Re: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli wrote: On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. Of course the problem is that if you update on the NFS server, then related /etc and /var files [1] will not get updated on the NFS client machines and you need to propagate changes there. I see as quite pointless to use let's export /usr via NFS as an argument, if Debian does not provide a way to make that setup tenable. 8-/ I really don't see the problems, and BTW debian provide also some tools. - On large parallel systems, people use something more than a base debian console installation. Usually on net you have a complete copy for root, var etc (in case of compromised computers. Very handy instead of reinstalling the system) So it is easier also to have a rsync script (without some dirs) And on infrequent security update where data format change, let sysadmin implement a tool to update such numberous systems. But such case is seldom. I really think that *most* debian machines are done in this way (because such systemns have huge number of debian machine, and debian is a very good distribution for such setups) - on homemade systems, Debian provide tools like apt-cron and other automatic update tools, which solve all problems (if one use only one distribution [like stable]). Also in this case, heuristic tell me that when we requires removing of a package, it is because it is substituted by an other, so no problems (when all systems are updated nearly at the same nightly time). It seems not a usual case that sysadmins remove packages from a single machine. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Giacomo Catenazzi c...@debian.org writes: - On large parallel systems, people use something more than a base debian console installation. Usually on net you have a complete copy for root, var etc (in case of compromised computers. Very handy instead of reinstalling the system) So it is easier also to have a rsync script (without some dirs) And on infrequent security update where data format change, let sysadmin implement a tool to update such numberous systems. But such case is seldom. I really think that *most* debian machines are done in this way (because such systemns have huge number of debian machine, and debian is a very good distribution for such setups) I think it's pretty unlikely that *most* Debian machines are done that way. There are a lot better tools for keeping large numbers of systems in sync these days than simple cloning from golden images, and a lot of drawbacks to the golden image approach. Also, reinstalling systems is completely trivial if you have a decent FAI infrastructure. It takes us about ten minutes to rebuild a server and reinstall all application software, and that's mostly waiting for the system BIOS boot-up checks and the small amount of manual keying we've not bothered to automate yet. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527199: ITP: python-ftputil -- A high-level FTP client library for Python
Package: wnpp Severity: wishlist Owner: Julián Hernández Gómez julianhernan...@gmail.com * Package name: python-ftputil Version : 2.4 Upstream Author : Stefan Schwarzer sschwar...@sschwarzer.net * URL : http://ftputil.sschwarzer.net/ * License : BSD Programming Lang: Python Description : A high-level FTP client library for Python The ftputil Python library is a high-level interface to the ftplib module. The FTPHost objects generated with ftputil allow many operations similar to those of os and os.path. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Well, some people argued for that. Like you, I'm wondering how one actually does this in practice! However there are some rather more reasonable uses which have been mentioned: - read-only /usr (for security) - backups - recovery (ability to mount root only; important if there's fs corruption) - on-line resizing - using LVM and/or RAID (Note: With modern Debian initramfs it is quite possible to have / on LVM [on RAID] since so long as /boot lives outside the initramfs can bring up RAID and initialise LVM to mount the rootfs. The system I'm physically typing this on has such a setup.) I keep a /usr because I suspect it gives more performance. unlike the rest of the disk, one doesn't read and write it all the time, so fragmentation should be less if it is kept separate. one can also use a filesystem type more suitable for this behaviour (reiserfs is probably not optimal) /Johan -- -- Johan Henriksson MSc Engineering PhD student, Karolinska Institutet http://mahogny.areta.org http://www.endrov.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Using uscan with VCS hosting sites
[no answers for this yet on ‘debian-mentors’, so trying here] Howdy all, I have an upstream for a package who has started using a VCS hosting site for publishing the code. It's possible they will continue to make tarball releases, but in case they don't at some point in the future, I'd like to use this as an opportunity to learn the capabilities of ‘uscan’. The package in question is ‘python-coverage’, and already has a ‘debian/watch’ file: = […] # Current version from Ned Batchelder's site http://nedbatchelder.com/code/modules/coverage.html \ code/modules/coverage-(.*).tar.gz = The author is now publishing their source code for this package at URL:http://bitbucket.org/ned/coveragepy/, a project hosting site using Mercurial for VCS. That service makes available URLs for tags in VCS repositories, but the tags are not in the URLs themselves, only in the text of the ‘A’ elements: = li class=icon-tags tags raquo; ul lia href=/ned/coveragepy/src/b24b35f0448b/tip/a/li lia href=/ned/coveragepy/src/79dd373074de/coverage-3.0b2/a/li lia href=/ned/coveragepy/src/4105a4de000e/coverage-3.0b1/a/li /ul /li = The page at the URL for a specific tag (e.g. that for ‘coverage-3.0b2’, URL:http://bitbucket.org/ned/coveragepy/src/79dd373074de/) has URLs for “get source”, including tarball: = lia class=link-downloadget source »/a ul lia rel=nofollow href=/ned/coveragepy/get/79dd373074de.zip class=zipzip/a/li lia rel=nofollow href=/ned/coveragepy/get/79dd373074de.gz class=compressedgz/a/li lia rel=nofollow href=/ned/coveragepy/get/79dd373074de.bz2 class=compressedbz2/a/li /ul /li = So, how do I go from “the URL for the project source is URL:http://bitbucket.org/ned/coveragepy/”, to a ‘debian/watch’ file that will enable ‘uscan’ to discover the current version is ‘coverage-3.0b2’, and its original source tarball is downloadable from URL:http://bitbucket.org/ned/coveragepy/get/79dd373074de.gz? -- \“If it ain't bust don't fix it is a very sound principle and | `\ remains so despite the fact that I have slavishly ignored it | _o__) all my life.” —Douglas Adams | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem? [/usr on NFS]
On Tue, 2009-05-05 at 16:25 -0700, Russ Allbery wrote: Stefano Zacchiroli z...@debian.org writes: Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. I have always been skeptical about sharing /usr on Debian, especially I've always wondered is how you upgrade the remote (nfs-mounted) systems? * How to upgrade /bin, /lib... files? * Can dpkg be told to not touch /usr on those machines? * Some (pre|post)(inst|rm) scripts use files in /usr... Aren't they guaranteed to behave in unpredictable way, if the version is /usr aren't the one expected by those scripts? I used lessdisk[1] in sarge, but it used to export the whole tree over NFS. Regards, Franklin P.S. I like the idea to use encrypted partition for the whole system, excepts /usr. [1] http://archive.debian.net/sarge/lessdisks -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem? [/usr on NFS]
Frank Lin PIAT fp...@klabs.be writes: On Tue, 2009-05-05 at 16:25 -0700, Russ Allbery wrote: It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. I have always been skeptical about sharing /usr on Debian, especially I've always wondered is how you upgrade the remote (nfs-mounted) systems? * How to upgrade /bin, /lib... files? * Can dpkg be told to not touch /usr on those machines? * Some (pre|post)(inst|rm) scripts use files in /usr... Aren't they guaranteed to behave in unpredictable way, if the version is /usr aren't the one expected by those scripts? I think it would be fairly difficult without using a golden image approach, where there's one system (or chroot on an NFS server) that you upgrade and then push the non-/usr results to all the systems mounting /usr. Doing that is fairly straightforward, though. Don't get me wrong: I don't do this, nor do I have any plans to do this. Disk is too cheap to bother and there are better ways of keeping systems in sync these days, IMO. But it's a very long-standing sysadmin technique, I wouldn't be surprised if some people still use it, and it's certainly technically doable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API
Package: wnpp Severity: wishlist Owner: Ritesh Raj Sarraf r...@researchut.com * Package name: inotifyx Version : 0.1.0 Upstream Author : Forest Bond for...@alittletooquiet.net * URL : http://www.alittletooquiet.net/software/inotifyx/ * License : MIT/X Programming Lang: C, Python Description : Simple Python binding to the Linux inotify file system event monitoring API inotifyx is a Python extension providing access to the Linux inotify file system event notification API. It is primarily written in C but has some Python window dressing. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 12:30:14AM +0200, Stefano Zacchiroli wrote: Of course the problem is that if you update on the NFS server, then related /etc and /var files [1] will not get updated on the NFS client machines and you need to propagate changes there. One thing to remember is when you export /usr (or /) over NFS, then you usually do not expect to install new software often (maybe once or twice a year), and security updates rarely bring big changes under /etc or /var. /etc can be managed with a couple of scripts; if you have a non-trivial amount of machines you already have the scripts to populate and customize it for a new machine. After an update, you just re-run that script for all the clients and you're done. /var is not an issue either. You can mount it read-only just like /usr and then you can mount some tmpfs instances over the locations where write access is really needed. /etc/fstab fragment: tmpfs /tmptmpfs size=100m,mode=1777 0 0 /tmp/var/tmpbindbind0 0 tmpfs /var/logtmpfs size=10m0 0 tmpfs /var/lib/gdmtmpfs size=10m0 0 tmpfs /var/lib/xkbtmpfs size=10m0 0 tmpfs /var/lib/nfstmpfs size=10m0 0 tmpfs /var/cache/hald tmpfs size=10m0 0 tmpfs /media tmpfs size=128k 0 0 You of course need a couple of mkdir/chown commands in an init script to create some required subdirectories. If you need persistence, then you mount a writable FS somewhere else, and you do something like mount --bind /home/terem/boinc-client/$HOSTNAME /var/lib/boinc-client (that's from a running cluster setup). If I take a look of what is actually under /var on that cluster, then I get: nfs-server# du -s . 147300 . nfs-server# du -s cache lib/apt lib/aptitude lib/dpkg log [...] 135616 total So even if you want a local /var on every machine, you can ignore over 92% of the data when you synchronize with say rsync (you can actually ignore even more, but then the above du -s line would have been too long). Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le mardi 05 mai 2009 à 16:25 -0700, Russ Allbery a écrit : It's not particularly difficult. You update the system master and push that update into NFS, synchronizing any non-/usr data as you need to across all the systems mounting that NFS partition. Sure, but what is the point of doing that instead of exporting / over NFS ? Remember, we support read-only root partition setups now. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
Le mardi 05 mai 2009 à 23:15 -0700, Russ Allbery a écrit : I think it's pretty unlikely that *most* Debian machines are done that way. There are a lot better tools for keeping large numbers of systems in sync these days than simple cloning from golden images, and a lot of drawbacks to the golden image approach. You’d be surprised to see the number of HPC people who are wasting their time with golden images. And the even larger number of HPC people who don’t even have an automated node deployment mechanism. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API
+ Ritesh Raj Sarraf (Wed, 06 May 2009 12:23:06 +0530): Hello!, and thanks for your interest in packaging new software for Debian. * Package name: inotifyx Version : 0.1.0 Upstream Author : Forest Bond for...@alittletooquiet.net * URL : http://www.alittletooquiet.net/software/inotifyx/ * License : MIT/X Programming Lang: C, Python Description : Simple Python binding to the Linux inotify file system event monitoring API inotifyx is a Python extension providing access to the Linux inotify file system event notification API. It is primarily written in C but has some Python window dressing. Could you please include in the description a few lines on why would one want to use inotifyx instead of the already available pyinotify bindings? By reading the upstream homepage, it already mentions: | Reasons you might choose inotifyx over pyinotify: | | * inotifyx is a C extension and does not use ctypes, making it faster | and less prone to subtle breakage due to changes in the inotify API. | | * inotifyx is a much thinner wrapper around inotify. pyinotify is more | complicated. It does provide features that inotifyx does not, but many | of them are not needed by most applications. | | * The API provided by pyinotify seems to change in incompatible ways on | a fairly regular basis and with little justification. inotifyx has a | simple API that will change rarely, if ever. Maybe that's a bit too long for the description, but it should be easy enough to summarize those arguments for the long description. By the way, do you have preview packages available already? Cheers, -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527205: Info received (Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API)
Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): w...@debian.org Ritesh Raj Sarraf r...@researchut.com If you wish to submit further information on this problem, please send it to 527...@bugs.debian.org, as before. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 527205: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=527205 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On 2009-05-06, Russ Allbery r...@debian.org wrote: Giacomo Catenazzi c...@debian.org writes: - On large parallel systems, people use something more than a base debian console installation. Usually on net you have a complete copy for root, var etc (in case of compromised computers. Very handy instead of reinstalling the system) So it is easier also to have a rsync script (without some dirs) And on infrequent security update where data format change, let sysadmin implement a tool to update such numberous systems. But such case is seldom. I really think that *most* debian machines are done in this way (because such systemns have huge number of debian machine, and debian is a very good distribution for such setups) I think it's pretty unlikely that *most* Debian machines are done that way. There are a lot better tools for keeping large numbers of systems in sync these days than simple cloning from golden images, and a lot of drawbacks to the golden image approach. We do the same with ~12 clients. One master image that's declared stable by rsyncing it using hardlinks[0] on the server and from there rsynced to the clients which reboot automatically if there are pending updates. After the rsyncing it does local profile-based patching. I wonder about the drawbacks of this because it works really nice for us. (Of course there's the downtime problem, but that's no problem for us, as those are clients not servers.) Sadly rsync still does too much I/O on the servers in our setup, but if that gets a problem we'll probably go with aufs and have an image on the client which remainds static there. Also, reinstalling systems is completely trivial if you have a decent FAI infrastructure. It takes us about ten minutes to rebuild a server and reinstall all application software, and that's mostly waiting for the system BIOS boot-up checks and the small amount of manual keying we've not bothered to automate yet. But why bother to do a complete reinstall everytime something changed if you could just sync the delta. (And yes, I'm roughly aware that there are something like softupdates in FAI too, but still.) Kind regards, Philipp Kern [0] Actually there's one test image and the stable images are hardlinked within themselves, so that changes in the test image do not propagate to the stable images. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API
On Wednesday 06 May 2009 13:45:19 Adeodato Simó wrote: Description : Simple Python binding to the Linux inotify file system event monitoring API inotifyx is a Python extension providing access to the Linux inotify file system event notification API. It is primarily written in C but has some Python window dressing. Could you please include in the description a few lines on why would one want to use inotifyx instead of the already available pyinotify bindings? Given the pytagsfs upstream maintainer's announcement email [1], I believe python-inotify is not going to be maintained further. But this whole discussion started with python-inotify in experimental, which isn't backward compatible. I'm CCing the python-inotify maintainer. Probably he can give a better status of python-inotify. By reading the upstream homepage, it already mentions: | Reasons you might choose inotifyx over pyinotify: | | * inotifyx is a C extension and does not use ctypes, making it faster | and less prone to subtle breakage due to changes in the inotify API. | | * inotifyx is a much thinner wrapper around inotify. pyinotify is more | complicated. It does provide features that inotifyx does not, but | many of them are not needed by most applications. | | * The API provided by pyinotify seems to change in incompatible ways on | a fairly regular basis and with little justification. inotifyx has a | simple API that will change rarely, if ever. Maybe that's a bit too long for the description, but it should be easy enough to summarize those arguments for the long description. Sure I'll reword and include a better description. By the way, do you have preview packages available already? I don't have one now, but will start working on it soon. [1] https://lists.launchpad.net/pytagsfs/msg00025.html Ritesh -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: This is a digitally signed message part.
Re: Bug#527205: ITP: inotifyx -- Simple Python binding to the Linux inotify file system event monitoring API
Twas brillig at 17:09:45 06.05.2009 UTC+05 when r...@researchut.com did gyre and gimble: RRS Given the pytagsfs upstream maintainer's announcement email [1], I RRS believe python-inotify is not going to be maintained further. RRS But this whole discussion started with python-inotify in RRS experimental, which isn't backward compatible. RRS I'm CCing the python-inotify maintainer. Probably he can give a RRS better status of python-inotify. pyinotify is known for several (two? can't remember exactly) API breaks, yes. So, as there are applications which rely on another inotifyx (which is not an application, but a library), it has to be packaged. But pyinotify is not dead upstream. -- pgpUvGaW9UD4v.pgp Description: PGP signature
Re: deprecating /usr as a standalone filesystem?
Em Qua, 2009-05-06 às 00:30 +0200, Stefano Zacchiroli escreveu: On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. Simple. You have a single /usr shared-mounted for several instances and a a / for each machine. Then you run the upgrade in one of those images and do the following: 1 - use a script to extract files not in /usr in that packages and install it in each root mount 2 - use a script to change the dpkg database in each root mount telling that the packages were unpacked but not configured. 3 - run dpkg --configure -a in each root mount to get the maint scripts to be run... 4 - profit daniel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On May 05, Steve Langasek vor...@debian.org wrote: This is false for Ubuntu. Not only is it supported, but significant effort was put into *fixing* a /usr-as-separate-mount bug in Ubuntu 9.04 as pertains to wpasupplicant. You may want to discuss this with Keybuk then, because he still disagrees. -- ciao, Marco signature.asc Description: Digital signature
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 09:38:39AM -0300, Daniel Ruoso wrote:
Simple.
sarcasm
Sure, that's precisely what I'd call being properly supported in
Debian.
/sarcasm
In particular, from the replies to my question the picture I get is
that everybody is using ad hoc solutions to implement what some people
are pretending to be properly supported by Debian. I found it not
defendable, maybe it's just me, maybe it's just bad marketing.
Of the two one:
- We decide that mounting /usr remotely is a Debian goal.
If we do so, the mechanisms to make it work should not be as ad hoc
as this thread as hinted. We should provide a package explicitly
made to make this workflow tenable and point our users to it.
- We decide that if you want to mount /usr remotely you are on your
own.
If we do so, we should stop using mount /usr remotely as an
argument for keeping /usr as a single filesystem.
A few side notes:
* various people replying to my request mentioned that in such a
setup, you are not expected to upgrade too often the machine
exporting /usr
* everybody overlooked the subtle theoretical problem that our
maintainer scripts can potentially do *everything* on the file
system and *everywhere*, and that they are written in a Turing
complete language (shell script). This means that you cannot, in the
general case discover what they have touched. As a consequence you
can not simply rely on the dpkg database to know what you have to
propagate.
The trick of fiddling the dpkg database on the client machine and
then run dpkg --configure -a there is indeed nice. But again,
requesting our users to do that, potentially messing up with the
dpkg database, is IMO not something we can call being properly
supported in Debian. If it is supposed to work that way, we have to
provide higher level tools that do that for our users.
Cheers.
--
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: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli wrote: On Wed, May 06, 2009 at 09:38:39AM -0300, Daniel Ruoso wrote: Simple. sarcasm Sure, that's precisely what I'd call being properly supported in Debian. /sarcasm In particular, from the replies to my question the picture I get is that everybody is using ad hoc solutions to implement what some people are pretending to be properly supported by Debian. I found it not defendable, maybe it's just me, maybe it's just bad marketing. But system administration is per definition ad hoc solution. This is our power. Why we give sources? Also to allow us to tweak debian. Debian is a distribution, not a complete solution. I think we have a different idea of what is debian. Of the two one: - We decide that mounting /usr remotely is a Debian goal. If we do so, the mechanisms to make it work should not be as ad hoc as this thread as hinted. We should provide a package explicitly made to make this workflow tenable and point our users to it. - We decide that if you want to mount /usr remotely you are on your own. If we do so, we should stop using mount /usr remotely as an argument for keeping /usr as a single filesystem. But you are still selling us vapor! We still don't understand the problem! Was this a topic of last meeting of the Italian cabal? What is the problem: - remote /usr not supported? - /usr in a different partition ? - union mount could solve this? we cannot discuss without knowing the real problem! ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, 06 May 2009, Stefano Zacchiroli wrote: Of the two one: - We decide that mounting /usr remotely is a Debian goal. If we do so, the mechanisms to make it work should not be as ad hoc as this thread as hinted. We should provide a package explicitly made to make this workflow tenable and point our users to it. If we were limited by what debian (and d-i) can do out of the box this would be a sad world. And it'd make most software and Debian pretty useless in a lot of cases. It's kind of the job of a sysadmin to take what Debian (or any other vendor) gives them and integrate this into an environment that fulfill's the local requirements. The level of support that Debian provides for mounting remote /usr filesystems is apparently just fine or at least sufficient for the kind of user that makes use of it. Just don't break crap that has worked for years for no other reason than I want to. -- | .''`. ** Debian GNU/Linux ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli wrote: A few side notes: * everybody overlooked the subtle theoretical problem that our maintainer scripts can potentially do *everything* on the file system and *everywhere*, and that they are written in a Turing complete language (shell script). This means that you cannot, in the general case discover what they have touched. As a consequence you can not simply rely on the dpkg database to know what you have to propagate. But package installation is nullpotent. You can install again on every system. You still have one /usr, but right data in other places. Is it so important a consistent database? Things will still work. Remember that our policy require not to hardcore paths, so that a sysadmin can overwrite program using /usr/local. This means indirectly that what it is in database and what it is installed doesn't need to be consistent with what it is really used. And I don't understand why the dpkg database MUST be accurate. dpkg is smart enough to do the right things anyways. The trick of fiddling the dpkg database on the client machine and then run dpkg --configure -a there is indeed nice. But again, requesting our users to do that, potentially messing up with the dpkg database, is IMO not something we can call being properly supported in Debian. If it is supposed to work that way, we have to provide higher level tools that do that for our users. I agree that we must not support (helping users) such systems (but usually they have good sysadmins), but I find stupid to make life harder to such sysadmins. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
[Stefano Zacchiroli] The trick of fiddling the dpkg database on the client machine and then run dpkg --configure -a there is indeed nice. But again, requesting our users to do that, potentially messing up with the dpkg database, is IMO not something we can call being properly supported in Debian. If it is supposed to work that way, we have to provide higher level tools that do that for our users. Also, this procedure would be much more reliable if we said, in Policy, that maintainer scripts are not allowed to fail if /usr is not writable. (mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.) Would you support that policy? I suspect ldconfig would have to be patched in some way. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote:
But system administration is per definition ad hoc solution.
This is our power. Why we give sources? Also to allow us
to tweak debian.
This is a utterly poor argument.
I can easily twist it against you by saying why we give binaries?
We can just offer sources, system administrators will be able to
compile them.
A distribution is about integration of unrelated softwares and is
about making easier / more manageable tasks for various kind of users,
including system administrators.
Debian is a distribution, not a complete solution.
I think we have a different idea of what is debian.
Maybe we have.
Was this a topic of last meeting of the Italian cabal?
Is there anything useful in raising the Italian cabal here? The fact
I'm Italian has nothing to do with my arguments, pretty much as your
nationality has nothing to do with yours.
Or else add smileys if it was meant to be a joke.
But you are still selling us vapor!
We still don't understand the problem!
Anyhow, *you* don't understand the problem and you are probably the
only one thinking I'm selling vapor. From other people's replies I
conclude that the problem is quite clear and my vapor was so concrete
that others hinted at technical solutions. But let me spell the
problem out for you, as you are raising the tone of the discussion
with exclamation marks (which was not my intention).
The problem is that our package manager (dpkg) assumes it is in charge
of files which reside on different top-level FHS directories: /usr,
/var, /boot, /bin, /sbin, /lib, /lib64, ...
In a scenario where /usr is remotely exported for NFS mounting, if you
use dpkg on the exporting machine, client machines will get out of
sync. Some files need to be copied over statically and, more
interestingly, maintainer scripts will need to be re-run on client
machines to deliver their side effects to all machines. Also the
status of the dpkg database need to be synced with clients.
My argument is mainly that we should not ask our user to do the above
sync by hand, still claiming we support it.
Cheers.
--
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: deprecating /usr as a standalone filesystem?
Stefano Zacchiroli wrote: On Wed, May 06, 2009 at 03:06:34PM +0200, Giacomo A. Catenazzi wrote: But system administration is per definition ad hoc solution. This is our power. Why we give sources? Also to allow us to tweak debian. This is a utterly poor argument. I can easily twist it against you by saying why we give binaries? We can just offer sources, system administrators will be able to compile them. I said *also*. 10 years ago this was a real argument: use Linux because you can adapt to your local needs. I never installed a Debian system, which is 100% Debian. It always have some of my personality. For this case I mean: I don't think we should support directly, but we should allow our sysadmin to tweak /usr Was this a topic of last meeting of the Italian cabal? Is there anything useful in raising the Italian cabal here? The fact I'm Italian has nothing to do with my arguments, pretty much as your nationality has nothing to do with yours. Or else add smileys if it was meant to be a joke. sorry! Yes, it was meant as a joke. But you are still selling us vapor! We still don't understand the problem! Anyhow, *you* don't understand the problem and you are probably the only one thinking I'm selling vapor. From other people's replies I conclude that the problem is quite clear and my vapor was so concrete that others hinted at technical solutions. But let me spell the problem out for you, as you are raising the tone of the discussion with exclamation marks (which was not my intention). The problem is that our package manager (dpkg) assumes it is in charge of files which reside on different top-level FHS directories: /usr, /var, /boot, /bin, /sbin, /lib, /lib64, ... In a scenario where /usr is remotely exported for NFS mounting, if you use dpkg on the exporting machine, client machines will get out of sync. Some files need to be copied over statically and, more interestingly, maintainer scripts will need to be re-run on client machines to deliver their side effects to all machines. Also the status of the dpkg database need to be synced with clients. No. So I think also you did not understand the real problem. The /usr in NFS is one interpretation, but I really think it was not the original problem. Such ad hoc methods was never supported. [BTW we saw in the thread that we could share also / on multiple systems!] I think the problem is having /usr in an other partition (a larger set of configuration, and in this case, we supported it), thus having problem at boot, on what the init script could expect (program and libraries). Sorry for my tone, but we are disturbed on the fact that a proposal was done without giving reasons. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
VMBuilder for Debian
Hi, are there any plans to adopt https://code.launchpad.net/vmbuilder for Debian? Being able to create ec2, vmware or similar images easily would be nice to have for Debian, too. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: VMBuilder for Debian
Bernd Zeimetz a écrit : Hi, are there any plans to adopt https://code.launchpad.net/vmbuilder for Debian? Being able to create ec2, vmware or similar images easily would be nice to have for Debian, too. Hi Bernd, There is this: On-demand Cloud Computing with Amazon EC2 and Eucalyptus Integration Student: David Wendt Jr, Mentor: Steffen Moeller In many academic fields, as well as commercial industries, people use clusters to distribute tasks among multiple machines. Many times this is done by packaging a whole operating system disk image, uploading it onto the cluster, and having the cluster run it in a VM. This project intends to make it easier for Debian to distribute prepared disk images templates like they distribute CD images now, for the users to recreate or customize these templates with Debian packages and for administrators to host such clusters with Debian. See http://wiki.debian.org/SummerOfCode2009#SelectedProjects Cheers Arthur -- Obey Arthur Liu http://www.milliways.fr signature.asc Description: OpenPGP digital signature
Bug#527286: ITP: ansel1 -- Horde photo management application
Package: wnpp Severity: wishlist Owner: Mathieu Parent math.par...@gmail.com * Package name: ansel1 Version : 1.0 Upstream Authors: Chuck Hagenbuch ch...@horde.org Michael J. Rubinsky mrubi...@horde.org * URL : http://horde.org/ansel/ * License : GPL2 Programming Lang: PHP Description : Horde photo management application Ansel is a full featured photo management application. With it, you can create any number of galleries and subgalleries, share galleries among other Horde users or even make them public. You can upload images either one at a time, as a zip archive, or even upload them via Windows XP's Publish to Web functionality. You can browse your images, download originals, view galleries as a slideshow, add comments to images, send an 'ecard' to a friend, and more. You can crop, resize and perform other image manipulation functions. Ansel supports photo and gallery tagging, face detection, EXIF auto rotate, gallery themes, thumbnails, RSS, and more. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 03:31:23PM +0200, Stefano Zacchiroli wrote: Anyhow, *you* don't understand the problem and you are probably the only one thinking I'm selling vapor. From other people's replies I conclude that the problem is quite clear and my vapor was so concrete that others hinted at technical solutions. But let me spell the problem out for you, as you are raising the tone of the discussion with exclamation marks (which was not my intention). The problem is that our package manager (dpkg) assumes it is in charge of files which reside on different top-level FHS directories: /usr, /var, /boot, /bin, /sbin, /lib, /lib64, ... In a scenario where /usr is remotely exported for NFS mounting, if you use dpkg on the exporting machine, client machines will get out of sync. Some files need to be copied over statically and, more interestingly, maintainer scripts will need to be re-run on client machines to deliver their side effects to all machines. Also the status of the dpkg database need to be synced with clients. My argument is mainly that we should not ask our user to do the above sync by hand, still claiming we support it. But _NOBODY_ said to support the sync part in Debian. Just leave things as-is, i.e. let it possible to have /usr as a separate filesystem. We can do the rest, thank you very much. The fact that clients can get out of sync is perfectly understood and handled when needed. There is nothing new here; mounting /usr over NFS on Solaris boxes a decade ago had exactly the same basic issues. Don't ask users to do the sync by hand. Just _let_ them do it if they wish. Mounting /usr over NFS is an old technique. I wouldn't recommend it to anyone today but it exists and deliberately breaking it just because you do not like it is stupid. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#527280: ITP: php-perl-1.0.0 (use Perl from within PHP scripts)
Okay, again; waldi told me there are missing information, and that debian-de...@lists.d.o has to be Cc’d. Package name: php-perl (Binary: php5-perl) Version:1.0.0 Upstream Author:Dmitry Stogov Licence:PHP 3.0 (upstream), GPL (packaging) Language: C Description:Embedded Perl module for PHP 5 This extension embeds Perl Interpreter into PHP. It allows to execute Perl files, evaluate Perl code, access Perl variables and instantiate Perl objects. It’s a PECL extension (I only built the PHP 5 package because PHP 4 is pretty dead) which links against libperl to embed the interpreter. Example use case (with libbsd-arc4random-perl): $ php -r '$perl = new Perl(); $perl-eval(require BSD::arc4random;); echo $perl-eval(BSD::arc4random::arc4random();).\n;' 429322985 I’ll probably be using it to wrap Authen::Passphrase, so that e.g. LDAP style passwords can be used within PHP code (to facilitate code reuse; otherwise I’d have to rewrite it in PHP myself…). If there are any questions or change requests, I’m sure to listen. I’d like to get this into Debian. bye, //mirabilos -- 17:57 jtsn Der 25C3 ist lustig. Deutsche Vortragende brechen sich vor deutschen Zuhörern auf Englisch einen ab. ;-) 18:01 jtsn Adolfs Werk war sehr nachhaltig. ;-)18:01 jtsn Das gab's nichtmal in der DDR, das Deutsche mit Deutschen auf Russisch reden. ;-) (10x cnuke@) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le mercredi 06 mai 2009 à 08:57 -0500, Peter Samuelson a écrit : Also, this procedure would be much more reliable if we said, in Policy, that maintainer scripts are not allowed to fail if /usr is not writable. (mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.) Would you support that policy? I suspect ldconfig would have to be patched in some way. So, after people pestered me so that I moved python-support files from /var to /usr, now others will complain again and require them to go again to /var? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: deprecating /usr as a standalone filesystem?
On Tue, 05 May 2009, Marco d'Itri wrote: I know that Debian supports this, but I also know that maintaning forever large changes to packages for no real gain sucks. I wonder what these are, and I hope you will start a separate thread with that information. So, does anybody still see reasons to continue supporting a standalone /usr? Yes. We use that mode in _ALL_ servers. We keep it read-only except while applying security updates. This means it *never* gets hosed by crashes, and it is less vulnerable to accidental damage. / is also protected, using different strategies: it has to be read-write if you want to keep sane right now, so we have in / only /root, /boot, /etc, /bin and /sbin, plus mountpoints. These almost never change, so the filesystem is rarely modified. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian is switching to EGLIBC
| Debian is switching to EGLIBC | | I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is | currently waiting in the NEW queue), which will soon replace the GNU | C Library (GLIBC). | [...] -- http://blog.aurel32.net/?p=47 Where did this decission (and the discussion around it) took place? I can't find anything neither on debian-devel nor on debian-devel-glibc. -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian is switching to EGLIBC
Le mercredi 06 mai 2009 à 18:18 +0200, Michael Prokop a écrit : Where did this decission (and the discussion around it) took place? I can't find anything neither on debian-devel nor on debian-devel-glibc. Do all maintainers need your approval before switching to another branch for packages they maintain? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Debian is switching to EGLIBC
Michael Prokop a écrit : | Debian is switching to EGLIBC | | I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is | currently waiting in the NEW queue), which will soon replace the GNU | C Library (GLIBC). | [...] -- http://blog.aurel32.net/?p=47 Where did this decission (and the discussion around it) took place? I can't find anything neither on debian-devel nor on debian-devel-glibc. It has been discussed with a few people during Debconf, and on #debian-glibc and #debian-arm. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian is switching to EGLIBC
* Josselin Mouette j...@debian.org wrote: Le mercredi 06 mai 2009 =C3=A0 18:18 +0200, Michael Prokop a =C3=A9crit : Where did this decission (and the discussion around it) took place? I can't find anything neither on debian-devel nor on debian-devel-glibc. Do all maintainers need your approval before switching to another branch for packages they maintain? No. Though I think that for essential packages like libc it could be worth a public discussion. regards, -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Build-Depends: foo-dbg ?
Should source packages need to build-depend on debug packages? (See python-gtk2 for one example. python-all-dbg is small but python-numpy-dbg is 15Mb!) Just curious - is it only python packages that do this? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpEIU5BM5WKR.pgp Description: PGP signature
Re: Build-Depends: foo-dbg ?
Le mercredi 06 mai 2009 à 17:35 +0100, Neil Williams a écrit : Should source packages need to build-depend on debug packages? When it is needed. (See python-gtk2 for one example. python-all-dbg is small but python-numpy-dbg is 15Mb!) python-all-dbg brings python2.[45]-dbg, which makes 48 MB. Just curious - is it only python packages that do this? If you want to build an extension for python-dbg, you need python-dbg (which is a different interpreter). Is that so strange? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Debian is switching to EGLIBC
Michael Prokop a écrit : * Josselin Mouette j...@debian.org wrote: Le mercredi 06 mai 2009 =C3=A0 18:18 +0200, Michael Prokop a =C3=A9crit : Where did this decission (and the discussion around it) took place? I can't find anything neither on debian-devel nor on debian-devel-glibc. Do all maintainers need your approval before switching to another branch for packages they maintain? No. Though I think that for essential packages like libc it could be worth a public discussion. Should we also ask permission to everybody before uploading a new version of the libc? Frankly there is far less difference between GLIBC 2.9 and EGLIBC 2.9 than between GLIBC 2.9 and GLIBC 2.10. I could also have just taken the EGLIBC patches and put them in debian/patches, no one would have noticed. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian is switching to EGLIBC
On Thu, May 7, 2009 at 12:33 AM, Michael Prokop m...@grml.org wrote: No. Though I think that for essential packages like libc it could be worth a public discussion. In this case there wouldn't be any point of discussing it, I predict the discussion would simply be yes, AOL, +1, do it already, why isn't it done yet and so on. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian is switching to EGLIBC
* Aurelien Jarno aurel...@aurel32.net wrote: Michael Prokop a écrit : * Josselin Mouette j...@debian.org wrote: Le mercredi 06 mai 2009 =C3=A0 18:18 +0200, Michael Prokop a =C3=A9crit : Where did this decission (and the discussion around it) took place? I can't find anything neither on debian-devel nor on debian-devel-glibc. Do all maintainers need your approval before switching to another branch for packages they maintain? No. Though I think that for essential packages like libc it could be worth a public discussion. Should we also ask permission to everybody before uploading a new version of the libc? No need to become cynical. I didn't intend to put your technical decission into question. I highly appreciate Debian libc maintainer's work. I was just wondering that reddit, LWN,... had the news but debian-devel not. -mika- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Build-Depends: foo-dbg ?
On Wed, 06 May 2009 18:39:32 +0200 Josselin Mouette j...@debian.org wrote: Le mercredi 06 mai 2009 à 17:35 +0100, Neil Williams a écrit : Should source packages need to build-depend on debug packages? When it is needed. (See python-gtk2 for one example. python-all-dbg is small but python-numpy-dbg is 15Mb!) python-all-dbg brings python2.[45]-dbg, which makes 48 MB. :-( Just curious - is it only python packages that do this? If you want to build an extension for python-dbg, you need python-dbg (which is a different interpreter). Is that so strange? It did strike me as unusual when working from a basis of autotools and C/C++ packages. If the -dbg package is more than just debugging symbols, should those other parts be in the -dev and leave the debugging symbols alone? Is that practical with python-all-dbg? I'm more used to seeing -dbg packages as only being useful at runtime, not on autobuilders. The context is Emdebian, where the Grip flavour is intended to be a native build environment, if only for individual packages, local packages and similar. Yes, -dev packages have a large installation requirement and building packages has a large temporary data requirement. It's just that adding -dbg packages to that mix did seem excessive. I'm assuming from your reply that it's only when building extensions to python itself that you'd need python-all-dbg rather than for ordinary python builds like GUI python applications? (I don't know enough about python builds.) Is python-gtk2 a different interpreter? -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpxlIHwbrNqI.pgp Description: PGP signature
Bug#527305: ITP: libatasmart -- ATA S.M.A.R.T. reading and parsing library
Package: wnpp Severity: wishlist Owner: Michael Biebl bi...@debian.org * Package name: libatasmart Version : 0.13 Upstream Author : Lennart Poettering lenn...@poettering.net * URL : http://0pointer.de/blog/projects/being-smart.html * License : LGPLv2+ Programming Lang: C Description : ATA S.M.A.R.T. reading and parsing library A small and lightweight parser library for ATA S.M.A.R.T. hard disk health monitoring. The package will be split into: libatasmart-dev libatasmart0 libatasmart-bin libatasmart is a dependency of DeviceKit-disks and will be managed within the pkg-utopia team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Le 6 mai 09 à 00:30, Stefano Zacchiroli a écrit : On Wed, May 06, 2009 at 12:10:54AM +0200, Joerg Jaspert wrote: So, does anybody still see reasons to continue supporting a standalone /usr? There had been lots of responses to that. Yes, the most repeated argument has been mount /usr via NFS. Unfortunately, nobody yet explained how do they update the resulting cluster of machines. I guess there is a way if you want to upgrade your machines one by one : temporarily have 3 instances of /usr. The not-yet-upgraded machines will use /usr(old), the upgraded machines /usr(new), and the machine currently being upgraded will work on a /usr(tmp) which is a copy of /usr(old) and which it will upgrade into a copy of /usr(new). Now there is another way, which is to upgrade just one machine and clone its hard drive (except for the couple of files which need to be different). So that's two fairly easy ways to do it. There may be more clever ones. T. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Breaking /emul/ia32-linux for squeeze
On Wed, Mar 11, 2009 at 10:10:13PM -0700, Steve Langasek wrote: But moving the 32-bit libs to /usr/lib32 does not make us standards-conformant on amd64, because the FHS (yuckily) standardized on storing the *32-bit* libs in /usr/lib on this architecture, with 64-bit libs in /usr/lib64. That is true, which means that someone will undoubtedly file FHS-violation bugs on anything using /usr/lib32 after such a transition. On Thu, Mar 12, 2009 at 10:53:21AM +0100, Goswin von Brederlow wrote: NO NO NO NO NO NO NO NO. It is high time to change to the multiarch dir. For that gcc needs to be fixed first so compiling 32bit code does not break. Transitioning to /usr/lib32 will just needlessly break systems. The rest of this thread gives me the impression that 1) there is precious little chance that multiarch will happen anytime reasonably soon 2) there is no point in using multiarch directories instead of /usr/lib32 prematurely Aurélien and I are talking about switching to /usr/lib32 somewhere around the time that (E)GLIBC hits sid. Are we going to have multiarch soon so that project can be abandoned? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Making timezone configuration more modular
On Wed, Mar 11, 2009 at 06:11:18PM +, Clint Adams wrote: Thoughts? I am going to assume from the lack of responses to this that no one but the bug submitters care. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 02:56:20PM +0200, Stefano Zacchiroli wrote: In particular, from the replies to my question the picture I get is that everybody is using ad hoc solutions to implement what some people are pretending to be properly supported by Debian. I found it not defendable, maybe it's just me, maybe it's just bad marketing. Of the two one: - We decide that mounting /usr remotely is a Debian goal. If we do so, the mechanisms to make it work should not be as ad hoc as this thread as hinted. We should provide a package explicitly made to make this workflow tenable and point our users to it. - We decide that if you want to mount /usr remotely you are on your own. If we do so, we should stop using mount /usr remotely as an argument for keeping /usr as a single filesystem. What about the (many) arguments made here about the *other* reasons to have /usr a separate filesystem? regards, iustin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian is switching to EGLIBC
Aurelien Jarno wrote: Michael Prokop a écrit : | Debian is switching to EGLIBC | | I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is | currently waiting in the NEW queue), which will soon replace the GNU | C Library (GLIBC). | [...] -- http://blog.aurel32.net/?p=47 Where did this decission (and the discussion around it) took place? I can't find anything neither on debian-devel nor on debian-devel-glibc. It has been discussed with a few people during Debconf, and on #debian-glibc and #debian-arm. So I think the problem here is not that you made a technically bad decision. It sounds like you made a good decision. It's how it was communicated. 1) It didn't happen on any of the official Debian places that developers read. Nothing on debian-devel or d-d-a. 2) It didn't really convey how much of an impact this had. How minor a change it is -- that it is really a patch series atop glibc much in the same manner as go-oo.org is to OpenOffice. 3) Announcing to small subgroups of developers (those that can afford to to to conferences or that happen to be in an obscure IRC channel at the right time of day) is no substitute for announcing to developers in general. 4) Posting on a blog is no substitute for posting to debian-devel. glibc *is* a big deal. I read your blog post and alarm bells went off in my head (the project has a *goal* to maintain API/ABI compatibility, but not a guarantee, for instance?) The language about switching made it worse. I for one would have appreciated it if, before the upload, you had laid out why you're planning to do it here on debian-devel. I don't think you would have met any opposition. You have to realize that glibc is not just another package. Where it may not matter that much to the general public if openoffice.org switches upstreams to a patch series, glibc is a different beast with far longer tentacles in every bit of the system. I, for one, have heard just about enough of Hey developers, we're doing $FOO, and it's already been decided, so put up or shut up from people. I'd like a little bit more along the lines of Hey developers, we really think $FOO is a good idea. Here's why. What do you all think? -- John -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian is switching to EGLIBC
John Goerzen jgoer...@complete.org wrote: Hi, I, for one, have heard just about enough of Hey developers, we're doing $FOO, and it's already been decided, so put up or shut up from people. I'd like a little bit more along the lines of Hey developers, we really think $FOO is a good idea. Here's why. What do you all think? How does hey developers, we're sick and tired of having to put up with Uli, how about you find some new people to maintain glibc in Debian sound like? Switching to eglibc is a matter of reducing the burden placed on our libc maintainers due to glibc upstream not giving a crap about most of the architectures we support. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Build-Depends: foo-dbg ?
On Wed, May 06, 2009, Neil Williams wrote: (See python-gtk2 for one example. python-all-dbg is small but python-numpy-dbg is 15Mb!) pythonx.y-dbg is ABI incompatible with pythonx.y and we need to bdep on pythonx.y-dbg to build a -dbg for a python extension -- these are *not* detached debugging symbols, but an alternate implementation of the module which will only work with debug versions of python. Because of this ABI difference, if you need to use python-foo to build python-bar, then you need a python-foo-dbg and to bdep on it to build python-bar-dbg. Cheers -- Loïc Minier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
Philipp Kern tr...@philkern.de writes: On 2009-05-06, Russ Allbery r...@debian.org wrote: I think it's pretty unlikely that *most* Debian machines are done that way. There are a lot better tools for keeping large numbers of systems in sync these days than simple cloning from golden images, and a lot of drawbacks to the golden image approach. We do the same with ~12 clients. One master image that's declared stable by rsyncing it using hardlinks[0] on the server and from there rsynced to the clients which reboot automatically if there are pending updates. After the rsyncing it does local profile-based patching. I wonder about the drawbacks of this because it works really nice for us. (Of course there's the downtime problem, but that's no problem for us, as those are clients not servers.) If you start getting node variation, it turns into a headache. If you're in a situation where you're assured of no node variation, it works fairly well within that situation, but we want one solution that works for *all* types of servers we run, whether clusters or one-offs or smaller sets of load-balanced servers. You can also get a slow accumulation of cruft in your golden image over time, and if you don't keep good documentation, it's really easy to discover that you no longer know exactly how to rebuild your golden image if you need to (such as for a new OS release). But why bother to do a complete reinstall everytime something changed if you could just sync the delta. (And yes, I'm roughly aware that there are something like softupdates in FAI too, but still.) We don't do it every time something changes; usually we use Puppet to push incremental changes. We rebuild systems whenever we repurpose them or whenever we do a major OS upgrade. I like rebuilding systems from first principles for exactly the same reason that I like recompiling the whole Debian archive. It tests your process. Having a complete process for building a system rather than a static system image that you may or may not be able to reproduce makes it much easier to migrate to new releases of the OS (because you can layer most of your policy on top of the new release), change any part of the process, etc. I've done this pretty much every different way you can with a lot of versions of UNIX: golden images, portions of the file system in network file systems, specific change application scripts, everything with native packages, mixes of native packaging and configuration management systems, etc. For a fairly heterogeneous mix of servers that may include some clusters of identical systems, I think FAI plus a good configuration management system like Puppet is the way to go. It makes me feel the most comfortable about the upgrade path, the testing of the whole system, and the robustness of the environment. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian is switching to EGLIBC
Hi all, It is new to me that we should announce changes in packages on debian-devel. I haven't seen that before for other (key) packages, while it is very usual to see such announcements on planet.debian.org. I have decided to add a blog entry after many people asking me on IRC What is this thing in NEW?. As it seems people are complaining, let's do it (copy and paste from my blog): | I have just uploaded Embedded GLIBC (EGLIBC) into the archive (it is | currently waiting in the NEW queue), which will soon replace the GNU | C Library (GLIBC). The EGLIBC is a variant of the GLIBC which stays | source and binary compatible with the original GLIBC. While primarily | targeted for embedded architectures, it has some really nice points: | - More friendly upstream (especially with regard to embedded | architectures): “Encourage cooperation, communication, civility, and | respect among developers” (as opposed to this). | - Stable branch with fixes for important bugs (a real one, not like the | GLIBC one which is left unchanged). | - Better support for embedded architectures. | - Support for different shells (GLIBC only supports bash). | - Support for building with -Os. | - Configurable components (do we really need NIS or RPC support in | debian-installer?). | - Better testsuite for optimized or biarch packages. Let's add an other point I forget: - Support of MPCore for ARM. | We do not use some of these features yet, but this upload is a first | step. From the user point of view, the package names are unchanged | (except the source package and the binary package containing the | sources) so no transition is needed. And to answer some of the questions: - EGLIBC is constantly tracking GLIBC. You should consider that as a set of patches applied on top of GLIBC. - The API and ABI compatibility is retained as long as you don't disable some components, in which case you are removing functions and breaking API and ABI. We do not plan to disable components in the main Debian package, but it something that may be possible in the future for example in the .udeb version. - As most as possible code (read if accepted) in EGLIBC is contributed back to GLIBC. That's why FSF assignement is still needed for EGLIBC. - I am following EGLIBC development for more than a year, and tried it on Debian during last Debconf. The code is already in the SVN for two/three months ago. - We could have done that silently by putting the patches in debian/patches (which would have skip the wait xxx days in NEW), but that would have been unfair with upstream EGLIBC, who is doing a great job. - The package has been built on all Debian architectures [1] and checked for regressions in the testsuite. Some bugs have been found in the biarch and optimized packages, as strangely some parts of the testsuite were skipped. - strlcpy() and strlcat() won't be added to EGLIBC as it would break the ABI and API. Use libbsd [2] for that, it is already in the archive. Cheers, Aurelien [1] alpha amd64 armel hppa i386 ia64 mips mipsel powerpc s390 sparc hurd-i386 kfreebsd-i386 kfreebsd-amd64 [2] http://libbsd.freedesktop.org -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net signature.asc Description: Digital signature
triggers and lenny-to-squeeze upgrades
Dear developers, There is an increased usage of triggers in squeeze and I would like to issue a word of warning concerning lenny to squeeze upgrade: Before removing the maintainer script code that that is replaced by the activation of a trigger, you have to make sure that a suitable version of the triggered package is installed, at the very least, one that register a trigger. To allow for lenny to squeeze upgrade (including partial upgrade), this means that either 1) the lenny version of the triggered package already register the trigger. or 2) the triggering package depends on an appropriate version of the triggered package. otherwise there is no garanty that the trigger will be available when the package is upgraded. This might be critical with e.g. boot loaders. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. signature.asc Description: Digital signature
Re: Debian is switching to EGLIBC
On Wed, 06 May 2009 21:57:19 +0200 Julien BLACHE jbla...@debian.org wrote: How does hey developers, we're sick and tired of having to put up with Uli, how about you find some new people to maintain glibc in Debian sound like? It sounds unnecessarily confrontational---it's daring people to disagree with you. It's going to get up the hackles of even those people who know what Ulrich Drepper is like to deal with. Trust the community to be reasonable, and it will trust you to do the right thing, too. Communicate to the community in a reasonable fashion, and it will do likewise. Be opaque, secretive and confrontational, well...GIGO. Switching to eglibc is a matter of reducing the burden placed on our libc maintainers due to glibc upstream not giving a crap about most of the architectures we support. Which is entirely reasonable, and I don't think anyone has suggested that these are not important things---and if you had sent a message to a list read by some significant portion of the community, outlining exactly those things, this would have likely been a non-issue. But the presentation---or lack thereof---of the issues was done in a way that might as well have been precision-engineered to create a backlash. That is not effective communication. Mike. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527328: ITP: python-django-south -- intelligent schema migrations for Django apps
Package: wnpp Severity: wishlist Owner: Janos Guljas ja...@janos.in.rs * Package name: python-django-south Version : svn Upstream Author : Andrew Godwin and...@aeracode.org * URL : http://south.aeracode.org * License : Apache Programming Lang: Python Description : intelligent schema migrations for Django apps Plaease include python-django-south. South is an intelligent database migrations library for the Django web framework. It is database-independent and DVCS-friendly, as well as a whole host of other features. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#508644: new release goal default-mta? (was: stable-p-u: mdadm 2.6.7.2-2)
On Tue, May 05, 2009 at 05:06:26PM +0200, martin f krafft wrote: also sprach Carsten Hey cars...@debian.org [2009.05.05.1645 +0200]: Depending on default-mta | mta in a upload to s-p-u does not fix anything since there is no default-mta in stable. This would possibly even break pinning in unexpected ways for users with stable and testing in their source.list. Thus please consider depending on exim4 | mta or postfix | mta in your upload to s-p-u and changing the dependency as discussed for your next upload to sid. Of course. sid: http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=commitdiff;h=93eecf12c706c1c01f1d0a8c45c20639ca8afe3f spu: http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=commitdiff;h=541c07a775104848ed99e2cb5935496c8718807a I cannot leave it at postfix|mta apparently, because that's frowned upon (although the policy does not back up this complaint). FWIW, Ubuntu did what I consider the right thing: http://launchpadlibrarian.net/21235281/mdadm_2.6.7.1-1ubuntu4_2.6.7.1-1ubuntu5.diff.gz Well, this is the right thing in Ubuntu because postfix is the default MTA for Ubuntu. In Debian, this is not the case, so mdadm recommending postfix by preference causes inconsistent behavior depending on the order in which the user installs packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
Steve Langasek wrote: On Tue, May 05, 2009 at 05:06:26PM +0200, martin f krafft wrote: also sprach Carsten Hey cars...@debian.org [2009.05.05.1645 +0200]: FWIW, Ubuntu did what I consider the right thing: http://launchpadlibrarian.net/21235281/mdadm_2.6.7.1-1ubuntu4_2.6.7.1-1ubuntu5.diff.gz Well, this is the right thing in Ubuntu because postfix is the default MTA for Ubuntu. In Debian, this is not the case, so mdadm recommending postfix by preference causes inconsistent behavior depending on the order in which the user installs packages. Maybe we should also consider changing the default MTA to postfix? Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#527328: ITP: python-django-south -- Intelligent schema migrations for django apps
On Wed, May 06, 2009 at 10:53:33PM +0200, Janos Guljas wrote: Package: wnpp Severity: wishlist Owner: Janos Guljas ja...@janos.in.rs * Package name: python-django-south An ITP for this was already filed[0] by David Watson (CCed) a few days ago. Maybe the two of you could work together on the package? [0] http://bugs.debian.org/526348 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On May 06, Luk Claes l...@debian.org wrote: Maybe we should also consider changing the default MTA to postfix? Agreed, it's about time. -- ciao, Marco signature.asc Description: Digital signature
Re: Debian is switching to EGLIBC
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 06 May 2009 14:21:05 -0500 John Goerzen jgoer...@complete.org wrote: I for one would have appreciated it if, before the upload, you had laid out why you're planning to do it here on debian-devel. I don't think you would have met any opposition. I wouldn't assume that. Cheers, - -- Yves-Alexis -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoCA6EACgkQTUTAIMXAW656MACgpIj3JIExKXUmK9D7h+xtObc5 KCMAn0gdxnNoKlQJq91cMWLYHpm2gVmL =cbbp -END PGP SIGNATURE-
Re: Bug#527328: ITP: python-django-south -- Intelligent schema migrations for django apps
I will get in touch with David Watson. Thank you. On Wed, May 6, 2009 at 11:29 PM, James Vega james...@debian.org wrote: On Wed, May 06, 2009 at 10:53:33PM +0200, Janos Guljas wrote: Package: wnpp Severity: wishlist Owner: Janos Guljas ja...@janos.in.rs * Package name : python-django-south An ITP for this was already filed[0] by David Watson (CCed) a few days ago. Maybe the two of you could work together on the package? [0] http://bugs.debian.org/526348 -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoCATAACgkQDb3UpmEybUBY2QCgkQpuBZBuAMfjw+rnGk60ZiVR cqIAn2h5io/4CYa32Jz2kOMPEWq7pAbK =/5c4 -END PGP SIGNATURE- -- Janoš Guljaš ja...@janos.in.rs WWW: http://www.janos.in.rs GPG: public key ID 61D97459, http://www.janos.in.rs/janosguljas.asc signature.asc Description: OpenPGP digital signature
Re: Build-Depends: foo-dbg ?
Le mercredi 06 mai 2009 à 18:14 +0100, Neil Williams a écrit : It did strike me as unusual when working from a basis of autotools and C/C++ packages. If the -dbg package is more than just debugging symbols, should those other parts be in the -dev and leave the debugging symbols alone? Is that practical with python-all-dbg? python-gtk2-dbg contains two things: * detached debugging symbols for the regular modules * modules suitable for the python2.X-dbg interpreters The detached symbols are often enough if a bug happens in GTK+ or directly in the override, but if you really want to debug the Python modules themselves with a look at the interaction between C and Python code, you need the python-dbg interpreter, with an entirely different set of modules. I'm assuming from your reply that it's only when building extensions to python itself that you'd need python-all-dbg rather than for ordinary python builds like GUI python applications? (I don't know enough about python builds.) Is python-gtk2 a different interpreter? You only need python-all-dbg when building C extensions for the python2.X-dbg interpreter. python-gtk2 is not an interpreter in itself, it is a set of C extensions for the python2.X interpreters, while python-gtk2-dbg is the same set of extensions for the python2.X-dbg interpreters. For developing pure Python applications, you only need python and python-gtk2. Only when developing C extensions to Python will you need python-all-dev, and when developing C extensions to Python deriving from the GTK+ classes will you need python-gtk2-dev. (Sorry for the repetitions, but there doesn’t seem to be a straightforward way to explain that.) Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Debian is switching to EGLIBC
Julien BLACHE wrote: John Goerzen jgoer...@complete.org wrote: Hi, I, for one, have heard just about enough of Hey developers, we're doing $FOO, and it's already been decided, so put up or shut up from people. I'd like a little bit more along the lines of Hey developers, we really think $FOO is a good idea. Here's why. What do you all think? How does hey developers, we're sick and tired of having to put up with Uli, how about you find some new people to maintain glibc in Debian sound like? Having to deal with Uli is a pretty strong argument in favor of switching to eglibc in my mind, but it still doesn't mean it has to be presented as a fait accompli. Switching to eglibc is a matter of reducing the burden placed on our libc maintainers due to glibc upstream not giving a crap about most of the architectures we support. JB. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
Le mercredi 06 mai 2009 à 23:29 +0200, Luk Claes a écrit : Maybe we should also consider changing the default MTA to postfix? Given that the default configuration is extremely simplistic and doesn’t use a percent of either exim or postfix features, I still wonder why it is not something like nullmailer or ssmtp. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: Debian is switching to EGLIBC
Yves-Alexis Perez wrote: On Wed, 06 May 2009 14:21:05 -0500 John Goerzen jgoer...@complete.org wrote: I for one would have appreciated it if, before the upload, you had laid out why you're planning to do it here on debian-devel. I don't think you would have met any opposition. I wouldn't assume that. Well, here it is on -devel, and you haven't met any opposition. Just people like me saying that it wasn't presented very well. Cheers, -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem? [386 support]
Le mardi 05 mai 2009 à 23:38 +0200, Frank Lin PIAT a écrit : Interesting. I thought 386 wasn't supported anymore (?) AFAIK the kernel is able to emulate a 486 when running on a 386. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
Josselin Mouette wrote: Le mercredi 06 mai 2009 à 23:29 +0200, Luk Claes a écrit : Maybe we should also consider changing the default MTA to postfix? Given that the default configuration is extremely simplistic and doesn’t use a percent of either exim or postfix features, I still wonder why it is not something like nullmailer or ssmtp. The default configuration and the default MTA are something different IMHO. The default configuration is the one that should work for most people. The default MTA if the one that should work easily for most situations IMHO. Cheers Luk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: blocked libtool
+ Thorsten Alteholz (Wed, 06 May 2009 13:22:53 +0200): Hi Adeodato, Hello, Thorsten (hope it's okay I'm quoting you in public). could you please tell me the reason for blocking libtool's transition from unstable to testing? I have a few packages that depend on libtool but don't want to disturb debian-release if there is still a reason for blocking it. Thorsten asks about this output in the migration pages: | Trying to update libtool from 1.5.26-4 to 2.2.6a-4 (candidate is 28 days old) | Not touching package, as requested by adeodato (contact debian-release if update is needed) I thought maybe more people are wondering about this, and I added an explanatory paragraph on my hint file [1], which I reproduce now: # == Performance blocks == # Block here some transitions so that britney runs faster. Even if any # of these packages is a candidate for migration itself (older than 10 # days, etc.), it doesn't mean it will be able to migrate, since all of # its reverse dependencies have to be ready as well. But britney chokes # rather badly on some of these packages, taking a lot of time to # process them and their reverse dependencies; because of this, and to # keep ftp-master free of spurious CPU churn (it's a host that sees # quite a lot of interactive use), we prevent britney from trying to # migrate some packages for as long as it wouldn't succeed anyway. (This # is determined by a human, but in general a package being blocked out # of this paragraph implies there's nothing else preventing migration # than waiting for the reverse dependencies to be ready.) block libtool block gnome-sharp2 block totem-pl-parser FWIW, this is only done for transitions that are big enough as to cause a noticeable slow down (libtool eg. involves around 600 Bin-NMUs), or transitions that britney really chokes on when calculating uninstallabilities (eg. totem-pl-parser, no idea why). Cheers, [1]: http://release.debian.org/britney/hints/adeodato -- - Are you sure we're good? - Always. -- Rory and Lorelai -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
also sprach Joerg Jaspert jo...@debian.org [2009.05.07.0002 +0200]: As much as i like postfix and hate exim: no. If we change, please go to something like nullmailer|ssmtp|whateversimple. Correct me if I am wrong, but I think those do not do queueing, which will break the default assumption that I've seen almost everywhere, which is that when sendmail returns, your email is getting delivered, or you'll get a DSN. Nullmailer is not LSB-compliant. And neither of the small ones handle mail to root on the local system (cron, apticron, logcheck, etc.) in an acceptable manner, I think. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems if beethoven's seventh symphony is not by some means abridged, it will soon fall into disuse. -- philip hale, boston music critic, 1837 digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
also sprach Marco d'Itri m...@linux.it [2009.05.06.2338 +0200]: Maybe we should also consider changing the default MTA to postfix? Agreed, it's about time. http://doodle.com/exre35q7ckruyxpx -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems the human brain is like an enormous fish -- it is flat and slimy and has gills through which it can see. -- monty python digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
Le jeudi 07 mai 2009 à 00:01 +0200, Luk Claes a écrit : The default MTA if the one that should work easily for most situations IMHO. Where do we draw the line for “most situations”? If you want to do serious email work, you’ll have to spend some time configuring your exim/postfix and install extra components to run with it. If you don’t, a trivial configuration will do the trick, and you’ll have it just as easily with “light” daemons, but with less bloat. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On 11742 March 1977, Luk Claes wrote: Maybe we should also consider changing the default MTA to postfix? As much as i like postfix and hate exim: no. If we change, please go to something like nullmailer|ssmtp|whateversimple. -- bye, Joerg Overfiend joshk: okay. I've manned a Debian booth before. I need to give you a quick training session. Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? Overfiend So, when's sarge going to be released? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: deprecating /usr as a standalone filesystem?
On Wed, May 06, 2009 at 09:36:56PM +0200, Iustin Pop wrote:
- We decide that if you want to mount /usr remotely you are on your
own.
If we do so, we should stop using mount /usr remotely as an
argument for keeping /usr as a single filesystem.
What about the (many) arguments made here about the *other* reasons to
have /usr a separate filesystem?
I've nothing against them, I was countering only this precise
argument. FWIW, I haven't seen that many, though the one about
read-only /usr was appropriate.
Cheers.
--
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: deprecating /usr as a standalone filesystem?
On Thu May 07 00:38, Stefano Zacchiroli wrote: What about the (many) arguments made here about the *other* reasons to have /usr a separate filesystem? I've nothing against them, I was countering only this precise argument. FWIW, I haven't seen that many, though the one about read-only /usr was appropriate. More to the point, has anyone actually presented any real arguments why _not_ to allow it? I've not actually seen anything other than the OP saying things might need changing to support it and then refusing to go into detail. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On Thu, 07 May 2009, martin f krafft wrote: Correct me if I am wrong, but I think those do not do queueing, which will break the default assumption that I've seen almost everywhere, which is that when sendmail returns, your email is getting delivered, or you'll get a DSN. Nullmailer does. Nullmailer is not LSB-compliant. Because it doesn't implement -bs (#271662), which is of dubious value (and a part of the LSB specification which only seems to be there because real MTAs supported it; there's was no rationale given in the standards why it has to be there.) And neither of the small ones handle mail to root on the local system (cron, apticron, logcheck, etc.) in an acceptable manner, I think. Nullmailer handles this by sending all of that mail to a single account. The main problem with nullmailer is that it currently can't handle messages which fail permanently (#329192). Don Armstrong -- Vimes hated and despised the privileges of rank, but they had this to be said for them: At least they meant that you could hate and despise them in comfort. -- Terry Pratchett _The Fifth Elephant_ p111 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527341: ITP: python-django-squeeze -- Squeeze JS/CSS files on the fly, for Django
Package: wnpp Severity: wishlist Owner: Janos Guljas ja...@janos.in.rs * Package name: python-django-squeeze Version : 0+git20090142 Upstream Author : Artiom Diomin kro...@gmail.com * URL : http://github.com/kron4eg/django-squeeze/tree * License : BSD Programming Lang: Python Description : Squeeze JS/CSS files on the fly, for Django Please package this very handy application. Django application for CSS and JavaScript minifacation on the fly. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dpkg-shlibdeps question
On Mon, 04 May 2009 19:07:18 +0200, Raphael Hertzog hert...@debian.org wrote: On Fri, 01 May 2009, Jiří Paleček wrote: should almost never happen (except diversion) and the result when it happens is Should I read it as the only legal situation where it returns multiple packages are diversions (the rest are errors) or the majority of situations ... are diversions, ie. does it make sense to return multiple packages in the absence of diversions? dpkg -S can return multiple packages for directories too since they can be shared by many packages but in the case of real files AFAIK it can only happen with diversions. Ok. Thanks. Yes, but I think this is unattainable. Especially when doing transitions, you're not likely to have both packages in sync. I don't see why it would be so difficult. Diverting a file means that you have a drop-in replacement and I don't see why you couldn't provide dependencies that are compatible (even if not exactly the same). Yes, you can make it compatible (although I'm not sure what exactly you mean by compatible). Or maybe even the same, but when things change, it has to be maintained, which doesn't happen automatically. I just wanted to know if it would be OK for dpkg-shlibdeps to use only one package for a library (eg. in case of diversions, use dpkg-divert to find the right one) and fail in case of ambiguity. What is the right one, the non-diverted one ? I'd say so. If the purpose of dpkg-shlibs is to translate shared object dependencies as viewed by ld.so into package dependencies for dpkg, it seems to me the correct package(s) to depend on is the one that provides the binary that was used for the build (let's put aside the situations when no package contains the library used, eg. it was provided by the user who overwrote the file from the package). Regards Jiri Palecek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On Thu, May 07, 2009 at 12:14:42AM +0200, martin f krafft wrote: also sprach Joerg Jaspert jo...@debian.org [2009.05.07.0002 +0200]: As much as i like postfix and hate exim: no. If we change, please go to something like nullmailer|ssmtp|whateversimple. Correct me if I am wrong, but I think those do not do queueing, which will break the default assumption that I've seen almost everywhere, which is that when sendmail returns, your email is getting delivered, or you'll get a DSN. Why do you want to wait for a DSN? For these non-queuing solutions, sendmail won't return until the mail have been delivered to the real MTA. If this doesn't not work, the process returns immediately with an error. If the mail does get to a real MTA, and then fails, then the real MTA will do the DSN. All the MUAs I have tried will show this error to the user, and allow the user to retry sending again. Obviously, yes, you really do need a real MTA, with properly queueing, somewhere. It doesn't have to run on every single system though. -- Brian May b...@snoopy.debian.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#527341: ITP: python-django-squeeze -- Squeeze JS/CSS files on the fly, for Django
Janos Guljas wrote: Please package this very handy application. Do you intend to package it, or do you want somebody else to package it? If the latter, this should be an RFP and not an ITP: http://www.debian.org/devel/wnpp/ Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: deprecating /usr as a standalone filesystem?
Peter Samuelson pe...@p12n.org writes: Also, this procedure would be much more reliable if we said, in Policy, that maintainer scripts are not allowed to fail if /usr is not writable. (mount -o ro, SELinux, chattr +i, NFS root_squash, whatever.) Would you support that policy? I suspect ldconfig would have to be patched in some way. I certainly wouldn't. The maintainer scripts need to be able to do whatever they need to do in order to get the package set up on the system. That certainly includes changing things in ‘/usr’, which requires that filesystem to be writable during package management. Those who want a read-only ‘/usr’ don't seriously try to leave it read-only while installing or upgrading packages, do they? -- \ “The optimist thinks this is the best of all possible worlds. | `\ The pessimist fears it is true.” —J. Robert Oppenheimer | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On May 06, Josselin Mouette j...@debian.org wrote: Given that the default configuration is extremely simplistic and doesn???t use a percent of either exim or postfix features, I still wonder why it is not something like nullmailer or ssmtp. Because it's expected from a UNIX system to be able to deliver mail to local mailboxes. -- ciao, Marco signature.asc Description: Digital signature
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
On Thu, May 07, 2009 at 03:24:13AM +0200, Marco d'Itri wrote:
On May 06, Josselin Mouette j...@debian.org wrote:
Given that the default configuration is extremely simplistic and doesn???t
use a percent of either exim or postfix features, I still wonder why it
is not something like nullmailer or ssmtp.
Because it's expected from a UNIX system to be able to deliver mail to
local mailboxes.
esmtp can do this, if you configure it to use procmail or something.
However, I very much dislike this Unix feature as it means mail can
accumulate on any {user,system} account on any computer and not get
noticed by the {user,system administrator}.
--
Brian May b...@snoopy.debian.net
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]
Quoting Josselin Mouette (j...@debian.org): Where do we draw the line for “most situations”? If you want to do serious email work, you’ll have to spend some time configuring your exim/postfix and install extra components to run with it. If you don’t, a trivial configuration will do the trick, and you’ll have it just as easily with “light” daemons, but with less bloat. With my preferred hat (the very dumb user/sysadmin hat), I would definitely wote for this. I have several servers spread around here and there in my professionnal environement, which I did setup in the past and all needed to have a local MTA. But none of them being a mail server per se, the MTA being often needed for minor pruposes... All of them are setup with postfix and its default configuration without any fancy stuff. This is the first thing I do when I install a Debian server, indeed. This is very certainly overbloat for these needs but it never harmed.and when some of these later needed a more specific setup, it became very easy to tweak it because of the widely available literature and tools that deal with postfix. So, from such POV, having postfix fits both my needs of a dumb person setup and the needs for more advanced features. Even though I have no competence for this, I've also always considered postfix as a kind of reference when it comes at security and reliabilityas well as somethign well maintained in the log term. That's purely subjective feeling but that counts and I think that having Debian install something that currently has the community recognition that Postfix has is something we wish. I'm not sure that the light daemons have this. signature.asc Description: Digital signature
Re: Debian is switching to EGLIBC
Quoting John Goerzen (jgoer...@complete.org): So I think the problem here is not that you made a technically bad decision. It sounds like you made a good decision. It's how it was communicated. I guess that, in some way, the glibc maintainers wanted to save us from a probably very long and useless thread in -devel. I personnally applause to the technical decision, mostly because I have a very deep confidence in glibc maintainers ability to handle this properly and take the right decisions. Still, as John points, I think that something should have happened before this, in a more publicly visible place than the internal development mailing list or a blog entry. Maybe a discussion with the Technical Comittee first, or something like this. Maybe even an annoucement in -devel-announce. Again, this is certainly not about asking permission to do things that *are* in the field of expertise of glibc maintainers but *anyway* communicating with others and not just announce this change in a blog post. I hope that you guys will understand that suggestion. signature.asc Description: Digital signature
Re: Debian is switching to EGLIBC
John Goerzen wrote: Julien BLACHE wrote: John Goerzen jgoer...@complete.org wrote: Hi, I, for one, have heard just about enough of Hey developers, we're doing $FOO, and it's already been decided, so put up or shut up from people. I'd like a little bit more along the lines of Hey developers, we really think $FOO is a good idea. Here's why. What do you all think? How does hey developers, we're sick and tired of having to put up with Uli, how about you find some new people to maintain glibc in Debian sound like? Having to deal with Uli is a pretty strong argument in favor of switching to eglibc in my mind, but it still doesn't mean it has to be presented as a fait accompli. I fully agree, especially considering that EGLIBC want to be more open in comparison to glibc (or better, its maintainer). Don't do the same errors as glibc! BTW, IMHO an announcement in d-d-d should be made. Normally a change of system libraries has huge impact on maintainer and user (and still on our nightmares), so an assuring mail would good. (and also to have better references to media. The auriel blog has too much personal attack). ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted debian-maintainers 1.58 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 15:43:35 +1000 Source: debian-maintainers Binary: debian-maintainers Architecture: source all Version: 1.58 Distribution: unstable Urgency: medium Maintainer: Debian Maintainer Keyring Team d-m-t...@lists.alioth.debian.org Changed-By: Anibal Monsalve Salazar ani...@debian.org Description: debian-maintainers - GPG keys of Debian maintainers Closes: 525541 526484 Changes: debian-maintainers (1.58) unstable; urgency=medium . * Add Debian maintainer Marco Túlio Gontijo e Silva. Closes: #525541 * Add Debian maintainer Sven Eckelmann. Closes: #526484 Checksums-Sha1: 6f778ab7da62060920ca68093ba1665c0c6ba623 1392 debian-maintainers_1.58.dsc 59e4fca2de7756eaaf22a10b42abd3f146730979 1220504 debian-maintainers_1.58.tar.gz e7d60beab0fc7a76f254afdd0a193d0af2b5baaf 537602 debian-maintainers_1.58_all.deb b5b0f715091e9f34724ba2fb57f6be079d50cb93 648668 debian-maintainers_1.58_all.gpg Checksums-Sha256: 0a8be92a426b15c3b612746a4ca73fb833da0c6a544fc64fdbae077914b7c301 1392 debian-maintainers_1.58.dsc e1ff6df78f3270d1817e096e673ac1b7ff9faf7094bcaface09fd7a62b69aac3 1220504 debian-maintainers_1.58.tar.gz e25c80ba39dcde9487606ac0e5d2423bf94b1f2eebfd76609d4afc510e84c193 537602 debian-maintainers_1.58_all.deb b2380268c90bd1370c65246525f998a30d1b7a6b5c79cbc57a0697f716acf9c0 648668 debian-maintainers_1.58_all.gpg Files: dcab80efc4006cbeaddbab5582564c00 1392 misc extra debian-maintainers_1.58.dsc 89d9e5b0b0e3b35721d77f698cf02fd9 1220504 misc extra debian-maintainers_1.58.tar.gz fdc2ba1ccd3babc315afec23e4ca6ebd 537602 misc extra debian-maintainers_1.58_all.deb d8be72054b2a4b6dc38254485290cc71 648668 raw-keyring - debian-maintainers_1.58_all.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoBKUcACgkQgY5NIXPNpFUxEwCghTF/LZT10Pd+f83uYSv6utxf ynMAnjMoTBpHbZJQxA8yjticgWgPUQbz =lVFl -END PGP SIGNATURE- Accepted: debian-maintainers_1.58.dsc to pool/main/d/debian-maintainers/debian-maintainers_1.58.dsc debian-maintainers_1.58.tar.gz to pool/main/d/debian-maintainers/debian-maintainers_1.58.tar.gz debian-maintainers_1.58_all.deb to pool/main/d/debian-maintainers/debian-maintainers_1.58_all.deb debian-maintainers_1.58_all.gpg byhand -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted freebsd-manpages 7.2-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 03 May 2009 12:05:51 +0200 Source: freebsd-manpages Binary: freebsd-manpages Architecture: source all Version: 7.2-1 Distribution: unstable Urgency: low Maintainer: Gürkan Sengün gur...@phys.ethz.ch Changed-By: Gürkan Sengün gur...@phys.ethz.ch Description: freebsd-manpages - Manual pages for a GNU/kFreeBSD system Changes: freebsd-manpages (7.2-1) unstable; urgency=low . * New upstream version. Checksums-Sha1: 9f082974fffc7e895d7537328ee0b76aa46e3e44 1056 freebsd-manpages_7.2-1.dsc 4864bf690cb885bd8421e84adb9b400a58511ebc 8121368 freebsd-manpages_7.2.orig.tar.gz b1c543b20416d9ffeca610839d96ccb5f8eaf93d 2526 freebsd-manpages_7.2-1.diff.gz f782eb6044be0246dbd1a36e033ba2278720fb84 6336326 freebsd-manpages_7.2-1_all.deb Checksums-Sha256: 34f97453c3e2748f0a1fff7ab06e28b3b0bcf52bfdd94d6a3aed67b8703fcfc8 1056 freebsd-manpages_7.2-1.dsc 35e3e48cc25f70c3c52f830855cc6e4b260dc39f930eedde09ff97e44f195e0b 8121368 freebsd-manpages_7.2.orig.tar.gz 663b655f736a0dd9118fe8cd69c01c012b1e681f2bfcb28d3319de045f6514aa 2526 freebsd-manpages_7.2-1.diff.gz 74880d284eba36920a812a3c1fdc7bec1b80c1bdc4f81a0994dc4f3e0c48c935 6336326 freebsd-manpages_7.2-1_all.deb Files: f0b15c95674873712d5f00660ee7f8d5 1056 doc optional freebsd-manpages_7.2-1.dsc 112f86a557df179471c20eb23c806ee5 8121368 doc optional freebsd-manpages_7.2.orig.tar.gz aabaf203a4d52270ba727bc2dd887643 2526 doc optional freebsd-manpages_7.2-1.diff.gz a398477ded0196c587aef8a32c668a83 6336326 doc optional freebsd-manpages_7.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKATXGw3ao2vG823MRAhMGAJ9FBxWMHupQC4HWUTYhEoLfuuQungCffqtj hYH5CJKOjURdvZDpnjPYThQ= =SB7p -END PGP SIGNATURE- Accepted: freebsd-manpages_7.2-1.diff.gz to pool/main/f/freebsd-manpages/freebsd-manpages_7.2-1.diff.gz freebsd-manpages_7.2-1.dsc to pool/main/f/freebsd-manpages/freebsd-manpages_7.2-1.dsc freebsd-manpages_7.2-1_all.deb to pool/main/f/freebsd-manpages/freebsd-manpages_7.2-1_all.deb freebsd-manpages_7.2.orig.tar.gz to pool/main/f/freebsd-manpages/freebsd-manpages_7.2.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
Accepted freebsd-buildutils 7.2-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 09:03:20 +0200 Source: freebsd-buildutils Binary: freebsd-buildutils Architecture: source amd64 Version: 7.2-1 Distribution: unstable Urgency: low Maintainer: Aurelien Jarno aure...@debian.org Changed-By: Aurelien Jarno aure...@debian.org Description: freebsd-buildutils - Utilities for building FreeBSD sources Changes: freebsd-buildutils (7.2-1) unstable; urgency=low . [ Petr Salinger ] * New upstream version (RELENG_7_2_0_RELEASE) Checksums-Sha1: 8034418a6da02d9958e7610738a463ce3dd58c9c 1292 freebsd-buildutils_7.2-1.dsc 800da0efeac1406140b1987415d97ec3442eff1d 749383 freebsd-buildutils_7.2.orig.tar.gz a0485052827ec149ecf4bb82fe7e192ed9525003 21969 freebsd-buildutils_7.2-1.diff.gz 86278533075981fd3b23dceaef02bcbe48169fa8 428214 freebsd-buildutils_7.2-1_amd64.deb Checksums-Sha256: 6615207a67c87c317ec23fbca6e82fd73ebe39de7c776e2a34811db2fd720806 1292 freebsd-buildutils_7.2-1.dsc fc1b1b4c5405639f6f04ec9bae027d8ea836f38d51613dc1c47d8501b5610db2 749383 freebsd-buildutils_7.2.orig.tar.gz 6b41fcfb990487274ebf4b6813774396779ba4043e25d95a674fe73ca1f5 21969 freebsd-buildutils_7.2-1.diff.gz a370e512550c7c8f336b7ff7fcf6444d46336c9bb1ea4217bac03ce5dc056729 428214 freebsd-buildutils_7.2-1_amd64.deb Files: f3053bcbd8f7f5b9eeb631f1b2f78531 1292 devel extra freebsd-buildutils_7.2-1.dsc 703856c205a315c17a431b7568b71bbd 749383 devel extra freebsd-buildutils_7.2.orig.tar.gz 557a5bac43e9142bbb53e53cb1a3143b 21969 devel extra freebsd-buildutils_7.2-1.diff.gz 2a7edb296efa7c963e900e7a0888f59e 428214 devel extra freebsd-buildutils_7.2-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKATgYw3ao2vG823MRArBIAJ41UxTpx5CVLE+1XjUR2bZ/qqXzlACZAS6+ ht+XFj7BtTWLdLfR4V9vWQs= =NU4F -END PGP SIGNATURE- Accepted: freebsd-buildutils_7.2-1.diff.gz to pool/main/f/freebsd-buildutils/freebsd-buildutils_7.2-1.diff.gz freebsd-buildutils_7.2-1.dsc to pool/main/f/freebsd-buildutils/freebsd-buildutils_7.2-1.dsc freebsd-buildutils_7.2-1_amd64.deb to pool/main/f/freebsd-buildutils/freebsd-buildutils_7.2-1_amd64.deb freebsd-buildutils_7.2.orig.tar.gz to pool/main/f/freebsd-buildutils/freebsd-buildutils_7.2.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
Accepted tulip 3.1.2-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 04 May 2009 21:43:57 +0200 Source: tulip Binary: tulip tlprender tulip-doc libtulip-3.1 libtulip-dev libtulip-ogl-3.1 libtulip-ogl-dev libtulip-qt4-3.1 libtulip-qt4-dev libtulip-pluginsmanager-3.1 libtulip-pluginsmanager-dev Architecture: source all i386 Version: 3.1.2-2 Distribution: unstable Urgency: low Maintainer: Yann Dirson dir...@debian.org Changed-By: Yann Dirson dir...@debian.org Description: libtulip-3.1 - Tulip graph library - core runtime libtulip-dev - Tulip graph library - core development files libtulip-ogl-3.1 - Tulip graph library - OpenGL runtime libtulip-ogl-dev - Tulip graph library - OpenGL development files libtulip-pluginsmanager-3.1 - Tulip graph library - Qt/OpenGL GUI runtime libtulip-pluginsmanager-dev - Tulip graph library - Qt/OpenGL GUI development files libtulip-qt4-3.1 - Tulip graph library - Qt/OpenGL GUI runtime libtulip-qt4-dev - Tulip graph library - Qt/OpenGL GUI development files tlprender - Off-screen renderer for tulip graphs tulip - A system dedicated to the visualization of huge graphs tulip-doc - Documentation for the Tulip graph-visualization system Closes: 526951 526968 Changes: tulip (3.1.2-2) unstable; urgency=low . * Fixed install target to cope with arch-dep-only builds (Closes: #526968). * Rename all manpages to .3tlp to avoid conflicting with various other pacakges (Closes: #526951). Checksums-Sha1: fb29c0c50a1bef26f4063ad741ea32c5b4a02a4a 1471 tulip_3.1.2-2.dsc c6f14a8e6581f9ad4ae840ef4b3340035cdadc39 499118 tulip_3.1.2-2.diff.gz b366c8d6f102e14ac8fd1c184def14dfae5003e5 30895652 tulip-doc_3.1.2-2_all.deb 5182604efe6f26b399ac92ce2a893de644d0ecf5 7320828 tulip_3.1.2-2_i386.deb 12099ba55d4ef24c76029508dba42d389cbee8a5 57338 tlprender_3.1.2-2_i386.deb e05ca5f6c3e3c3235cc9265e6a8b60b385849f56 717000 libtulip-3.1_3.1.2-2_i386.deb ff09e12894e9841dbb3e62c1da5b17583d401ba4 73762 libtulip-dev_3.1.2-2_i386.deb 0a4cc7dd65275ac31b3161aec3db8935d82c4650 492340 libtulip-ogl-3.1_3.1.2-2_i386.deb aa347a1f760a3e63daa50f6e1a72b4ab11ba6cde 48986 libtulip-ogl-dev_3.1.2-2_i386.deb f98ca1dee67c9b770b0a986d5879a192f4326b65 673162 libtulip-qt4-3.1_3.1.2-2_i386.deb 7783be18eeec51365938e83b2010859fd0c575a8 65794 libtulip-qt4-dev_3.1.2-2_i386.deb b902b3dac05f41a25972a4fc9ad3624bd2a58ac2 219330 libtulip-pluginsmanager-3.1_3.1.2-2_i386.deb 190cab127b625e363ed450e1faae11998a6c92d8 21400 libtulip-pluginsmanager-dev_3.1.2-2_i386.deb Checksums-Sha256: e7de755ef74222121fd29a256c5b3f227f4e418fb8c65d8bed8a566e659ba68b 1471 tulip_3.1.2-2.dsc 14eb3069c250cd211588de4b8c98c67def1dfd4fde8dd8a6c49c15ea7e80201d 499118 tulip_3.1.2-2.diff.gz 8562e223f455153f53e42ad13cd40819746a3df900875edb8ada1d4ff8e4d228 30895652 tulip-doc_3.1.2-2_all.deb 9022c17d112e9348ce15eeff991231549a18e550806efa73eb164dd9a6471af5 7320828 tulip_3.1.2-2_i386.deb 573141d63796a6cc1dca2da17a282c834f51ada4a6acadcbb49e7f5cc32b522b 57338 tlprender_3.1.2-2_i386.deb 9910cba7b5dfa5eec533020aac6bc4e3e09fe2a0ac1d30f6b910a2028718d106 717000 libtulip-3.1_3.1.2-2_i386.deb 97b87049aa8f1e892cba4f24f12132afd11edcb0cbb2080bb283112c3890a0a5 73762 libtulip-dev_3.1.2-2_i386.deb 2504c18d5fdf46d87f68877ae31611b3203cd849d26adb4ffd770d36018675d9 492340 libtulip-ogl-3.1_3.1.2-2_i386.deb e19baee39e1f99ef190ed1f00232435dcabd17677a4fd9019910a554c7a4699c 48986 libtulip-ogl-dev_3.1.2-2_i386.deb 7e18f5d2f512047643ad21c4fb585cc1bb09d22aa58a50d00c0cf9dc23404f97 673162 libtulip-qt4-3.1_3.1.2-2_i386.deb 2ca250a2ea9856c0633a548a4635772f61ff97f0cc37ad65957588379435e778 65794 libtulip-qt4-dev_3.1.2-2_i386.deb b7b7f0fc92e994ed87c2a29dfc02d21151376ed527cb8fad73ca53fde7e035c1 219330 libtulip-pluginsmanager-3.1_3.1.2-2_i386.deb 70cfabd0eea6cafcd2d0ff4173d90785a3a12a77cd5f3acfcd5cf6aa06dd6cd1 21400 libtulip-pluginsmanager-dev_3.1.2-2_i386.deb Files: 72ca84464e13f79efa9f75d44eb29141 1471 graphics optional tulip_3.1.2-2.dsc fb3445c57166239add1d868dedc2ccf9 499118 graphics optional tulip_3.1.2-2.diff.gz 9ef63c32e4c01a48f06c017fa57751a7 30895652 doc optional tulip-doc_3.1.2-2_all.deb 860977f436b8b18a24f15e2dfda9e0a0 7320828 graphics optional tulip_3.1.2-2_i386.deb 8898604c31697ad72b4bbc6053c881f3 57338 graphics optional tlprender_3.1.2-2_i386.deb ba0f816ff487d5786ad81615e301427a 717000 libs optional libtulip-3.1_3.1.2-2_i386.deb 3d5afc6fb9cb074deb5cfed10001d2d8 73762 libdevel optional libtulip-dev_3.1.2-2_i386.deb f458254d1a2b8afc70dd57f7f1f409a5 492340 libs optional libtulip-ogl-3.1_3.1.2-2_i386.deb 24d5a02a7bcf124d1a10ca2ec3a4162f 48986 libdevel optional libtulip-ogl-dev_3.1.2-2_i386.deb a8c02b3b89f500166551d49d172285d6 673162 libs optional libtulip-qt4-3.1_3.1.2-2_i386.deb ff05d687bc4f3ea64177e4beb0d9bc74 65794 libdevel optional libtulip-qt4-dev_3.1.2-2_i386.deb 69218856e11713d06fd0c70fe135e347 219330 libs optional libtulip-pluginsmanager-3.1_3.1.2-2_i386.deb 14e12bd98798c214b355a5f6e9c46c4e
Accepted ecasound2.2 2.6.0-1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 15:18:46 +0900 Source: ecasound2.2 Binary: ecasound libecasound2.2-dev libkvutils2.2-dev python-ecasound2.2 libecasound-ruby1.8 libecasoundc2.2-dev ecasound-el Architecture: source all amd64 Version: 2.6.0-1 Distribution: unstable Urgency: low Maintainer: Junichi Uekawa dan...@debian.org Changed-By: Junichi Uekawa dan...@debian.org Description: ecasound - Multitrack-capable audio recorder and effect processor ecasound-el - emacs binding files for ecasound sound editing environment libecasound-ruby1.8 - ruby binding files for ecasound libecasound2.2-dev - development files for ecasound libecasoundc2.2-dev - c binding files for ecasound (devel) libkvutils2.2-dev - kvutils library required for ecasound - development python-ecasound2.2 - python binding files for ecasound 2.2 Closes: 526535 Changes: ecasound2.2 (2.6.0-1) unstable; urgency=low . * New upstream release - 08_fix_header_install: remove - 07_configure_in_maintainer_mode: update - do not install manpage copies, and just install symlinks for ecatools.1 * Build-Depend on texlive-latex-recommended too for ecrm1000 font. (closes: #526535) Checksums-Sha1: 5cd2e7b1f3b716899aa2f71d90c43deec68278d0 1752 ecasound2.2_2.6.0-1.dsc fb34fd31d112a4a1d3e1a87f302324152f62eac7 966629 ecasound2.2_2.6.0.orig.tar.gz 94350ba9bdec75ecca58a4296411a0ca0b95c8bb 193128 ecasound2.2_2.6.0-1.diff.gz f03cc0178ee6cce3a911cc292ec05ca08b8a6ee0 17932 python-ecasound2.2_2.6.0-1_all.deb c54e5fe9199bc56e62d7b658e6f385597be2e78b 37568 ecasound-el_2.6.0-1_all.deb f63eff61511b094cd6e61f5a98629414738f8b42 1736240 ecasound_2.6.0-1_amd64.deb 47ac87b602a5e2d6b291fa4ab44d72affe3da826 1351776 libecasound2.2-dev_2.6.0-1_amd64.deb 3752079ec7d49679376944345470cf676b90def9 62710 libkvutils2.2-dev_2.6.0-1_amd64.deb ba04eb1b2a10a8b39618a234daa052592cb65b0f 14850 libecasound-ruby1.8_2.6.0-1_amd64.deb 8404a2fe177f424ba57a008847a141f4e925da9d 30228 libecasoundc2.2-dev_2.6.0-1_amd64.deb Checksums-Sha256: 9d946caa75ca2241876670ba1b6002097701cfac6b5822d36414129b34d3eb1d 1752 ecasound2.2_2.6.0-1.dsc 925d12a422883c356565c542110d070f61c3693e01eaa1b00eb25082e4779f88 966629 ecasound2.2_2.6.0.orig.tar.gz 258b819d87a7ee06d6fd750fad79dce5b17c939f4e48fce6475865b8cdae6411 193128 ecasound2.2_2.6.0-1.diff.gz c6450af2bc204e673e4c87e9344904f37b36bf3a32559318728fd745195769c5 17932 python-ecasound2.2_2.6.0-1_all.deb 8cdb418b10c8b944fd9c9869b14576325b883c9be90f031c4aa8c6d36b4e4696 37568 ecasound-el_2.6.0-1_all.deb 81165c112720bdcf20428528a8bf8865f547e4f1751156fa738a00ddfca0f5c1 1736240 ecasound_2.6.0-1_amd64.deb 45bbf260ffebc267a0afe32263529e5fbd442b92edeee69d96a28c1bb9eac5d0 1351776 libecasound2.2-dev_2.6.0-1_amd64.deb 852ee6b2fdcb4d57ee445c061922ddcc946d6020b7f2f77c738d1ef7bc4ed182 62710 libkvutils2.2-dev_2.6.0-1_amd64.deb be5d86d0381b38a64ccc4e924e8710357b6fe122c412e30981be3a0691d53d45 14850 libecasound-ruby1.8_2.6.0-1_amd64.deb 4159bb0fb04c3073bac42f0f03c43031a7748321465801d69e5743618b6ca64a 30228 libecasoundc2.2-dev_2.6.0-1_amd64.deb Files: 629970cd8d1dfc4f43d8e53f80bbc36a 1752 sound extra ecasound2.2_2.6.0-1.dsc 41f9445b9a9c0cde141831cb53d1ef8f 966629 sound extra ecasound2.2_2.6.0.orig.tar.gz 111409368e8e7d679468f73358099707 193128 sound extra ecasound2.2_2.6.0-1.diff.gz 614523b6d9bc0d6fe3c4f7c298748deb 17932 python extra python-ecasound2.2_2.6.0-1_all.deb 7fd905a8affb7acc66bd41610d883c72 37568 sound extra ecasound-el_2.6.0-1_all.deb e2e588f061f241b7fd005063d1b3ccde 1736240 sound extra ecasound_2.6.0-1_amd64.deb 2463933f5d079abe7ea1fe0010980447 1351776 libdevel extra libecasound2.2-dev_2.6.0-1_amd64.deb a1635866b845725cfe6e6be18b33f7c9 62710 libdevel extra libkvutils2.2-dev_2.6.0-1_amd64.deb 1b980888ccfb31e42e37d0ebac171ae7 14850 libs extra libecasound-ruby1.8_2.6.0-1_amd64.deb 063b9f0c272dd6fb8187856db0aaa7db 30228 libdevel extra libecasoundc2.2-dev_2.6.0-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKATlz2Dd9TugeVcERAvqFAJ486IhOckYAwKO3ZOpP3EvjpMzTugCfWlHb ml303j7g5J4QmgbbxudX6dQ= =msc5 -END PGP SIGNATURE- Accepted: ecasound-el_2.6.0-1_all.deb to pool/main/e/ecasound2.2/ecasound-el_2.6.0-1_all.deb ecasound2.2_2.6.0-1.diff.gz to pool/main/e/ecasound2.2/ecasound2.2_2.6.0-1.diff.gz ecasound2.2_2.6.0-1.dsc to pool/main/e/ecasound2.2/ecasound2.2_2.6.0-1.dsc ecasound2.2_2.6.0.orig.tar.gz to pool/main/e/ecasound2.2/ecasound2.2_2.6.0.orig.tar.gz ecasound_2.6.0-1_amd64.deb to pool/main/e/ecasound2.2/ecasound_2.6.0-1_amd64.deb libecasound-ruby1.8_2.6.0-1_amd64.deb to pool/main/e/ecasound2.2/libecasound-ruby1.8_2.6.0-1_amd64.deb libecasound2.2-dev_2.6.0-1_amd64.deb to pool/main/e/ecasound2.2/libecasound2.2-dev_2.6.0-1_amd64.deb libecasoundc2.2-dev_2.6.0-1_amd64.deb to pool/main/e/ecasound2.2/libecasoundc2.2-dev_2.6.0-1_amd64.deb libkvutils2.2-dev_2.6.0-1_amd64.deb to
Accepted whizzytex 1.3.1-4 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 15:19:54 +0900 Source: whizzytex Binary: whizzytex Architecture: source all Version: 1.3.1-4 Distribution: unstable Urgency: low Maintainer: Junichi Uekawa dan...@debian.org Changed-By: Junichi Uekawa dan...@debian.org Description: whizzytex - a WYSIWYG emacs environment for LaTeX Closes: 525992 525996 Changes: whizzytex (1.3.1-4) unstable; urgency=low . * Dependency update: move gv to recommends, remove tetex dependency and keep the texlive dependnecy, and keep advi as depends. (closes: #525992, #525996) Checksums-Sha1: 1fe1070f96d89f0fac45cad331287f4588e80058 813 whizzytex_1.3.1-4.dsc 67c9667318dd5f9a39918d63ff4b4c3e4e81d2a8 201099 whizzytex_1.3.1-4.tar.gz f8f8f3da8b8734a9d98366c6a7acb3b16987fb43 178880 whizzytex_1.3.1-4_all.deb Checksums-Sha256: 50abf8b0349566f10d81a817d908bb2ca1da0a981ad662416335bef0c349f9a3 813 whizzytex_1.3.1-4.dsc a4ed16cccbd0b9ad0178a7d4dfc2dc849e371cd7122e80e319ac2f82bd350f12 201099 whizzytex_1.3.1-4.tar.gz cac941d0600c8f0eeeb7a23fbf55e00f54c061f83c586fc54f1d66795f3f1009 178880 whizzytex_1.3.1-4_all.deb Files: 789de1d71235c37853cf985f8a0bb68c 813 tex optional whizzytex_1.3.1-4.dsc c2eb19223d3cb2f3976575769c415524 201099 tex optional whizzytex_1.3.1-4.tar.gz 38a4716d421086af5d57d9f6bfca5103 178880 tex optional whizzytex_1.3.1-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKATls2Dd9TugeVcERAvQ4AJ9PQZcY0ZjvpzFXmBoESLi4qI4KtwCfZE12 V93xKtT3pZKa81PffdlADfM= =JQxR -END PGP SIGNATURE- Accepted: whizzytex_1.3.1-4.dsc to pool/main/w/whizzytex/whizzytex_1.3.1-4.dsc whizzytex_1.3.1-4.tar.gz to pool/main/w/whizzytex/whizzytex_1.3.1-4.tar.gz whizzytex_1.3.1-4_all.deb to pool/main/w/whizzytex/whizzytex_1.3.1-4_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted lp-solve 5.5.0.13-5 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 11:22:45 +0200 Source: lp-solve Binary: lp-solve lp-solve-doc liblpsolve55-dev Architecture: source amd64 all Version: 5.5.0.13-5 Distribution: unstable Urgency: low Maintainer: Juan Esteban Monsalve Tobon este...@v7w.com Changed-By: Rene Engelhard r...@debian.org Description: liblpsolve55-dev - Solve (mixed integer) linear programming problems - library lp-solve - Solve (mixed integer) linear programming problems lp-solve-doc - Solve (mixed integer) linear programming problems - documentation Closes: 524295 Changes: lp-solve (5.5.0.13-5) unstable; urgency=low . * make liblpsolve55-dev depend on libsuitesparse-dev (closes: #524295) Checksums-Sha1: 31b3d92b83ac0d1d49f37a2c744f22ea85ddd982 1185 lp-solve_5.5.0.13-5.dsc 5720144a69e1934810ffaf1722b9f3750fddb194 378769 lp-solve_5.5.0.13-5.diff.gz a6ed6372881b2abba264a14828b4b1d26fee888f 333758 lp-solve_5.5.0.13-5_amd64.deb 689f4cd9ad9a5a173516944d346e995dcc574fdf 393040 lp-solve-doc_5.5.0.13-5_all.deb a1e8d56d81c6512ac06754a0897c4ff5aecda1e0 774860 liblpsolve55-dev_5.5.0.13-5_amd64.deb Checksums-Sha256: b0da41788e27e5d8a94bbd1fc3b9e2b34b770cae84434896a54801ff202bc2d9 1185 lp-solve_5.5.0.13-5.dsc 113bf9d51624b90525ba15ee475800c4c7f4ad2dee6a678d343aea5d5128c2c7 378769 lp-solve_5.5.0.13-5.diff.gz f90450c97a472002cb2aa588dc482970c259fb5293237fd80577632bec3ee627 333758 lp-solve_5.5.0.13-5_amd64.deb a6df955457aa2308ec77f8a089cafe50744e4e8d5030a0d0eaf7cdf368afeafe 393040 lp-solve-doc_5.5.0.13-5_all.deb 7562217dc88be8cfd025651fcefc0f69c4094d2e2f443a448b194eda42f0d07a 774860 liblpsolve55-dev_5.5.0.13-5_amd64.deb Files: 1cf5bb0fd616ba8b83ac990e4da5c1a7 1185 math optional lp-solve_5.5.0.13-5.dsc a50979773d7c8da3182ddcc56bb965c3 378769 math optional lp-solve_5.5.0.13-5.diff.gz 59bfe990d3ab3b1a6ee4920c4817c816 333758 math optional lp-solve_5.5.0.13-5_amd64.deb eabacc0653682896b6d51ccf0519454e 393040 doc optional lp-solve-doc_5.5.0.13-5_all.deb 339b948ef8fffcb97dbebdfbf428db99 774860 libdevel optional liblpsolve55-dev_5.5.0.13-5_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKAVec+FmQsCSK63MRAjlvAJ9xnjva2huXbg784rKNu9MWd69AmwCfcNg6 pOFRJIQf9HEmgA9xHG2BoCY= =BQQm -END PGP SIGNATURE- Accepted: liblpsolve55-dev_5.5.0.13-5_amd64.deb to pool/main/l/lp-solve/liblpsolve55-dev_5.5.0.13-5_amd64.deb lp-solve-doc_5.5.0.13-5_all.deb to pool/main/l/lp-solve/lp-solve-doc_5.5.0.13-5_all.deb lp-solve_5.5.0.13-5.diff.gz to pool/main/l/lp-solve/lp-solve_5.5.0.13-5.diff.gz lp-solve_5.5.0.13-5.dsc to pool/main/l/lp-solve/lp-solve_5.5.0.13-5.dsc lp-solve_5.5.0.13-5_amd64.deb to pool/main/l/lp-solve/lp-solve_5.5.0.13-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
Accepted ttf-hanazono 20090506-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 19:15:17 +0900 Source: ttf-hanazono Binary: ttf-hanazono Architecture: source all Version: 20090506-1 Distribution: unstable Urgency: low Maintainer: Nobuhiro Iwamatsu iwama...@nigauri.org Changed-By: Nobuhiro Iwamatsu iwama...@nigauri.org Description: ttf-hanazono - Japanese TrueType font by KAGE system and FontForge Closes: 523776 Changes: ttf-hanazono (20090506-1) unstable; urgency=low . * New upstream release. (Closes: #523776) * Change section from x11 to fonts in debian/control. Checksums-Sha1: 683679e481d0b8ee482c491cf9856659ed1a27d2 1115 ttf-hanazono_20090506-1.dsc 2f4a3650b0d53f100755c6aedba8f2148061dbf0 10805051 ttf-hanazono_20090506.orig.tar.gz 1f9449331892400663b6c13f6b0a1d06f35068c2 2170 ttf-hanazono_20090506-1.diff.gz 98f5fac0881284489df22c628cd0c663621f5f12 10816128 ttf-hanazono_20090506-1_all.deb Checksums-Sha256: 2b29a47e3fdbe3d71b0dcdf42af45482352e92b6d845c9a843ea120831d97236 1115 ttf-hanazono_20090506-1.dsc 9fa25d158da9223550464f21e12f8eb2790c25db69060e80b45084d88bfc6946 10805051 ttf-hanazono_20090506.orig.tar.gz d994a0fe31caa36e5e06bd7293d89309fc4bb4bdba46ce14b0210f21b254b5e9 2170 ttf-hanazono_20090506-1.diff.gz b214c19b1f3d5b16fb8c2f50bb4aae438f3ae6419a9d1adbb1812217c5d6d09d 10816128 ttf-hanazono_20090506-1_all.deb Files: 83bc394091434a6c7df7f7509ecd1596 1115 fonts optional ttf-hanazono_20090506-1.dsc f592c230427c9a7bdeca965039f8517d 10805051 fonts optional ttf-hanazono_20090506.orig.tar.gz edac8b4f60dcc14adfbde789fc28be71 2170 fonts optional ttf-hanazono_20090506-1.diff.gz 6d431c13c09b6fce73573fd7e69b3835 10816128 fonts optional ttf-hanazono_20090506-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoBZMgACgkQQSHHQzFw6+ncDQCbB6Dwckr+fPiIJM52dS2XQo18 pgUAnjfvVmyoiPBVJPf7nRJSliHBUgsg =2upq -END PGP SIGNATURE- Accepted: ttf-hanazono_20090506-1.diff.gz to pool/main/t/ttf-hanazono/ttf-hanazono_20090506-1.diff.gz ttf-hanazono_20090506-1.dsc to pool/main/t/ttf-hanazono/ttf-hanazono_20090506-1.dsc ttf-hanazono_20090506-1_all.deb to pool/main/t/ttf-hanazono/ttf-hanazono_20090506-1_all.deb ttf-hanazono_20090506.orig.tar.gz to pool/main/t/ttf-hanazono/ttf-hanazono_20090506.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
Accepted sane-backends 1.0.20-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 12:02:59 +0200 Source: sane-backends Binary: sane-utils libsane libsane-dev libsane-dbg Architecture: source amd64 Version: 1.0.20-2 Distribution: unstable Urgency: low Maintainer: Julien BLACHE jbla...@debian.org Changed-By: Julien BLACHE jbla...@debian.org Description: libsane- API library for scanners libsane-dbg - API development library for scanners [debug symbols] libsane-dev - API development library for scanners [development files] sane-utils - API library for scanners -- utilities Closes: 527196 Changes: sane-backends (1.0.20-2) unstable; urgency=low . * Update previous changelog entry wrt #519101 resolution. . * debian/patches/04_udev_rules_fix.dpatch: + Added; fix udev rules, use ATTRS instead of ATTR (closes: #527196). * debian/patches/05_saned_avahi_fds_fix.dpatch: + Added; fix a possible net backend hang when saned is run in debug mode. Could also happen in standalone mode, but a lot less likely. Checksums-Sha1: 095fbfba09ffda0166a184f78420c19f6f2451c2 1445 sane-backends_1.0.20-2.dsc e5fe87d2ebea2510c8ba4622867b42798e95a176 44000 sane-backends_1.0.20-2.diff.gz 8c57936a0a6b78c7a6f6c90acc323456e7a211dc 244510 sane-utils_1.0.20-2_amd64.deb 5976861c674db6869b4219e3277490e172b9731b 4147072 libsane_1.0.20-2_amd64.deb 4f7ff234080cffa8f3db3ae2bedf52bbfee762bc 3882784 libsane-dev_1.0.20-2_amd64.deb 35269b1efdff9251ce97044d80c4149ba383c94e 4338758 libsane-dbg_1.0.20-2_amd64.deb Checksums-Sha256: ea6693a93acdd2075efb60380e15ab39c45df714117de0e327bbeba86b71de69 1445 sane-backends_1.0.20-2.dsc 49f758ee94c21a69c54d7ac53c51eaf8c40980d9e7d7a02ec92e3af87da64957 44000 sane-backends_1.0.20-2.diff.gz c4ef574b381cdb87421cd2bb06587525868d0f5bfafb7cec1fde14a40c0641a9 244510 sane-utils_1.0.20-2_amd64.deb 187644572a273ffbce1740ff92a1896ee60504a34e1eec7b7a563239120d5198 4147072 libsane_1.0.20-2_amd64.deb bb48c19e3d4033b0c8368fd12daeac7f5db070d812bda767517326f50a184428 3882784 libsane-dev_1.0.20-2_amd64.deb 371487f4198bb104b9f90a52b018d7aee992fbcb10519478604c6c46af844128 4338758 libsane-dbg_1.0.20-2_amd64.deb Files: c5932e735a813737375e656ed0cf711a 1445 graphics optional sane-backends_1.0.20-2.dsc c90878481f45a7faaa2340acb9db38c9 44000 graphics optional sane-backends_1.0.20-2.diff.gz 4008c0a9b0b640cec4d31a4358e9a566 244510 graphics optional sane-utils_1.0.20-2_amd64.deb 4102d03d7dafee15903e35f5cd7cb072 4147072 libs optional libsane_1.0.20-2_amd64.deb 5f682d57eb7a374c26c47bdb3bb9007f 3882784 libdevel optional libsane-dev_1.0.20-2_amd64.deb 5987a2c9b03df587c4f4cf80bdfdcc83 4338758 debug extra libsane-dbg_1.0.20-2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKAWLZzWFP1/XWUWkRAsf+AKCq20xJsSdDLbBOWXsDUSRVqCOIxACeOr3r dl+fR5jM06p7GhCfY/HlJhc= =maGF -END PGP SIGNATURE- Accepted: libsane-dbg_1.0.20-2_amd64.deb to pool/main/s/sane-backends/libsane-dbg_1.0.20-2_amd64.deb libsane-dev_1.0.20-2_amd64.deb to pool/main/s/sane-backends/libsane-dev_1.0.20-2_amd64.deb libsane_1.0.20-2_amd64.deb to pool/main/s/sane-backends/libsane_1.0.20-2_amd64.deb sane-backends_1.0.20-2.diff.gz to pool/main/s/sane-backends/sane-backends_1.0.20-2.diff.gz sane-backends_1.0.20-2.dsc to pool/main/s/sane-backends/sane-backends_1.0.20-2.dsc sane-utils_1.0.20-2_amd64.deb to pool/main/s/sane-backends/sane-utils_1.0.20-2_amd64.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted busybox 1:1.13.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 13:46:20 +0200 Source: busybox Binary: busybox busybox-static busybox-udeb Architecture: source i386 Version: 1:1.13.3-1 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Bastian Blank wa...@debian.org Description: busybox- Tiny utilities for small and embedded systems busybox-static - Standalone rescue shell with tons of builtin utilities busybox-udeb - Tiny utilities for the debian-installer (udeb) Closes: 487433 503581 504089 510058 521443 Changes: busybox (1:1.13.3-1) unstable; urgency=low . * New upstream release. - Unbreak compressed usage. (closes: #521443) * [deb, udeb] Enable udhpc. (closes: #504089) * [udeb] Enable tftp. (closes: #510058) * [udeb] Enable tar archive creation. (closes: #487433) * Make strip build option work correctly. (closes: #503581) Checksums-Sha1: bbb64a23c7a5e8fbce75153f59d61ed7ca4e4e7e 1074 busybox_1.13.3-1.dsc b81af8db1206e606e450ef83e1a9e2a648bf417f 2415209 busybox_1.13.3.orig.tar.gz 10b7784bbab0343d03e05f9143395350134fef91 22990 busybox_1.13.3-1.diff.gz 83c31b94f855cac32b5236feb16c0a3e3c79 751204 busybox-static_1.13.3-1_i386.deb fef421c1ad7e85d4e730858ae05d573f6894ae83 316168 busybox_1.13.3-1_i386.deb 0bf507b5a25c5b2f17dc4a5525401c3a4bf23b44 130162 busybox-udeb_1.13.3-1_i386.udeb Checksums-Sha256: 94928e72b0c653801a4e938bf82033664721424a937af04d479dc622359fab9a 1074 busybox_1.13.3-1.dsc 19f8fcd0555671fea563ca0343043530b026dff602ff111c6ff773c72d594d7f 2415209 busybox_1.13.3.orig.tar.gz f5c541e857f083c844e095b03ce1240038db3d30c49d9ff5b2d6317b55fec557 22990 busybox_1.13.3-1.diff.gz 198d3188251036b7b2d3e6bd689c99a1b4ad527b0163e4e5ea3f2e08d845fc43 751204 busybox-static_1.13.3-1_i386.deb 4b2137b51a66e6e60a929ed67b63b4ce15e3ea89dfc4d265b9efd792c0f36f7a 316168 busybox_1.13.3-1_i386.deb 5b56387000bea980954366fb10e5a551bc9e67040afeec9d15cf4ed49938b807 130162 busybox-udeb_1.13.3-1_i386.udeb Files: e00fe3ef5567c7866cfa23270e5b7409 1074 utils optional busybox_1.13.3-1.dsc ceacf414a279f4ee3b31720f5af07459 2415209 utils optional busybox_1.13.3.orig.tar.gz dec24bd34bb38ac8b08a0af64116ee3c 22990 utils optional busybox_1.13.3-1.diff.gz 8c6d51e2848c02db1e6c9cd57da07488 751204 shells extra busybox-static_1.13.3-1_i386.deb 6f5ee7a4ecd489ac7a412426b3fd8e44 316168 utils optional busybox_1.13.3-1_i386.deb 13b6042f3ac7c174d306ed576a990e7f 130162 debian-installer extra busybox-udeb_1.13.3-1_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoBeNQACgkQLkAIIn9ODhEdugCffXC2TnI0lPc9sW1NcNCfkgp2 CKkAoOPOe53X14b0S8gDfjREya85WiJ7 =y416 -END PGP SIGNATURE- Accepted: busybox-static_1.13.3-1_i386.deb to pool/main/b/busybox/busybox-static_1.13.3-1_i386.deb busybox-udeb_1.13.3-1_i386.udeb to pool/main/b/busybox/busybox-udeb_1.13.3-1_i386.udeb busybox_1.13.3-1.diff.gz to pool/main/b/busybox/busybox_1.13.3-1.diff.gz busybox_1.13.3-1.dsc to pool/main/b/busybox/busybox_1.13.3-1.dsc busybox_1.13.3-1_i386.deb to pool/main/b/busybox/busybox_1.13.3-1_i386.deb busybox_1.13.3.orig.tar.gz to pool/main/b/busybox/busybox_1.13.3.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
Accepted mklibs 0.1.27 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 13:56:04 +0200 Source: mklibs Binary: mklibs mklibs-copy Architecture: source all i386 Version: 0.1.27 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-b...@lists.debian.org Changed-By: Bastian Blank wa...@debian.org Description: mklibs - Shared library reduction script mklibs-copy - Shared library reduction script Closes: 469070 499744 505025 508929 518088 Changes: mklibs (0.1.27) unstable; urgency=low . [ Joey Hess ] * Apply patches from Joseph S. Myers (closes: #469070): - mklibs-readelf: Uninitialized data fix - mklibs-readelf: Endian fix - mklibs: Add --sysroot, to locate all libraries and other related input files relative to a specified root directory rather than /. - mklibs: Add --gcc-options and --libdir options as well. - mklibs: Correct diagnostic text when symbol cannot be found. - mklibs: Ignore missing symbols from libthread_db, which are defined in the application that uses it. * Document --root in the man page. . [ Frans Pop ] * Apply patches from Joseph S. Myers: - Ignore the fact that symbol __gnu_local_gp is undefined for mips as it is defined by the linker. Thanks to Joseph S. Myers. Closes: #499744. * Remove myself as uploader. . [ Martin Michlmayr ] * mklibs-readelf: add missing header to avoid build error with GCC 4.4. Closes: #505025. . [ Bastian Blank ] * Support file definitions in version requirements. Based on patch by Andrew Stubbs a...@codesourcery.com. (closes: #508929) * Various cleanups. * Ignore symbols with empty names. (closes: #518088) Checksums-Sha1: e7b3c9c88e570c512290cf905745d1b6e4821fb1 969 mklibs_0.1.27.dsc bbf12828d09af12df501b5a748ff544c2bf3e25a 113602 mklibs_0.1.27.tar.gz d0b6804b85de9a532a839edc717f5e590f8a31bc 12988 mklibs_0.1.27_all.deb c7106ccb17e136d678a9d677d9b3da16bdb89bc5 44700 mklibs-copy_0.1.27_i386.deb Checksums-Sha256: 1d6722106dd092c22e9839b668ae1a7dfb29036a3322f61b993d7e6944041f93 969 mklibs_0.1.27.dsc 9eb44b5106f4c0d243c3c28e9c7f0d21667a6207ea32b2508936591cbed2519d 113602 mklibs_0.1.27.tar.gz 9827873656f4bc7f7e74857e9b8c8fee94d0a0c7ed1b460114c94b2ad0631d24 12988 mklibs_0.1.27_all.deb f4e91935144cff23f1e53e77562f0e85b795b42d0d38b3da24ed0701a21a28a0 44700 mklibs-copy_0.1.27_i386.deb Files: c0bfa4e721e2c755ec3bf37d884c146e 969 devel optional mklibs_0.1.27.dsc ce906873efcf84c401479e9c10279660 113602 devel optional mklibs_0.1.27.tar.gz c55b104408f866f03dde78c1f98cfc38 12988 devel optional mklibs_0.1.27_all.deb 5769bcf8e7eb2e61d148f250d4affaa7 44700 devel optional mklibs-copy_0.1.27_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoBevAACgkQLkAIIn9ODhHgRwCgwtG5By62ROiWiQlqHgLYPFX2 Qm4AoLIkyC1t1Q5C+ARLI81OMgk4ldEb =L9ab -END PGP SIGNATURE- Accepted: mklibs-copy_0.1.27_i386.deb to pool/main/m/mklibs/mklibs-copy_0.1.27_i386.deb mklibs_0.1.27.dsc to pool/main/m/mklibs/mklibs_0.1.27.dsc mklibs_0.1.27.tar.gz to pool/main/m/mklibs/mklibs_0.1.27.tar.gz mklibs_0.1.27_all.deb to pool/main/m/mklibs/mklibs_0.1.27_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted libwmf 0.2.8.4-6.1 (source all amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 09:19:49 +0200 Source: libwmf Binary: libwmf0.2-7 libwmf-bin libwmf-dev libwmf-doc Architecture: source amd64 all Version: 0.2.8.4-6.1 Distribution: unstable Urgency: high Maintainer: Loic Minier l...@dooz.org Changed-By: Giuseppe Iuculano giuse...@iuculano.it Description: libwmf-bin - Windows metafile conversion tools libwmf-dev - Windows metafile conversion development libwmf-doc - Windows metafile documentation libwmf0.2-7 - Windows metafile conversion library Closes: 526434 Changes: libwmf (0.2.8.4-6.1) unstable; urgency=high . * Non-maintainer upload. * Fixed Use-after-free vulnerability in the embedded GD library (Closes: #526434) (CVE-2009-1364) Checksums-Sha1: 56391729e4e628f0010f351ee717b0ef012bcf9d 1175 libwmf_0.2.8.4-6.1.dsc 39d959e88f976ed704a966b0d9591e0c0ffa54f1 7853 libwmf_0.2.8.4-6.1.diff.gz fec690ed2b465861709feb16e2010b6000c256f2 186392 libwmf0.2-7_0.2.8.4-6.1_amd64.deb fea814e6d08a65e25c4fa550284c5c32024259b5 19048 libwmf-bin_0.2.8.4-6.1_amd64.deb 7e204d9bb9e5bb2dc605fa6824b0c2e91c4f5fd0 210720 libwmf-dev_0.2.8.4-6.1_amd64.deb 9a01f104b6025cdb21a9b74a8d63a91bfeacef6b 285956 libwmf-doc_0.2.8.4-6.1_all.deb Checksums-Sha256: 8aa66067ec33aefbc53994ac5e6f8ca16583c8acb88e7b3579539fc975477f3a 1175 libwmf_0.2.8.4-6.1.dsc 7cedf0a0dc25dc6586c9d3ac30e95512056e6d00636c14ec865a30942ec9 7853 libwmf_0.2.8.4-6.1.diff.gz 09c5fa458628e4dd892fc05a53bc13f8b7383009916620e08ee947275e7e2fd5 186392 libwmf0.2-7_0.2.8.4-6.1_amd64.deb 6c758c8cefec6ce8c55ecdc7f17e33c5c4b928c60f10e7db20dc1c030df43c7d 19048 libwmf-bin_0.2.8.4-6.1_amd64.deb b085c0a0b4f00965a101e3526f0ee534e74c608b3abec2dda71fb497aea35731 210720 libwmf-dev_0.2.8.4-6.1_amd64.deb 6e10c7077cbdc09a5192e2a44e92c76d87fd676aec27ca68b6379053b4d3f717 285956 libwmf-doc_0.2.8.4-6.1_all.deb Files: 36f886ec765b92e8498e6c1f597dda51 1175 libs optional libwmf_0.2.8.4-6.1.dsc 148c2791f1fd89991c3354bf89e847fc 7853 libs optional libwmf_0.2.8.4-6.1.diff.gz 0cbee925c5397ec10a41e31cc5c28cbd 186392 libs optional libwmf0.2-7_0.2.8.4-6.1_amd64.deb 1caa89daebf5d8eb68cbb24d1d706874 19048 graphics optional libwmf-bin_0.2.8.4-6.1_amd64.deb d7f32f0d7a42c7fbec6aca9309b469e6 210720 libdevel optional libwmf-dev_0.2.8.4-6.1_amd64.deb 6d4c151ae43eb25635a23339776789e3 285956 doc optional libwmf-doc_0.2.8.4-6.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoBgaQACgkQHYflSXNkfP//SwCbBddMFob+LLrVMptGwN5/mwBy LB8AnRji1vz3QX9cUKWqfubDJ5MnENFN =POMA -END PGP SIGNATURE- Accepted: libwmf-bin_0.2.8.4-6.1_amd64.deb to pool/main/libw/libwmf/libwmf-bin_0.2.8.4-6.1_amd64.deb libwmf-dev_0.2.8.4-6.1_amd64.deb to pool/main/libw/libwmf/libwmf-dev_0.2.8.4-6.1_amd64.deb libwmf-doc_0.2.8.4-6.1_all.deb to pool/main/libw/libwmf/libwmf-doc_0.2.8.4-6.1_all.deb libwmf0.2-7_0.2.8.4-6.1_amd64.deb to pool/main/libw/libwmf/libwmf0.2-7_0.2.8.4-6.1_amd64.deb libwmf_0.2.8.4-6.1.diff.gz to pool/main/libw/libwmf/libwmf_0.2.8.4-6.1.diff.gz libwmf_0.2.8.4-6.1.dsc to pool/main/libw/libwmf/libwmf_0.2.8.4-6.1.dsc -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted sane-backends-extras 1.0.20.1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 May 2009 14:21:17 +0200 Source: sane-backends-extras Binary: libsane-extras libsane-extras-dev libsane-extras-dbg Architecture: source amd64 Version: 1.0.20.1 Distribution: unstable Urgency: low Maintainer: Julien BLACHE jbla...@debian.org Changed-By: Julien BLACHE jbla...@debian.org Description: libsane-extras - API library for scanners -- extra backends libsane-extras-dbg - API library for scanners -- extra backends [debug symbols] libsane-extras-dev - API development library for scanners [development files] Changes: sane-backends-extras (1.0.20.1) unstable; urgency=low . * Based on sane-backends 1.0.20. * backends removed: + hp_rts88xx: replaced by the rts8891 backend from sane-backends 1.0.20. . * debian/rules: + Do not install the now-empty FDI file. + Use DESTDIR install time. * debian/libsane-extras.preinst: + Remove obsolete conffile /etc/sane.d/hp_rts88xx.conf. * debian/control: + Stop mentioning hp_rts88xx. + Move libsane-extras-dbg to debug section. * debian/README.Debian, debian/copyright: + Stop mentioning hp_rts88xx. * debian/libsane-extras.fdi, debian/libsane-extras.udev: + Remove hardware supported by hp_rts88xx. * debian/libsane-extras.install: + Stop installing hp_rts88xx documentation. * debian/libsane-extras.NEWS: + Document the removal of hp_rts88xx and direct users to rts8891. Checksums-Sha1: 7954a94c872d755255d194e674e6badfac6ba5db 869 sane-backends-extras_1.0.20.1.dsc f9318a0346c465336623113cb0644d48a81ee765 701542 sane-backends-extras_1.0.20.1.tar.gz 10d95d59ed939b63d183f3e66ec17fea05f6d335 69324 libsane-extras_1.0.20.1_amd64.deb 50c528599cb4e32c0141f89947e9d9858ddc76b6 69298 libsane-extras-dev_1.0.20.1_amd64.deb d4f829ff8967f7a287e977793b8f4bfbdf3a41de 85492 libsane-extras-dbg_1.0.20.1_amd64.deb Checksums-Sha256: 1a4610e628b589c5bdcf5c459d15772cad8786af9a04e07f1e7eabffd9a180b3 869 sane-backends-extras_1.0.20.1.dsc 7b2f3e491eb19e00dc9aaf7634533925b5b9883720c477da8bc0ef4fb458355b 701542 sane-backends-extras_1.0.20.1.tar.gz 64541c766c25f5405bb3498df6e76b3e5c14ceb3da974496dbc2af0a8085b02f 69324 libsane-extras_1.0.20.1_amd64.deb 079c43bf402915717e61e333f989a5307611c325a3dbd74ae661ad0c39a535a5 69298 libsane-extras-dev_1.0.20.1_amd64.deb ec2800abccc64c4dafa7d0d18ef9672e27c50331e9117d4c7d02079267485663 85492 libsane-extras-dbg_1.0.20.1_amd64.deb Files: 05d16892482b0c80a9d6940beef065e6 869 graphics optional sane-backends-extras_1.0.20.1.dsc 45b822abd9fde08ea7be6b39687e0536 701542 graphics optional sane-backends-extras_1.0.20.1.tar.gz 27d259a73f96a6e5da4e55882ee8f833 69324 libs optional libsane-extras_1.0.20.1_amd64.deb b26a990a5131af5aef872f22d36e1a9d 69298 libdevel optional libsane-extras-dev_1.0.20.1_amd64.deb a31b1a0a3f5653addd7621704780bc6b 85492 debug extra libsane-extras-dbg_1.0.20.1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKAYI3zWFP1/XWUWkRAsCmAJ0Ql15psW/menrR3Ycekt6UGSBIjACcCMJR mlgoZ5E2u2I0K9p7Ypf6s5Y= =V+wU -END PGP SIGNATURE- Accepted: libsane-extras-dbg_1.0.20.1_amd64.deb to pool/main/s/sane-backends-extras/libsane-extras-dbg_1.0.20.1_amd64.deb libsane-extras-dev_1.0.20.1_amd64.deb to pool/main/s/sane-backends-extras/libsane-extras-dev_1.0.20.1_amd64.deb libsane-extras_1.0.20.1_amd64.deb to pool/main/s/sane-backends-extras/libsane-extras_1.0.20.1_amd64.deb sane-backends-extras_1.0.20.1.dsc to pool/main/s/sane-backends-extras/sane-backends-extras_1.0.20.1.dsc sane-backends-extras_1.0.20.1.tar.gz to pool/main/s/sane-backends-extras/sane-backends-extras_1.0.20.1.tar.gz -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted debian-xcontrol 0.0.4-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.8
Date: Wed, 06 May 2009 14:19:18 +0200
Source: debian-xcontrol
Binary: debian-xcontrol
Architecture: source amd64
Version: 0.0.4-1
Distribution: unstable
Urgency: low
Maintainer: Simon Richter s...@debian.org
Changed-By: Simon Richter s...@debian.org
Description:
debian-xcontrol - Extended syntax for debian/control files
Changes:
debian-xcontrol (0.0.4-1) unstable; urgency=low
.
* New version
* Add Recommends/Suggests/Conflicts/Replaces/Provides/Breaks
* Add Cross-Compiling
* Add Bootstrap
* Add Optional
* Add per-package Build-Depends{,-Tools,-Indep}
* Fix alternatives handling in xdpkg-checkbuilddeps
Checksums-Sha1:
fe978ce9b4f19fd6fcdbe9fbdd0921ce8fc5c30d 1203 debian-xcontrol_0.0.4-1.dsc
780d5f396561e76366ab16a8b8defb6efb7d61ac 107978
debian-xcontrol_0.0.4.orig.tar.gz
05653df4af308114fb39bfef4621a312f019ad53 2425 debian-xcontrol_0.0.4-1.diff.gz
23af33c7c76446bf9c684405aea037004a9f8bf0 74420
debian-xcontrol_0.0.4-1_amd64.deb
Checksums-Sha256:
11254f71b8e3f39c194069072dec30ecd4e88a5b1adfe9718391ff7dde5ef0cc 1203
debian-xcontrol_0.0.4-1.dsc
914aca836332565a1ab91bbbcb431d182d6a2e4244b0fe2438c112eec3c907eb 107978
debian-xcontrol_0.0.4.orig.tar.gz
efaf8e5f9392cebb32e60e5bd142232d70caa6be9032fc39d72e57018fa79c18 2425
debian-xcontrol_0.0.4-1.diff.gz
102a8e860c322fa43a1f56aa6459cf405d39f31e39ad499ff39147439ebb4059 74420
debian-xcontrol_0.0.4-1_amd64.deb
Files:
f303230b81a25621d3008811156740e5 1203 devel extra debian-xcontrol_0.0.4-1.dsc
23839e817f5a004713384b7e64ff5bc1 107978 devel extra
debian-xcontrol_0.0.4.orig.tar.gz
f090732c0c0ffc59c8e8d298533b99f5 2425 devel extra
debian-xcontrol_0.0.4-1.diff.gz
5026fe0879ad2bdd5c7c783f7eda4225 74420 devel extra
debian-xcontrol_0.0.4-1_amd64.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iJwEAQECAAYFAkoBgekACgkQ0sfeulffv7t0GwP6A3KUEEjgh5rAMF15cK93UKFo
25e4FEfZxw+jfJMamamOKxMI91a5ZGQpYswjd3qWp+UsE5YGCvSIasIUmhT9NGnb
+8nK18y1s8uocesMdsYVRuZCcQjmHlsYasNm4DRqEmkknzk9FrrI7UK1X4fjg1On
dHcJRD/JTlQqlyUeF68=
=d8+F
-END PGP SIGNATURE-
Accepted:
debian-xcontrol_0.0.4-1.diff.gz
to pool/main/d/debian-xcontrol/debian-xcontrol_0.0.4-1.diff.gz
debian-xcontrol_0.0.4-1.dsc
to pool/main/d/debian-xcontrol/debian-xcontrol_0.0.4-1.dsc
debian-xcontrol_0.0.4-1_amd64.deb
to pool/main/d/debian-xcontrol/debian-xcontrol_0.0.4-1_amd64.deb
debian-xcontrol_0.0.4.orig.tar.gz
to pool/main/d/debian-xcontrol/debian-xcontrol_0.0.4.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
Accepted libio-socket-inet6-perl 2.54-1.1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 04 May 2009 15:09:36 +0200 Source: libio-socket-inet6-perl Binary: libio-socket-inet6-perl Architecture: source all Version: 2.54-1.1 Distribution: unstable Urgency: low Maintainer: Masahito Omote om...@debian.org Changed-By: Sean Finney sean...@debian.org Description: libio-socket-inet6-perl - Object interface for AF_INET6 domain sockets Closes: 522478 Changes: libio-socket-inet6-perl (2.54-1.1) unstable; urgency=low . * Non-maintainer upload. * Fix for error resolving addresses with AF_UNSPEC (closes: #522478). Checksums-Sha1: 09402a6da56c5f068e6cb20b59b1e7fe6c577923 1100 libio-socket-inet6-perl_2.54-1.1.dsc 3caffec70ae63a58e622751eee03698eb82661e3 2460 libio-socket-inet6-perl_2.54-1.1.diff.gz ff7a07a54b11f2deff47e101d81486dba0a198da 15044 libio-socket-inet6-perl_2.54-1.1_all.deb Checksums-Sha256: fc16b23cea1945a0fe5ac086fa195088634ae1bd34afbb2baaa91e0d16c0d2cf 1100 libio-socket-inet6-perl_2.54-1.1.dsc 95de22ba4b25399bc5db2713a1a583c2d855207c7c3e28093c189c1c1b5b2187 2460 libio-socket-inet6-perl_2.54-1.1.diff.gz 1cc799d00b241e171eb65b8681c912fe054e9a06efa0ef4ac90b162777d35c91 15044 libio-socket-inet6-perl_2.54-1.1_all.deb Files: aeaf7876c1aa45b0a061d60c7bc2bc7f 1100 perl optional libio-socket-inet6-perl_2.54-1.1.dsc b42220f9ae61850ef81f67ce7ff22e42 2460 perl optional libio-socket-inet6-perl_2.54-1.1.diff.gz b29dbc9b7e0fdea16cf476a134836e37 15044 perl optional libio-socket-inet6-perl_2.54-1.1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFJ/uoaynjLPm522B0RAsa0AJ940qH2UNYjvIdECbQxchk+8hcQdACeKKUy 954KvUIauhN9m85th7wx5rc= =1ouR -END PGP SIGNATURE- Accepted: libio-socket-inet6-perl_2.54-1.1.diff.gz to pool/main/libi/libio-socket-inet6-perl/libio-socket-inet6-perl_2.54-1.1.diff.gz libio-socket-inet6-perl_2.54-1.1.dsc to pool/main/libi/libio-socket-inet6-perl/libio-socket-inet6-perl_2.54-1.1.dsc libio-socket-inet6-perl_2.54-1.1_all.deb to pool/main/libi/libio-socket-inet6-perl/libio-socket-inet6-perl_2.54-1.1_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
