debian-it/ubuntu-it miniconf @ software freedom day 2010
Cari tutti,
ho incontrato di recente Paolo Sammicheli (in copia) che si occupa di
organizzare la presenza della comunità Ubuntu-it al prossimo software
freedom day, il 18 Settembre 2010 a Perugia.
Una possibilità interessante che si è discussa assieme, è quella di
avere un evento congiunto debian/ubuntu mini-conference in seno a tale
manifestazione. A mio avviso, l'interesse della comunità di debian-it a
farlo è molteplice:
- per un motivo o per l'altro, da qualche anno non siamo più riusciti a
rifare la DCC-IT, magari unendo le forze abbiamo un po' più di massa
critica organizzativa
- a livello di comunità territoriali, non mi sembra abbia molto senso
fare i separatisti, dato che ci sono molti interessi comuni
- credo Ubuntu-it sia un buon terreno di caccia (Paolo: perdonami :))
per acchiappare nuovi sviluppatori Debian: la mia esperienza è che la
comunità Ubuntu è più che sensibile ai valori di Debian, serve solo
che li conosca di più, magari conoscendo di più i suoi sviluppatori
La domanda per questa lista è quindi: ci interessa? Se si organizziamo
un evento Debian-Ubuntu Community Conference - Italia (nome tirato a
caso in quel momento) @ Perugia, 18/9/2010. Se no ognun per se (a quel
punto però, se ci salta di nuovo la DCC-IT si che facciamo la figura dei
cioccolatai!).
Nel caso la cosa interessi, ecco i dettagli logistici che grazie a Paolo
abbiamo già recuperato:
- quando: domenica 18 settembre 2010
- dove: Perugia (I.T.C. Aldo Capitini - Vittorio Emanuele Secondo)
- spazi: 2 aule (una per talk, una a-la hacklab)
- logistica (mia proposta): una mezza giornata di talk (30 min max) +
una mezza giornata di hacking; l'interesse della seconda parte secondo
me è principalmente skill exchange, e.g.: Debianisti che spiegano a
Ubuntisti come richiedere sponsoring e/o usare alioth, Ubuntisti che
spiegano a Debianisti come chiedere sync dei propri pacchetti, etc.
Magari si fa pure un BSP/HugDay congiunto.
Nel caso la cosa interessi, non sarebbe male se trovassimo un volontario
Debian-side disposto a coordinare la cosa assieme a Paolo
(Ubuntu-side). Io getto il sasso e tolgo la mano, 'gn posso fare.
Grazie per l'attenzione,
a presto.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: debian-it/ubuntu-it miniconf @ software freedom day 2010
On May 26, Stefano Zacchiroli z...@debian.org wrote: La domanda per questa lista è quindi: ci interessa? Se si organizziamo Mi interesserebbe, ma chi è già stato a Perugia sa bene che bisogna fare un viaggio discretamente impegnativo per arrivarci in treno. Io quindi mi defilo, anche perché a fine settembre spero ancora di potere andare al mare... :-) -- ciao, Marco signature.asc Description: Digital signature
Re: RFH: bashisms in configure script
Hi, I'm still feeling uneasy about this whole bash-dash thing. We sacrified a lot of usability in the name of POSIX compliance (only a minority of users care) and a few seconds spared during boot (who cares? I only boot my laptop for kernel upgrades). Was is really the right path to follow? Wouldn't it have been easier to work on bash to make sure that it supports everything POSIX requires, and to improve its performance a bit? Now we are going to patch configure scripts to make sure that they can run correctly with dash. What's next? Rewrite C programs that use GCC-specific extensions? -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526060532.ga9...@xanadu.blop.info
Re: RFH: bashisms in configure script
On 25/05/10 at 23:10 +0100, Neil Williams wrote: On Tue, 25 May 2010 16:13:36 -0500 Raphael Geissert geiss...@debian.org wrote: A much more sane list is in the bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=45;filename=failed-dash.txt;att=1;bug=582952 124 source packages. Bad, but not as crazy as 1,540. (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) No. 124 is the number of packages that failed to build. Not the number of source packages that silently generated incorrect binary packages. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526060740.gb9...@xanadu.blop.info
Re: RFH: bashisms in configure script
On Tue, 25 May 2010, Peter Samuelson wrote:
And more false positives:
possible bashism in ./configure line 44 ($BASH_SOMETHING):
if test -z $BASH_VERSION$ZSH_VERSION \
(test X`print -r -- $as_echo` = X$as_echo) 2/dev/null; then
possible bashism in ./configure line 367 (should be word 21):
$as_echo $as_me:${as_lineno-$LINENO}: error: $1 $3
Both were produced by autoconf 2.65.
First is a false positive for the same reason Kurt's example is.
Second is a false positive because $3 in this instance is a numbered
file descriptor.
Same goes for dpkg, it only has those two warnings.
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100526062150.ga16...@rivendell
Re: RFH: bashisms in configure script
On 05/26/2010 08:05 AM, Lucas Nussbaum wrote: Hi, I'm still feeling uneasy about this whole bash-dash thing. We sacrified a lot of usability in the name of POSIX compliance (only a minority of users care) and a few seconds spared during boot (who cares? I only boot my laptop for kernel upgrades). Many desktop users boot regulary, besides if you have a difficult to reach SLA, it's nice to have a fast boot... Was is really the right path to follow? Wouldn't it have been easier to work on bash to make sure that it supports everything POSIX requires, and to improve its performance a bit? Now we are going to patch configure scripts to make sure that they can run correctly with dash. What's next? Rewrite C programs that use GCC-specific extensions? Making sure they run correctly with dash is one solution, making sure they run with bash is another one... Regarding C, that's kind of happening with gcc becoming more and more compliant with the standard... Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfcbf41.5060...@debian.org
Re: RFH: bashisms in configure script
On mar., 2010-05-25 at 19:35 -0500, Raphael Geissert wrote:
./configure is a *generated* script too, if dash cannot handle it, dash
has to be crippled to let the other packages continue working. Unless
autoconf itself has already been patched to fix all of these issues when
regenerating ./configure from configure.ac, all this would be a waste
of effort anyway.
It is not about whether dash can handle it or not. The bashisms don't come
from autoconf, the come from what the author's added to configure.in{,.in}.
I beg to differ, at least some of them don't come from configure.*. One
example is
http://people.debian.org/~geissert/source-bashisms/evolution_2.30.1.2-2.dsc
where I can't really fine the $3 call (nor any for that matter) in the
configure.* files.
And here, just a quick test shown that:
cor...@hidalgo: grep -c '' /usr/share/*/config.{guess,sub}
/usr/share/automake-1.11/config.guess:13
/usr/share/automake-1.7/config.guess:13
/usr/share/misc/config.guess:13
/usr/share/automake-1.11/config.sub:5
/usr/share/automake-1.7/config.sub:5
/usr/share/misc/config.sub:5
cor...@hidalgo: dpkg -S /usr/share/*/config.{guess,sub}
automake: /usr/share/automake-1.11/config.guess
automake1.7: /usr/share/automake-1.7/config.guess
autotools-dev: /usr/share/misc/config.guess
automake: /usr/share/automake-1.11/config.sub
automake1.7: /usr/share/automake-1.7/config.sub
autotools-dev: /usr/share/misc/config.sub
Interestingly, they don't seem to be caught by checkbashisms (maybe I
still have a non working version?)
cor...@hidalgo: checkbashisms /usr/share/*/config.{guess,sub}
possible bashism in /usr/share/automake-1.11/config.guess line 95 (trap with
signal numbers):
trap 'exit 1' 1 2 15
possible bashism in /usr/share/automake-1.7/config.guess line 95 (trap with
signal numbers):
trap 'exit 1' 1 2 15
possible bashism in /usr/share/misc/config.guess line 95 (trap with signal
numbers):
trap 'exit 1' 1 2 15
Cheers,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
Re: RFH: bashisms in configure script
On mer., 2010-05-26 at 08:29 +0200, Yves-Alexis Perez wrote:
It is not about whether dash can handle it or not. The bashisms
don't come
from autoconf, the come from what the author's added to
configure.in{,.in}.
I beg to differ, at least some of them don't come from configure.*.
One
example is
http://people.debian.org/~geissert/source-bashisms/evolution_2.30.1.2-2.dsc
where I can't really fine the $3 call (nor any for that matter) in the
configure.* files.
Ok, sorry, didn't see earlier in the thread that it was a false
positive.
Cheers,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
Re: The story behind UPG and umask.
This one time, at band camp, Steve Langasek said: On Tue, May 25, 2010 at 11:30:49PM +0100, Stephen Gran wrote: This one time, at band camp, Michael Banck said: Seems worthwhile to change adduser how you suggest to me, is there a bug filed to this end? adduser has had bugs filed in the past asking for uid to be equal to gid by default, and I have so far rejected them as not worth the complexity for the aesthetic pleasure of having numbers match. Is there some problem with username == primary group name? pam_umask requires both username == primary group name and uid == gid before it will assume UPG are in place when using its 'usergroups' option, and I am not willing to diverge from upstream on this as this would mean admins coming from other systems may get an unpleasant surprise when they find that Debian gives a more relaxed umask than they were expecting in some corner cases. So either someone should convince Linux-PAM upstream to change the behavior of pam_umask, or adduser should enforce the same rules as other implementations, if pam_umask is to be involved here. Beyond that, I have no particular opinion on this question. That's the first useful argument I've heard for changing adduser's behavior. Interoperability with other software is a useful goal, and when I was arguing it wasn't worth the complexity, either pam_umask didn't exist or I was unaware of it. I'll try to get this change into squeeze. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Ludovic Brenta wrote:
Over the last two weeks I have been testing upgrades of
Ada packages from Lenny to Sid and Squeeze in a chroot.
The picture is not as pretty as it should be. In a
nutshell, when you change /etc/apt/sources.list from lenny
to squeeze (unstable, actually) and do aptitude update,
you end up with a lot of broken packages and must
intervene manually to resolve the problem (i.e. remove the
broken packages, install new versions).
A long-term, partial solution is to introduce a
build-essential-ada package, which depends on gnat and all
the current development packages. That would also make it
quicker to prepare a new system for developing Ada programs.
(As a teacher, it is a package I have missed a lot.)
In the case of libgnat{vsn,prj}4.3-dev, this is only
because I recently added dummy transition packages,
libgnat{vsn,prj}-dev in gnat-4.4 (= 4.4.4-4).
Could you create such dummy transition packages for all
development packages? (Again only a long-term solution.)
I think a short-term solution might be to make gnat suggest
the new versions of the development packages. (Or the
above-mentioned transition packages?)
Greetings,
Jacob
--
There are only two types of data:
Data which has been backed up
Data which has not been lost - yet
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/alpine.deb.1.10.1005260705510.8...@munin.nbi.dk
Re: RFH: bashisms in configure script
This doesn't necessarily mean that we are drowned by bashisms, as some of those may already be fixed by Debian- provided packages or might affect unused code s/packages/patches/ Don't you think we should run the test *after* the patches got applied? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005261000.58635.mes...@debian.org
extlinux (was: Re: lilo removal in squeeze (or, please test grub2))
Daniel Baumann dan...@debian.org writes: as of current git, you can now use EXTLINUX_UPDATE=false in /etc/default/extlinux to prevent having update-extlinux do anything. That's the single feature I misseded. Thanks. Although it would be even better if it was possible to include some fixed part in it, while keeping most of it auto updated. I tested the extlinux package after reading about it yesterday, and the missing feature that immediately hit me was the ability to use a serial console. This is of course as easy as with sys-/pxe-/mem-linux: just add serial 0 9600 0 or something similar to the config file. But running update-extlinux would remove it on every kernel upgrade. Anyway, I understand that this issue is now solved. It has puzzled me for a while that grub2 has been chosen over extlinux as the default x86 bootloader, but didn't know until this discussion came up that extlinux now was packaged separately from syslinux, with the nice helper scripts. I guess we all know syslinux and pxelinux very well from Linux installation procedures over the last 15 years (for syslinux at least), and HPA has been an active upstream maintainer all this time AFAIK. This makes me very confident in extlinux. While grub2 has already bitten me too much to be considered at all on the important boxes... Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more than enough information to choose extlinux over grub2 Thanks a lot for packaging extlinux! Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4qrjbk2.fsf...@nemi.mork.no
Re: extlinux (was: Re: lilo removal in squeeze (or, please test grub2))
Bjørn Mork, le Wed 26 May 2010 10:45:49 +0200, a écrit : Just comparing http://git.kernel.org/?p=boot/syslinux/syslinux.git with http://bzr.savannah.gnu.org/r/grub/trunk/grub/ should IMHO give more than enough information to choose extlinux over grub2 I don't understand what you mean here. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526085116.gw5...@const.bordeaux.inria.fr
Re: Translations copyrights/licences
Hello, On Tue, May 25, 2010 at 06:41:09PM +0100, Darren Salt wrote: I demand that Helge Kreutzmann may or may not have written... Speaking both with my translator and my Debian Maintainer hat on, I can state the following: a) There are lots of drive by translators. Systems like launchpad or DDTP even *encourage* this. In this case, it is most likely not possible at all to contact individual translators. b) In structured projects (Debian, Fedora, OOo, KDE, GNOME) there are often language teams. In this case, translations are often channeled via the team. So if you want, you can try to collect the names in the copyright, but a team adress is more valuable. To me, this all doesn't matter so long as who changed what is recorded and I can get (or generate) a series of diffs which I can then commit where appropriate. If I can't, then I'm not really interested. From my experience the workflow is as follows: Either the Last Translator or someone else notices or becomes noticed that a translation is out of date. She then updates it (or asks on the list for an update), the translation is reviewed (more or less formally) and in the end the translation is sent to the package / upstream. Hopefully the copyright statements in the header are updated, and the Last Translator address is working. If the Last Translator actually was the last translator I'm not always sure, he might be the language coordinator or the field might simply not be up to date anymore. The German team takes both license as well as Last Translator seriously. So if you are in doubt, contact the mentioned translation list (which unfortunately might be out of sync as well). In essence: Take the translation and the Last Translator for your records as stated. There is not much more you can do if you don't want to go into the nitty gritty details of each language team. (I personally ask the submitter, however, if the headers are obviously wrong, but I don't believe this scales if you happen to have lots of translations). Greetings Helge -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 11:55:58PM +0200, Frans Pop wrote: For example, almost all udebs are listed. Why? Because udebs execute busybox shell as /bin/sh, which happens to be fairly compatible with bash. The busybox /bin/sh is also a dash, but a different version than the dash package. Bastian -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526091546.ga14...@wavehammer.waldi.eu.org
Re: RFH: bashisms in configure script
On 26/05/10 08:07, Lucas Nussbaum wrote: On 25/05/10 at 23:10 +0100, Neil Williams wrote: 124 source packages. Bad, but not as crazy as 1,540. (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) No. 124 is the number of packages that failed to build. Not the number of source packages that silently generated incorrect binary packages. Right. That's exactly why I suggested debdiffing the resulting binary packages from a new and an old dash. Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfcf029.4040...@debian.org
Re: RFH: bashisms in configure script
On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote: On 26/05/10 08:07, Lucas Nussbaum wrote: On 25/05/10 at 23:10 +0100, Neil Williams wrote: 124 source packages. Bad, but not as crazy as 1,540. (I've heard of off-by-one errors but off-by-one-order-of-magnitude is a stretch.) No. 124 is the number of packages that failed to build. Not the number of source packages that silently generated incorrect binary packages. Right. That's exactly why I suggested debdiffing the resulting binary packages from a new and an old dash. Are you volunteering? :-) Just debdiffing doesn't work, since some source packages generate different things by design (think of html converters that generate random identifiers for html and images). Generally, I am interested in the idea of comparing rebuild results to find problems (not only old dash vs new dash, but also current archive vs freshly rebuilt). But I don't have the time to work on that myself. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526111416.ga19...@xanadu.blop.info
Re: RFH: bashisms in configure script
On 26/05/10 13:14, Lucas Nussbaum wrote: On 26/05/10 at 11:55 +0200, Emilio Pozuelo Monfort wrote: Right. That's exactly why I suggested debdiffing the resulting binary packages from a new and an old dash. Are you volunteering? :-) No. I'm not volunteering on adding LINENO support back to dash either though :-) Emilio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd04a9.2070...@debian.org
Bug#583207: RFA: fusecompress -- transparent filesystem compression using FUSE
Package: wnpp Severity: normal I request an adopter for the fusecompress package. Overall the packaging is in pretty good shape. There are a couple of bugs (forwarded upstream) that need some love. Upstream also has support for lzma in the git repo but I have not bothered backporting that. The package description is: FuseCompress provides a mountable Linux filesystem which transparently compress its content. Files stored in this filesystem are compressed on the background and Fuse allows to create a transparent interface between compressed files and user applications. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526113145.15288.79161.report...@champaran.hq.netapp.com
Bug#583209: ITP: haskell-smtpclient -- Simple Haskell SMTP client library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: mascell...@poisson.phc.unipi.it Package name: haskell-smtpclient Version: 1.0.2 Upstream Author: Stephen Blackheath URL: http://hackage.haskell.org/package/SMTPClient License: BSD Description: Simple Haskell SMTP client library This Haskell library is a simple SMTP client, making the task of sending an email as easy as calling a function. Rationale: it is a dependency of happstack (bug #569501). Regards, Giovanni. -- Giovanni Mascellani mascell...@poisson.phc.unipi.it Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD 003F FCB0 BB5C 5F1F BF70) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7760e8bf9f0ba4baed83f1c20231e...@poisson.phc.unipi.it
Re: The story behind UPG and umask.
On Wed, May 26, 2010 at 08:40:26AM +0100, Stephen Gran wrote: This one time, at band camp, Steve Langasek said: On Tue, May 25, 2010 at 11:30:49PM +0100, Stephen Gran wrote: This one time, at band camp, Michael Banck said: Seems worthwhile to change adduser how you suggest to me, is there a bug filed to this end? adduser has had bugs filed in the past asking for uid to be equal to gid by default, and I have so far rejected them as not worth the complexity for the aesthetic pleasure of having numbers match. Is there some problem with username == primary group name? pam_umask requires both username == primary group name and uid == gid before it will assume UPG are in place when using its 'usergroups' option, and I am not willing to diverge from upstream on this as this would mean admins coming from other systems may get an unpleasant surprise when they find that Debian gives a more relaxed umask than they were expecting in some corner cases. So either someone should convince Linux-PAM upstream to change the behavior of pam_umask, or adduser should enforce the same rules as other implementations, if pam_umask is to be involved here. Beyond that, I have no particular opinion on this question. That's the first useful argument I've heard for changing adduser's behavior. Interoperability with other software is a useful goal, and when I was arguing it wasn't worth the complexity, either pam_umask didn't exist or I was unaware of it. I don't agree with the upstream or Steve here. The UID==GID mapping breaks with just one call to addgroup which gets them out of sync. UIDs and GIDs are just a convenient mapping from the actual names to numbers; so long as they are constant and unique, the actual numerical values are unimportant. For UPG, comparing the names of the user and group makes sense; comparing the UID/GID does not. While interoperability is important, this UID==GID concept is not something we have ever guaranteed and makes little sense from a security POV--the name is the only part that matters. It's akin to arguing that the index offset into a table is more important than the content at that index. We also need to consider interoperability with ourselves, and the current pam_umask is broken on Debian systems where the numbers are not in sync. I'd be interested to understand the upstream POV here--with current Debian systems, assuming UID==GID without additionally checking that the names match is horribly insecure. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: RFH: bashisms in configure script
On mercredi 26 mai 2010 02:39:52 Raphael Geissert wrote: [SNIP] Yes, $BASH_SOMETHING is just used to make it easier to see that the following code (probably a bashism) is only executed after checking the shell is actually bash. That and the other FP are the most common ones, yet not that easy to fix (the latter, of course, the former is not a FP.) I'm seeing only these for gxine, xine-lib and xine-ui, which is slightly odd because testing with dash has shown up an actual bashism in xine-lib's configure.ac (which I've just fixed upstream): use of test x == y. Could you please send me by email the files with false negatives? those are very likely bugs in checkbashisms' quotes handling code. Among other false positive there is warning about scripts removed in clean target of debian/rules. Anyway, thanks for the massive run of checkbashism, it made me discover a few bashism in 2 upstream scripts in my packages. Thanks. Cheers, Best regards signature.asc Description: This is a digitally signed message part.
Bug#583215: ITP: haskell-cairo -- Binding to the Cairo library
Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-cairo Version : 0.11.0 Upstream Author : Axel Simon, Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : BSD3 Programming Lang: Haskell Description : Binding to the Cairo library This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . Cairo is a library to render high quality vector graphics. There exist various backends that allows rendering to Gtk windows, PDF, PS, PNG and SVG documents, amongst others. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526124833.3990.55818.report...@zezinho
Let's write a system admin friendly mail server packaging system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear everyone, 1/ Briefly, who am I My first Debian package was for the web hosting control panel (a web interface) that my company released in open source. I'm the main programmer of it. The first time I tried to have it enter in Debian, it created a huge controversy, with (I heard) a 70 post thread in -private after it got sponsored. The reason was that my package goal is to have an over-simplified system, so that the user of it doesn't have to touch anything to the system configuration, everything has to be automated (which is the goal of my app). In Debian, by policy, a package cannot touch another package's configuration file. While I believe this policy is a good one, but it prevented me from having my postinst to do a successful setup without breaking the policy. The result is that what should have been sent to the postinst of my package has then been sent to a userland script (with often, users not starting the script an complaining about it in my forum). It doesn't make this script less ugly if running in userland rather than in the maintainer scripts (it is REALLY an ugly script, and I'm quite not proud of it), but at least it respects the policy. As I am soon to become a Debian Developer (if the DAM accepts me, after my AM wrote his report), I believe it is now time to get even more involved in Debian, and try to solve that issue once and for all. Even if for a reason or another, I'm rejected (which I don't think will happen), I still want to start the below discussion. 2/ The problematic == What happens here is that, if you take a normal Debian system, then install postfix, then let's say amavis, they don't talk to each other. In the same way, if you add dkimproxy (that I maintain), or clamsmtp, or tumgreyspf (that I maintain as well), you end up with a system that is not configured at all. None of these mail server components are aware of each other, and a system administrator has to spend a great deal of time to make it work. Truth is, in today's world, it is totally unrealistic to believe that just postfix is enough for setting up a mail system. There's just too much spams. It is also totally unrealistic to say that it's up to the system administrator to configure everything by hand. If, like me, you do at least one setup a day, it takes too much time for no reason, and it has to be automated in some way. There's loads of howtos available in many places that describe in 10 pages or more how to have a successful setup. This is really a pain. This is the reason why I'm writing this today: I want to (with the help of other maintainer of the concerned packages, if they agree) change that fact. 3/ Goal description === In the ideal world, a command like this: apt-get install postfix-mysql clamav clamav-daemon clamav-freshclam spamassassin tumgreyspf would create a mail toaster with postfix and all the above apps configured correctly so that the mail system would do like this: 1- postfix gets a mail, does some basic domain checkings (domain MX existance, etc.) 2- postfix asks tumgreyspf to check for SPF and greylisting 3- (see later) 4- postfix forwards the email to amavis 5- amavis does clamav and spamassassin checks with header tagging 6- amavis forwards the email to postfix 7- postfix sends the email to maildrop for delivery Let's say now that I add dkimproxy, I would do: apt-get install dkimproxy and then the sequence would become: 3- postfix sends the email to dkimproxy for DKIM signature checkings 4- dkimproxy forwards the email to amavis I don't see any reason why it shouldn't be as easy to use as what I wrote above. The complexity of this kind of setup MUST be done on our side, and not rely on the system administrator knowledge. The above is what we currently use, but of course, this could be extended to DSPAM (I read it's better than spamassassin), clamsmtp, some milter checks, some alternative MDA, etc. And of course, this could be extended as well to other mail servers (exim4 anyone?). That's for the problematic. Now, how to achieve this, I'm not sure how to do it yet, but I have couples of ideas. 4/ Few ideas, and what I believe should happen == First thing we could do, would be a special postfix package that would have the above packages as dependency. Let's say we call it postfix-toaster, and it would have the configuration already made so that it would be already configured for using other packages. But that's not really idealistic, because of so many possibilities that we have. The second idea would be to have some kind of triggers, a bit like we have for generating the mandb and others. The trigger would ask the MTA scripts to do the reconfiguration process, for example, giving it as argument a list of packages that it should use. But the MTA is not the only one to modify here, for example we might have to change the
Re: lilo removal in squeeze (or, please test grub2)
On Wed, 26 May 2010 00:23:04 -0400 (EDT), Daniel Baumann wrote: On 05/26/2010 03:36 AM, Stephen Powell wrote: ... That works for now; but if a package upgrade for extlinux is ever downloaded, I'm afraid that new versions of the hook scripts will be copied into these directories which are marked executable, and my hand-made configuration file will get wiped out. ... as of current git, you can now use EXTLINUX_UPDATE=false in /etc/default/extlinux to prevent having update-extlinux do anything. That's good to know, thanks. I'm looking forward to that feature migrating into squeeze. Second, it is important that any script run as a hook script not produce any output at all to standard output. I found that out the hard way when I was writing my own hook scripts for use with lilo. That's because they run under debconf, which has redirected standard output for its own purposes. Thus, anything written to standard output is (1) never seen by the user and (2) has a good chance of messing up debconf, which is examining the output. The invocation of update-extlinux should have a redirection on it to redirect output to standard error. For example, update-extlinux 2 none of the hooks is doing this (initramfs-tools, grub, etc), might needs further convincing. It is a little-known requirement, and often you can get away with it, but not always. I'm going from memory here, but I believe that debconf redirects standard output, then calls the maintainer script for the kernel, which calls the run-parts utility, which then calls the hook script. If the standard output produced by the hook script matches something that debconf is looking for it can mess things up. Sometimes the failure will occur for one type of call, such as a purge, but not for another type of call, such as a configure or a remove. Manoj Srivastava, author and Debian package maintainer of the kernel-package package, mentions it in the man page for kernel-img.conf, and I have personally been burned by it with one of my own hook scripts that I wrote for use with lilo. The hook script failed with a non-zero return code, which caused the kernel installation process to fail. I could not figure out for the life of me what was wrong. The script ran fine when invoked stand-alone, but not as a hook script. Redirecting lilo output to standard error solved the problem. It ran perfectly after that. But even if the stuff written to standard output does not mess up debconf, the user still won't see it. The safe (and informative) thing to do is for all hook scripts to write all output to standard error. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/375009335.66290.1274880285294.javamail.r...@md01.wow.synacor.com
Bug#583217: ITP: libconfig-mvp-reader-ini-perl -- Perl module providing a MVP config reader for .ini files
Package: wnpp Severity: wishlist Owner: Ansgar Burchardt ans...@43-1.org * Package name: libconfig-mvp-reader-ini-perl Version : 1.101450 Upstream Author : Ricardo Signes r...@cpan.org * URL : http://search.cpan.org/dist/Config-MVP-Reader-INI/ * License : Artistic or GPL-1+ (like perl) Programming Lang: Perl Description : Perl module providing a MVP config reader for .ini files Config::MVP::Reader::INI implements a reader for .ini files for use with Config::MVP. Config::MVP::Reader::INI has moved to a different distribution upstream (was included in libconfig-ini-mvp-perl before). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526132301.31379.64616.report...@marvin.43-1.org
Re: Let's write a system admin friendly mail server packaging system
Thomas Goirand tho...@goirand.fr wrote: What happens here is that, if you take a normal Debian system, then install postfix, then let's say amavis, they don't talk to each other. ... much spams. It is also totally unrealistic to say that it's up to the system administrator to configure everything by hand. If, like me, you do at least one setup a day, it takes too much time for no reason, and it has to be automated in some way. There are lots of examples out there where already works what you are requesting for mail servers. Let's have a look at web servers (well, apache... okay) and how they deal with it. I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Let's have a look at DHCP and how they deal with it. I'm installing dhcp3-client and my machine's network settings are configured automagically. I'm installing resolvconf and my name servers become configured automagically via DHCP. I'm installing samba and it's also getting configured automagically via DHCP. I'm installing ntp and my ntp-server is configured automagically via DHCP. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Let's have a look at SysV boot mimics and how they deal with it. I'm installing the sysvinit packages ... well, you can imagine the rest: ... There is some conf.d directory which contains config snippets for each of the packages. Why would you like to go another way with mail servers? Get maintainer support for such conf.d directories, maybe get upstream support for such conf.d mimics (sendmail most likely won't need it - some m4 magic and triggers will just do it, dunno how it is for the less flexible ones like postfix, exim, whatever), change the depending packages to put their config snippets in there, everything is fine. argument a list of packages that it should use. But the MTA is not the only one to modify here, for example we might have to change the listen and relay port of dkimproxy and amavis, depending if each others are present on the system or not. I am quite in the favor of this system, I don't think this is really necessary. It would probably be a bit more efficient to have one component forwarding the stuff it processed to the next one, but I'm sure there is a less efficient but more generic way to just bounce it back to the MTA which continues forwarding it to the next components. ... And who cares about efficiency in generic approaches. regards Mario -- who | grep -i blonde | talk; cd; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; true; gasp; umount; make clean; sleep -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvqa8s.m0q.mario.ho...@darkside.dyn.samba-tng.org
Re: Packaging Gzstream?
Le Fri, May 21, 2010 at 10:58:05AM +0200, Adam Borowski a écrit : On Fri, May 21, 2010 at 04:00:56PM +0900, Charles Plessy wrote: A quick apt-file search indicates that at least two other packages (CCed) may be using the gzstream library, k3d and freecad. So it seems that it would make sense to package the gzstream library separately. It appears to be just a single file less than four pages long. It does nothing but translate zlib's API to C++ iostream API. While generally avoiding duplicated code is a very good idea, it doesn't have to be done with any small snippet. Heck, I've written three zlib wrappers myself (two of them had bzip2 support as well), and it never came to me that it's a task big enough to be worth a whole library. Since nobody contradicted Adam, I will go for the simplest way and package the software with its convenience copy of gzstream. When contacting upstream, I will nevertheless recommed them the boostiostream library. Thanks everybody for your answers, and have a nice day, -- Charles Plessy Debian Med packaging team Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526141714.gc13...@kunpuu.plessy.org
Re: Improving in-place upgrades of Ada packages from Lenny to Squeeze
Jacob Sparre Andersen wrote:
Ludovic Brenta wrote:
Over the last two weeks I have been testing upgrades of
Ada packages from Lenny to Sid and Squeeze in a chroot.
The picture is not as pretty as it should be. In a
nutshell, when you change /etc/apt/sources.list from lenny
to squeeze (unstable, actually) and do aptitude update,
you end up with a lot of broken packages and must
intervene manually to resolve the problem (i.e. remove the
broken packages, install new versions).
A long-term, partial solution is to introduce a
build-essential-ada package, which depends on gnat and all
the current development packages. That would also make it
quicker to prepare a new system for developing Ada programs.
(As a teacher, it is a package I have missed a lot.)
OK, since there is user demand, it seems reasonable. Note that
the build-essential-ada package really is the gnat package;
a new package that brings in the whole shebang would rather be
called complete-ada-development-environment-with-bells-and-
whistles :)
In the case of libgnat{vsn,prj}4.3-dev, this is only
because I recently added dummy transition packages,
libgnat{vsn,prj}-dev in gnat-4.4 (= 4.4.4-4).
Could you create such dummy transition packages for all
development packages? (Again only a long-term solution.)
No; the whole point of the package name changes is to break
the Depends: of third-party programs before they FTBFS for
reasons mysterious to the programmer but obvious to the
Debian Ada maintainers :)
I think a short-term solution might be to make gnat suggest
the new versions of the development packages. (Or the
above-mentioned transition packages?)
That seems quite reasonable but a Recommends: would be needed
to force automatic package upgrades (i.e. deletion of the old
packages and installation of new ones). The other drawback is
that it would be necessary to change the gnat package each
time a new -dev package appears in Debian :) I think we can
live with such a drawback for the time being.
Thanks for the feedback.
--
Ludovic Brenta.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/af6b1e49e807b6fdf4d1fadd814dd...@localhost
Bug#583220: ITP: haskell-pango -- Binding to the Pango text rendering engine
Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-pango Version : 0.11.0 Upstream Author : Axel Simon, Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the Pango text rendering engine This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . This package provides a wrapper around the Pango C library that allows high-quality rendering of Unicode text. It can be used either with Cairo to output text in PDF, PS or other documents or with Gtk+ to display text on-screen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526141240.23244.35956.report...@zezinho
Re: Let's write a system admin friendly mail server packaging system
On Wednesday 26 May 2010 15:58:51 Mario 'BitKoenig' Holbe wrote: Why would you like to go another way with mail servers? Get maintainer support for such conf.d directories, maybe get upstream support for such conf.d mimics (sendmail most likely won't need it - some m4 magic and triggers will just do it, dunno how it is for the less flexible ones like postfix, exim, whatever), change the depending packages to put their config snippets in there, everything is fine. Amavis already has conf.d it's a start :) Bye -- Salvo Tomaselli signature.asc Description: This is a digitally signed message part.
Bug#583225: ITP: haskell-gtk -- Binding to the Gtk+ graphical user interface library
Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gtk Version : 0.11.0 Upstream Author : Axel Simon, Duncan Coutts and many others * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the Gtk+ graphical user interface library This package provides the documentation for a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . This is the core library of the Gtk2Hs suite of libraries for Haskell based on Gtk+. Gtk+ is an extensive and mature multi-platform toolkit for creating graphical user interfaces. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526142952.8910.74554.report...@zezinho
Bug#583228: ITP: haskell-gconf -- Binding to the GNOME configuration database system
Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gconf Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : GPL Programming Lang: Haskell Description : Binding to the GNOME configuration database system This package provides a library for the Haskell programming language, compiled for profiling. See http://www.haskell.org/ for more information on Haskell. . GConf is a configuration database system for storing application preferences. It supports default or mandatory settings set by the administrator, and changes to the database are instantly applied to all running applications. It is written for the GNOME desktop but doesn't require it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526143956.12135.39756.report...@zezinho
Re: RFH: bashisms in configure script
On Wednesday 26 May 2010 03:00:58 Michael Meskes wrote: Don't you think we should run the test *after* the patches got applied? That's done if the package uses format 3.0 (quilt). Regards, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005261053.40241.geiss...@debian.org
Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. Why would you like to go another way with mail servers? Because upstream doesn't want a conf.d folder, unfortunately, and that the issue is NOT ONLY with postfix, but with so many package that have to understand each other. Let me give an example. If you setup postfix + amavis, then postfix must relay emails to the incoming port of amavis, and amavis got to give the email back to postfix on another port. Both postfix and amavis have to be configured so they can talk to each other. Now, add dkimproxy in the loop. You have to configure dkimproxy to receive from postfix, relay to amavis, and amavis forwards to postfix. This is a LOT less trivial than what you pretend. Get maintainer support for such conf.d directories, maybe get upstream support for such conf.d mimics (sendmail most likely won't need it - some m4 magic and triggers will just do it, dunno how it is for the less flexible ones like postfix, exim, whatever), change the depending packages to put their config snippets in there, everything is fine. argument a list of packages that it should use. But the MTA is not the only one to modify here, for example we might have to change the listen and relay port of dkimproxy and amavis, depending if each others are present on the system or not. I am quite in the favor of this system, I don't think this is really necessary. It would probably be a bit more efficient to have one component forwarding the stuff it processed to the next one, but I'm sure there is a less efficient but more generic way to just bounce it back to the MTA which continues forwarding it to the next components. ... And who cares about efficiency in generic approaches. OF COURSE we do care about the performances of a mail server. Some ISP are running servers that are managing 100s of thousands of mail a day. But anyway, this was just an example, there's many use case where you must configure one of the elements of your mail server. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd4522.4080...@goirand.fr
Bug#583236: ITP: haskell-glade -- Binding to the glade library
Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-glade Version : 0.11.0 Upstream Author : Manuel M T Chakravarty * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2+ Programming Lang: Haskell Description : Binding to the glade library This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . This library allows to load externally stored user interfaces into programs. This allows alteration of the interface without recompilation of the program. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526160222.13556.23403.report...@zezinho
Re: The story behind UPG and umask.
Hi, On Wed, May 26, 2010 at 01:00:49PM +0100, Roger Leigh wrote: This one time, at band camp, Steve Langasek said: pam_umask requires both username == primary group name and uid == gid before it will assume UPG are in place when using its 'usergroups' option, I'd be interested to understand the upstream POV here--with current Debian systems, assuming UID==GID without additionally checking that the names match is horribly insecure. See the text you quoted yourself, or am I missing something? Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526122243.gb2...@nighthawk.chemicalconnection.dyndns.org
Re: The story behind UPG and umask.
On Wed, May 26, 2010 at 02:36:53AM +0200, C. Gatzemeier wrote: Am Tue, 25 May 2010 22:47:51 +0200 schrieb Harald Braumann ha...@unheit.net: On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote: The path into your home directory is not restricted, just as the path others can take to ring your bell at home is not restricted. Depends on adduser settings. Both, world readable and private home directories are common. Thanks! Adding ...the path to your home *is by default* not restricted,... seems to be more precise. In light of UPG, we might want to revisit the default here as well, maybe it makes sense to have your $HOME not world-readable be the default? Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526122558.gc2...@nighthawk.chemicalconnection.dyndns.org
Re: Let's write a system admin friendly mail server packaging system
On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. Eh, Debian can patch upstream software if it thinks it is necessary for inter-operation, that's the one of the major points of having a distribution. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526164250.gf2...@nighthawk.chemicalconnection.dyndns.org
Re: The story behind UPG and umask.
On Wed, May 26, 2010 at 02:22:43PM +0200, Michael Banck wrote: Hi, On Wed, May 26, 2010 at 01:00:49PM +0100, Roger Leigh wrote: This one time, at band camp, Steve Langasek said: pam_umask requires both username == primary group name and uid == gid before it will assume UPG are in place when using its 'usergroups' option, I'd be interested to understand the upstream POV here--with current Debian systems, assuming UID==GID without additionally checking that the names match is horribly insecure. See the text you quoted yourself, or am I missing something? The UID==GID scheme works initially, but any call to addgroup to add a group will get the two out of sync. Because historically we haven't enforced the two to be equal, on any system with =1 groups added, the UID is guaranteed to not equal the GID. In consequence, the UID==GID check will fail with these historical passwd/group files, and that's not even counting databases coming from NIS or LDAP sources where it's not under our control. What, exactly, does comparing the UID and GID get you? I.e. what is is protecting you against? If you're using a system such as Debian, which has created a group by the same name for many years, you're in no danger of accidentally creating a group with the same name of a user, since it will already exist. Additionally, adding a new user will fail if the group already exists. Are there any other corner cases this prevents problems with? How will adduser cope with group addition; does it skip UIDs until it finds an unused unique UID/GID pair? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gnomevfs Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GNOME Virtual File System library This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . GNOME VFS is the GNOME virtual file system. It is the foundation of the Nautilus file manager. It provides a modular architecture and ships with several modules that implement support for local files, http, ftp and others. It provides an URI-based API, a backend supporting asynchronous file operations, a MIME type manipulation library and other features. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526170722.3466.90528.report...@zezinho
Re: Let's write a system admin friendly mail server packaging system
On Wed, May 26, 2010 at 06:42:50PM +0200, Michael Banck wrote: On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. Eh, Debian can patch upstream software if it thinks it is necessary for inter-operation, that's the one of the major points of having a distribution. That is true. However, it must be balanced with making the software different than it is on every other platform. I'm not saying that it cannot be done. Rather, there needs be a discussion as to whether that is something that Debian wants to do. It is not as simple as just patching a high profile package like postfix. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Bug#583261: ITP: haskell-gstreamer -- Binding to the GStreamer open source multimedia framework
Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gstreamer Version : 0.11.0 Upstream Author : Peter Gavin, Axel Simon * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GStreamer open source multimedia framework This package provides a library for the Haskell programming language, compiled for profiling. See http://www.haskell.org/ for more information on Haskell. . This package provides a wrapper around the GStreamer C library. GStreamer is a library for constructing graphs of media-handling components. The applications it supports range from simple OggVorbis playback, audiovideo streaming to complex audio (mixing) and video (non-linear editing) processing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526172923.16161.81853.report...@zezinho
Re: Let's write a system admin friendly mail server packaging system
On 05/26/2010 11:42 AM, Michael Banck wrote: On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. Eh, Debian can patch upstream software if it thinks it is necessary for inter-operation, that's the one of the major points of having a distribution. That would be some *serious* patching. Maybe, though, LaMont Jones (the Postfix DD) has a better relationship with upstream and could convince them that conf.d is a good idea. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd5ff6.8020...@cox.net
Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva wrote: Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gnomevfs Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GNOME Virtual File System library It's my understanding that gnome-vfs is deprecated upstream and is going away. Most GNOME components no longer use it or include support for it. Do you really want to package a binding for unsupported software? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
Hi Brian. Excerpts from brian m. carlson's message of Qua Mai 26 14:53:48 -0300 2010: On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva wrote: Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gnomevfs Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GNOME Virtual File System library It's my understanding that gnome-vfs is deprecated upstream and is going away. Most GNOME components no longer use it or include support for it. Do you really want to package a binding for unsupported software? This is a good point. But I'm not going to introduce this package in Debian. The new version of gtk2hs split the source package in a lot of source packages, so I'm filling ITPs to new source packages, but the binary packages are the same. Therefore, I'm only updating the version of the binary package. Greetings. (...) -- marcot http://wiki.debian.org/MarcoSilva signature.asc Description: PGP signature
Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
Hi, - brian m. carlson sand...@crustytoothpaste.ath.cx wrote: On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva wrote: Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gnomevfs Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GNOME Virtual File System library It's my understanding that gnome-vfs is deprecated upstream and is going away. Most GNOME components no longer use it or include support for it. Do you really want to package a binding for unsupported software? Indeed. GVFS has replaced GnomeVFS in the GNOME platform. William -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/9514770.3811274896715696.javamail.r...@ifrit.dereferenced.org
Re: extlinux
On 05/26/2010 10:45 AM, Bjørn Mork wrote: That's the single feature I misseded. Thanks. welcome. Although it would be even better if it was possible to include some fixed part in it, while keeping most of it auto updated. I tested the extlinux package after reading about it yesterday, and the missing feature that immediately hit me was the ability to use a serial console. This is of course as easy as with sys-/pxe-/mem-linux: just add serial 0 9600 0 or something similar to the config file. But running update-extlinux would remove it on every kernel upgrade. Anyway, I understand that this issue is now solved. how about adding your parameters to EXTLINUX_PARAMETERS in /etc/default/extlinux? then they will be used for all images in the config automatically. in case that's not what you were looking for: as stated in another mail, i've added update-extlinux/extlinux-install and it fits my setups well - but any suggestions are welcome, please feel encouraged to submit bug reports against extlinux. It has puzzled me for a while that grub2 has been chosen over extlinux as the default x86 bootloader extlinux doesn't support as many filesystems to read the kernels from as grub does (extlinux basically only supports extlinux, and in 4.0 also btrfs; and syslinux would support fat, though). while i really like extlinux for the reasons outlined earlier[0], i don't think it's a good default for everyone and anything. HPA has been an active upstream maintainer all this time AFAIK. indeed, he's an excellent upstream in every aspect. Regards, Daniel [0] http://blog.daniel-baumann.ch/2009/11/30#20091130_extlinux-as-alternative-bootloader -- Address:Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist Email: daniel.baum...@panthera-systems.net Internet: http://people.panthera-systems.net/~daniel-baumann/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd692b.1010...@debian.org
Bug#583272: ITP: haskell-gtkglext -- Binding to the GTK+ OpenGL Extension
Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gtkglext Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GTK+ OpenGL Extension This package provides a library for the Haskell programming language. See http://www.haskell.org/ for more information on Haskell. . GtkGLExt provides the GDK objects to support OpenGL rendering in GTK+, and GtkWidget API add-ons to make GTK+ widgets OpenGL-capable. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526181318.4905.4039.report...@zezinho
Re: Bug#583257: ITP: haskell-gnomevfs -- Binding to the GNOME Virtual File System library
On Wed, May 26, 2010 at 14:59:41 -0300, Marco Túlio Gontijo e Silva wrote: Hi Brian. Excerpts from brian m. carlson's message of Qua Mai 26 14:53:48 -0300 2010: On Wed, May 26, 2010 at 02:07:22PM -0300, Marco Túlio Gontijo e Silva wrote: Package: wnpp Severity: wishlist Owner: Marco Túlio Gontijo e Silva mar...@debian.org * Package name: haskell-gnomevfs Version : 0.11.0 Upstream Author : Duncan Coutts * URL : http://www.haskell.org/gtk2hs/ * License : LGPL-2.1+ Programming Lang: Haskell Description : Binding to the GNOME Virtual File System library It's my understanding that gnome-vfs is deprecated upstream and is going away. Most GNOME components no longer use it or include support for it. Do you really want to package a binding for unsupported software? This is a good point. But I'm not going to introduce this package in Debian. The new version of gtk2hs split the source package in a lot of source packages, so I'm filling ITPs to new source packages, but the binary packages are the same. Therefore, I'm only updating the version of the binary package. Doesn't seem necessary to file ITP bugs in such a case... Cheers, Julien signature.asc Description: Digital signature
Re: Let's write a system admin friendly mail server packaging system
Thomas: Sorry for the private mail, I hit the wrong reply button. On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. The packaging of Exim optionally supports a setup in which the config file is split into several conf.d-like directories. Whenever Exim is restarted all files in those directories are concatenated into a single file somewhere under /var which is then fed to the Exim daemon. Couldn't the postfix package be modified to do something similiar? Andreas signature.asc Description: Digital signature
Re: Let's write a system admin friendly mail server packaging system
Ron Johnson wrote: On 05/26/2010 11:42 AM, Michael Banck wrote: On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. Eh, Debian can patch upstream software if it thinks it is necessary for inter-operation, that's the one of the major points of having a distribution. That would be some *serious* patching. Maybe, though, LaMont Jones (the Postfix DD) has a better relationship with upstream and could convince them that conf.d is a good idea. I have to admit that I didn't insist so much, given the type of response I had when I asked. I also agree that it would be much better if upstream were happily accepting such patch, even if one of us is doing the job. I didn't really dive into the postfix code to know how hard it would be to add the feature, and I hope that LaMont Jones can talk about it. Anyway, postfix is NOT the only package that we shall consider modifying here. As per my original post, there's loads of other components that are to configure as well. The question is: is there a will to do this job by other maintainers. I am myself strongly motivated for this, but I wont be able to do it alone. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd7686.4030...@goirand.fr
Re: Let's write a system admin friendly mail server packaging system
On 05/26/2010 02:29 PM, Thomas Goirand wrote: [snip] Anyway, postfix is NOT the only package that we shall consider modifying here. As per my original post, there's loads of other components that are to configure as well. The question is: is there a will to do this job by other maintainers. I am myself strongly motivated for this, but I wont be able to do it alone. As was mentioned earlier, this can't be a Debian-only task. It's just too big and complicated. Upstream of all the relevant packages must buy in. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd86c6.7080...@cox.net
Re: Recent changes in dpkg
On 05/24/2010 11:05 AM, Raphael Hertzog wrote: Hello, The versions 1.15.6 and 1.15.7 of dpkg introduced several important changes. Let's skim over them: [...] * dpkg-dev provides a new script called dpkg-buildflags that packages should use in debian/rules to retrieve the default value of various compilation flags. Bug #578597[1] has been submitted against debian-policy. When generalized this offer us centralized archive-wide control of the default build flags as well as the possibility for end-users to try out easily new flags. So you plan to enforce something which resulted in a lot of FTBFS due to the fact that buildflags, which were written into a Makefile by configure or similar tools, were overridden by the default values from dpkg again as they were still present in the environment? * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfd87f8.90...@bzed.de
Re: Recent changes in dpkg
On 2010-05-26, Bernd Zeimetz be...@bzed.de wrote: * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. ETOPIC. You have to specify the format in the package. Nowhere they write that 1.0 will disappear. And they say in the long term too, so debian/source/format should be propagating naturally into most of the packages due to the lintian tag. Kind regards, Philipp Kern -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnhvr2ff.hvt.tr...@kelgar.0x539.de
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. I think you're misreading the announcement. What will change is that declaring the format (either 1.0 or 3.0 in whatever variant) will be required, not migrating to the new formats. regards, iustin signature.asc Description: Digital signature
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: Hello, The versions 1.15.6 and 1.15.7 of dpkg introduced several important changes. Let's skim over them: [...] * dpkg-dev provides a new script called dpkg-buildflags that packages should use in debian/rules to retrieve the default value of various compilation flags. Bug #578597[1] has been submitted against debian-policy. When generalized this offer us centralized archive-wide control of the default build flags as well as the possibility for end-users to try out easily new flags. So you plan to enforce something which resulted in a lot of FTBFS due to the fact that buildflags, which were written into a Makefile by configure or similar tools, were overridden by the default values from dpkg again as they were still present in the environment? [...] Environment variables do not override variable definitions in a makefile. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526210731.ge5...@decadent.org.uk
Re: SRWare Iron: Chromium without the data-mining
]] Josselin Mouette | Le samedi 22 mai 2010 à 08:43 +0200, Tollef Fog Heen a écrit : | | I don't see what you mean by iffy tabbed browsing, what's wrong with | | tabbed browsing in Epiphany? | | For me, at least two things: | | - C-TAB/C-S-TAB doesn't work for switching tabs, I have to use |C-PgUp/PgDn. | | This is the default GTK+ shortcut for that. I realise that, but it's not default in various web browsers. (Well, most I've used seem to support both C-PgUp/C-PgDn and C-TAB/C-S-Tab). This is probably the major gripe for me each time I end up using epiphany for anything. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ocg2l5s2@qurzaw.linpro.no
Re: The story behind UPG and umask.
]] C. Gatzemeier | So yes, you can setup UPGs with UID!=GID, but then you'll also | have to set the umask manually to make it work (globally or in gecos or | ldap etc.). | | The UID==GID and username==groupname restriction of the | pam_umask's usergroups option ensures that the umask is only relaxed | automatically in very specific defined cases. | | That's why I'am thinking the UID==GID restriction pam_umask makes (and | login made before) can be sane choice. (Others seem to use it also, | and it is upstream.) The problem is when you then run addgroup foo, every user created after that will not be considered to be a UPG user. Perhaps addgroup shouldn't use the same gid range as what we are using for users, to make this problem at least smaller, if not make it go away. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87k4qql5gy@qurzaw.linpro.no
Re: Recent changes in dpkg
On Wed, 26 May 2010 22:59:25 +0200 Iustin Pop iu...@k1024.org wrote: On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. I think you're misreading the announcement. What will change is that declaring the format (either 1.0 or 3.0 in whatever variant) will be required, not migrating to the new formats. Declaring a format mandates touching every single package because the vast majority of packages are currently dpkg source format 1.0 ONLY because debian/source/format does NOT exist. The dpkg maintainers appear to want all packages to have a file that currently only exists in a fraction of packages. We cannot add a file to packages without touching them / rebuilding them, so as the lack of a file is proposed as being *against eventual policy* then Policy is being abused to do what it has been claimed Policy should never do - force a change that is NOT already implemented in most affected packages. The ABSENCE of debian/source/format needs to be explicitly retained as a de facto declaration of dpkg source format 1.0. i.e. unless explicitly specified, 1.0 needs to BE the default. Any other proposal tries to abuse Policy to implement a (trivial) change affecting every single source package in Debian. I find that unacceptable. If dpkg eventually causes FTBFS due to the lack of this file, then dpkg will be buggy, not the package. This is especially true when nothing has changed in the package; the only change would be in dpkg behaviour. has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The I think the announcement is wrong, we cannot ever expect every single package to be touched for any single change. We don't even do that when libc changes SONAME - that only affects compiled packages, this theoretically affects all source packages which means huge numbers of rebuilds and transitions. There is nothing wrong with a source package that glides through several stable releases without needing a rebuild, especially if it only builds an Arch:all binary package. As long as it is bug free, an ancient standards version alone is not sufficient reason to change anything in the package or make any upload just for the sake of making an upload. debian/source/format cannot become mandatory without causing every single source package to be modified. For what? Just to add 6 bytes? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpvYmN5ux453.pgp Description: PGP signature
Re: Let's write a system admin friendly mail server packaging system
]] Michael Banck | On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: | Mario 'BitKoenig' Holbe wrote: | I'm installing apache2 and have a web server - more or less working, | I'm installing dhelp and ... magic, magic ... it extends the running | web-server to serve the dhelp content as well. I'm installing smb2www | and it extends the running web-server to act as smb client as well. | How do they do this? There is some conf.d directory which contains | config snippets for each of the packages. | | Yes, which feature I requested from the upstream of postfix. I got a | stunning reply that it was a stupid idea, that it would be slow to | parse, and that postconf wouldn't work anymore. So forget about having | this in postfix, we must find another way. | | Eh, Debian can patch upstream software if it thinks it is necessary for | inter-operation, that's the one of the major points of having a | distribution. Wouldn't it be easier to generate a configuration directory in /var from snippets in /etc/postfix, if that was what you desired? The init script could do that easily enough. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87fx1el4xf@qurzaw.linpro.no
Re: Recent changes in dpkg
On Wed, May 26, 2010 at 10:34:32PM +0100, Neil Williams wrote: On Wed, 26 May 2010 22:59:25 +0200 Iustin Pop iu...@k1024.org wrote: On Wed, May 26, 2010 at 10:43:36PM +0200, Bernd Zeimetz wrote: On 05/24/2010 11:05 AM, Raphael Hertzog wrote: * The plan concerning dpkg-source and the default source format has been clarified. In the long term, the default format will disappear and debian/source/format will become mandatory. The lintian tag missing-debian-source-format[2] will help us track that. Which will force developers to touch most of the packages in the archive just to realize this? Sorry, but that's insane. You should not try to force people into migrating to some new format because *you* think it is better. This is not a decision which should be decided by the dpkg maintainers - instead it needs to be discussed within the developers and maintainers. While the new format provides some advantages when it comes to the handling of patches, the 1.0 format is still much more flexible to use - for example it does not require an existing tarball to build a package, which is very useful for testing. You know that there are a lot of arguments against the 3.0 format out there, so please do not enforce such changes without discussing them first. I think you're misreading the announcement. What will change is that declaring the format (either 1.0 or 3.0 in whatever variant) will be required, not migrating to the new formats. Declaring a format mandates touching every single package because the vast majority of packages are currently dpkg source format 1.0 ONLY because debian/source/format does NOT exist. […] I was only responding to Bernd's email which sounded like he misread the change. Whether the actual change is good or not, it's another issue, on which I'm disagreeing (but not very strongly, i.e. I could live with it): I think the announcement is wrong, we cannot ever expect every single package to be touched for any single change. We don't even do that when libc changes SONAME - that only affects compiled packages, this theoretically affects all source packages which means huge numbers of rebuilds and transitions. Agreed. There is nothing wrong with a source package that glides through several stable releases without needing a rebuild, especially if it only builds an Arch:all binary package. As long as it is bug free, an ancient standards version alone is not sufficient reason to change anything in the package or make any upload just for the sake of making an upload. But here I disagree. A couple of stable releases is, let's say, 4 years? In the last four years, there have been significant changes (advancements?) in the state of Debian packaging. As such, most, if not all, nontrivial packages would be improved if they're brought up to date. debian/source/format cannot become mandatory without causing every single source package to be modified. For what? Just to add 6 bytes? Mandatory? I agree it shouldn't be mandatory. I would rather propose a 'W' lintian tag, nothing more, and which will only fire if the last changelog date is after the date this proposal goes live. iustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526214452.gb2...@teal.hq.k1024.org
Re: The story behind UPG and umask.
Am Wed, 26 May 2010 18:05:32 +0100 schrieb Roger Leigh rle...@codelibre.net: What, exactly, does comparing the UID and GID get you? I.e. what is is protecting you against? If you're using a system such as Debian, which has created a group by the same name for many years, you're in no danger AFAIU it is meant for cases where you connect a debian box to an existing LDAP etc. environment, where a user and group might exits but not be related. Like a user that is called admin and an admin system group etc. Having alligned UIDs==GIDs makes UPGs systems more distinguishable from other systems. The check will also recognize RH, f, ... UPGs systems, and the allignment will make those other systems also recognized a debian server as an UPG system. Cheers, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526232212.1047deefc.gatzeme...@tu-bs.de@tu-bs.de
GID/UID algorithm? (Re: The story behind UPG and umask.)
Am Wed, 26 May 2010 18:05:32 +0100 schrieb Roger Leigh rle...@codelibre.net: How will adduser cope with group addition; does it skip UIDs until it finds an unused unique UID/GID pair? Maybe just skip taken GIDs by default? (every user has one, less gap more likely to be usable for a user account), starting +1 from the highest GID that was ever created without specifying specific IDs on the system (to avoid giving possibly remaining old files from deleted users/groups to new users/groups). Set that search start pointer back to MIN_GID if it points to MAX_GID. If the admin hasn't manually created any users/groups with higer IDs, the first (+1) GID should already be an available slot. The UIDs and GIDs match nicely, occasionally (where a regular group has been created) some UIDs will stay unused. There shouldn' be any drawback. Does adduser rely on useradd? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526232358.17ffb67fc.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Am Wed, 26 May 2010 14:25:58 +0200 schrieb Michael Banck mba...@debian.org: On Wed, May 26, 2010 at 02:36:53AM +0200, C. Gatzemeier wrote: Am Tue, 25 May 2010 22:47:51 +0200 schrieb Harald Braumann ha...@unheit.net: On Tue, May 25, 2010 at 10:09:35PM +0200, C. Gatzemeier wrote: The path into your home directory is not restricted, just as the path others can take to ring your bell at home is not restricted. Depends on adduser settings. Both, world readable and private home directories are common. Thanks! Adding ...the path to your home *is by default* not restricted,... seems to be more precise. In light of UPG, we might want to revisit the default here as well, maybe it makes sense to have your $HOME not world-readable be the default? Just making a list of consequences to consider here. Users can not modify the permissions of their home on their own, but they can manage everything within their home. The UPG scheme works directory based. So for private things, there should be a ready to use and set up ~/priv directory by default. That is a place where a user may keep much of his stuff, if he does not want to change permissions of other subdirs. As world readable is a largely used default programs with really privacy relevant config files should take care of their config file permissions already. If the $HOME however is not world accessible you can not have your ~/incoming or ~/Public directory within your home. More importantly users can not create new group directories on their own in their home, and they can not be allowed write access to a separate place like /home/group for this. When I'd set up an ISP/hosting system where users are not supposed to collaborate and work on their own, I'd change the default home permissions in adduser.conf. There is also some discussion about the home permission on https://wiki.ubuntu.com/MultiUserManagement Cheers, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527001837.6bfdd866c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
Wed, 26 May 2010 23:26:37 +0200, Tollef Fog Heen: Perhaps addgroup shouldn't use the same gid range as what we are using for users, to make this problem at least smaller, if not make it go away. Hm, that may be another option to allign UIDs and GIDs, you'd create split max. UID/GID amounts though, and would still need adduser/useradd to skip any available GIDs with old/manually taken UIDs to ensure UID==GUID UPG accounts. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527004121.6b029358c.gatzeme...@tu-bs.de@tu-bs.de
Re: The story behind UPG and umask.
This one time, at band camp, Roger Leigh said: How will adduser cope with group addition; does it skip UIDs until it finds an unused unique UID/GID pair? That certainly is the only approach that makes sense - it has the benefit of simplicity, if not elegance. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: The story behind UPG and umask.
This one time, at band camp, Michael Banck said: In light of UPG, we might want to revisit the default here as well, maybe it makes sense to have your $HOME not world-readable be the default? That is already trivailly settable and not a debate likely to bring much new to the table on either side. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: The story behind UPG and umask.
This one time, at band camp, Tollef Fog Heen said: The problem is when you then run addgroup foo, every user created after that will not be considered to be a UPG user. Perhaps addgroup shouldn't use the same gid range as what we are using for users, to make this problem at least smaller, if not make it go away. I've been unhappy for one reason or another with ideas like this in the past (gids below 100 are reserved, then there come system groups, then usergroups starting at 1000, unless you want to interoperate with RHEL and derivatives in which case they start at 500. You also don't want to pick a high range because large sites will have uids creep up from behind, etc. Blech) The current arrangement isn't brilliant, but it's at least clear that if a gid is = 1000, it is not the gid of a system account (unless of course it's nobody/nogroup ... :) ), although you can't necessarily say much more than that. I suspect it will be simplest to just add a bit of logic to adduser to make it 'skip ahead' until it can get matching uids/gids. This will leave holes in both passwd and group, but that's not exactly a problem. FWIW, I tend to agree with Roger that the added step of uid == gid doesn't actually buy us all that much, but if other software we are currently shipping depends on that behavior, we might as well not deliberately break it. Cheers, -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: The story behind UPG and umask.
Am Tue, 25 May 2010 16:43:21 -0700 schrieb Steve Langasek vor...@debian.org: I am not willing to diverge from upstream on this as this would mean admins coming from other systems may get an unpleasant surprise when they find that Debian gives a more relaxed umask than they were expecting in some corner cases. Would you, or somebody else, be willing to write a patch for pam_umask to read the USERGROUPS_ENAB option from /etc/login.defs or /etc/default/login, just as it is reading the UMASK option from there? Cheers, Christian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527010259.4fe10b74c.gatzeme...@tu-bs.de@tu-bs.de
Re: Recent changes in dpkg
Hi, On Mittwoch, 26. Mai 2010, Philipp Kern wrote: ETOPIC. You have to specify the format in the package. Nowhere they write that 1.0 will disappear. And they say in the long term too, so debian/source/format should be propagating naturally into most of the packages due to the lintian tag. Yes, I agree. most. But .deb is used in a lot of environments. And I haven't heard of a single reason, why the lack of debian/source/format *shouldn't* be interpreted as, well, source/format = 1.0. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Let's write a system admin friendly mail server packaging system
Roberto C. Sánchez robe...@connexer.com wrote: On Wed, May 26, 2010 at 06:42:50PM +0200, Michael Banck wrote: On Wed, May 26, 2010 at 11:58:26PM +0800, Thomas Goirand wrote: Mario 'BitKoenig' Holbe wrote: I'm installing apache2 and have a web server - more or less working, I'm installing dhelp and ... magic, magic ... it extends the running web-server to serve the dhelp content as well. I'm installing smb2www and it extends the running web-server to act as smb client as well. How do they do this? There is some conf.d directory which contains config snippets for each of the packages. Yes, which feature I requested from the upstream of postfix. I got a stunning reply that it was a stupid idea, that it would be slow to parse, and that postconf wouldn't work anymore. So forget about having this in postfix, we must find another way. Eh, Debian can patch upstream software if it thinks it is necessary for inter-operation, that's the one of the major points of having a distribution. That is true. However, it must be balanced with making the software different than it is on every other platform. I'm not saying that it cannot be done. Rather, there needs be a discussion as to whether that is something that Debian wants to do. It is not as simple as just patching a high profile package like postfix. FWIW, dovecot supports config.d too. For postfix, as I understand the design, it would be as non-trivial effort to move to a similar cascading config directory approach. Fortunately it's not needed. In postfix you need to be able to programmatically modify both main.cf and master.cf. I believe that the upstream supported postconf tool supports making all needed changes to main.cf. The Debian package also ships some Debian (and derivative) specific scripts to allow smtp filters and policy services to be added to master.cf by other packages in a policy compliant way. They are simplistic, but should serve this use case (it's the one I wrote them for). Additionally, Ubuntu ships a distro specific binary called dovecot-postfix that implements part of this vision already. We'd love to see it in Debian if the dovecot maintainer is interested. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aa1a35fd-a1de-4e9f-b4ac-a8795379b...@email.android.com
Re: lilo removal in squeeze (or, please test grub2)
In article enjn8-64s...@gated-at.bofh.it, Ferenc Wagner wf...@niif.hu wrote: Sorry, I don't trust in the future of LILO myself. If there's anything which only LILO can do, I recommend you start complaining on the Syslinux and the Grub mailing lists. I suppose it will be heard. Does either grub2 or syslinux allow for single-key booting? (For example, if in lilo.conf I have the command single-key near the beginning of the file, alias=w in the stanza for Windows, and no labels begin with w or W, then at boot time the single key w will cause lilo to start booting Windows.) --Paul Vojta, vo...@math.berkeley.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/htkfei$3r...@news.eternal-september.org
Re: Let's write a system admin friendly mail server packaging system
Scott Kitterman debian at kitterman.com writes: Additionally, Ubuntu ships a distro specific binary called dovecot-postfix that implements part of this vision already. We'd love to see it in Debian if the dovecot maintainer is interested. The dovecot maintainer might be interested if someone told him about it. Like with a wishlist bug to the BTS maybe? -- Jaldhar H. Vyas jald...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20100527t030124-...@post.gmane.org
Re: Let's write a system admin friendly mail server packaging system
Jaldhar H. Vyas jald...@debian.org wrote: Scott Kitterman debian at kitterman.com writes: Additionally, Ubuntu ships a distro specific binary called dovecot-postfix that implements part of this vision already. We'd love to see it in Debian if the dovecot maintainer is interested. The dovecot maintainer might be interested if someone told him about it. Like with a wishlist bug to the BTS maybe? Excellent. It's only been recently it's gotten to the point that I think it might be worth looking at for Debian. Scott K -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/91519a0b-55e1-4c06-b3b0-4f48c6efa...@email.android.com
Re: lilo removal in squeeze (or, please test grub2)
Paul Vojta, le Thu 27 May 2010 00:47:14 +, a écrit : In article enjn8-64s...@gated-at.bofh.it, Ferenc Wagner wf...@niif.hu wrote: Sorry, I don't trust in the future of LILO myself. If there's anything which only LILO can do, I recommend you start complaining on the Syslinux and the Grub mailing lists. I suppose it will be heard. Does either grub2 or syslinux allow for single-key booting? It is available in the experimental branch of grub2. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527013126.gr4...@const.famille.thibault.fr
Meaning of the different “ format” fields and files.
Dear all, I am getting confused by the different meanings of the Format fields and the format file in the Debian source packages and their accompanying files. [In the paragraphs below, I name the files according to Policy 3.8.4 §5] * In Debian changes files, Format is currently 1.8; I suppose that it defines the meaning and syntax of the other fields. Is there a place were the history of this file format is defined? Is it a general format number for what we call the “pseudo RFC-822”, “paragraph”, or “stanza” format? * In the Debian source control files, Format is 1.0 or 3.0 (variant). This defines the format of the source package. Is the format of the Debian source control file itself tied to the format of the source package, or is it independant as for the changes files? * A Format field in source package control files used to determine the Format field of the Debian source control files, but in the latest Policy, this field is not listed in §5.2, that defines source package control files. However, other fields, like the VCS-* fields are not listed there, so it does not mean that the Format field is disallowed. Nevertheless it seems to be deprecated. Should the policy be updated to reflect this? * §5.6.16 specifies a value of 1.5 for all Format fields. Is it a source package format version or a “pseudo RFC-822” format version. If yes should this number be updated to 1.8, or even to 1.9 to reflect that the Format field is deprecated in source package control files? * Lastly, there is the new debian/source configuration directory, that is used by the latest dpkg-dev, but also by lintian. Is the structure of this directory described somewhere? Is it versionned? Needless to say, I volunteer to send a patch to the Policy that will summarise the answers to this email. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527050522.gb13...@kunpuu.plessy.org
Accepted jfractionlab 0.84-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 10:52:09 +0200 Source: jfractionlab Binary: jfractionlab Architecture: source all Version: 0.84-2 Distribution: unstable Urgency: low Maintainer: José L. Redrejo Rodríguez jredr...@debian.org Changed-By: José L. Redrejo Rodríguez jredr...@debian.org Description: jfractionlab - Educative program to practice fractions Closes: 581115 Changes: jfractionlab (0.84-2) unstable; urgency=low . * Fix bashism in JFractionLab script (Closes: #581115) Checksums-Sha1: 5a7df2a41fa9ce68c5f8c9fd1ee17f51e50cc0d4 1110 jfractionlab_0.84-2.dsc 70c40b6d39ae857454d5aafa48ebe01dd47f4103 7914 jfractionlab_0.84-2.debian.tar.gz f876ad38ad02eb0f905852a0ed261d71c4f05084 5032576 jfractionlab_0.84-2_all.deb Checksums-Sha256: 188641d4ee1ab8b838a41bf3c478b0386f5f23ade8fa2acbbed724abb9cd8cec 1110 jfractionlab_0.84-2.dsc 2e7d5c9de1059d0e5f4189eb26d70990346f21c3a7e65b8cba50751a84f1d10c 7914 jfractionlab_0.84-2.debian.tar.gz 6286aba083a5541de582558ea4055c3bd7187cd88a96b238de626c6668e2f7bb 5032576 jfractionlab_0.84-2_all.deb Files: 97fc4edafa3bdf7aa39829aa290b3923 1110 math extra jfractionlab_0.84-2.dsc ee3c8fcd6af7acca65f9757143a28a3f 7914 math extra jfractionlab_0.84-2.debian.tar.gz 0518aa17314fd00bdd30b797fd51aa51 5032576 math extra jfractionlab_0.84-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv84xkACgkQmqVR2WapDeLPjQCfaGIcT+DdfRwkV9FgVx08TsWt 8dUAoJKLxBu9ndAtV6Q3vGXLBSOxqVIg =u+2V -END PGP SIGNATURE- Accepted: jfractionlab_0.84-2.debian.tar.gz to main/j/jfractionlab/jfractionlab_0.84-2.debian.tar.gz jfractionlab_0.84-2.dsc to main/j/jfractionlab/jfractionlab_0.84-2.dsc jfractionlab_0.84-2_all.deb to main/j/jfractionlab/jfractionlab_0.84-2_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohdad-00018f...@ries.debian.org
Accepted libdrm 2.4.20-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 26 May 2010 10:33:22 +0200 Source: libdrm Binary: libdrm-dev libdrm2 libdrm2-dbg libdrm-intel1 libdrm-intel1-dbg libdrm-nouveau1 libdrm-nouveau1-dbg libdrm-radeon1 libdrm-radeon1-dbg Architecture: source amd64 Version: 2.4.20-3 Distribution: experimental Urgency: low Maintainer: Debian X Strike Force debia...@lists.debian.org Changed-By: Julien Cristau jcris...@debian.org Description: libdrm-dev - Userspace interface to kernel DRM services -- development files libdrm-intel1 - Userspace interface to intel-specific kernel DRM services -- runt libdrm-intel1-dbg - Userspace interface to intel-specific kernel DRM services -- debu libdrm-nouveau1 - Userspace interface to nouveau-specific kernel DRM services -- ru libdrm-nouveau1-dbg - Userspace interface to nouveau-specific kernel DRM -- debugging s libdrm-radeon1 - Userspace interface to radeon-specific kernel DRM services -- run libdrm-radeon1-dbg - Userspace interface to radeon-specific kernel DRM services -- deb libdrm2- Userspace interface to kernel DRM services -- runtime libdrm2-dbg - Userspace interface to kernel DRM services -- debugging symbols Changes: libdrm (2.4.20-3) experimental; urgency=low . [ Sven Joachim ] * Update libdrm-nouveau1 to the ABI of Linux 2.6.34. - Drop 03_revert_abi_change.diff. - Bump libdrm-nouveau shlibs and symbols versions to 2.4.20-3~ to ensure that packages built against this version are not used with an older libdrm-nouveau1 version. - Add versioned Breaks against xserver-xorg-video-nouveau to force an upgrade of that package and prevent X segfaults. * Include full SONAME in libdrm-nouveau1.install. * Update xsfbs to 81fc271788605b52e85c2d11635a0371fb44605e0. Checksums-Sha1: 8363ea66dbb6cf73cf16e51f142f3f479e767c84 2080 libdrm_2.4.20-3.dsc 5c97e7b872b7d6d842463b2a802d671155c90a40 412728 libdrm_2.4.20-3.diff.gz 578f11c4d1667b8c4a4136b4926b1098ba736ad1 560412 libdrm-dev_2.4.20-3_amd64.deb 167bf47e702a031c93989644feb82bfdfc48a678 413160 libdrm2_2.4.20-3_amd64.deb 146fd6899461d80d8d5ad179a4564aff94b2ed6d 427064 libdrm2-dbg_2.4.20-3_amd64.deb c673bf6b14828c1c590fd277e89aa07081f5b9dd 413472 libdrm-intel1_2.4.20-3_amd64.deb 3f404c4ff79ba33b55db800312fa4e821da6d1c6 425654 libdrm-intel1-dbg_2.4.20-3_amd64.deb 93e4cd1d964ead91a583620b620c21c1a2b802a4 403306 libdrm-nouveau1_2.4.20-3_amd64.deb c76e393939e1c15cd4e1bf8f307987396e8ee41b 414206 libdrm-nouveau1-dbg_2.4.20-3_amd64.deb 3b4d39cac52cd0b89e248c024ac3f1b2a23b1bb4 401032 libdrm-radeon1_2.4.20-3_amd64.deb 367d623aaf5acca491b6e5f2e955b4f21f975bcc 409330 libdrm-radeon1-dbg_2.4.20-3_amd64.deb Checksums-Sha256: 2bc028ec4c17d5ed76db31c366112d52b02e201077d6586786bf8f64565c143b 2080 libdrm_2.4.20-3.dsc c396490a2f6bb7549503b90bfd3748ef961ff629595de21fcd3c16f5f510f73d 412728 libdrm_2.4.20-3.diff.gz b2312ac5b50868de999e3755390ccb836c0504c78f4ec5101e46dd587fb14b37 560412 libdrm-dev_2.4.20-3_amd64.deb bc7b237d63c3bcb2f69b6fcd339d93a33450c7ffa469e0118a339a2fff714ae8 413160 libdrm2_2.4.20-3_amd64.deb 7536f053340c86db9e1f44b9c521ac19b5bd8deafc20e87b84967086dad3a51e 427064 libdrm2-dbg_2.4.20-3_amd64.deb 6d6641c343b5dcd0262572afcfea239129412cb5bb985f757feefeaff0952fd0 413472 libdrm-intel1_2.4.20-3_amd64.deb 08603fccedad4cf03bf996ec18d7d726711e43787906271a857c0ba2491a3d0b 425654 libdrm-intel1-dbg_2.4.20-3_amd64.deb eae5caf96408cb196f315e27e31dd5df52ae64af027cb5e01fb9989fa11349ab 403306 libdrm-nouveau1_2.4.20-3_amd64.deb 1468cda17ee64a55d9d5a28c02899670ea5519729261bac65995b79afa9b29ea 414206 libdrm-nouveau1-dbg_2.4.20-3_amd64.deb 8f01d7b2f83d6b7c86129a0c29223ef2b5ef28c279fd2f4a007987b35aa2d52c 401032 libdrm-radeon1_2.4.20-3_amd64.deb 0b5a45b7b79c93a884a25ff019630ab31f89b780656774966dc417bc77b0b105 409330 libdrm-radeon1-dbg_2.4.20-3_amd64.deb Files: 1f020dac556fd11a678d38cf26fd4ff5 2080 libs optional libdrm_2.4.20-3.dsc e208fc0ea515979276bf4c66095201f5 412728 libs optional libdrm_2.4.20-3.diff.gz 8fbc6afdec317c5ecb939a24fdde7f94 560412 libdevel optional libdrm-dev_2.4.20-3_amd64.deb 94e7f2664aec2475a69a57bc7edcc5e2 413160 libs optional libdrm2_2.4.20-3_amd64.deb 684108c9a6f531b0e610f1cf5f7fc4af 427064 debug extra libdrm2-dbg_2.4.20-3_amd64.deb bcc8fb0c92e3fa0f09c17dd266db7c90 413472 libs optional libdrm-intel1_2.4.20-3_amd64.deb 036f0c232856f1d1a0edfa82b8ff1ede 425654 debug extra libdrm-intel1-dbg_2.4.20-3_amd64.deb b11609d1a09f513fe833c7534ca77111 403306 libs optional libdrm-nouveau1_2.4.20-3_amd64.deb 72c3aa33bebdb6f466fd16b7cc9c5928 414206 debug extra libdrm-nouveau1-dbg_2.4.20-3_amd64.deb adfb4565632e05f95820b13f3bf298a2 401032 libs optional libdrm-radeon1_2.4.20-3_amd64.deb bc6c314de3efcf7e8d19f002ae73ee1a 409330 debug extra libdrm-radeon1-dbg_2.4.20-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJL/N8CAAoJEDEBgAUJBeQMnmoP/2P4O7+f0sbnUIAlNRbx60U3
Accepted lm-sensors-3 1:3.1.2-5 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 11:15:17 +0200 Source: lm-sensors-3 Binary: lm-sensors libsensors4 libsensors4-dev fancontrol sensord Architecture: source amd64 all Version: 1:3.1.2-5 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno aure...@debian.org Changed-By: Aurelien Jarno aure...@debian.org Description: fancontrol - utilities to read temperature/voltage/fan sensors libsensors4 - library to read temperature/voltage/fan sensors libsensors4-dev - lm-sensors development kit lm-sensors - utilities to read temperature/voltage/fan sensors sensord- hardware sensor information logging daemon Closes: 582979 Changes: lm-sensors-3 (1:3.1.2-5) unstable; urgency=low . * Use the --check option in both the initscript and the fancontrol script (closes: bug#582979). Checksums-Sha1: da7c88417d7109e100bc75d8a08f1d8fe952b191 1099 lm-sensors-3_3.1.2-5.dsc cc09c7bd3dd5fbc278f1749b86769f230a0170e7 31041 lm-sensors-3_3.1.2-5.diff.gz 993fecbc255411745abba607981ce66f9e5b8302 118100 lm-sensors_3.1.2-5_amd64.deb 47670c4907a60b14b0b51c65f71b4253f10f78eb 54232 libsensors4_3.1.2-5_amd64.deb 744cf53f02e06d1ebb1c9aeaea04bb1a25a94683 60366 libsensors4-dev_3.1.2-5_amd64.deb 78db4d0d68fa4aa3e246b78bebe9c0ae3040bd43 44252 sensord_3.1.2-5_amd64.deb 71b1aaf37c22241d045beed46cf7718a0c52cb68 40766 fancontrol_3.1.2-5_all.deb Checksums-Sha256: 2767f26ace2d79efcd70bd98bd2a59db463553d209662f2227374709cf0e7a11 1099 lm-sensors-3_3.1.2-5.dsc 78a1eeda21a2664e408c003cb7c230d4594b837b251a96dfe2da61cfcda721f7 31041 lm-sensors-3_3.1.2-5.diff.gz 28a9f42813d0c0419b16d89ad13aee4fcb63be96f1fbd987b4a778ef3f5407ad 118100 lm-sensors_3.1.2-5_amd64.deb 8033ec4989a49352f5849fb37795d6218c5aed4cf3bc678590f4d906eb6b7fbb 54232 libsensors4_3.1.2-5_amd64.deb 60dd3ad40aad324968a0130818f600fac56c0427f8176a36737c07436c4c13e9 60366 libsensors4-dev_3.1.2-5_amd64.deb bf9f090f1a4af66626b4fa118db33aab58a72ddbffcdb1f2627b674b2808f11d 44252 sensord_3.1.2-5_amd64.deb 8e911cded06aad6e5ba6fa0f6895c1f31101c8d5f565c2d9efa5c42e8dc105f6 40766 fancontrol_3.1.2-5_all.deb Files: 99550b04509ecf3055e2f9fe72c845c1 1099 utils extra lm-sensors-3_3.1.2-5.dsc 2f8f4ab8412ba73727389d2d39821ada 31041 utils extra lm-sensors-3_3.1.2-5.diff.gz ae84ce17169394c7658fabc7f2a084ed 118100 utils extra lm-sensors_3.1.2-5_amd64.deb 0024c277df4e62c8196469d8b0172fba 54232 libs optional libsensors4_3.1.2-5_amd64.deb e7e5d07141c99b1a6b30b5005bc7ffde 60366 libdevel extra libsensors4-dev_3.1.2-5_amd64.deb 77b66831a390b154c297c74c4078726a 44252 utils extra sensord_3.1.2-5_amd64.deb 44297ab8a5f6e09e4fe15ce71effce07 40766 utils extra fancontrol_3.1.2-5_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFL/OiQw3ao2vG823MRArVKAJ40/4x2M6SrBa11ctQn9vAAIfONjgCdEKNV hD4YR/ui83w7go7R+6aQUDU= =30FU -END PGP SIGNATURE- Accepted: fancontrol_3.1.2-5_all.deb to main/l/lm-sensors-3/fancontrol_3.1.2-5_all.deb libsensors4-dev_3.1.2-5_amd64.deb to main/l/lm-sensors-3/libsensors4-dev_3.1.2-5_amd64.deb libsensors4_3.1.2-5_amd64.deb to main/l/lm-sensors-3/libsensors4_3.1.2-5_amd64.deb lm-sensors-3_3.1.2-5.diff.gz to main/l/lm-sensors-3/lm-sensors-3_3.1.2-5.diff.gz lm-sensors-3_3.1.2-5.dsc to main/l/lm-sensors-3/lm-sensors-3_3.1.2-5.dsc lm-sensors_3.1.2-5_amd64.deb to main/l/lm-sensors-3/lm-sensors_3.1.2-5_amd64.deb sensord_3.1.2-5_amd64.deb to main/l/lm-sensors-3/sensord_3.1.2-5_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohdhc-0002na...@ries.debian.org
Accepted hw-detect 1.78 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 08:04:02 +0200 Source: hw-detect Binary: hw-detect ethdetect disk-detect driver-injection-disk-detect archdetect Architecture: source i386 all Version: 1.78 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Petter Reinholdtsen p...@debian.org Description: archdetect - Hardware architecture detector (udeb) disk-detect - Detect disk drives (udeb) driver-injection-disk-detect - Detect OEM driver injection disks (udeb) ethdetect - Detect network hardware and load kernel drivers for it (udeb) hw-detect - Detect hardware and load kernel drivers for it (udeb) Changes: hw-detect (1.78) unstable; urgency=low . [ Petter Reinholdtsen ] * Add support for Dell Driver Injection disk v1, an integrated flash media based solution for adding in drivers after OS launches. Patch from Mario Limonciello and Ubuntu (LP: #341526). This add some untranslated strings the the .po files. * Install mouseemu on systems likely to have single-button mice (i.e. non-desktop Macs LP: #251830), but not powerpc64 since it is said to cause an oops in the input layer. Patch from Colin Watson and Ubuntu. * Depend on pciutils-udeb for lspci. Patch from Colin Watson and Ubuntu. * Adjust code reloading modules in check-missing-firmware.sh to only reload once when a module need several firmware files. Checksums-Sha1: 48237335253be8b18d4b262cacb45c7155ffdce2 988 hw-detect_1.78.dsc b80755e89480572bf99d1122c72a8cdef3fee9d7 174465 hw-detect_1.78.tar.gz 1df2017bfa4725e83f7d9bce69ff5e1ab9589e66 93536 hw-detect_1.78_i386.udeb a0f371bb32739f323c8b99488f60bc68cf869c80 27774 ethdetect_1.78_all.udeb f26af65f7b606efc573ed340d7106c03b96235ba 21220 disk-detect_1.78_all.udeb 21ea480e8ded8030f2fe43c19cae008a389295e5 1662 driver-injection-disk-detect_1.78_all.udeb a6cd4509e6a0272c1f479b8f85bea19f3881dad7 2146 archdetect_1.78_i386.udeb Checksums-Sha256: c851a556dd3fe5d33ac1be97eebfba15d82f4f796b39d01a10df43c33893dd50 988 hw-detect_1.78.dsc 0490c24757b84a13db8c3bafe4c00bb62992f42bc0c1f4e6edf1435f5f7bcb55 174465 hw-detect_1.78.tar.gz 4c82bd3dbcc71b59d8275ef402062ba4f9fa6ff2e0670787ea0361bdc5514026 93536 hw-detect_1.78_i386.udeb a85e9b5858ac4ca54137bd0986cb755e7935a7be9fa83512f8f3abb9030e687f 27774 ethdetect_1.78_all.udeb 09f807a6bf2e411e8545c3cb75a989aea1cb468dd1235667139db9fda35e8aa5 21220 disk-detect_1.78_all.udeb 08598fd7ce770f83e8398f9bdc454645b84f97231e982fb3642a17572ff0f94a 1662 driver-injection-disk-detect_1.78_all.udeb a8b085df7441ae4c0d699212529f923aaaebdef95c98a587a91e7c120c941bc8 2146 archdetect_1.78_i386.udeb Files: 1a9b01cedd035a6d3ef28edd74e3cfcc 988 debian-installer standard hw-detect_1.78.dsc c48a1b5504af2fb628cfe246f11c213d 174465 debian-installer standard hw-detect_1.78.tar.gz 32d46aa1235e7575094025edba72d9ff 93536 debian-installer standard hw-detect_1.78_i386.udeb fccaf0d1a6f8d8f357d7097468676d9c 27774 debian-installer optional ethdetect_1.78_all.udeb f7617ed50a252470fdc26f7d9c9e22b7 21220 debian-installer optional disk-detect_1.78_all.udeb 9b786e5b9f307375fc1af61f3fd4769a 1662 debian-installer optional driver-injection-disk-detect_1.78_all.udeb f306badc987f8c552bf5dfb799e995a4 2146 debian-installer standard archdetect_1.78_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFL/L1N20zMSyow1ykRAtvgAKCfyKU1D67c2rzHWUAPU+i/EzSnAwCgiR+N lwOxExb5t/eQAAzmH4zpd2w= =pLO8 -END PGP SIGNATURE- Accepted: archdetect_1.78_i386.udeb to main/h/hw-detect/archdetect_1.78_i386.udeb disk-detect_1.78_all.udeb to main/h/hw-detect/disk-detect_1.78_all.udeb driver-injection-disk-detect_1.78_all.udeb to main/h/hw-detect/driver-injection-disk-detect_1.78_all.udeb ethdetect_1.78_all.udeb to main/h/hw-detect/ethdetect_1.78_all.udeb hw-detect_1.78.dsc to main/h/hw-detect/hw-detect_1.78.dsc hw-detect_1.78.tar.gz to main/h/hw-detect/hw-detect_1.78.tar.gz hw-detect_1.78_i386.udeb to main/h/hw-detect/hw-detect_1.78_i386.udeb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohdfj-0004ns...@ries.debian.org
Accepted kingston-update-notifier 1.0 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 01 May 2010 18:00:56 +0200 Source: kingston-update-notifier Binary: update-notifier-kde Architecture: source amd64 Version: 1.0 Distribution: unstable Urgency: low Maintainer: Sune Vuorela s...@debian.org Changed-By: Sune Vuorela s...@debian.org Description: update-notifier-kde - Update notifier for the KDE Plasma Desktop Changes: kingston-update-notifier (1.0) unstable; urgency=low . * Initial Release. Checksums-Sha1: 31fa34c7c1458ebdc1d6f5129f7d0cec19d98654 789 kingston-update-notifier_1.0.dsc 1335ac1be71a9f55305d2ce6e75889900e7525fd 6354 kingston-update-notifier_1.0.tar.gz 8a097e62bfa0283cf14a1001d63a9cb294bb7275 15372 update-notifier-kde_1.0_amd64.deb Checksums-Sha256: ccc284bad07cbad53a7c30b2bd3dc5f4c4e21312db8f8f4b2a24760a46168acf 789 kingston-update-notifier_1.0.dsc bdb1b6fa5645c612f3c69fef38505fa3ea3720b7bfbbba838c50f1110e2da1b1 6354 kingston-update-notifier_1.0.tar.gz a177eb656e2d3110fc0b4d4e8549af02fd884404e607df578a353bda38e8dc18 15372 update-notifier-kde_1.0_amd64.deb Files: 823f43c3ae407937c747ddd0afd8c70d 789 kde optional kingston-update-notifier_1.0.dsc dc100cea1dda3bc39d62ab5ff3448b73 6354 kde optional kingston-update-notifier_1.0.tar.gz ca595ce5bae25171b31073e5fa377c0a 15372 kde optional update-notifier-kde_1.0_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkvhIZAACgkQnMvaFgH6i0qUUwCgi+TxmE2ZSSfgXVc7PBhwobLM SqkAoKtZh6Ls8F+DfWx7E3b2JkI7S6mJ =KSM+ -END PGP SIGNATURE- Accepted: kingston-update-notifier_1.0.dsc to main/k/kingston-update-notifier/kingston-update-notifier_1.0.dsc kingston-update-notifier_1.0.tar.gz to main/k/kingston-update-notifier/kingston-update-notifier_1.0.tar.gz update-notifier-kde_1.0_amd64.deb to main/k/kingston-update-notifier/update-notifier-kde_1.0_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohdfz-0004pu...@ries.debian.org
Accepted liblingua-en-inflect-phrase-perl 0.04-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 25 May 2010 22:43:40 +0100 Source: liblingua-en-inflect-phrase-perl Binary: liblingua-en-inflect-phrase-perl Architecture: source all Version: 0.04-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org Changed-By: Chris Butler chr...@debian.org Description: liblingua-en-inflect-phrase-perl - Inflect short English Phrases Closes: 580276 Changes: liblingua-en-inflect-phrase-perl (0.04-1) unstable; urgency=low . * Initial Release. (closes: #580276) Checksums-Sha1: 44dc21d4702add23be17994df0118bc7ac97d710 2126 liblingua-en-inflect-phrase-perl_0.04-1.dsc 0959d9ac6c34f3e56a0cbb410509b1862b412dc4 24418 liblingua-en-inflect-phrase-perl_0.04.orig.tar.gz 1b694a4a53e9c6c80bc684c033e0fee8a22f903b 1319 liblingua-en-inflect-phrase-perl_0.04-1.debian.tar.gz 8c66d1d3c19156e0fe7e6a1cfe6905580c23b294 6562 liblingua-en-inflect-phrase-perl_0.04-1_all.deb Checksums-Sha256: 28e4847d3503ea4bb847e4ae2b4b2d987e436cbf258bf42b02a759702113853d 2126 liblingua-en-inflect-phrase-perl_0.04-1.dsc 20713b94a78834ce5a247a0a3f953dd86567b46cdda1c7fbd6cbe7c0e6274789 24418 liblingua-en-inflect-phrase-perl_0.04.orig.tar.gz 1d7ffe2fef232d997fde1228c44e85a80e316c43469641c861b2acbd1345dc0e 1319 liblingua-en-inflect-phrase-perl_0.04-1.debian.tar.gz 441d2bfd5341d1b225c82d2a9d02de290d6d6b81793434c9e7f3ee10d612a792 6562 liblingua-en-inflect-phrase-perl_0.04-1_all.deb Files: 83e74f02a375bfa6a436f05d2302a0b7 2126 perl optional liblingua-en-inflect-phrase-perl_0.04-1.dsc 79aa10fd4a3502ff0c7b0aedce4a0f6a 24418 perl optional liblingua-en-inflect-phrase-perl_0.04.orig.tar.gz 31c60e5790805fd9bac90d52d6c8e8d0 1319 perl optional liblingua-en-inflect-phrase-perl_0.04-1.debian.tar.gz 7e3a6e97012f8388c01919af9ef45e93 6562 perl optional liblingua-en-inflect-phrase-perl_0.04-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJL/E1BAAoJEMOedOBJ46zTmH8P/ApbnSjLEkkElqZ4GZkky/We /FSWZyA703LNPQ9X0kVM+q3coIR+SMZy2A9ArIShoBmC7XUrpemRCFhBRGeGNdCl okYFYf6ketBThsKjKLdMiMEZe0PHLujg8k9TdixQ5ngXeRKHTLCXcR4WQJ+4SV6j R3P1rufwIVcUmiU7S1mdNGyGCgs6MoNHX76MoS+92QXG9Q4y+sEWDwHlQYLdhoa0 9Ki/yotwFhoarSLQKHr9KbCPlEH0wQUcSbvTLJsuhbKCyWAJelAQYTtJjCMJTw0w HDjLlaZ9pVfLnKkqL98gxgzjSZ/j8W/nSF1zXP39WE7O6Lo0a4vI3+TM6EIsNblf xMEzoHIoY4HX/C8pS/P8UYmYgsLIcMLVo/6LCQ7VtK3ksk/tZhlR5lqxiYg6ijQw H93v9EhUDSJx/ltgv36TKeojRd8KmYiPhrV4CfxV2O9l6xPfIHXmnSkIaznV/F5A Eq+qthuRwvHC6ciz02mGGiBdbdEcprtdp5gVjgWRkxtNpxYFxq0qYjwnrmTyDd18 rV8DjedZQ/OhEn6FxFtnNLDbCjvZGcncUvV7mznt0l1d8oi6rbpcko3uD3KbYRTR zVNkLBuYhw6wenGq1dupOrLUbMfduiBuwBt+HIlRBdLlcGi/qEAEIS+6ySDhVbds 102S7HB5703fUl3e1Ihd =N4EV -END PGP SIGNATURE- Accepted: liblingua-en-inflect-phrase-perl_0.04-1.debian.tar.gz to main/libl/liblingua-en-inflect-phrase-perl/liblingua-en-inflect-phrase-perl_0.04-1.debian.tar.gz liblingua-en-inflect-phrase-perl_0.04-1.dsc to main/libl/liblingua-en-inflect-phrase-perl/liblingua-en-inflect-phrase-perl_0.04-1.dsc liblingua-en-inflect-phrase-perl_0.04-1_all.deb to main/libl/liblingua-en-inflect-phrase-perl/liblingua-en-inflect-phrase-perl_0.04-1_all.deb liblingua-en-inflect-phrase-perl_0.04.orig.tar.gz to main/libl/liblingua-en-inflect-phrase-perl/liblingua-en-inflect-phrase-perl_0.04.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohdgf-0004rv...@ries.debian.org
Accepted pdfgrep 1.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Mon, 03 May 2010 10:43:01 +0200 Source: pdfgrep Binary: pdfgrep Architecture: source i386 Version: 1.0-1 Distribution: unstable Urgency: low Maintainer: Christoph Egger christ...@debian.org Changed-By: Christoph Egger christ...@debian.org Description: pdfgrep- search in pdf files for strings matching a regular expression Closes: 580065 Changes: pdfgrep (1.0-1) unstable; urgency=low . * Initial release (Closes: #580065) Checksums-Sha1: 7138ac8fe2bce2c0dff380e8b5fb16b5a6f650a1 1796 pdfgrep_1.0-1.dsc bd1c99c8e63f70e50162396a55ba93ae3e947af4 90215 pdfgrep_1.0.orig.tar.gz 56b1e3427e3a149b1326ea6922bfb9949d94bbe1 1766 pdfgrep_1.0-1.diff.gz c23cf107a45fe670acac29515bbf2f72bf29e56d 9628 pdfgrep_1.0-1_i386.deb Checksums-Sha256: a5ba83fb8f8f920a75416bfd6240e98558efe94918fcee74625a67dd132659fe 1796 pdfgrep_1.0-1.dsc ab989f24a50bebdbaeed301c15168ee2c73f24b7ba1a1701d23f5be3605fecd8 90215 pdfgrep_1.0.orig.tar.gz bef97d33099b965553f850abd6cc297efeb521ca4a864316ed25e196ed76e940 1766 pdfgrep_1.0-1.diff.gz 3c7a285f9d25ffeada2f6bc9c4df284d175f8711c50ce64a577c21910f7f2183 9628 pdfgrep_1.0-1_i386.deb Files: 74c8b8452334ac80b70a1eb8c8036e18 1796 utils optional pdfgrep_1.0-1.dsc 32c962ce4d6c03c78981c0331ab8fc47 90215 utils optional pdfgrep_1.0.orig.tar.gz 8f059839e99d67fab4c38a8e90ab6945 1766 utils optional pdfgrep_1.0-1.diff.gz 47e9b1e1d7ea64084cff9da7749264bb 9628 utils optional pdfgrep_1.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCgAGBQJL30tmAAoJEKv/7bJACMb5198QAKPNDFmfgC5gqFRNacvaw7Xo SHVh5yBx5+detI/VjV82f1BY6lwHaQzDCByfd56EvI/IPcRlErzlyzAKtDDAh/6Z RC9hTC5oy8NTuTLA75Fb+oCGUc0i6ifv6S/qrr+tIUsmAVq6hlpZdelBPc9XtaOv XMDUWGETTDUtMW1ug3LeG8dm7bEUCxNZNg4Tha4D44DCSJYtquklz2kcnKsBl8o9 CcAuPwyGmeY1VZv7aurWaQbUL/A3vtwg9vY7/s/0/LYQ/XSj2IZbXYxtLjIxKcYc lA73p7Ic3iyMLJ9TNL2dYfzBKLut7wgQTzuoZOeYNPzyidOvwYc0TNCja4lODoCk RUrJZRtyP1jgOF6Pi69H0VRiv4HQMMyIk8FYQDpGtLmhxhCM878kklFRsXP9Z5CH ZLnraw5dhx8g5w3gAQazjJsoDRj60GL/gZeXOmYlrSB8lL178vKwZiFo80wpJLJH M79D/msiclNsVJdZk/AfCX0rn6G2Bs6YbCHn9cJYQHBtKo6bewR8jvDVgIFkkx5f FRCgXQauzRZoLkJEn30brvnM0qa98f5N3cOQKmk/XPyLaTpwiN2MhsPORcmbP8zH 7JhnmG25XJxXlhpBqE5lCNEq4CwwFUPFGGNfA8faqf04TSi7F5OBCZM8q4yk5tWC CdnuKibtx7jhIvAdoWI5 =xUWe -END PGP SIGNATURE- Accepted: pdfgrep_1.0-1.diff.gz to main/p/pdfgrep/pdfgrep_1.0-1.diff.gz pdfgrep_1.0-1.dsc to main/p/pdfgrep/pdfgrep_1.0-1.dsc pdfgrep_1.0-1_i386.deb to main/p/pdfgrep/pdfgrep_1.0-1_i386.deb pdfgrep_1.0.orig.tar.gz to main/p/pdfgrep/pdfgrep_1.0.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohdgw-0004u2...@ries.debian.org
Accepted qt4-x11 4:4.7.0~beta1-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 21 May 2010 10:31:22 +0300 Source: qt4-x11 Binary: libqtcore4 libqt4-core libqtgui4 libqt4-gui libqt4-network libqt4-opengl libqt4-script libqt4-scripttools libqt4-sql libqt4-sql-ibase libqt4-sql-mysql libqt4-sql-odbc libqt4-sql-psql libqt4-sql-sqlite libqt4-sql-sqlite2 libqt4-sql-tds libqt4-svg libqt4-webkit libqt4-xml libqt4-xmlpatterns libqt4-dbus libqt4-qt3support libqt4-designer libqt4-help libqt4-test libqt4-multimedia libqt4-mediaservices libqt4-phonon libqt4-declarative libqt4-declarative-particles libqt4-declarative-multimedia libqt4-declarative-widgets libqt4-declarative-webkitqmlplugin libqt4-dev libqt4-opengl-dev libqt4-dbg libqt4-webkit-dbg libqt4-xmlpatterns-dbg qt4-demos-dbg qt4-designer qt4-dev-tools qt4-qmake qt4-qtconfig qt4-demos qt4-qmlviewer qt4-doc qt4-doc-html Architecture: source amd64 all Version: 4:4.7.0~beta1-1 Distribution: experimental Urgency: low Maintainer: Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org Changed-By: Fathi Boudra f...@debian.org Description: libqt4-core - transitional package for Qt 4 core non-GUI runtime libraries libqt4-dbg - Qt 4 library debugging symbols libqt4-dbus - Qt 4 D-Bus module libqt4-declarative - Qt 4 Declarative module libqt4-declarative-multimedia - Qt 4 multimedia QML plugin libqt4-declarative-particles - Qt 4 particles QML plugin libqt4-declarative-webkitqmlplugin - Qt 4 WebKit QML plugin libqt4-declarative-widgets - Qt 4 widgets QML plugin libqt4-designer - Qt 4 designer module libqt4-dev - Qt 4 development files libqt4-gui - transitional package for Qt 4 GUI runtime libraries libqt4-help - Qt 4 help module libqt4-mediaservices - Qt 4 MediaServices module libqt4-multimedia - Qt 4 Multimedia module libqt4-network - Qt 4 network module libqt4-opengl - Qt 4 OpenGL module libqt4-opengl-dev - Qt 4 OpenGL library development files libqt4-phonon - Qt 4 Phonon module libqt4-qt3support - Qt 3 compatibility library for Qt 4 libqt4-script - Qt 4 script module libqt4-scripttools - Qt 4 script tools module libqt4-sql - Qt 4 SQL module libqt4-sql-ibase - Qt 4 InterBase/FireBird database driver libqt4-sql-mysql - Qt 4 MySQL database driver libqt4-sql-odbc - Qt 4 ODBC database driver libqt4-sql-psql - Qt 4 PostgreSQL database driver libqt4-sql-sqlite - Qt 4 SQLite 3 database driver libqt4-sql-sqlite2 - Qt 4 SQLite 2 database driver libqt4-sql-tds - Qt 4 FreeTDS database driver libqt4-svg - Qt 4 SVG module libqt4-test - Qt 4 test module libqt4-webkit - Qt 4 WebKit module libqt4-webkit-dbg - Qt 4 WebKit library debugging symbols libqt4-xml - Qt 4 XML module libqt4-xmlpatterns - Qt 4 XML patterns module libqt4-xmlpatterns-dbg - Qt 4 XML patterns library debugging symbols libqtcore4 - Qt 4 core module libqtgui4 - Qt 4 GUI module qt4-demos - Qt 4 examples and demos qt4-demos-dbg - Qt 4 examples and demos debugging symbols qt4-designer - graphical designer for Qt 4 applications qt4-dev-tools - Qt 4 development tools qt4-doc- Qt 4 API documentation qt4-doc-html - Qt 4 API documentation (HTML format) qt4-qmake - Qt 4 qmake Makefile generator tool qt4-qmlviewer - Qt 4 QML viewer qt4-qtconfig - Qt 4 configuration tool Changes: qt4-x11 (4:4.7.0~beta1-1) experimental; urgency=low . * New upstream release. - QtAssistant client library removal (libqt4-assistant). - legacy Qt Assistant removal (assistant_adp). - new QtDeclarative module (libqt4-declarative). - new QtMediaServices module (libqt4-mediaservices). * Remove upstream patches: - 0001_qpixmap_load_no_modify_referenced_copies.diff - stolen upstream - 0002_qmake_qfileinfo_absolutepath.diff - stolen upstream - 0003_s390_fix_atomic_ops_related_crashes.diff - stolen upstream - 0004_problem_displaying_half_width_character.diff - stolen upstream - 0005_always_redraw_the_complete_control.diff - stolen upstream - 0006_expand_indicator_would_not_be_displayed.diff - stolen upstream * Remove Debian patches: - 82_hurd_SA_SIGINFO.diff - merged upstream - 95_sparc_platform_definition.diff - merged upstream - 98_alpha_ftbfs_wtf_platform_support.diff - stolen upstream * Refresh Debian patches: - 30_webkit_unaligned_access.diff - partially merged upstream * Update debian/control: - add libgstreamer0.10-dev, libgstreamer-plugins-base0.10-dev, libpulse-dev and libxv-dev build dependencies. - add libqt4-declarative, libqt4-mediaservices, libqt4-declarative-$PLUGINS and qt4-qmlviewer packages. - remove libqt4-assistant package. * Update debian/rules: - add -importdir configure option. * Update installed files. * Update symbols files. Checksums-Sha1: 08a2bd6f68cafcd4f85574870ce5997d11d93068 3086 qt4-x11_4.7.0~beta1-1.dsc ccb3126e64ce0a0142970a8898625fe5e84c7361 191807197 qt4-x11_4.7.0~beta1.orig.tar.gz c615fa3ff806ce0e587c412349e0ad4a5396b47c 403507
Accepted sciscipy 0.3.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 08 Feb 2010 12:06:28 +0100 Source: sciscipy Binary: python-sciscipy Architecture: source i386 Version: 0.3.0-1 Distribution: unstable Urgency: low Maintainer: Sylvestre Ledru sylves...@debian.org Changed-By: Sylvestre Ledru sylves...@debian.org Description: python-sciscipy - A Python binding of Scilab Closes: 579070 Changes: sciscipy (0.3.0-1) unstable; urgency=low . * Initial import (Closes: #579070) Checksums-Sha1: ad648c1c91570231c36a16bdecc42abca15245f6 1283 sciscipy_0.3.0-1.dsc 9cf1513a333e1bfb2faadcb0b31640e2389e743d 24575 sciscipy_0.3.0.orig.tar.gz 74bc7b811dc2d8c31916b2f1ba3da178bd24c922 2338 sciscipy_0.3.0-1.diff.gz b8e94643f334c176508391825d1d1b24ae1fb918 14308 python-sciscipy_0.3.0-1_i386.deb Checksums-Sha256: 3f7f7b61ef7066a1cd35aec19f78cc134ab7dcafa073ae7f0a6667abaf474212 1283 sciscipy_0.3.0-1.dsc 1e2c373fd4c2267f175a23f05f9cc05cb5bb31a76ed81c9f052a4ff9f96892a3 24575 sciscipy_0.3.0.orig.tar.gz 57eac1dc3f3b8b3a0381772a1f19b38951aba44c31f341210b4db90eb318dc41 2338 sciscipy_0.3.0-1.diff.gz 02c927c78d8d9fa233e91910fc4040f82ae924e1da112735b5ac6ee847db6af7 14308 python-sciscipy_0.3.0-1_i386.deb Files: 20d4f08e5663bd3a9057789ca892ed87 1283 python optional sciscipy_0.3.0-1.dsc 957f85c847e637ca20e9a9bac24c4ecc 24575 python optional sciscipy_0.3.0.orig.tar.gz 799c9136baeff2064b85d45c86239c7f 2338 python optional sciscipy_0.3.0-1.diff.gz 5c0c64b86d24b5cef6064b8fd07ec817 14308 python optional python-sciscipy_0.3.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkvfMecACgkQiOXXM92JlhCT8wCePEoftVgxypukBNvHi67riMGj wl4An0WIB9C1IY7wdMlWOxWoFQKY7eF4 =d+NZ -END PGP SIGNATURE- Accepted: python-sciscipy_0.3.0-1_i386.deb to main/s/sciscipy/python-sciscipy_0.3.0-1_i386.deb sciscipy_0.3.0-1.diff.gz to main/s/sciscipy/sciscipy_0.3.0-1.diff.gz sciscipy_0.3.0-1.dsc to main/s/sciscipy/sciscipy_0.3.0-1.dsc sciscipy_0.3.0.orig.tar.gz to main/s/sciscipy/sciscipy_0.3.0.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohdlt-0007ww...@ries.debian.org
Accepted uimaj 2.3.0-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 26 Apr 2010 22:22:45 +0200 Source: uimaj Binary: libuima-core-java libuima-vinci-java libuima-adapter-soap-java libuima-adapter-vinci-java libuima-cpe-java libuima-document-annotation-java libuima-tools-java uima-utils uima-examples uima-doc Architecture: source all Version: 2.3.0-1 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers pkg-java-maintain...@lists.alioth.debian.org Changed-By: Damien Raude-Morvan draz...@debian.org Description: libuima-adapter-soap-java - Library to provide SOAP web services within UIMA libuima-adapter-vinci-java - Library to provide Vinci web services within UIMA libuima-core-java - Core library for the UIMA framework libuima-cpe-java - Library for the UIMA Collection Processing Engine libuima-document-annotation-java - Library for the UIMA document annotation libuima-tools-java - UIMA library for the UIMA tools libuima-vinci-java - Library to handle Vinci web service protocol uima-doc - Documentation for the Apache UIMA framework uima-examples - Examples of UIMA components uima-utils - UIMA tools Closes: 56 Changes: uimaj (2.3.0-1) unstable; urgency=low . * New upstream release. * Initial release for Debian (Closes: #56) Checksums-Sha1: ddd832d028acd25c0a4196f727e84ecb404cf34b 1913 uimaj_2.3.0-1.dsc 792cb26443396fffc7f36e23f147a4b6b3f17e0d 8793656 uimaj_2.3.0.orig.tar.gz 453a53ab9218aa2d3653608dbcb6d676ccfc49a1 21647 uimaj_2.3.0-1.debian.tar.gz b0393ea7ffa4d5ecaf8c31bb37ffda22c9ccf118 1175300 libuima-core-java_2.3.0-1_all.deb a3874b02d379565feb9ff48319df73bc889748aa 136718 libuima-vinci-java_2.3.0-1_all.deb 74d9ed4aa332479a10dfc56f31f889e77e799f2e 34578 libuima-adapter-soap-java_2.3.0-1_all.deb 2012ce4cccb60337fd472cc2142cac4fe9ee4ca7 44338 libuima-adapter-vinci-java_2.3.0-1_all.deb 9773bf14508ca6b0e2a671605df7f1009937ed9b 318314 libuima-cpe-java_2.3.0-1_all.deb b167cdbb02d74db988d894a3ba59884e684594cd 9392 libuima-document-annotation-java_2.3.0-1_all.deb e954a9af1920017dd9b103574a2a2b75de7b8b61 479350 libuima-tools-java_2.3.0-1_all.deb bfab86ee999c7410dc8c674255572ba74475ed73 36334 uima-utils_2.3.0-1_all.deb dfe4040260bcfc75bda86204f37b22f170ee0aca 204654 uima-examples_2.3.0-1_all.deb 59829f5c5441c85e3039fd080c49b2ef11eef215 14318462 uima-doc_2.3.0-1_all.deb Checksums-Sha256: b65e493b82d654eef71106d64940d4d3ae029c70a336385c6279ffed28a9df8b 1913 uimaj_2.3.0-1.dsc 0402c63e3641292de1918aa2c6d52997740e9c508a4ed50441ee77ea88058bf9 8793656 uimaj_2.3.0.orig.tar.gz 37ae3574f591c7dba316a370793c9b4eb09db88a2c9aaa5ba34a3f48d2c4fdc4 21647 uimaj_2.3.0-1.debian.tar.gz 3dbc943eac956886381df92cba467753fa344a178da8ba2ea3f689aef5611401 1175300 libuima-core-java_2.3.0-1_all.deb 458129cd4160a51e510d67f35a71eccd8cb90bf115febe298c8c98100d2b6d7e 136718 libuima-vinci-java_2.3.0-1_all.deb 8e97e5cc0a8916e70846b2aa85abb7c085a32d6f6016f82447c3f5dfe33a0aa0 34578 libuima-adapter-soap-java_2.3.0-1_all.deb a26167cbb510a45a67c10bb906eef2f182bab668ee8c42739b155b5b15ca2c92 44338 libuima-adapter-vinci-java_2.3.0-1_all.deb daae1858b85244f1182ed83b9a59262684ffa5f64190d565ad5a28899855b4c7 318314 libuima-cpe-java_2.3.0-1_all.deb 0bde0571333e00639d8c60797e18122034cbcc63e561bd444c71930eeabaec55 9392 libuima-document-annotation-java_2.3.0-1_all.deb 7b60b97b7b4b0a84257359248d775e36b09fb75c2974ff03d37ba82b300acc21 479350 libuima-tools-java_2.3.0-1_all.deb b65a153f3411562733bd02b807decd8df0c3b492fa7808f9a76c6f5b90ef7e71 36334 uima-utils_2.3.0-1_all.deb 10ed79d53c623866c4d628480a745e96b46795da28e5a9d48de60b36dba0a387 204654 uima-examples_2.3.0-1_all.deb 18c9613f73302d5814a542963f3217ef3b535c77b4ec4366595e0bb9cb266e84 14318462 uima-doc_2.3.0-1_all.deb Files: a3f045d9ea731838db8450d0d226a642 1913 java optional uimaj_2.3.0-1.dsc 9be9cf33592630fd3368cbeae5d544c0 8793656 java optional uimaj_2.3.0.orig.tar.gz 8ff8090a01f9eb61c54659725ce73004 21647 java optional uimaj_2.3.0-1.debian.tar.gz 8da9f4f1ef6a131e9c7c4e78330a78b6 1175300 java optional libuima-core-java_2.3.0-1_all.deb 945391b36ab0d4235bc524c5204c0409 136718 java optional libuima-vinci-java_2.3.0-1_all.deb 0f83e95f8851104b10a69950f5e16cdd 34578 java optional libuima-adapter-soap-java_2.3.0-1_all.deb a258421605373cb8b95a62b772d91322 44338 java optional libuima-adapter-vinci-java_2.3.0-1_all.deb 88b95c057620c7d08eb4398348c4e4a6 318314 java optional libuima-cpe-java_2.3.0-1_all.deb ed09c91b9be33c6a0043606a4d5aabfc 9392 java optional libuima-document-annotation-java_2.3.0-1_all.deb 5942a16259b432cdabc5e033fb89fcbb 479350 java optional libuima-tools-java_2.3.0-1_all.deb afe5bebc4c5ba7a378652ac5b0c35165 36334 java optional uima-utils_2.3.0-1_all.deb 7b5f3a70a47eff62c4af1dd1b1c55012 204654 java optional uima-examples_2.3.0-1_all.deb 12cc3a033a769da57ac4eec5d7575612 14318462 doc optional uima-doc_2.3.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux)
Accepted gmic 1.3.5.1+dfsg-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 12:13:50 +0200 Source: gmic Binary: gmic gimp-gmic Architecture: source amd64 Version: 1.3.5.1+dfsg-1 Distribution: unstable Urgency: low Maintainer: Bernd Zeimetz b...@debian.org Changed-By: Bernd Zeimetz b...@debian.org Description: gimp-gmic - GIMP plugin for GREYC's Magic Image Converter gmic - GREYC's Magic Image Converter Changes: gmic (1.3.5.1+dfsg-1) unstable; urgency=low . * [97366020] Use -O0 in case the system we build on has less than 1GB RAM. * [6aca1038] Merge commit 'upstream/1.3.5.1+dfsg' * [fe6b2057] Fix awk call to evaluate the available memory. * [6806172f] Updating patches. Checksums-Sha1: fa46c7707d6534f7804d30c3fc30b44e602715e9 1371 gmic_1.3.5.1+dfsg-1.dsc 45039fe3c315f998af4a086239dda022e6161f41 719890 gmic_1.3.5.1+dfsg.orig.tar.gz c0251a71f544512ac71889408f69f053cc876447 12159 gmic_1.3.5.1+dfsg-1.debian.tar.gz f03f297e1328994600e8f2d63e2bc25224f78b82 4007198 gmic_1.3.5.1+dfsg-1_amd64.deb 4f77b3750c9b37219490260becdb619b9db67883 932274 gimp-gmic_1.3.5.1+dfsg-1_amd64.deb Checksums-Sha256: d288e3c0ccf56c072cb60ae742b7ee2a9f9b83e609cc55306fe7a63c06a6916e 1371 gmic_1.3.5.1+dfsg-1.dsc 941edf9b224640d503da4f830b6815a3d78c5b014ba4479ff7f63ec44337c614 719890 gmic_1.3.5.1+dfsg.orig.tar.gz 88478729f309214deb170ecafd6ae341b1ff349c6a1e95766152b1b7bf8ac4c9 12159 gmic_1.3.5.1+dfsg-1.debian.tar.gz 448f341e0a2c789e3bb38e72f4b5a5c17659ce00439581e26d2da9dd2d4b9b83 4007198 gmic_1.3.5.1+dfsg-1_amd64.deb 6c6b3477b43d2902e7bcc19ae3c4c847252981b3e3633920a1af7a6ce128285d 932274 gimp-gmic_1.3.5.1+dfsg-1_amd64.deb Files: 492faf75ab271589466bc82d0635c4a0 1371 graphics optional gmic_1.3.5.1+dfsg-1.dsc a3bade42215b9b5fb744ec7e0f19bfb1 719890 graphics optional gmic_1.3.5.1+dfsg.orig.tar.gz 93722a59f7839da337dfec88e71dc39a 12159 graphics optional gmic_1.3.5.1+dfsg-1.debian.tar.gz f3ba9e1be2e7610f43297391f322a89a 4007198 graphics optional gmic_1.3.5.1+dfsg-1_amd64.deb 6ac2e9aa53fd69cad236f93aceab1bec 932274 graphics optional gimp-gmic_1.3.5.1+dfsg-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv8/3EACgkQBnqtBMk7/3nJegCeKh8Vis4bXl5sgeUCCo0rqzr4 xqEAnjbhUHIedfN68L/xz0o7BfJwgSUt =bQfL -END PGP SIGNATURE- Accepted: gimp-gmic_1.3.5.1+dfsg-1_amd64.deb to main/g/gmic/gimp-gmic_1.3.5.1+dfsg-1_amd64.deb gmic_1.3.5.1+dfsg-1.debian.tar.gz to main/g/gmic/gmic_1.3.5.1+dfsg-1.debian.tar.gz gmic_1.3.5.1+dfsg-1.dsc to main/g/gmic/gmic_1.3.5.1+dfsg-1.dsc gmic_1.3.5.1+dfsg-1_amd64.deb to main/g/gmic/gmic_1.3.5.1+dfsg-1_amd64.deb gmic_1.3.5.1+dfsg.orig.tar.gz to main/g/gmic/gmic_1.3.5.1+dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1oheqi-0003sj...@ries.debian.org
Accepted libbio-mage-perl 20030502.3-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 20:34:03 +0900 Source: libbio-mage-perl Binary: libbio-mage-perl Architecture: source all Version: 20030502.3-2 Distribution: unstable Urgency: low Maintainer: Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org Changed-By: Charles Plessy ple...@debian.org Description: libbio-mage-perl - Container module for classes in the MAGE package: MAGE Changes: libbio-mage-perl (20030502.3-2) unstable; urgency=low . [ Charles Plessy] * Updated my email address (debian/control). * Incremented Standards-Version to reflect conformance with Policy 3.8.4 (debian/control, no changes needed). * Using Debhelper 7 (debian/control, debian/compat). . [Andreas Tille] * Standards-Version: 3.8.1 (no changes needed) * Fixed spacing in long description Checksums-Sha1: f9aa49514cda7d7ae122541b8e4515efc049eb8c 1426 libbio-mage-perl_20030502.3-2.dsc f5f2944f8e69c986f732b93c0880705e0f1e8680 1967 libbio-mage-perl_20030502.3-2.diff.gz 338f09fef1eec1b57b863b4be547e9e3149e3dd8 1732998 libbio-mage-perl_20030502.3-2_all.deb Checksums-Sha256: 2040d64f192acc36a6fd6d44a2ee97f98a0791c93c7bbfcc603b831ea4513ee7 1426 libbio-mage-perl_20030502.3-2.dsc 8115ee3736de5d3ad2f3fccf42e3593d86987808e2e1cca0b9c6a2a326448edd 1967 libbio-mage-perl_20030502.3-2.diff.gz 30a8e907374f4e27cf53f8545774b9762b8baebe1c30284ec3f604fcbd04b213 1732998 libbio-mage-perl_20030502.3-2_all.deb Files: 74537e6ac44ed52ca9b34f45117d8f6a 1426 science optional libbio-mage-perl_20030502.3-2.dsc 32047580130b26a584172ac52729b37f 1967 science optional libbio-mage-perl_20030502.3-2.diff.gz 52ab3e2e1eb9bf3e1f52fee80c344559 1732998 perl optional libbio-mage-perl_20030502.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkv9CCQACgkQdYl1krr+x/JO4ACePd7UPktGIH+wNbvVkGjt6GkT 2JAAn0e94yo8nSbQ6Si9pegoZ44QVKup =cDuP -END PGP SIGNATURE- Accepted: libbio-mage-perl_20030502.3-2.diff.gz to main/libb/libbio-mage-perl/libbio-mage-perl_20030502.3-2.diff.gz libbio-mage-perl_20030502.3-2.dsc to main/libb/libbio-mage-perl/libbio-mage-perl_20030502.3-2.dsc libbio-mage-perl_20030502.3-2_all.deb to main/libb/libbio-mage-perl/libbio-mage-perl_20030502.3-2_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohf50-0004my...@ries.debian.org
Accepted xserver-xorg-video-nouveau 1:0.0.16+git20100518+4b8f1a0-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 26 May 2010 13:28:28 +0200 Source: xserver-xorg-video-nouveau Binary: xserver-xorg-video-nouveau xserver-xorg-video-nouveau-dbg Architecture: source amd64 Version: 1:0.0.16+git20100518+4b8f1a0-1 Distribution: experimental Urgency: low Maintainer: Debian X Strike Force debia...@lists.debian.org Changed-By: Julien Cristau jcris...@debian.org Description: xserver-xorg-video-nouveau - X.Org X server -- Nouveau display driver (experimental) xserver-xorg-video-nouveau-dbg - X.Org X server -- Nouveau display driver (debug symbols) Changes: xserver-xorg-video-nouveau (1:0.0.16+git20100518+4b8f1a0-1) experimental; urgency=low . [ Sven Joachim ] * New upstream snapshot, with uevent support. - Add build-dependency on libudev-dev. * Build against updated librm, kernel 2.6.34 is now required. - Bump build-dependency on libdrm-dev to (= 2.4.20-3~). * Add a NEWS.Debian for that problem and update README.Debian. * Add myself to Uploaders. Checksums-Sha1: a3e25dd6105e9ba9da6a962fb2f51a40c4a72d11 2595 xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.dsc a38ac312ce9f2d18a2073b4d6ea4ce42bfc6fc0d 325194 xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0.orig.tar.gz 186862dc34af273ac72964ef6b0fb10cc4634458 44006 xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.diff.gz 15d0e83ac0157a9150c726b9ef2367317ad5623f 275488 xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1_amd64.deb 555cdd08e99629630fc593f241d9fbe5ed28486f 679036 xserver-xorg-video-nouveau-dbg_0.0.16+git20100518+4b8f1a0-1_amd64.deb Checksums-Sha256: 66b3c6f77cf2ec88b0a42a2a73e506674b2eee67f776559bf96e47cbff0efced 2595 xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.dsc 8c4b6218d28adb28f22f8137dc594fb1e83fb02a0ff93544e9e2545fb2042871 325194 xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0.orig.tar.gz 489d69f89649ba57d7eaf9399faece7c3735f696ecb3cf793af69aada258d408 44006 xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.diff.gz faea01f9c8194e5dbe283e809f93da65a1aee7c3904ce65e1fbe0417a997dd13 275488 xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1_amd64.deb 354d354dd448d3eb6cf71d4749524275c27ee2b00eaff209fbcef653b79e8445 679036 xserver-xorg-video-nouveau-dbg_0.0.16+git20100518+4b8f1a0-1_amd64.deb Files: 54a5016ccba0391915db881ee6ffa947 2595 x11 optional xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.dsc 84f70bf2dc3d8d6a82269022e6dcac79 325194 x11 optional xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0.orig.tar.gz 0e3eb5124ea7702acae8f64703a545f2 44006 x11 optional xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.diff.gz f2c4b6f82703b429119798b8d37f3c10 275488 x11 optional xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1_amd64.deb 528b00bf33e4483b3c151fa58f7a6cd4 679036 debug extra xserver-xorg-video-nouveau-dbg_0.0.16+git20100518+4b8f1a0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJL/Qd+AAoJEDEBgAUJBeQMgR4P/0orWipwmLqVvJFioy9DY05y pfl3aoRcrYg+6TMAamRR+KyMTUG0ywfIlh2fYE+qocTkfJjMn8jtXMixkWkjwOp8 XTMu8l587uGwtYZYc250YUmAiz8R0JH6iuupOSKUsHFKDijbYaWkL9FQRkURjAu5 rok3yzLa1dG6YyhA/D4Ot0OiAkDNTEsC24druUl/ONp80eF1ltPzlZ63r45mzRA5 Gin96RGWtjfGXKK2ZwF09XYT+HnhwiRKjvp/wiToVPZt1a8XRutIP9r0B+QD8H+h qVC/d050B0al7AXWsurr9D6fDyXMh6tVDZspUnqgkS/pxz2YM5YY25c0DOO2i1vo xe8JyRfNR14KT/QtYT5ztoUcpa8a0jd1/wyKy34Z8OIiXWICx/TaaEL79qewj8Ud QuG1dE/oOcjqC/f0nnIcbfGsiV5bGfUweqKCrfjLvfPIHhiBN8217KOtEzYKijnu ZSTmldsH7JeEm3RNCAqrAhnjPZaIAha00JTeVND7/ykBLG44XNRxE3eNCfrJmP3c QI77/rezX0PdSgzHmWwMphtI2G/BuR0gNdjI96KPbI2W7s9rN9HavICkrPk/ov3A kDjBqmgaIkXIF7xLG5UoeZiAoEIFolcIQtziId5NLElLb5flBLTPl7S7HEqdB30q 1TN7W1sxftvRf83iRgtI =tahT -END PGP SIGNATURE- Accepted: xserver-xorg-video-nouveau-dbg_0.0.16+git20100518+4b8f1a0-1_amd64.deb to main/x/xserver-xorg-video-nouveau/xserver-xorg-video-nouveau-dbg_0.0.16+git20100518+4b8f1a0-1_amd64.deb xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.diff.gz to main/x/xserver-xorg-video-nouveau/xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.diff.gz xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.dsc to main/x/xserver-xorg-video-nouveau/xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1.dsc xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1_amd64.deb to main/x/xserver-xorg-video-nouveau/xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0-1_amd64.deb xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0.orig.tar.gz to main/x/xserver-xorg-video-nouveau/xserver-xorg-video-nouveau_0.0.16+git20100518+4b8f1a0.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohf5u-0004rl...@ries.debian.org
Accepted jclic 0.2.1.0-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 11:06:04 +0200 Source: jclic Binary: jclic Architecture: source all Version: 0.2.1.0-1 Distribution: unstable Urgency: low Maintainer: José L. Redrejo Rodríguez jredr...@debian.org Changed-By: José L. Redrejo Rodríguez jredr...@debian.org Description: jclic - Tool for the development use of multimedia educational activiti Closes: 576465 581114 Changes: jclic (0.2.1.0-1) unstable; urgency=low . * New upstream version * Fixed bashism in jclic launcher (Closes: #581114) * Switch to dpkg-source 3.0 (quilt) format * debian/control: bumped standards version to 3.8.4 * debian/control: added quilt build dependency * fix detection of PulseAudio and remote DISPLAY, thanks again to Mario Izquierdo for his hints (Closes: #576465) Checksums-Sha1: 4f8d60acb437d64ea82844134408d8980b4011b1 1093 jclic_0.2.1.0-1.dsc 45d00b703eab28013451bbe75fd9ebd04d060906 2566146 jclic_0.2.1.0.orig.tar.gz 2d1131d0c9adda4f232fd08a17d889874695c014 7857 jclic_0.2.1.0-1.debian.tar.gz 8392e29e62c2b6cf63f0aff724848148fea67fbb 2175016 jclic_0.2.1.0-1_all.deb Checksums-Sha256: 39173361e1cbde7f3332e5ceceeab97e56285128699da4977bfbdce41b68acd1 1093 jclic_0.2.1.0-1.dsc 0542cc982f55c1eb022c54b8f7724d210d1cd0a9d592413a316d92a3c3a01b5f 2566146 jclic_0.2.1.0.orig.tar.gz 60c49ae3d40039d8791a85b84919f832dc96f57883c0e34a10728596ec3733e2 7857 jclic_0.2.1.0-1.debian.tar.gz 415e30709b352430878cebe01f71b1a3882fa4d7982e37492c74c5a288adbb9b 2175016 jclic_0.2.1.0-1_all.deb Files: 59cf9e7ac96505f1055e89e7bb27218e 1093 misc optional jclic_0.2.1.0-1.dsc fc60477d0036e0048ba896f9a585f7b5 2566146 misc optional jclic_0.2.1.0.orig.tar.gz dd213f9b1a68217244bc6cd6a6efd579 7857 misc optional jclic_0.2.1.0-1.debian.tar.gz ec59e7bc652496b4958af193273fd80b 2175016 misc optional jclic_0.2.1.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv9DlgACgkQmqVR2WapDeJphgCfdrv15tOfV1vHoNjXqe+QTRx3 0XAAnjq9IGxr5UpMvAFqK1Pic82oDclh =xSI9 -END PGP SIGNATURE- Accepted: jclic_0.2.1.0-1.debian.tar.gz to main/j/jclic/jclic_0.2.1.0-1.debian.tar.gz jclic_0.2.1.0-1.dsc to main/j/jclic/jclic_0.2.1.0-1.dsc jclic_0.2.1.0-1_all.deb to main/j/jclic/jclic_0.2.1.0-1_all.deb jclic_0.2.1.0.orig.tar.gz to main/j/jclic/jclic_0.2.1.0.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohfyf-0006jb...@ries.debian.org
Accepted r-base 2.11.1~20100525-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 06:48:15 -0500 Source: r-base Binary: r-base r-base-core r-base-dev r-mathlib r-base-html r-doc-pdf r-doc-html r-doc-info r-recommended r-base-core-dbg Architecture: source i386 all Version: 2.11.1~20100525-1 Distribution: unstable Urgency: low Maintainer: Dirk Eddelbuettel e...@debian.org Changed-By: Dirk Eddelbuettel e...@debian.org Description: r-base - GNU R statistical computation and graphics system r-base-core - GNU R core of statistical computation and graphics system r-base-core-dbg - GNU R debug symbols for statistical comp. language and environmen r-base-dev - GNU R installation of auxiliary GNU R packages r-base-html - GNU R html docs for statistical computing system functions r-doc-html - GNU R html manuals for statistical computing system r-doc-info - GNU R info manuals statistical computing system r-doc-pdf - GNU R pdf manuals for statistical computing system r-mathlib - GNU R standalone mathematics library r-recommended - GNU R collection of recommended packages [metapackage] Changes: r-base (2.11.1~20100525-1) unstable; urgency=low . * Release Candidate (r52102) of R 2.11.1 expected for May 31 Checksums-Sha1: 468f878fc05c50b43374c639c7b0ac218e855321 1788 r-base_2.11.1~20100525-1.dsc 131a6eb9ba9777e28efa2f7219c50ec5fecc904f 19728863 r-base_2.11.1~20100525.orig.tar.gz e16fae08efddaab9f4611936f5c5a0699eef1bd5 68296 r-base_2.11.1~20100525-1.diff.gz cf8fb63649c79d93b90e32983f13db1aa8f83abc 13622050 r-base-core_2.11.1~20100525-1_i386.deb f36a260c3b3584f1ee9cbfb3c066463ca5b7ed54 550544 r-mathlib_2.11.1~20100525-1_i386.deb 10cd3e3401e8fdd4f161ab34afec51cdd1edf3e9 2420612 r-base-core-dbg_2.11.1~20100525-1_i386.deb 05c223e07b30ad3b5d090fee461f1444cc6f9915 33844 r-base_2.11.1~20100525-1_all.deb 943e3d7f0550a00a8027f92b2522d15e225b9c7e 3498 r-base-dev_2.11.1~20100525-1_all.deb f8df5b02f395297eb4db36109d2d3a54f9e9906f 82132 r-base-html_2.11.1~20100525-1_all.deb 57d430ce0ac85987181d550a9f86719e9a1d020f 7780810 r-doc-pdf_2.11.1~20100525-1_all.deb 7005dc0cd2e9b588d5ae65cc503347739e65fde7 585250 r-doc-html_2.11.1~20100525-1_all.deb e24414c63b80e8f320dbcbd765535d8ad57ccdc5 502818 r-doc-info_2.11.1~20100525-1_all.deb d0e1d60b935afa8fe294747c10a2572d3d972caf 2682 r-recommended_2.11.1~20100525-1_all.deb Checksums-Sha256: 18f21516fa92bda995cd69e45aa35251d7c336113893dbdf1c04138d552792fb 1788 r-base_2.11.1~20100525-1.dsc 1e335f3de8c6614c355980472d2579bd241f0251ae63191d92b6d4ee9cf6b248 19728863 r-base_2.11.1~20100525.orig.tar.gz 4fff1527e877c3033f1b091e3088e4755bd78f0c670568ed732ec5081de67055 68296 r-base_2.11.1~20100525-1.diff.gz d6e8155e2b8893222a62d603a133a672849ed1381d04423a3e14834755a7413e 13622050 r-base-core_2.11.1~20100525-1_i386.deb 2a9af2da01eee86155817ac64f009870624e771f5a052e1b011cf382d7fc1a4b 550544 r-mathlib_2.11.1~20100525-1_i386.deb 6a017b6a1fa00a13b0e71037450cd749be409ec10c973ec8ee379503c487ebf4 2420612 r-base-core-dbg_2.11.1~20100525-1_i386.deb 57efa57b4aba5fb25e16b4690ba4ab8be3cd0e7075e413d7079b9fa5b03355d1 33844 r-base_2.11.1~20100525-1_all.deb 90f34d75c2f1b529e19a6b5d407ea846e78b8f194c9b8bec4968eac260cb956f 3498 r-base-dev_2.11.1~20100525-1_all.deb 4671042fa2a57ec8b3d10d389734eba3f539b49cc7268cdf4cb6551b6d4f10bb 82132 r-base-html_2.11.1~20100525-1_all.deb 3dee3c0d64582ab2d705627ff015b8e3fee899f189b8f395f03f725a3669e97f 7780810 r-doc-pdf_2.11.1~20100525-1_all.deb 3fbdb7583ff038ad39a3ba7b95ad1348a172c275fbf71f19d5c6d717870daac9 585250 r-doc-html_2.11.1~20100525-1_all.deb 6292af466ed6d160fa438826c7935e8adca04715cab4c27db72c7183a784e8cc 502818 r-doc-info_2.11.1~20100525-1_all.deb 0bef9a3340868f619e5eed04498c398d3cb17da2919437453d178c96776db2c6 2682 r-recommended_2.11.1~20100525-1_all.deb Files: 2964c77200abe333aba1a0f747624740 1788 gnu-r optional r-base_2.11.1~20100525-1.dsc 0e8977a72fcabf2b9c3673e62603 19728863 gnu-r optional r-base_2.11.1~20100525.orig.tar.gz daf0b205c44eade1c995afbfbc0bbbc6 68296 gnu-r optional r-base_2.11.1~20100525-1.diff.gz 088e576609ab6724e655aa19e081d41b 13622050 gnu-r optional r-base-core_2.11.1~20100525-1_i386.deb af8de0f0f6ba5e35a142621bb3ae5790 550544 gnu-r optional r-mathlib_2.11.1~20100525-1_i386.deb f97558658f51aa3a870139fad41dab2b 2420612 debug extra r-base-core-dbg_2.11.1~20100525-1_i386.deb 552af9cc74bdf88c02e25df3c8ad8e02 33844 gnu-r optional r-base_2.11.1~20100525-1_all.deb 25e337c178236ff33f0dee9c60d1f771 3498 gnu-r optional r-base-dev_2.11.1~20100525-1_all.deb b18be59a3f2af28d3716951cc1715d39 82132 doc extra r-base-html_2.11.1~20100525-1_all.deb e50af23b7c8f5244848f9cf3e8853d38 7780810 doc optional r-doc-pdf_2.11.1~20100525-1_all.deb 2ef8d41882735a261a4f1fda8f2020ba 585250 doc optional r-doc-html_2.11.1~20100525-1_all.deb 96ffaa1a64b120441e5621da4a148867 502818 doc optional r-doc-info_2.11.1~20100525-1_all.deb 85e8acada3b546f85c26e928c94843a7 2682 gnu-r optional
Accepted q4wine 0.118-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.8 Date: Wed, 26 May 2010 15:16:23 +0400 Source: q4wine Binary: q4wine Architecture: source amd64 Version: 0.118-3 Distribution: unstable Urgency: low Maintainer: Boris Pek tehnic...@mail.ru Changed-By: Boris Pek tehnic...@mail.ru Description: q4wine - Qt4 GUI for wine (W.I.N.E) Changes: q4wine (0.118-3) unstable; urgency=low . * Fixed `Depends' in debian/control. (wine for amd64, hurd-i386, i386, kfreebsd-i386, powerpc and sparc is now available only in experimental branch of Debian) * Fixed `Build-Depends' for hurd-i386 in debian/control. (wine for hurd-i386 is now available in experimental branch of Debian) * Removed xdg-utils dependency from debian/control. (It's unnecessary in Q4Wine since version 0.118) Checksums-Sha1: a99c3af91ccecec86f093a93f4eef5b031d6de7e 1234 q4wine_0.118-3.dsc 3818497d51d1f7b70dd069d0dcd6bfb241130ffb 3459 q4wine_0.118-3.debian.tar.gz 98989e5214050f09e7f2f33606603f1abdf1f32c 1281110 q4wine_0.118-3_amd64.deb Checksums-Sha256: 59d09e38937513b07f36cd3300ebcd74950042e81ce114ea5a1d63566ddc616c 1234 q4wine_0.118-3.dsc 8848c0c07f4b2793df45f85c6d17031d3fa39cf532dd69f63ff708c8ec40a601 3459 q4wine_0.118-3.debian.tar.gz 86056530f4314881aef5b7bc7dde3e1d93f169bce1d050c357f36ec0708eb608 1281110 q4wine_0.118-3_amd64.deb Files: e135889e67666fb114116bc8d37a95e4 1234 otherosfs optional q4wine_0.118-3.dsc 087ccbc2606142d8ffae906828ef4fdf 3459 otherosfs optional q4wine_0.118-3.debian.tar.gz ba1488fc3e2ed0f9fd36d0d461812975 1281110 otherosfs optional q4wine_0.118-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkv9EmQACgkQq4wAz/jiZTeK7gCeKzZ4GEJz8ori6C+ZdvBK1qzD yYgAoOpyJeG9P3FPOBgu0ks0po72qsgq =ODBH -END PGP SIGNATURE- Accepted: q4wine_0.118-3.debian.tar.gz to main/q/q4wine/q4wine_0.118-3.debian.tar.gz q4wine_0.118-3.dsc to main/q/q4wine/q4wine_0.118-3.dsc q4wine_0.118-3_amd64.deb to main/q/q4wine/q4wine_0.118-3_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohfpo-0007z1...@ries.debian.org
Accepted xfstt 1.7-8 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 14:08:40 +0200 Source: xfstt Binary: xfstt Architecture: source amd64 Version: 1.7-8 Distribution: unstable Urgency: low Maintainer: Guillem Jover guil...@debian.org Changed-By: Guillem Jover guil...@debian.org Description: xfstt - X Font Server for TrueType fonts Closes: 583202 Changes: xfstt (1.7-8) unstable; urgency=low . * Fix abort when listing fonts due to fortify support. The current code does not pose any real problem as the overwritten variable gets initialized later on, although the fix makes it correct and future-proof. Thanks to Erik Devriendt erik.devrie...@siemens.com. (Closes: #583202) Checksums-Sha1: 035794c111b546c35166b490cfb68d246f2c 1134 xfstt_1.7-8.dsc 1020bd54d74d7e12d9cf4ea7be5645e071da1b38 34223 xfstt_1.7-8.debian.tar.gz 0f0b55a000b459865e3041e93ecdd9546b3adb74 78488 xfstt_1.7-8_amd64.deb Checksums-Sha256: d943ab8349878a2afd6ae818cfbc54f30303954d3fbd5bf1c7961047a1c668a0 1134 xfstt_1.7-8.dsc ca7bb3f7be54854cec5703243a1f7d52c6996e20bda839c92de4589775124254 34223 xfstt_1.7-8.debian.tar.gz d94f0b37688b4d839e1b90017cc7a3ca549c96867ad8479eae01e176b28b184a 78488 xfstt_1.7-8_amd64.deb Files: 7b847e7df5602b42d2d31f00bdac6531 1134 x11 extra xfstt_1.7-8.dsc 5cbbb111d8041292dad99063e8b55762 34223 x11 extra xfstt_1.7-8.debian.tar.gz cd36cbcf84ec7a23ec66eb037a844008 78488 x11 extra xfstt_1.7-8_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv9D7IACgkQuW9ciZ2SjJtrTgCfecJKwa141EhdjRJFCXBiKu8B 934An3taM8Z00+liCekfNBD0HRWSMOi1 =pdyD -END PGP SIGNATURE- Accepted: xfstt_1.7-8.debian.tar.gz to main/x/xfstt/xfstt_1.7-8.debian.tar.gz xfstt_1.7-8.dsc to main/x/xfstt/xfstt_1.7-8.dsc xfstt_1.7-8_amd64.deb to main/x/xfstt/xfstt_1.7-8_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohfrd-0007hj...@ries.debian.org
Accepted grass 6.4.0~rc6+42329-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 24 May 2010 16:47:55 +0200 Source: grass Binary: grass grass-doc grass-dev Architecture: source all i386 Version: 6.4.0~rc6+42329-1 Distribution: unstable Urgency: low Maintainer: Debian GIS Project pkg-grass-de...@lists.alioth.debian.org Changed-By: Francesco Paolo Lovergine fran...@debian.org Description: grass - Geographic Resources Analysis Support System grass-dev - GRASS GIS development files grass-doc - Geographic Resources Analysis Support System documentation Changes: grass (6.4.0~rc6+42329-1) unstable; urgency=low . * New upstream snapshot with some fixes in modules. Checksums-Sha1: 58a544fcc4137b68b84fab36e6654cb638da2897 1804 grass_6.4.0~rc6+42329-1.dsc 70c36788957db567acbef6511cadebea564dc720 21988396 grass_6.4.0~rc6+42329.orig.tar.gz 0952593f777ef31b879a457ffc2809a07355a81d 142361 grass_6.4.0~rc6+42329-1.diff.gz a3bb0b8e433da4430cdb78974c352769b87e90d9 13834882 grass-doc_6.4.0~rc6+42329-1_all.deb 9652b27bae0382e44473091752754813ac39b063 13770200 grass_6.4.0~rc6+42329-1_i386.deb bac9bd59f2fe7127331e5c30bea0779925f2a5fd 208630 grass-dev_6.4.0~rc6+42329-1_i386.deb Checksums-Sha256: b9cb92b6d8f51610ec69775f4e7414d839baf5b45427c1995dca37cefdd15a18 1804 grass_6.4.0~rc6+42329-1.dsc c3c0510f2c0a9230be7e425519de2081a9321157550fe6ec9f901e1f37e21ea0 21988396 grass_6.4.0~rc6+42329.orig.tar.gz 84ae9c6d0153e4dd6e3c089873e4e4a2c031beb78e9cb9b7ac24e5d804ac9ab5 142361 grass_6.4.0~rc6+42329-1.diff.gz 0a623b547249fce74f5640244aac7aa754728a717582a5f313e9991f76e225f9 13834882 grass-doc_6.4.0~rc6+42329-1_all.deb 6820074c46186a5ad31cd6db48dae625bcd8e5d5d494d674a7f20c4a5c7f0cc1 13770200 grass_6.4.0~rc6+42329-1_i386.deb 5279cc9994429a2b39d42fd305a48f10f442acae6c4bc5523a7a592a8a5b3bc4 208630 grass-dev_6.4.0~rc6+42329-1_i386.deb Files: 1cd5a01483c5072103e5d85f0ebb14b1 1804 science optional grass_6.4.0~rc6+42329-1.dsc f418f8a6efcef1506b007bc08e2a5947 21988396 science optional grass_6.4.0~rc6+42329.orig.tar.gz 5d3c91975d3766a87291a22fac08a8db 142361 science optional grass_6.4.0~rc6+42329-1.diff.gz d5fe96d7f7c090f4bf326298f238d119 13834882 doc optional grass-doc_6.4.0~rc6+42329-1_all.deb b6a1b7720ab930ef26e0abc0de628b0d 13770200 science optional grass_6.4.0~rc6+42329-1_i386.deb 62343345dcf749ba325310aa6839d4b2 208630 devel optional grass-dev_6.4.0~rc6+42329-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv6oeQACgkQpFNRmenyx0cF5QCfVBq50ZTnkk0QBnYS/l9G0Sii HT8An2qd2rdFEFxkiACFLv/x2EbvHn8k =Q+AZ -END PGP SIGNATURE- Accepted: grass-dev_6.4.0~rc6+42329-1_i386.deb to main/g/grass/grass-dev_6.4.0~rc6+42329-1_i386.deb grass-doc_6.4.0~rc6+42329-1_all.deb to main/g/grass/grass-doc_6.4.0~rc6+42329-1_all.deb grass_6.4.0~rc6+42329-1.diff.gz to main/g/grass/grass_6.4.0~rc6+42329-1.diff.gz grass_6.4.0~rc6+42329-1.dsc to main/g/grass/grass_6.4.0~rc6+42329-1.dsc grass_6.4.0~rc6+42329-1_i386.deb to main/g/grass/grass_6.4.0~rc6+42329-1_i386.deb grass_6.4.0~rc6+42329.orig.tar.gz to main/g/grass/grass_6.4.0~rc6+42329.orig.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohgj6-0003l2...@ries.debian.org
Accepted aspell-pl 20100526-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 14:42:18 +0200 Source: aspell-pl Binary: aspell-pl Architecture: source all Version: 20100526-1 Distribution: unstable Urgency: low Maintainer: Krzysztof Krzyżaniak (eloy) e...@debian.org Changed-By: Krzysztof Krzyżaniak (eloy) e...@debian.org Description: aspell-pl - Polish dictionary for aspell Changes: aspell-pl (20100526-1) unstable; urgency=low . * New upstream release * Switch to dpkg-source 3.0 (quilt) format Checksums-Sha1: 7875d21cbb90b821db7708a49e35258afb244b6a 1086 aspell-pl_20100526-1.dsc 8b6aae9a9720e921ac6861f6eb8c148c628995c1 556362 aspell-pl_20100526.orig.tar.bz2 b8bbcb0309232be983334965ff8e7a4a7e1d0fb5 8210 aspell-pl_20100526-1.debian.tar.gz fedddcf7e9f7ca6a0c5a653c72c14c8adaeb36ce 703592 aspell-pl_20100526-1_all.deb Checksums-Sha256: e7b8eef326d61fd951a10748e5ce0b14c24178092bc1b9b4a3136e8bf0ebae51 1086 aspell-pl_20100526-1.dsc e4ad712a73cc6b5bff810b925b918190844a89820852d06098dc9bbb255e6280 556362 aspell-pl_20100526.orig.tar.bz2 1ad271d970c6d7bc6b234e46bfaec473e6ee3e79ac760b8504de1f7fcfad727b 8210 aspell-pl_20100526-1.debian.tar.gz cd93e1627d9c3941f8a980b2bd24c111ada4d0e74482922d7e33e4c8305ca712 703592 aspell-pl_20100526-1_all.deb Files: 89160c331e40255335c424787e73c6cc 1086 text optional aspell-pl_20100526-1.dsc 11632e5c79851582b3ba35b047213dd3 556362 text optional aspell-pl_20100526.orig.tar.bz2 db20de1b93a417138b67b3d431d80702 8210 text optional aspell-pl_20100526-1.debian.tar.gz 1bb721d96b23a3d7d1774fd1f2dd3369 703592 text optional aspell-pl_20100526-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkv9IWYACgkQy+HP4f7iC8sb3QCgksXFqAuGEbPHKQuZp9GDmBso 52IAoJHwOWKT87JaGkVNkGL5X+QETL1d =ky9T -END PGP SIGNATURE- Accepted: aspell-pl_20100526-1.debian.tar.gz to main/a/aspell-pl/aspell-pl_20100526-1.debian.tar.gz aspell-pl_20100526-1.dsc to main/a/aspell-pl/aspell-pl_20100526-1.dsc aspell-pl_20100526-1_all.deb to main/a/aspell-pl/aspell-pl_20100526-1_all.deb aspell-pl_20100526.orig.tar.bz2 to main/a/aspell-pl/aspell-pl_20100526.orig.tar.bz2 -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohgwu-0003p4...@ries.debian.org
Accepted ardour 1:2.8.7-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 26 May 2010 15:58:32 +0200 Source: ardour Binary: ardour ardour-altivec ardour-i686 Architecture: source amd64 Version: 1:2.8.7-1 Distribution: unstable Urgency: low Maintainer: Debian Multimedia Maintainers pkg-multimedia-maintain...@lists.alioth.debian.org Changed-By: Adrian Knoth a...@drcomp.erfurt.thur.de Description: ardour - digital audio workstation (graphical gtk2 interface) ardour-altivec - digital audio workstation (graphical gtk2 interface) [altivec] ardour-i686 - digital audio workstation (graphical gtk2 interface) [i686] Closes: 573469 582938 Changes: ardour (1:2.8.7-1) unstable; urgency=low . [ Jonas Smedegaard ] * Drop Robert Jordens as uploader. Closes: bug#573469 - thanks for your contributions, Robert! * Add myself as uploader. * Indent with single space (not tab or multiple spaces) continuated fields in control file, to follow Debian Policy §7.1 documented convention. . [ Adrian Knoth ] * New upstream release * Add mute patch to enable mute buttons by default (Closes: #582938) Checksums-Sha1: f0a74d3f228b8780febf0a08cc3d89113a50481c 2583 ardour_2.8.7-1.dsc ac2ce9b3f77647e8bf8ead580cd2dcd2a9c4a6df 3248764 ardour_2.8.7.orig.tar.bz2 67dc7342686f23dd6e4cbb1aad0eae65b1183bfc 52187 ardour_2.8.7-1.debian.tar.gz ef4cdb8620a7ce30309114692b29c26156d59d99 27033972 ardour_2.8.7-1_amd64.deb Checksums-Sha256: 04d35df199a324f652f3612a7f7b9222f4fc351d9575f8f73069b3217dd52a6f 2583 ardour_2.8.7-1.dsc 49549a1a009e553080b11e35527a8798ff09668ebb7193506273d889294db9b8 3248764 ardour_2.8.7.orig.tar.bz2 b4e3af1277b4f6a524c546908eac226e29e6ea979516d79b6d6cfd7ccc50fe4d 52187 ardour_2.8.7-1.debian.tar.gz 4fb7cf9cc9cd55537dfa1c18a8288a7800d4d54ec946f42c8b17b35f239cc6f2 27033972 ardour_2.8.7-1_amd64.deb Files: 8083833428ddd3fa47a715a612678c16 2583 sound optional ardour_2.8.7-1.dsc 77fbcf4d472c9567da367274bdc6b53d 3248764 sound optional ardour_2.8.7.orig.tar.bz2 cbe597013701a6390e0e930274f107ba 52187 sound optional ardour_2.8.7-1.debian.tar.gz b989e54c84365cfa0bed5b006dd3e5d2 27033972 sound optional ardour_2.8.7-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJL/TnhAAoJEI8ytEIvUhB/dmYP/j0xoBb/i164zhRA521wkkIw f4mY+7Ni7KxC58c/PQt/TYh7PNJR4Xzm7bRuyVjCx90GzN+xmUGg6P442DSIq5SD WkWNHvN6oLytMumHGKWJ9Rl2NGaBojRiWDyld5VUm1Xp6Vz5/tTQ3JmuGKm1QxyH 28Ys5y+aSs9JsInlqqyBIr/WH1ej8pWQxM34WdWlD+aoa4H33Ok2moI5F78IZT09 Px9LE5gG08gjj7mlv8zQOSKwk4cPst6dPANWvPbscmoZEh9f1ic5Sy4zCYojH3am OW8V4xvEuLs/4+xKsm3vTjhv8vQC0fKYPccQ6VJ8SJ6wAHnRJ+Mv+YjzPzjFUt8a kzZko5WYJASfHBoO9pihb2MFOJb0jY5cxidLauV15wL8VsQAhMyDOLwER/7jEQlF Lui0WMAJVwC58vicvlJ0DVBZonBiZEMZY/VV9bhtFqt0AZO3uqS3/KCCqo0N3vMv o8f4Mgx4RS2FvPPKXPGe6Ox06dQyIK3yEQX+TsTUUhYGmTwnQzyVhpK0WJs4X1rq oaB9ep4QT+juD/1pkxSUNd0Zu4G5Uxsy833hz21Wo5aCt+Im79xOzZ963bWfNZ3o ef9m9I7HQdhGWdD5AU6NcmZefu5XwA+MsPL65+nqRQdzZy4Za74NWsAaGAreML8Z L+Db3feTAkEbNk3lGjka =t+63 -END PGP SIGNATURE- Accepted: ardour_2.8.7-1.debian.tar.gz to main/a/ardour/ardour_2.8.7-1.debian.tar.gz ardour_2.8.7-1.dsc to main/a/ardour/ardour_2.8.7-1.dsc ardour_2.8.7-1_amd64.deb to main/a/ardour/ardour_2.8.7-1_amd64.deb ardour_2.8.7.orig.tar.bz2 to main/a/ardour/ardour_2.8.7.orig.tar.bz2 -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohipx-00038t...@ries.debian.org
Accepted bootcd 3.20 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 25 May 2010 10:21:07 +0200 Source: bootcd Binary: bootcd bootcd-i386 bootcd-hppa bootcd-ia64 bootcd-mkinitramfs bootcd-backup Architecture: source all Version: 3.20 Distribution: unstable Urgency: low Maintainer: Bernd Schumacher bernd.schumac...@hp.com Changed-By: Bernd Schumacher bernd.schumac...@hp.com Description: bootcd - run your system from cd without need for disks bootcd-backup - tools to backup a Debian or alien Linux installation bootcd-hppa - bootcd extension to create images that can boot on parisc/hppa bootcd-i386 - bootcd extension to create images that can boot on i386 bootcd-ia64 - bootcd extension to create images that can boot on ia64 bootcd-mkinitramfs - initramfs extension for bootcd Closes: 474148 Changes: bootcd (3.20) unstable; urgency=low . * Support Kernels with ramdisk as module (as used in squeeze). - S12bootcdram.sh loads ramdisk Module (brd) if it exists - S12bootcdram.sh may have to create /dev/ram2 manually - bootcd-check.lib now accepts kernels with CONFIG_BLK_DEV_RAM=[m|y] * Support newer login that does not allow devices outside of /dev - bootcdwrite makes sure /etc/securetty has full path when running from bootcd - bootcd2disk restores original /etc/securetty * Bashism - do not use bash command declare any more * This is the first try to support Grub2. Maybe it is more sure to use Grub for now. * check that if bootcd-mkinitramfs is installed, it has modified the correct initrd. While installing bootcd-mkinitramfs it only modifies the actual running initrd, other initrds have to be modified manually. The check tells the command to execute. * Added sr_mod to the MANUAL_MODULES in bootcdmodprobe. Thanks to Kushal Koolwal kushalkool...@hotmail.com and Daniel Wozniak d...@edgeos.com. Successfuly tested squeeze kernel vmlinuz-2.6.32-3-686. Fixed bugs reported by Alessandro Polverini a...@nibbles.it. Also Tested bootcd2disk with this kernel. Closes: #474148 * Added startscripts bootcdram and bootcdflop with LSB support instead of old S12bootcdram.sh and S13bootcdflop.sh. Checksums-Sha1: 85aad4c5c4a02a69468c4b105fd1bfa7d363e390 761 bootcd_3.20.dsc 9023213906babcdcb52db0e881621eb9f5d796e1 109305 bootcd_3.20.tar.gz 181c6b5406e0e6d3a2adf8d0adb49746f8af8dfc 82428 bootcd_3.20_all.deb cd43fb32e54a4b12858de4e58a7c3e1348352e3b 14318 bootcd-i386_3.20_all.deb a8f0fcbbd904fa6bd1998fb87ad4144d3e874542 14136 bootcd-hppa_3.20_all.deb d5264f2ed99869a00035e315377f9c5eb517c396 15014 bootcd-ia64_3.20_all.deb c077cbf0101907272dd54d5f116d799cad9e2484 18232 bootcd-mkinitramfs_3.20_all.deb 39799fcd9fc3eb2086edbb5fe54207cc02b53e56 49762 bootcd-backup_3.20_all.deb Checksums-Sha256: 87400878d68f06c0b47352d1783a398310d8b8fd08f98d6d248e2d3460ca3bc4 761 bootcd_3.20.dsc 46212e0e79af04c891a3ded6eef06e15ab52879aa206db6ec308c81b297b37d4 109305 bootcd_3.20.tar.gz ae0b5aad4e695074d44bc013a26674c31fbca6fbbf11e638732ca5292e8c7967 82428 bootcd_3.20_all.deb b079fdb37a5f3f653a63a93272e21941224129d7e3b39f7f33d53df5c1b845b3 14318 bootcd-i386_3.20_all.deb 2a317a870d8cc347e90ae41b617cb46cfd15c9d4ab2329fd60c704a2abe45136 14136 bootcd-hppa_3.20_all.deb 03a09310ac9da9eb32c17fe1609b6120a9d9d89dce3d0938be2c373f2efbe0e8 15014 bootcd-ia64_3.20_all.deb 75ac6c2d783118dfcfff1f377409f36fbf789fac5502beb1f1c944500d7f5b7d 18232 bootcd-mkinitramfs_3.20_all.deb 4414b1c7279f490e075ae01433c9d87b10381fae175740841ce6c29ed9edb58e 49762 bootcd-backup_3.20_all.deb Files: c7f5ae42bd2ea0979417d63ee3f1a9e3 761 utils extra bootcd_3.20.dsc 4f10c9bd745cc67ccac5eddd7747ffb5 109305 utils extra bootcd_3.20.tar.gz 2fd5ffd9e7671ca8f638fa6876158c99 82428 utils extra bootcd_3.20_all.deb 408d717d5fe1ac8bf409ac20c5084afd 14318 utils extra bootcd-i386_3.20_all.deb 0829d21b807210baca326f04d032d545 14136 utils extra bootcd-hppa_3.20_all.deb a516953371c94a38a72c21c9aaa04b96 15014 utils extra bootcd-ia64_3.20_all.deb f9946885b8a8aa8efd34442139779975 18232 utils extra bootcd-mkinitramfs_3.20_all.deb 7bea166bba0b6f27e23b14039301ae47 49762 utils extra bootcd-backup_3.20_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFL/TWNINZoglnvXbwRAsZaAJ0bgWUum62MjX3XZRP3o/sLmr7KkwCfX8cN XKCv+5Akie7fvhsdKOeV9os= =lY8s -END PGP SIGNATURE- Accepted: bootcd-backup_3.20_all.deb to main/b/bootcd/bootcd-backup_3.20_all.deb bootcd-hppa_3.20_all.deb to main/b/bootcd/bootcd-hppa_3.20_all.deb bootcd-i386_3.20_all.deb to main/b/bootcd/bootcd-i386_3.20_all.deb bootcd-ia64_3.20_all.deb to main/b/bootcd/bootcd-ia64_3.20_all.deb bootcd-mkinitramfs_3.20_all.deb to main/b/bootcd/bootcd-mkinitramfs_3.20_all.deb bootcd_3.20.dsc to main/b/bootcd/bootcd_3.20.dsc bootcd_3.20.tar.gz to main/b/bootcd/bootcd_3.20.tar.gz bootcd_3.20_all.deb to main/b/bootcd/bootcd_3.20_all.deb -- To UNSUBSCRIBE, email to
Accepted exactimage 0.8.1-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Fri, 21 May 2010 01:28:14 +0200 Source: exactimage Binary: exactimage exactimage-dbg libexactimage-perl exactimage-perl php5-exactimage python-exactimage Architecture: source i386 all Version: 0.8.1-1 Distribution: unstable Urgency: low Maintainer: Jakub Wilk jw...@debian.org Changed-By: Jakub Wilk jw...@debian.org Description: exactimage - fast image manipulation programs exactimage-dbg - fast image manipulation library (debug symbols) exactimage-perl - transitional dummy package libexactimage-perl - fast image manipulation library (Perl bindings) php5-exactimage - fast image manipulation library (PHP bindings) python-exactimage - fast image manipulation library (Python bindings) Closes: 582431 Changes: exactimage (0.8.1-1) unstable; urgency=low . * New upstream release: + Drop configure-perl-detection.diff, different fix applied upstream. + Drop utility-timer-dead-code.diff, different fix applied upstream. * Fix FTBFS with nostrip build option. * Remove bogus Python modules directory created by upstream Makefile (closes: #582431). Thanks to Stefano Rivera for the bug report. * Use DESTDIR, not prefix, for make install. * Update years in debian/copyright. Checksums-Sha1: dcc63e24e7eb33aa320e3fb7f6a1700d017afb86 2212 exactimage_0.8.1-1.dsc 2aa8398d52b62cee5f62356fb81b0d1b8e7f6137 283660 exactimage_0.8.1.orig.tar.bz2 384f2cf7ec2aac0486018b5d2a0affd6a4b989d0 15597 exactimage_0.8.1-1.debian.tar.gz 9ebfa8fdf0c7de9fcd1b248f386905d72cb64e8d 3276280 exactimage_0.8.1-1_i386.deb 52efbe0128140037d258cd65e3aab3c350aa794c 14169982 exactimage-dbg_0.8.1-1_i386.deb 66ef23ed69775e03eb1b5a78c180a5b7d2915405 595010 libexactimage-perl_0.8.1-1_i386.deb aa6a9e21afcd979d91442bf5fbcf0b7d19f5ec7a 6486 exactimage-perl_0.8.1-1_all.deb 327ae4ce7588467632c114c8a94d99e4b8e2eafa 569968 php5-exactimage_0.8.1-1_i386.deb 0bd2874d6a731c9f89f0001ea1aed4ea1ea89a1d 1130870 python-exactimage_0.8.1-1_i386.deb Checksums-Sha256: e3f9a8b8d11fad389890e1d2f2b3b7377809fc7d1cbe7f55b7100cb4b66ffec8 2212 exactimage_0.8.1-1.dsc 926a09c897489705ba42daeb01fc4a3c327a8194dc65431f630d50684390e28b 283660 exactimage_0.8.1.orig.tar.bz2 2c4e53c2e52793c057a12ffc2eed60e9017a1c5a9ba70e3e781a8fbfe817dc89 15597 exactimage_0.8.1-1.debian.tar.gz 0921e75270345a47f9d9738b3278074ffc0bdd87fcb51e0d589ced86f4512caa 3276280 exactimage_0.8.1-1_i386.deb 1b1488c5a0a4c4fd5e89a54e5d374a65c369de06d61293e87c98930cd7ba23ea 14169982 exactimage-dbg_0.8.1-1_i386.deb 9e3a39df8954b991e37610310d53ff917b39c2a98b0d364af90f0e709f198a7a 595010 libexactimage-perl_0.8.1-1_i386.deb 7a47878babc2b0a7cc0e234d97355c69b99cf367a95b9cf984a8701595abe3f0 6486 exactimage-perl_0.8.1-1_all.deb 03237b19edec12d57ec008d3c09d82fce4bf36cd7a6e0960d44a0934339afa63 569968 php5-exactimage_0.8.1-1_i386.deb 92bf88df50f82339516dcb8eafb8ca914c0c1675a2e2c9bbe602c77a17c8774a 1130870 python-exactimage_0.8.1-1_i386.deb Files: 16845d394ab5ca60950f1c09d3637080 2212 graphics optional exactimage_0.8.1-1.dsc f6c5a068a21a90c314ba557f0a601352 283660 graphics optional exactimage_0.8.1.orig.tar.bz2 d17923028dc1932d13ed217faf2e42d7 15597 graphics optional exactimage_0.8.1-1.debian.tar.gz 9028b722a6f00f964015bd5248d6a0fa 3276280 graphics optional exactimage_0.8.1-1_i386.deb 4cd16aa215c68fa8d81268de74ed1f4c 14169982 debug extra exactimage-dbg_0.8.1-1_i386.deb 12540b31378c33d6f3de932e4162d55a 595010 perl optional libexactimage-perl_0.8.1-1_i386.deb 470c16bb6428326f8dec3883961beea4 6486 perl optional exactimage-perl_0.8.1-1_all.deb 58f233a68b403e31421aa1c8ef5f1cc7 569968 php optional php5-exactimage_0.8.1-1_i386.deb 5ed688e2c1e7c0c2937b5ea841bb1c39 1130870 python optional python-exactimage_0.8.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJL/TBSAAoJEC1Os6YBVHX17aEP/3PIxwn8drY+eZ4eFv3FJQxd SVp2jx0jjy/455c56YZ9c3mKHdh1Td51XRye5gzASkm2qzI8rTltgquRGnGXmNSr 4+ApHwg8dKCqRBI16vqKhhnRRVM8fAXMAHzXQJEfm7YMz2ELrKlxTNa1mu+WBmq7 6i62+pPU1BZfrGXGxO39gkoTa9OvW3TfnwaHNTrx46rMOknyPUiuIC6siMB2OUGY Hm46AMKXSZZRi9iBjgwCdxKgS5ppSY2h+uN9vzfifjnbJZi+XADQg6uFLAzImv+I 0nGCSyiImp/YeQN9rK9Mv5n2dqQ0M3H4d4JhH/QIHrf9df7l09Qi7LwVDL2Oi+Kv Sv/9rHyechFbDoGW6C1pFt3/H5EE6rf4FEVJ/1bl+UebtA0GFJjDGQPMfSGzwP1X BHdUsqvS5ee7P+dElhbyZnoBBgaxUHQpEOJzUXxamdMo2Bn2dccCdncBMmM4m2ev LRVrdeXNMntiw4M1zqgYhf3BpMMsgJHiA7hUzOW7I1GQL5XC4JP2Uhj6i7aw+jdq CGkUKzOlAlBG8VauxUB0PfBQXtsO1c4TSoiWa3GKE8l7PaTa/TQ25YD5Wfq8cZJj XlrijHG1KCl95NJ2RZuPyKy3EijeOCmtN6rSsiPDZs4hhKIBOLA8AVVDVz4zKUXD +byx5vO/pFIvfXF85uY3 =FSVk -END PGP SIGNATURE- Accepted: exactimage-dbg_0.8.1-1_i386.deb to main/e/exactimage/exactimage-dbg_0.8.1-1_i386.deb exactimage-perl_0.8.1-1_all.deb to main/e/exactimage/exactimage-perl_0.8.1-1_all.deb exactimage_0.8.1-1.debian.tar.gz to main/e/exactimage/exactimage_0.8.1-1.debian.tar.gz exactimage_0.8.1-1.dsc to main/e/exactimage/exactimage_0.8.1-1.dsc
Accepted gjs 0.7-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Wed, 26 May 2010 10:55:19 -0300 Source: gjs Binary: gjs libgjs0a libgjs-dev Architecture: source amd64 Version: 0.7-1 Distribution: unstable Urgency: low Maintainer: Gustavo Noronha Silva gustavo.noro...@collabora.co.uk Changed-By: Gustavo Noronha Silva gustavo.noro...@collabora.co.uk Description: gjs- Mozilla-based javascript bindings for the GNOME platform libgjs-dev - Mozilla-based javascript bindings for the GNOME platform libgjs0a - Mozilla-based javascript bindings for the GNOME platform Changes: gjs (0.7-1) unstable; urgency=low . * New upstream release * Bumped Standards-Version with no changes Checksums-Sha1: 184c6d8c652ab27a4a2db9e92423b05de5ac00fe 1602 gjs_0.7-1.dsc a2e3d090757419c5a1b3c5999de1b2871e9e1ba8 579758 gjs_0.7.orig.tar.gz 3f13b6503a5c14dafa94df08a132fd1775ab14f5 3997 gjs_0.7-1.diff.gz a349481f1b720ca2aec5d0f1936281494561adbf 10694 gjs_0.7-1_amd64.deb f5435c81900928c013e5b0887bf0620998157ef0 187662 libgjs0a_0.7-1_amd64.deb 06b9ed7530c0ccc7bf64899ba185d33027dd57b7 15582 libgjs-dev_0.7-1_amd64.deb Checksums-Sha256: 1f5cfe426bcab8278779959f422379bca558948aa3ca64f8efb2b82e5d8d2bcf 1602 gjs_0.7-1.dsc f4a455f1617c189c4456f9c7450b5f6ea522e88c50c3297d4fcda91caa842f53 579758 gjs_0.7.orig.tar.gz 2b47238cd08eba3b022b7644a6bf11f407506077968136c9edab94ea3da52e1a 3997 gjs_0.7-1.diff.gz 8a3de5946f57621784b6e3ce1388aa52ab31efeafdeb8dbf6d9afd93c19a09d6 10694 gjs_0.7-1_amd64.deb 9405158404af899159ba6c8184cb6f2bba46310d9f0136bfb979c7864b67e71a 187662 libgjs0a_0.7-1_amd64.deb 769ed4933b461628cc664cc13245ac3d153bab0c84eeae6303f5aca48e23b72c 15582 libgjs-dev_0.7-1_amd64.deb Files: d80ebdef9499ac0879dd6160a81fdd1a 1602 interpreters extra gjs_0.7-1.dsc ce5c2ce8526d733b488c255d265d429f 579758 interpreters extra gjs_0.7.orig.tar.gz 5fd0a8c07df3ce2f639678578fff3466 3997 interpreters extra gjs_0.7-1.diff.gz a8f1302d2c8ffd7c0c63a49935e6e8f0 10694 interpreters extra gjs_0.7-1_amd64.deb e802518d7da8f727039e0d0d0d9801d5 187662 libs extra libgjs0a_0.7-1_amd64.deb d16f5d161284592600213118d7ce758f 15582 libdevel extra libgjs-dev_0.7-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJL/TWAAAoJENIA6zCg+12mwhMH/ioo9kAWwjG+xUoQoFjJbkiv Qeibuc6g5p8Zl3qWu5OllReHV+Mrveji3cuFUCAviL/Qu6js83v3F8Uj7XevDI8t 8FVasMgfSpJs24kylLY4kHpyu9s4faBaRHu8gBOs6w12Dfg+XPwYUIdbuS+VEAMY TyZ8S12sb311nySQmvauIU8muXOSU5DzTsm84d6APm7mN5NcaElHZ1YsPE0eaMgq TVekXVw5UfsOnAuzvqDmnPx9LZ5wfCo/9gZN+2q7by2mDRyoCgZxc+JXNi8pH+1B cqeQruKmssAlMbpbWlx875+scVCviOHUCHYhefx8KNCASy45QQ5sJmfCstaMtDI= =QcOu -END PGP SIGNATURE- Accepted: gjs_0.7-1.diff.gz to main/g/gjs/gjs_0.7-1.diff.gz gjs_0.7-1.dsc to main/g/gjs/gjs_0.7-1.dsc gjs_0.7-1_amd64.deb to main/g/gjs/gjs_0.7-1_amd64.deb gjs_0.7.orig.tar.gz to main/g/gjs/gjs_0.7.orig.tar.gz libgjs-dev_0.7-1_amd64.deb to main/g/gjs/libgjs-dev_0.7-1_amd64.deb libgjs0a_0.7-1_amd64.deb to main/g/gjs/libgjs0a_0.7-1_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ohito-0003lj...@ries.debian.org
