Re: Handling of changelogs and bin-nmus
Hi, On Sun, 10 Jun 2012, Andreas Barth wrote: Asking to be sure: For sbuild, that means instead of changing the file debian/changelog before starting the build, a new file debian/changelog.binary-rebuild (or however it is named) is created and from there on all works by itself? That's the idea, yes. Do we have other tools than dpkg that parse the changelog to find out the package version? How far are we away from getting that implemented once we decide we want that? Why other than dpkg? In any case, we have dpkg-parsechangelog. And I guess you probably refer to sbuild where you want to grab the version number. It could use the Dpkg::Changelog modules from libdpkg-perl. It already uses those modules for various purposes. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120611045351.gb13...@rivendell.home.ouaza.com
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Mon, 2012-06-11 at 11:39:24 +0100, Ian Jackson wrote: Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability): As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I think this is the wrong design. The changelog is primarily used by humans, not software, and burying it in the dpkg database is not helpful. I think the solution with the binNMU changelogs is straightforward and should be implemented. Well, the dpkg suite makes extensive use of the changelog to retrieve all kinds of information, dpkg (the program) does not currently access it though, but that data is still package metadata. The same could be said about some fields in the control file and it still makes sense to have them there, because again it's package metadata. There's also other precedent of package metadata not handled directly by dpkg (currently or in the past) which gets installed in the info database, like templates, config, md5sums and clilibs, for some I'm aware of. I disagree placing it in the dpkg database is not helpful, for a user or other programs wanting to access that structured package metadata it's obviously easier and better to do something like «dpkg --show-changelog foo» or «dpkg-query --control-path foo changelog», than having to go hunt where in the filesystem the changelog might be located, regardless of distribution path polcies. The same for the copyright information, and I've actually been asked in the past why dpkg does not have a command to show package copyright information. I've listed the other reasons (which you trimmed) in the parent mail. And if by “the binNMU changelogs”, you mean the split changelog solution, I still disagree that's the correct avenue. It means the information of why the package was rebuilt either ends up in yet another different place on the filesystem, or lost if the helper does not get updated to cope with that or if the package does not use any helper, which is still a non-insignificant amount of the archive. It might also break with packages poking at the debian/changelog file directly as Jonathan mentioned, or external software accessing the source tree, because debian/changelog is an interface, and while it might seem like a straightforward solution it looks like it will cause more problems than the ones it solves, and it still seems like a workaround. * changelog extractors (like apt-listchanges) would not need (eventually) to extract the whole .deb data member to get the changelog, it would just need to extract the control member, and get a fixed filename. They would stop needing to hardcode possible paths to the files too. This still leaves the NEWS.Debian file but then maybe that should also be considered metadata... This path leads, eventually, to all structured data currently stored in the filesystem being subsumed by dpkg. This is not healthy for dpkg and not healthy for the rest of the project. Eh, only structured data that is packaging metadata. TBH, I don't see other clear candidates besides changelog and copyright (maybe even NEWS.Debian, but this one might be a stretch), and those two are clearly package metadata. So, I'm still unconvinced by the arguments you brought up. regards, guillem -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612065943.ga19...@gaara.hadrons.org
Bug#675926: transition: naspro-bridge-it
On Mon, Jun 11, 2012 at 7:32 PM, Julien Cristau jcris...@debian.org wrote: I don't understand if/how this affects the transition. In fact this doesn't affect the transition :) I think this can be closed now, thank you! -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer | quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMHuwoyPdsK-voYGrY+OtwBxy7Bo_SZhxk9GHLzftO1=to7...@mail.gmail.com
Re: Handling of changelogs and bin-nmus
On Sun, 2012-06-10 at 14:40:28 +0200, Raphael Hertzog wrote:
On Sun, 10 Jun 2012, Guillem Jover wrote:
As I mentioned in the long ref-counting thread, I strongly disagree this
is a correct solution, it just seems like a hack to me. Instead I
think we should consider changelog (and copyright as long as it's in
machine parseable format) as dpkg metadata (something dpkg misses
compared to rpm or other package managers for example) and as such they
should go into the .deb control member, which would end up in the dpkg
database w/o any kind of file conflict, and very minor packaging effort
as for most that would be handled by helpers.
I agree that we should move into this direction. Still I believe it's
important to distinguish source changelog and binary changelog.
And while we might not want to keep this distinction in the generated
package, we should have it at the source package level.
As such, I suggest that we handle binary rebuild differently:
- debian/changelog is left unmodified since it's the source changelog
= it defines the ${source:Version} substvar
- debian/changelog.binary-rebuild (or any other better name) is created
when we want to do a bin-nmu
= it defines the ${binary:Version} and it's not included in
the generated source package
By definition a binNMU cannot produce a source package anyway, so I
fail to see the point in this artifical need to distinguish “source”
and “binary” changelogs through different files, AFAIR I already
mentioned reasons against this in the ref-counting thread, and now
again in reply to Ian's mail.
This allows us to get rid of the special-casing of bin-nmu in dpkg where
we only support one extension (+bX).
We have many other cases where it would be helpful to be able to do such
binary-only rebuild in different environments and where it might be
interesting to share the same source package.
If the main purpose of this is to generalize the binNMU versioning
syntax then instead of entangling these different issues I think it's
way better to mark the changelog entry as such, so that there's actual
generic metadata that can be used by the tools, that does not need to
change the debian/changelog interface, neither modify other possible
parsers to look into different files, etc.
I've just cooked code to support this in dpkg, an example entry could
look like this (the binary-only key could be named something else):
,---
pkg (1.0-1+b1) unstable; urgency=low, binary-only=yes
* Binary-only non-maintainer upload for amd64; no source changes.
* Reason.
-- Guillem Jover guil...@debian.org Tue, 12 Jun 2012 12:30:41 +0200
pkg (1.0-1) unstable; urgency=low
* Some change.
-- Guillem Jover guil...@debian.org Sat, 09 Jun 2012 16:16:17 +0200
`---
Then dpkg-gencontrol and dpkg-genchanges check if the parser returns
a Binary-Only field, and if it does it parses the previous entry, and
passes the source and binary versions explicitly to the substvar module.
In addition dpkg-source refuses to proceed if Binary-Only is set.
This is something that is on my relatively short-term TODO list for dpkg.
Guillem, do you agree with this change?
No, I do not agree.
guillem
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120612104757.ga23...@gaara.hadrons.org
Re: Handling of changelogs and bin-nmus
Hi, On Tue, 12 Jun 2012, Guillem Jover wrote: This allows us to get rid of the special-casing of bin-nmu in dpkg where we only support one extension (+bX). We have many other cases where it would be helpful to be able to do such binary-only rebuild in different environments and where it might be interesting to share the same source package. If the main purpose of this is to generalize the binNMU versioning syntax then instead of entangling these different issues I think it's way better to mark the changelog entry as such, so that there's actual generic metadata that can be used by the tools, that does not need to change the debian/changelog interface, neither modify other possible parsers to look into different files, etc. OK, that looks a reasonable approach for this need. But then it doesn't help with the short term problem of bin-nmus and changelogs. We don't have many solutions, and none is perfect. They should all be considered as temporary measures until we have implemented storage of changelog in control.tar.gz: 1/ we modify dpkg to ignore differences on /usr/share/doc/*/changelog.*gz for multi-arch: same packages 2/ we modify dh_installchangelogs to strip the entries marked binary-only for packages which are multi-arch same (this doesn't help packages that are not using debhelper but it's probably not a big deal) I've just cooked code to support this in dpkg, an example entry could look like this (the binary-only key could be named something else): Can you push your preliminary code to your personal repo? I'd be interested to complete the work if you don't have the time. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612110957.gb31...@rivendell.home.ouaza.com
Re: Bug#618351: gcc-doc: Still depends on gcc-4.4-doc after the move to 4.5.
On 11.06.2012 00:57, Axel Beckert wrote: Hi Russ, Russ Allbery wrote: We're now at gcc 4.7 for most architectures, the freeze is close and gcc-doc still depends on gcc-4.4-doc. ... because there doesn't seem to exist any gcc-4.x-doc package with x = 5. *puzzled* Isn't the GCC documentation now non-free? It was already (in) non-free back in the GCC 4.4 days and gcc-doc is a package in contrib. I won't work on this myself. Feel free to upload updated packages. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd752be.3050...@debian.org
Re: Migration path for 'Multi-Arch:allowed' packages
On Tue, Jun 12, 2012 at 11:45 AM, David Kalnischkies wrote: On Mon, Jun 11, 2012 at 9:40 PM, Michael Gilbert wrote: In particular, I filed a bug against dpkg requesting that it produce more informative error messages in these cases [0], but I wonder if a part of the solution shouldn't be more automated or at least presented at a higher level through apt/aptitude, etc? Chicken or the egg? You need to upgrade to support MultiArch, but you need MultiArch to upgrade… (beside, how would the detection for such a message look like?) A squeeze-proposed-update could help that along, right? So, it appears that allowed is the wrong flag (although the Ubuntu wine package also uses allowed in that sense). The algorithm would look something like: if package depends on a missing native package if package is set with some new Multi-Arch: no-native flag present multiarch instructions else present missing package error Although that may not be necessary. I'm implementing a wine-bin | wine64-bin solution where the wine64-bin package simply presents multiarch instructions. It's not very elegant or ideal, but it will in fact help users along. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPhLfc52RwY=6psoesqmrxtqym6mob8dgpm-ucxosu...@mail.gmail.com
Processed: block
Processing commands for cont...@bugs.debian.org: block 671115 by 677259 Bug #671115 [release.debian.org] transition: mysql-5.5 671115 was blocked by: 674328 675836 676595 673528 650059 667428 673263 650058 660686 674122 649955 651110 674309 672714 650060 672950 666331 672619 673264 672716 677114 651317 673262 674210 640818 672765 661422 673260 673183 673161 676083 649638 668232 673153 672824 672621 672816 672207 672588 671115 was blocking: 672928 Added blocking bug(s) of 671115: 677259 End of message, stopping processing here. Please contact me if you need assistance. -- 671115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671115 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133952233828773.transcr...@bugs.debian.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Ian Jackson (ijack...@chiark.greenend.org.uk) [120611 13:21]: Guillem Jover writes (Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability): As I mentioned in the long ref-counting thread, I strongly disagree this is a correct solution, it just seems like a hack to me. Instead I think we should consider changelog (and copyright as long as it's in machine parseable format) as dpkg metadata (something dpkg misses compared to rpm or other package managers for example) and as such they should go into the .deb control member, which would end up in the dpkg database w/o any kind of file conflict, and very minor packaging effort as for most that would be handled by helpers. I think this is the wrong design. The changelog is primarily used by humans, not software, and burying it in the dpkg database is not helpful. I think the solution with the binNMU changelogs is straightforward and should be implemented. Hm. Though I see the reasoning in general, would you think it hurts to have the binary epoch (and the corresponding binNMU reason) be stored in the metadata instead of the changelog as today? Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612185205.gn13...@mails.so.argh.org
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
* Guillem Jover (guil...@debian.org) [120612 09:00]: I disagree placing it in the dpkg database is not helpful, for a user or other programs wanting to access that structured package metadata it's obviously easier and better to do something like «dpkg --show-changelog foo» or «dpkg-query --control-path foo changelog», than having to go hunt where in the filesystem the changelog might be I don't see why dpkg --show-changelog foo can't work even if the changelog is stored in the filesystem. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612185352.go13...@mails.so.argh.org
Re: Handling of changelogs and bin-nmus
* Raphael Hertzog (hert...@debian.org) [120612 13:10]: 1/ we modify dpkg to ignore differences on /usr/share/doc/*/changelog.*gz for multi-arch: same packages Doesn't sound too bad to me, at least for short-term (where I'd tend to take the changelog-version of the main architecture on installation time, but that's just a tiny side note). Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612185613.gp13...@mails.so.argh.org
Re: ia64 qualification for Wheezy
On Mon, 2012-05-28 at 22:20 +1000, Aníbal Monsalve Salazar wrote: On Mon, May 28, 2012 at 01:05:58PM +0100, Adam D. Barratt wrote: On 23.05.2012 19:31, Adam D. Barratt wrote: On Wed, 2012-05-16 at 13:19 +0100, Adam D. Barratt wrote: With the sound of the ever approaching freeze ringing loudly in our ears, we're (somewhat belatedly) looking at finalising the list of release architectures for the Wheezy release. [...] One thing that was bought to my attention in private mail is #638068 in initramfs-tools. I'm happy to test a possible fix for #638068 on my ia64 machines. Does someone have a hint about fixing it? Has there been any progress on that? It's not hugely useful to ship Debian on an architecture where one needs to hack the initrd in order to make machines boot. :-/ Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1339528545.31672.6.ca...@jacala.jungle.funky-badger.org
Re: Migration path for 'Multi-Arch:allowed' packages
Michael, am Tue, Jun 12, 2012 at 12:57:12PM -0400 hast du folgendes geschrieben: A squeeze-proposed-update could help that along, right? no, we don't generally require people to update to the latest stable to upgrade to the next stable version. Also depending on the solution it might also not be suitable for a stable update. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: ttb upload to proposed-updates
On Mon, 2012-06-11 at 13:55 +0200, Jeroen Schot wrote:
On Fri, Jun 08, 2012 at 05:31:18PM +0200, Cyril Brulebois wrote:
Touko Korpela touko.korp...@iki.fi (08/06/2012):
-Depends: ${python:Depends}, ${misc:Depends}, python-gtk2
+Depends: ${python:Depends}, ${misc:Depends}, python-glade, python-gtk2
Description: Browse teletekst (Dutch) on your computer
Teletekst Browser (ttb) is a small browser for the Teletekst system
as used in
I think this has a typo, python-glade - python-glade2
Once that's fixed, looks good to me.
Thanks, and sorry for the silly typo. I prepared the package and am
waiting on my sponsor to review/upload.
For the record, this was uploaded and I've flagged the package for
acceptance in to proposed-updates; thanks.
Regards,
Adam
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1339533302.31672.12.ca...@jacala.jungle.funky-badger.org
Bug#675594: pu: package lockfile-progs/0.1.15
tag 675594 + confirmed squeeze thanks On Sat, 2012-06-02 at 13:21 +0200, Niels Thykier wrote: I have backported the fix for #626752[1], which currently makes the --use-pid feature useless in stable. The fix has already been deployed in sid (version 0.1.16). Please go ahead; thanks. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1339533286.31672.11.ca...@jacala.jungle.funky-badger.org
Processed: Re: Bug#675594: pu: package lockfile-progs/0.1.15
Processing commands for cont...@bugs.debian.org: tag 675594 + confirmed squeeze Bug #675594 [release.debian.org] pu: package lockfile-progs/0.1.15 Added tag(s) squeeze and confirmed. thanks Stopping processing here. Please contact me if you need assistance. -- 675594: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675594 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.133953336216708.transcr...@bugs.debian.org
Re: Migration path for 'Multi-Arch:allowed' packages
* David Kalnischkies (kalnischk...@gmail.com) [120612 18:03]: You need to upgrade to support MultiArch, but you need MultiArch to upgrade… (beside, how would the detection for such a message look like?) We had discussed to export foreign-arch packages to the arches packages files at debconf. That would mean in this case that the amd64-packages file contains the i386-package wine-bin. That would allow to detect we need multi-arch packages easily (and avoid that people have to add all i386-packages to an amd64-system just to install wine-bin). In order to get that going, we would need to document in the release notes that certain packages either need to be put on hold prior to the upgrade in case they're installed or to upgrade apt, aptitude and dpkg first. Both had been done before. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612203928.gb2...@mails.so.argh.org
Re: rstatd: does not work with kernel 3.0/3.1 or any other 3.x kernel (s-p-u possible?)
On Wed, 2012-06-06 at 22:12 +0200, Julien Cristau wrote: On Wed, Jun 6, 2012 at 21:25:37 +0200, Salvatore Bonaccorso wrote: Agreed, and thanks for feedback. Indeed the fix was simply taken from the version in unstable, which maybe should change that too. Yes, that would be better. (and indeed it did) Attached is the new debdiff for it. Looks good to me, thanks. Agreed. Please go ahead (with the obvious tweak to the version and an s/an the/and the/ in the changelog); thanks. Regards, Adam -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1339533973.31672.16.ca...@jacala.jungle.funky-badger.org
Haskell status summary
Hi Release and Haskell team, his is a summary of the current issues around GHC and Haskell, I hope I did not miss anything. The transition is mostly ready, excluding haskell-cryptocipher reverse dependencies on mips, powerpc, s390, s390x and sparc. The latest upload involving the transition is haskell-bindings-libzip which has aged 6 of its 10 days. haskell-cryptocipher FTBFS on big endian machines, due to a bug in the code. A fix is available and has been tested in experimental. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674811 Additionally, haskell-cryptocipher FTBFS on powerpc. Erik debugged the issue, reported it upstream and later noticed that it is fixed in the latest compiler version, GHC-7.4.2, which was just released. He was unable to identify the commit that fixed the problem, so we have no patch available for this problem for the current versions in unstable. http://hackage.haskell.org/trac/ghc/ticket/6156 The ghc postinst is incompatible with the latest dpkg. The dpkg maintainers have promised a work-around (which is required anyways to be able to install old packages), but could be fixed with a new GHC upload: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676874 Additionally, Joey Hess identified an important bug in xmonad that is not RC but would be fixed by an upgrade to GHC-7.4.2: http://bugs.debian.org/677096 The GHC changes in 7.4.2 are, for the most part, bug fixes. A notable exception is the newly added support for GHCi on arm distributions, finally supporting this architecture fully: http://www.haskell.org/ghc/docs/7.4.2/html/users_guide/release-7-4-2.html Possible courses of action: A) Upload the fixed haskell-cryptocipher to unstable, let it build on mips, s390, s390x and sparc, remove stuff on powerpc, migrate. B) Remove stuff on mips, powerpc, s390, s390x and sparc, migrate. C) Upload GHC 7.4.2 and fixed haskell-cryptocipher rebuild everything (using binNMUs, not sourceful uploads), migrate. D) (Under the assumption that the fix for the powerpc issue can be isolated.) Backport that fix, upload a patched GHC 7.4.1, hope that ABIs stay stable and no rebuilds are necessary, upload a patched haskell-cryptocipher, let stuff build on mips, s390, s390x and sparc, migrate. I’m leaning towards A or B to get the migration done and only then consider GHC 7.4.2. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
NEW changes in proposedupdates
Processing changes file: asterisk_1.6.2.9-2+squeeze6_amd64.changes ACCEPT Processing changes file: asterisk_1.6.2.9-2+squeeze6_armel.changes ACCEPT Processing changes file: asterisk_1.6.2.9-2+squeeze6_i386.changes ACCEPT Processing changes file: asterisk_1.6.2.9-2+squeeze6_ia64.changes ACCEPT Processing changes file: asterisk_1.6.2.9-2+squeeze6_mips.changes ACCEPT Processing changes file: asterisk_1.6.2.9-2+squeeze6_mipsel.changes ACCEPT Processing changes file: asterisk_1.6.2.9-2+squeeze6_powerpc.changes ACCEPT Processing changes file: asterisk_1.6.2.9-2+squeeze6_s390.changes ACCEPT Processing changes file: asterisk_1.6.2.9-2+squeeze6_sparc.changes ACCEPT Processing changes file: ttb_1.0.1-3+squeeze1_i386.changes ACCEPT -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1seye4-000845...@franck.debian.org
Re: Haskell status summary
Joachim Breitner wrote: Possible courses of action: A) Upload the fixed haskell-cryptocipher to unstable, let it build on mips, s390, s390x and sparc, remove stuff on powerpc, migrate. B) Remove stuff on mips, powerpc, s390, s390x and sparc, migrate. C) Upload GHC 7.4.2 and fixed haskell-cryptocipher rebuild everything (using binNMUs, not sourceful uploads), migrate. D) (Under the assumption that the fix for the powerpc issue can be isolated.) Backport that fix, upload a patched GHC 7.4.1, hope that ABIs stay stable and no rebuilds are necessary, upload a patched haskell-cryptocipher, let stuff build on mips, s390, s390x and sparc, migrate. I’m leaning towards A or B to get the migration done and only then consider GHC 7.4.2. I'm ok with either A or B if that clears the way to start work on 7.4.2 sooner. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120613081832.5c7b5a682538135a4e6f5...@mega-nerd.com
Bug#667906: transition: libffi
On 11.06.2012 00:29, Adam D. Barratt wrote: On Sun, 2012-06-10 at 22:59 +0100, Adam D. Barratt wrote: Are there likely to be any issues if the transition migrated in stages - i.e. if the new libffi including libffi6 and the old libffi5 binary (kept around by britney) co-exist in testing - and rebuilt binaries migrate as and when they're ready, rather than needing to have the entire set ready at once? To partly answer my own question, it looks like neither library includes versioned symbols, so it could be an issue if both end up being loaded by the same application. no, this should be safe. there are no ABI changes for existing functions. the new version adds functions for variadic support, and removes some debug functions. from my point of view, these should be able to coexist. Matthias -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd7c46d.5060...@debian.org
Re: Haskell status summary
On 06/12/2012 10:49 PM, Joachim Breitner wrote: Hi Release and Haskell team, his is a summary of the current issues around GHC and Haskell, I hope I did not miss anything. There is at least a problem with haskell-dummy still referencing the happstack packages (maybe others) that were removed from unstable, and preventing their removal from testing. I'm still investigating the rest… -- Mehdi Dogguy مهدي الدڤي http://dogguy.org/ -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd7c57f.3040...@dogguy.org
e2fsprogs 1.42.4 uploaded
Hi all, Since the freeze is supposed to be coming any day now, I thought I would mention that I've just uploaded e2fsprogs 1.42.4-1 to unstable. This has a number of bug fixes that I would really like to get into the stable release, including a couple of bugs that could cause e2fsck to corrupt large file systems with 64-bit block numbers. (See below for the complete list of fixes.) Since the e2fsprogs package tends to be one of the first to freeze, since it generates udebs used by the installer, I thought I would make a special mention that it would really be good if we could get 1.42.4 in before the freeze. Thanks, regards, - Ted e2fsprogs (1.42.4-1) unstable; urgency=medium * New upstream version * Fix 64-bit block number bugs in e2fsck, dumpe2fs, and debugfs which could corrupt file systems * Fixed e2fsck's handling of how errors propagate from the journal to the file system superblock * Fixed a false positive complaint from e2fsck if all of the extents in the last extent block are uninitialized and located after the end of the file. * dumpe2fs will display the journal's error indicator in the superblock if it is set * Fixed a bug which caused e2fsck to incorrectly use O_EXCLUSIVE in some corner cases. * Fix truncation of extent-mapped inodes in e2fsck and libext2fs * Fixed i_blocks accounting in bigalloc file systems. * Add support for btrfs's No_COW flag to lsattr and chattr * Debugfs interprets the date strings of the form @ddd as ddd seconds after the epoch * Updated/fixed various man pages (Closes: #674453, #674694) -- Theodore Y. Ts'o ty...@mit.edu Tue, 12 Jun 2012 18:20:55 -0400 e2fsprogs (1.42.3-1) unstable; urgency=low * New upstream version * Fix bugs on 32-bit systems which could corrupt 16TB file systems * Quiet complaints in e2fsck when the total free blocks or inodes are incorrect in the superblock after an system crash, since we don't update nor depend on the superblock summaries at each commit boundary * Fixed support for (hidden) quota files built into ext4; in particular, don't rewrite the quota inode unless the quotas are inconsistent * Optimized reading and writing bitmaps if direct I/O was enabled * Update Czech, Dutch, French, German, Polish, Sweedish, and Vietnamese translations * Fixed incorrect indentation in tune2fs man page * Update debian policy compliance to 3.9.3 -- Theodore Y. Ts'o ty...@mit.edu Mon, 14 May 2012 14:43:09 -0400 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1sezm1-0008ge...@tytso-glaptop.cam.corp.google.com
Re: e2fsprogs 1.42.4 uploaded
Hello, adding debian-boot@, people there might be interested. Mraw, KiBi. Theodore Ts'o ty...@mit.edu (12/06/2012): Since the freeze is supposed to be coming any day now, I thought I would mention that I've just uploaded e2fsprogs 1.42.4-1 to unstable. This has a number of bug fixes that I would really like to get into the stable release, including a couple of bugs that could cause e2fsck to corrupt large file systems with 64-bit block numbers. (See below for the complete list of fixes.) Since the e2fsprogs package tends to be one of the first to freeze, since it generates udebs used by the installer, I thought I would make a special mention that it would really be good if we could get 1.42.4 in before the freeze. Thanks, regards, - Ted e2fsprogs (1.42.4-1) unstable; urgency=medium * New upstream version * Fix 64-bit block number bugs in e2fsck, dumpe2fs, and debugfs which could corrupt file systems * Fixed e2fsck's handling of how errors propagate from the journal to the file system superblock * Fixed a false positive complaint from e2fsck if all of the extents in the last extent block are uninitialized and located after the end of the file. * dumpe2fs will display the journal's error indicator in the superblock if it is set * Fixed a bug which caused e2fsck to incorrectly use O_EXCLUSIVE in some corner cases. * Fix truncation of extent-mapped inodes in e2fsck and libext2fs * Fixed i_blocks accounting in bigalloc file systems. * Add support for btrfs's No_COW flag to lsattr and chattr * Debugfs interprets the date strings of the form @ddd as ddd seconds after the epoch * Updated/fixed various man pages (Closes: #674453, #674694) -- Theodore Y. Ts'o ty...@mit.edu Tue, 12 Jun 2012 18:20:55 -0400 e2fsprogs (1.42.3-1) unstable; urgency=low * New upstream version * Fix bugs on 32-bit systems which could corrupt 16TB file systems * Quiet complaints in e2fsck when the total free blocks or inodes are incorrect in the superblock after an system crash, since we don't update nor depend on the superblock summaries at each commit boundary * Fixed support for (hidden) quota files built into ext4; in particular, don't rewrite the quota inode unless the quotas are inconsistent * Optimized reading and writing bitmaps if direct I/O was enabled * Update Czech, Dutch, French, German, Polish, Sweedish, and Vietnamese translations * Fixed incorrect indentation in tune2fs man page * Update debian policy compliance to 3.9.3 -- Theodore Y. Ts'o ty...@mit.edu Mon, 14 May 2012 14:43:09 -0400 signature.asc Description: Digital signature
Please consider stopping uploads with *uncoordinated* changes to debconf templates before the release
Dear fellow developers,
I would hereby kindly ask you (once again) to consider more
coordination with the i18n teams when preparing uploads for packages
when these introduce changes to debconf templates: either new
templates, modified ones (even for trivial changes), etc.
The i18n teams are currently working hard to try getting fully
translated templates for several languages and each time such
uncoordinated action happens, we enter yet another loop for the said
package:
- review the templates (in debian-l10n-english)
- coordinated the review with the maintainer
- call for translations
- coordinated them
- track the transition to testing.
During last weeks, several package maintainers did such changes
(ledgersmb, icinga, pleiades, uptimed, nginx, nova and, last but not
least, screen).
I have no intent to discuss the NEED for such user interaction, often
in solving release critical bugs. But, really, I would like to call
for more consideration for the work we're doing. Often, these debconf
interactions are strongly needed and there is no reasons for our users
for not having them in their language and not only in (often bad) English.
Just like I did for squeeze, I am considering to ask our release team
to *block* transitions for such packages with uncoordinated debconf
changes, on a case by case basis. This, in order to give us enough
time to work on localization.
And, for ${DEITY}'s sake, please now limit debconfing to really really
really really needed interaction.
For this, also, please remember that we're preparing a release and
that takes time to settle down.
Many thanks in advance for your consideration. Any many thanks as well
to those of you who are *already* properly interacting with the i18n
teams. You know who you are and you deserve kudos.
--
signature.asc
Description: Digital signature
Re: rstatd: does not work with kernel 3.0/3.1 or any other 3.x kernel (s-p-u possible?)
Hi Adam, hi Anibal
On Tue, Jun 12, 2012 at 09:46:13PM +0100, Adam D. Barratt wrote:
On Wed, 2012-06-06 at 22:12 +0200, Julien Cristau wrote:
On Wed, Jun 6, 2012 at 21:25:37 +0200, Salvatore Bonaccorso wrote:
Agreed, and thanks for feedback. Indeed the fix was simply taken from
the version in unstable, which maybe should change that too.
Yes, that would be better.
(and indeed it did)
Attached is the new debdiff for it.
Looks good to me, thanks.
Agreed. Please go ahead (with the obvious tweak to the version and an
s/an the/and the/ in the changelog); thanks.
I just uploaded (as NMU) with the attached debdiff.
Adam, If you like, could you consinder to have it trough
stable-updates (like at's fix for = 3.2.9 kernels)?
Many thanks for your release work and for accepting the fix!
Regards,
Salvatore
diff -u rstatd-4.0.1/getdata.c rstatd-4.0.1/getdata.c
--- rstatd-4.0.1/getdata.c
+++ rstatd-4.0.1/getdata.c
@@ -285,7 +285,8 @@
if (0 == strncmp(u.release, 2.4, 3)) {
getdata.disk = get_disk24;
}
- if (0 == strncmp(u.release, 2.6, 3)) {
+ /* defaults to get_*26 for kernel version = 2.6 */
+ else {
getdata.disk = get_disk26;
getdata.vm = get_vm26;
}
diff -u rstatd-4.0.1/debian/changelog rstatd-4.0.1/debian/changelog
--- rstatd-4.0.1/debian/changelog
+++ rstatd-4.0.1/debian/changelog
@@ -1,3 +1,13 @@
+rstatd (4.0.1-4+squeeze1) stable; urgency=low
+
+ * Non-maintainer upload.
+ * Patch getdata.c. Work with 3.x Linux kernels. A machine running
+kernel 3.x and the rpc.rstatd does not reply to any rup request from
+remote or even from local host. This renders the package unusable.
+Thanks to Thomas Lange (Closes: #654276)
+
+ -- Salvatore Bonaccorso car...@debian.org Wed, 13 Jun 2012 07:43:56 +0200
+
rstatd (4.0.1-4) unstable; urgency=low
* Reduce log verbosity; closes: #418969
@@ -131 +140,0 @@
-
signature.asc
Description: Digital signature
