The following contributors got their Debian Developer accounts in the last two months:
The following contributors got their Debian Developer accounts in the last two months:
gitlab-foss and gitlab-ee,
but whatever). CE was taking up roughly 1GB and EE was taking up the
rest.
So I deleted both repos, which means that the next time I want to
contribute a fix to their documentation which is as far as I managed
to contribute to GitLab I will need to re-fork those humongous
repositories.
Maybe I'm reading this wrong. Maybe there's a bug in the quotas
system. Or, if I'm reading this right, GitLab is actually
double-billing people: once for the source repository, and once for
the fork. Because surely repos are not duplicating all those blobs
on disk... right? RIGHT?
Either case, that's rather a bad move on their part, I feel like. With
GitHub charging 4$/user/month, it feels like GitLab is going to
have to trouble to compete by charging 20$/user/month as a
challenger...
(Update: as noted in the comments by Jim Sorenson, this is actually an
issue with older versions of GitLab. Deleting and re-forking the repos
will actually fix the issue so, in a way, I did exactly what I
should. Another workaround is to run the housekeeping jobs on the
repo, although I cannot confirm this works myself.)
But maybe it's just me: I'm not an economist, surely there's some
brilliant plan here I'm missing...
In the meantime, free-ish alternatives include Quay.io (currently
free for public repos) and sr.ht (2$/mth, but at least not
open-core, unfortunately no plan for a container registry). And
of course, you can painfully self-host GitLab, sr.ht, gitea,
pagure, or whatever it is the current fancy gitweb.
tar and of all of the compression tools (gzip, bzip2, xz) and by what exact options were used when creating the original tarballs. Because of this, pristine-tar currently has a few embedded copies of old versions of compressors to be able to reconstruct tarballs produced by them, and also rely on a ever-evolving patch to tar that is been carried in Debian for a while.
So basically keeping pristine-tar working is a game of Whac-A-Mole. Joey provided a good summary of the situation when he orphaned pristine-tar.
Going forward, we may need to rely on other ways of ensuring integrity of upstream source code. That could take the form of signed git tags, signed uncompressed tarballs (so that the compression doesn t matter), or maybe even a different system for storing actual tarballs. Debian bug #871806 contains an interesting discussion on this topic.
Recent improvements
Even if keeping pristine-tar useful in the long term will be hard, too much of Debian work currently relies on it, so we can t just abandon it. Instead, we keep figuring out ways to improve. And I have good news: pristine-tar has recently received updates that improve the situation quite a bit.
In order to be able to understand how better we are getting at it, I created a "visualization of the regression test suite results. With the help of data from there, let s look at the improvements made since pristine-tar 1.38, which was the version included in stretch.
pristine-tar 1.39: xdelta3 by default.
This was the first release made after the stretch release, and made xdelta3 the default delta generator for newly-imported tarballs. Existing tarballs with deltas produced by xdelta are still supported, this only affects new imports.
The support for having multiple delta generator was written by Tomasz, and was already there since 1.35, but we decided to only flip the switch after using xdelta3 was supported in a stable release.
pristine-tar 1.40: improved compression heuristics
pristine-tar uses a few heuristics to produce the smaller delta possible, and this includes trying different compression options. In the release Tomasz included a contribution by Lennart Sorensen to also try the --gnu, which gretly improved the support for rsyncable gzip compressed files. We can see an example of the type of improvement we got in the regression test suite data for delta sizes for faad2_2.6.1.orig.tar.gz:
pristine-tar 1.41: support for signatures
This release saw the addition of support for storage and retrieval of upstream signatures, contributed by Chris Lamb.
pristine-tar 1.42: optionally recompressing tarballs
I had this idea and wanted to try it out: most of our problems reproducing tarballs come from tarballs produced with old compressors, or from changes in compressor behavior, or from uncommon compression options being used. What if we could just recompress the tarballs before importing then? Yes, this kind of breaks the pristine bit of the whole business, but on the other hand, 1) the contents of the tarball are not affected, and 2) even if the initial tarball is not bit by bit the same that upstream release, at least future uploads of that same upstream version with Debian revisions can be regenerated just fine.
In some cases, as the case for the test tarball util-linux_2.30.1.orig.tar.xz, recompressing is what makes it possible to reproduce the tarball (and thus import it with pristine-tar) possible at all:
In other cases, if the current heuristics can t produce a reasonably small delta, recompressing makes a huge difference. It s the case for mumble_1.1.8.orig.tar.gz:
Recompressing is not enabled by default, and can be enabled by passing the --recompress option. If you are using pristine-tar via a wrapper tool like gbp-buildpackage, you can use the $PRISTINE_TAR environment variable to set options that will affect any pristine-tar invocations.
Also, even if you enable recompression, pristine-tar will only try it if the delta generations fails completely, of if the delta produced from the original tarball is too large. You can control what too large means by using the --recompress-threshold-bytes and --recompress-threshold-percent options. See the pristine-tar(1) manual page for details.
The Debian project recently welcomed the first nine sponsors for Debconf15: credativ and sipgate as Gold sponsors, Google, Farsight Security, Inc., Martin Alfke / Buero 2.0 and Ubuntu as silver sponsors, and Logilab, Netways and Hetzner as Bronze-level.
But things have kept moving! The Matanel Foundation just committed to support DebConf15 as Gold-level sponsor, and Mirantis as Silver-level. So, at the time of writing this, we have 11 sponsors. We are very thankful for that!
The DebConf team aims to organize the Debian Conference as a self-sustaining event, despite its size and complexity (the Final Report for DebConf14 gives a good indication). The financial contributions by individuals, companies and organizations, as well as the support by our infrastructure sponsors, media partners, and volunteers, are pivotal to our success.
There are many different possibilities to support DebConf. If you know any company or organization that could be interested, don t hesitate to point them at our sponsorship brochure (also available in German) or tell us about any leads.
18.2. MPEG-4. MPEG-4 technology may be included with the software. MPEG LA, L.L.C. requires this notice: This product is licensed under the MPEG-4 visual patent portfolio license for the personal and non-commercial use of a consumer for (i) encoding video in compliance with the MPEG-4 visual standard ( MPEG-4 video ) and/or (ii) decoding MPEG-4 video that was encoded by a consumer engaged in a personal and non-commercial activity and/or was obtained from a video provider licensed by MPEG LA to provide MPEG-4 video. No license is granted or shall be implied for any other use. Additional information including that relating to promotional, internal and commercial uses and licensing may be obtained from MPEG LA, LLC. See http://www.mpegla.com. This product is licensed under the MPEG-4 systems patent portfolio license for encoding in compliance with the MPEG-4 systems standard, except that an additional license and payment of royalties are necessary for encoding in connection with (i) data stored or replicated in physical media which is paid for on a title by title basis and/or (ii) data which is paid for on a title by title basis and is transmitted to an end user for permanent storage and/or use, such additional license may be obtained from MPEG LA, LLC. See http://www.mpegla.com for additional details. 18.3. H.264/AVC. H.264/AVC technology may be included with the software. MPEG LA, L.L.C. requires this notice: This product is licensed under the AVC patent portfolio license for the personal use of a consumer or other uses in which it does not receive remuneration to (i) encode video in compliance with the AVC standard ( AVC video ) and/or (ii) decode AVC video that was encoded by a consumer engaged in a personal activity and/or was obtained from a video provider licensed to provide AVC video. No license is granted or shall be implied for any other use. Additional information may be obtained from MPEG LA, L.L.C. See http://www.mpegla.com.Note the requirement that the videos created can only be used for personal or non-commercial purposes. The Sorenson Media software have similar terms:
With respect to a license from Sorenson pertaining to MPEG-4 Video Decoders and/or Encoders: Any such product is licensed under the MPEG-4 visual patent portfolio license for the personal and non-commercial use of a consumer for (i) encoding video in compliance with the MPEG-4 visual standard ( MPEG-4 video ) and/or (ii) decoding MPEG-4 video that was encoded by a consumer engaged in a personal and non-commercial activity and/or was obtained from a video provider licensed by MPEG LA to provide MPEG-4 video. No license is granted or shall be implied for any other use. Additional information including that relating to promotional, internal and commercial uses and licensing may be obtained from MPEG LA, LLC. See http://www.mpegla.com. With respect to a license from Sorenson pertaining to MPEG-4 Consumer Recorded Data Encoder, MPEG-4 Systems Internet Data Encoder, MPEG-4 Mobile Data Encoder, and/or MPEG-4 Unique Use Encoder: Any such product is licensed under the MPEG-4 systems patent portfolio license for encoding in compliance with the MPEG-4 systems standard, except that an additional license and payment of royalties are necessary for encoding in connection with (i) data stored or replicated in physical media which is paid for on a title by title basis and/or (ii) data which is paid for on a title by title basis and is transmitted to an end user for permanent storage and/or use. Such additional license may be obtained from MPEG LA, LLC. See http://www.mpegla.com for additional details.Some free software like Handbrake and FFMPEG uses GPL/LGPL licenses and do not have any such terms included, so for those, there is no requirement to limit the use to personal and non-commercial.
The recent update by S ren H jsgaard's to
his gRbase
package for graphical models made it the 75th package to depend on our
Rcpp package for R
and C++ integration. So in a lighthearted weekend moment, I
tweeted about gRbase being number 75 for Rcpp
to which Hadley replied, asking if Rcpp was in
fact number one among R package Depends.
Far from it, and I immediately replied listing lattice and
Matrix as packages with way more other packages depending upon them.
But as the question seemed deserving of a bit more analysis, I spent a few minutes
on this and prepared three charts listing package in order of reverse
Depends, reverse Imports and reverse LinkingTo.
First off, the reverse Depends:. This is the standard means of
declaring a dependence of one package upon another.
Unsurprisingly, the MASS package from the
classic Venables and Ripley
book comes first, with Deepayan Sarkar's powerful
lattice package (also
covered in a
book)
coming second. These are both recommended packages which are commonly distributed with R itself.
Next are mvtnorm
and
survival. Our
Rcpp is up there in
the top-ten, but not a frontrunner.
With the advent of namespaces a few R releases ago, it became possible to
import functions from other packages. So the Imports: statement
now provides an alternative to the (older) Depends:. The next
chart displays the same relationship for Imports::
Now
lattice still leads,
but
Hadleys's plyr package
grabbed the second spot just before
MASS and
Matrix.
It is interesting to see that the sheer number of Imports: is
still not where the Depends: are. On the other hand, we see a
number of more recent packages popping up in the second chart. This may
reflect more recent coding practices. It will be interesting to see how this
stacks up over time when we revisit this chart.
Lastly, we can also look at LinkingTo:, a declaration used to
provide a C/C++-level dependency at the source code level. We use
this in the
Rcpp family to
provide automatic resolution of the header files needed to compile against
our packages. And unsurprisingly, because packages using
Rcpp
actually use its API (rather than R functions), the package is a little ahead
of others. In the package we find three more packages of the
Rcpp
family, but only a limited number of other packages as
C/C++-level dependencies are still somewhat rare in the R universe.
There are also fewer packages overall making use of this mechanism.
One could of course take this one level further and sum up dependencies in a
recursive manner, or visualize the relationship differently. But these
dotchart graphs provide a first visual description of the
magnitude of Depends, Imports and
LinkingTo among CRAN packages for R.
Recently the upstream Linux kernel released a fix for a serious security vulnerability (CVE-2012-0056) without coordinating with Linux distributions, leaving a window of vulnerability open for end users. Luckily:
$ make correct_proc_mem_reproducer ... $ ./correct_proc_mem_reproducer vulnerable
# apt-get install -y systemtap linux-image-$(uname -r)-dbg
$ sudo apt-get install -y lsb-release
$ echo "deb http://ddebs.ubuntu.com/ $(lsb_release -cs) main restricted universe multiverse" \
sudo tee -a /etc/apt/sources.list.d/ddebs.list
$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys ECDCAD72428D7C01
$ sudo apt-get update
sudo apt-get install -y systemtap linux-image-$(uname -r)-dbgsym
$ sudo apt-get install -y systemtap dpkg-dev $ wget http://ddebs.ubuntu.com/pool/main/l/linux/$(dpkg -l linux-image-$(uname -r) grep ^ii awk ' print $2 "-dbgsym_" $3 ' tail -n1)_$(dpkg-architecture -qDEB_HOST_ARCH).ddeb $ sudo dpkg -i linux-image-$(uname -r)-dbgsym.ddeb
$ cat > proc-pid-mem.stp <<'EOM'
probe kernel.function("mem_write@fs/proc/base.c").call
$count = 0
EOM
$ sudo stap -Fg proc-pid-mem.stp
$ ./correct_proc_mem_reproducer not vulnerable
$count = 0), which effectively closes this vulnerability.
UPDATE: here s a systemtap script from Soren that doesn t require the full debug symbols. Sneaky, put can be rather slow since it hooks all writes in the system. :)
2012, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
People are using computers, everywhere, really! ;)dorei, running Debian GNU/Linux screen -rd, -r for reattach a running screen session, -d for detach it if it is already attached somewhere else. Or I can start a new session by just typing screen. Inside the screen I have multiple windows (one can create new ones with ^A c) with all the needed software running. I can switch windows by pressing ^A N, N being the number of the window, ^A n for the next window, ^A p for the previous one or ^A ^a for the last one. Or I can get a window-list with ^A w. If needed, I can rename windows with ^A A, followed by the new name. That should be enough for almost everyone. Let s just add a window-list to the bottom (as you might have seen on GNOME, Xfce, KDE and even Windows ;) by adding the following to the ~/.screenrc:caption always " " # clear line before hardstatus hardstatus alwayslastline "% = kb [ % B %H:$USER % b ][ %=% w %?%-Lw%?% b (% W %n*%f %t%?(%u)%?% b )% w %?%+Lw%?%?%= % b ][% B %l % B % W %d.%0m % b ]"You get the current host- and username, the machine load and the date for free ;)Even if it is possible, I do not have any autostart like stuff in my
.screenrc as the machine is running stable and I start the screen and the apps inside maybe once a year after a reboot.screenrcMy .screenrc looks like this:# detach on hangup autodetach on # don't display the copyright page startup_message off # set scrollback to 2000 lines, default 100 defscrollback 2000 # set silencewait to 15 seconds, default 30 silencewait 15 # new shells should be started as login-shells shell -$SHELL # make a fancy statusline caption always " " # clear line before hardstatus hardstatus alwayslastline "% = kb [ % B %H:$USER % b ][ %=% w %?%-Lw%?% b (% W %n*%f %t%?(%u)%?% b )% w %?%+Lw%?%?%= % b ][% B %l % B % W %d.%0m % b ]" # make higlighting bold, black on blue background sorendition +b bk # some fixes, no I do not know where they come from :) termcap xterm hs@:cs=\E[%i%d;%dr:im=\E[4h:ei=\E[4l terminfo xterm hs@:cs=\E[%i%p1%d;%p2%dr:im=\E[4h:ei=\E[4l termcapinfo xterm Z0=\E[?3h:Z1=\E[?3l:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l termcapinfo xterm* OL=100 termcapinfo xterm 'VR=\E[?5h:VN=\E[?5l' termcapinfo xterm 'k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~' termcapinfo xterm 'kh=\EOH:kI=\E[2~:kD=\E[3~:kH=\EOF:kP=\E[5~:kN=\E[6~' termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007' termcapinfo xterm 'vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l' termcapinfo xterm 'XC=K%,%\E(B,[\304,\\\\\326,]\334, \344, \366, \374,~\337' termcapinfo xterm* be termcapinfo xterm xterms xs ti@:te=\E[2J termcapinfo wy75-42 xo:hs@ termcapinfo wy* CS=\E[?1h:CE=\E[?1l:vi=\E[?25l:ve=\E[?25h:VR=\E[?5h:VN=\E[?5l:cb=\E[1K:CD=\E[1J termcapinfo hp700 'Z0=\E[?3h:Z1=\E[?3l:hs:ts=\E[62"p\E[0$~\E[2$~\E[1$ :fs=\E[0 \E[61"p:ds=\E[62"p\E[1$~\E[61"p:ic@' termcap vt100* ms:AL=\E[%dL:DL=\E[%dM:UP=\E[%dA:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC terminfo vt100* ms:AL=\E[%p1%dL:DL=\E[%p1%dM:UP=\E[%p1%dA:DO=\E[%p1%dB:LE=\E[%p1%dD:RI=\E[%p1%dC termcapinfo linux C8 # some bindings bind k bind ^k bind . bind ^\ bind \\ bind ^h bind h bind 'w' windowlist -b bind 'W' windows bind 'K' kill bind 'I' login on bind 'O' login off bind ' ' history bind = resize = bind + resize +3 bind - resize -3 # Mutt demands this # http://wiki.mutt.org/?MuttFaq/Appearance defbce on term screen-bceThat s all for my screen setup. The obvious, boring screenshot follows:
See you next time, when I will present my mutt setup here.--architecture flag on to cowbuilder and pbuilder.
update, create, or login, pass
any additional arguments to cowbuilder. Patch from Svend Sorensen.
Once there was a project called Debian and a Ganneff.... (unfortunately in German only....)
22:20 < cb> Das ist doch voll die Arbeit Maintainer zu werden :-). Ich geb gew nschte Pakete immer nur weiter an einen der da sowieso schon den Kernel betreut :-) 22:21 < Ganneff> es is nur viel arbeit wenn du keinen schimmer hast 22:22 < cb> ja ich hab nur das seepferdchen *g* 22:22 < Obilan> Knusper: ja sicher ist es das 22:22 < Knusper> kopf -> tisch 22:22 < cb> Knusper, wenn du die verwaisten pakete findest siehst du auf der gleichen seite auch die links wie man maintainer wird 22:22 < Knusper> die hab ich gefunden 22:22 < cb> zumindest hab ich das das letzte mal dort gesehen 22:24 < Ganneff> wnpp? 22:24 < Knusper> aber man brauch dann schon leute, die einen "hoffieren" 22:26 < Ganneff> du brauchst erstmal die ahnung nen paket zu bauen. 22:26 < Ganneff> dazu siehe new maint guide 22:26 < Ganneff> dann brauchste nen sponsor. dazu gehe zur mentors liste 22:26 < Ganneff> dann machste mit dem eh weng rum (also normal so paketuploads via dem) 22:26 < Ganneff> und hast da halt schon dein maintenance krams. 22:27 < Ganneff> irgendwann is der sponsor angekotzt von dir und dem laufenden arbeit generieren 22:27 < Ganneff> der tritt dich dann dass du mal DM anf ngst. 22:27 < Ganneff> das machste dann, und jemand anders tritt dir deine pakete als dmua zurecht, nachdem du in nem keyring irgendwo steckst. 22:27 < Ganneff> und dann kannste denn krampf selbst hochladen. aber nix andres. 22:27 < Ganneff> irgendwann willste was andres. und willst das auch noch ohne son doofen sponsor 22:28 < Ganneff> dann versuchste dich an DD 22:28 < Knusper> ahhhhhh 22:28 < Ganneff> dazu musste dir nen advocate suchen 22:28 < Ganneff> der is blicherweise einer dem du vorher im prozess laufend auf den wecker fielst 22:28 < Ganneff> und er deswegen den nm leutz sagt "oh gott, befreit mich bloss von dem" 22:28 < Ganneff> die machen das dann, aber sie wollen dir mal etwas schmerzen zur ckgeben 22:28 < Ganneff> desdewegen wirste viele fragen beantworten m ssen 22:29 < Ganneff> und wie beim t v das auto musste hier deine pakete nochmal vorstellen und checken lassen 22:29 < Ganneff> und dann nochmal fragen beantworten 22:29 < Knusper> thx... 22:29 < Ganneff> irgendwann gehst du dann mit den antworten den nm leuten so auf den geist dass die dem frontdesk sagen "meine kacke, den wolle mehr nit mehr sehen, schickts den dochma zu den DAMs, die hamms verdient" 22:30 < Ganneff> und die machen das dann meist. ausser sie m gen dich nich. dann darfste nochma fragen beantworten 22:30 < Ganneff> bei den dams darfste nur warten. die testen deine geduld 22:30 < Ganneff> irgendwann langweilen die sich aber 22:30 < Ganneff> und dann kriegste pl tzlich mail 22:30 < Ganneff> OH MEIN GOTT. EIN NEUER DD. 22:30 < Ganneff> ende 22:30 < Ganneff> kapitel 2: 22:30 < cb> sch ne beschreibung 22:30 < Ganneff> du machst ne zeit als dd rum 22:30 < Knusper> LOL 22:30 < Ganneff> votest durch die gegend 22:30 < Ganneff> l dst pakete umher 22:30 < Ganneff> machst bugs in stable 22:30 < Ganneff> gibts dem security team arbeit 22:31 < Ganneff> sprich - du gehst allen auf den sack. denn das is was ein dd macht. muss ja schliesslich auch spass machen. 22:31 < Ganneff> aber irgendwann, also irgendwann, da wird das langweilig 22:31 < Ganneff> und dann verschwindeste mal ne zeit. 22:31 < Ganneff> weil du weisst - da gibts noch son team. das brauch auch arbeit 22:31 < Ganneff> die suchen so leute die weggehen und sich verstecken 22:31 < Ganneff> nennt sich mia. die suchen. 22:31 < Ganneff> vielleicht finden die dich ja auch. 22:32 < Ganneff> dann kommste zur ck und machst mal wieder etwas arbeit f r security/stable/sonstwen 22:32 < Ganneff> oder nicht, aber das is langweilig, da fliegste einfach. 22:32 < Ganneff> wennde dann gar keinen bock mehr hast und ne l ngre pause willst 22:32 < Ganneff> dann gehste und machst eien auf emeritus 22:32 < Ganneff> das sind die rentner, die alten s cke, die sich zur cklehnen und ber die versuche der neuen lachen die sich grad von den sponsoren qu len lassen 22:33 < Ganneff> ende kap. 2, ich hab keinen bock mehr. (jaja, emeritus)Cheers to #debian.de on freenode
I just uploaded nvidia-graphics-drivers 180.44 that work with Debian's 2.6.29 thanks to package team member Len Sorensen. If anyone wants to be as amazing as Len you may join the packaging team too. I've uploaded the amd64 version of the current drivers tonight. I'll test the i386 version tomorrow and upload if it works as well. I'd like to thank my team member, Len Sorensen who did a lot of work on this release.
I'm pleased to announce Lennart Sorensen has joined the Debian NVIDIA Maintainers packaging team.