Bug#677311: ITP: r-bioc-biocgenerics -- generic functions for Bioconductor
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-biocgenerics Version : 0.2.0 Upstream Author : The Bioconductor Dev Team * URL : http://www.bioconductor.org/packages/release/bioc/html/BiocGenerics.html * License : Artistic-2.0 Programming Lang: R Description : generic functions for Bioconductor S4 generic functions needed by many other Bioconductor packages. . Bioconductor provides tools for the analysis and comprehension of high-throughput genomic data. Bioconductor uses the R statistical programming language, and is open source and open development. The packaging was initially prepared by Charles Plessy and finished by me in the Debian Med repositoy git://git.debian.org/debian-med/r-bioc-biocgenerics.git -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120613064527.9783.5546.report...@mail.an3as.eu
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On 13/06/2012 03:53, Serge wrote: > 2012/6/12 Bjørn Mork wrote: > >> I still think that the easy tmpfs resizing makes it superior for /tmp. > > Why do people repeat that tmpfs is easy to resize? Yes, you need about 3 > commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on > disk, because it's large by default and you don't need to resize it. It's > easier to NOT resize /tmp on disk then resize /tmp on tmpfs, isn't it? ;) Obviously, you only think of /tmp as mounted on /. This is often seen as not a good move to have a user-writable directory on the system partition(s), since this provides for easy DOS (even involuntary; I know of people daily working with 30GB files, and this easily fills the / partition). -- Jean-Christophe Dubacq (beating a dead horse) signature.asc Description: OpenPGP 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: Lets (eventually) find a good solution for /tmp
2012/6/12 Barak A. Pearlmutter wrote: > The real issue here is that having /tmp be just another directory in a > writable partition filesystem, like / or /home or whatever, means that > /tmp gets all the associated properties. One such property (A) is > that files can be large and can bleed off to disk smoothly without > thrashing the system, both of which are problems with tmpfs. On the > other hand, another property (B) is that a great deal of effort is > going into ensuring that files get written to disk in a timely > fashion, that data and metadata survives crashes, and that structures > on disk are consistent, up-to-date, and if necessary, quick to check. > We want /tmp to have (A), but it need not have (B). Ext3 has (A) and does not have (B). :) You don't think that writing some bytes of ext3 journal is "a great deal of effort" for /tmp, do you? ;) > So this is a technical question. Can we implement a filesystem which > provides properties A, but which (C) has zero data surviving after a > crash or umount, and takes advantage of property C to make things > faster. Whatever filesystem you invent, you'll need to recreate it as empty on every boot. This is not going to be much faster than replaying ext3 journal. And since you're replaying journal for your root partition anyway, keeping /tmp on your root partition is the fastest thing you can get, I guess. :) > But even though it may be an easy problem, to my knowledge, no one has > implemented a solution. Probably that's because nobody really needed such a filesystem yet. :) > IDEAS > One thought would be to make a fuse filesystem [...] > Another thought would be to hack tmpfs [...] BTW, what do you need all this for? I mean, it's an interesting idea about inventing a special limited version of tmpfs. I was thinking about that myself (e.g. aufs-mount with writable branches on tmpfs and disk), it's quite possible to implement. There're even fuse-filesystems partially implementing this feature. But how are you going to use it? How can you check that this new InventedFS is better than plain ext3? What do you want to use it for? I mean, there're plenty of different filesystems already, if you describe some use-case, or some problem to solve, then maybe, I could find a filesystem that will help you? For example if you need it to be fast, you can forget about fuse, I can suggest you to look at aufs3 patches. Hacking tmpfs won't be easy, unless you're good at understanding kernel/vfs code. -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caoveneobqcovjsvretryzjd3m_yn3bh378jrjsjgsoqe5tg...@mail.gmail.com
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
2012/6/12 Bjørn Mork wrote: > I still think that the easy tmpfs resizing makes it superior for /tmp. Why do people repeat that tmpfs is easy to resize? Yes, you need about 3 commands to resize tmpfs, but you need 0 (zero!) commands to resize /tmp on disk, because it's large by default and you don't need to resize it. It's easier to NOT resize /tmp on disk then resize /tmp on tmpfs, isn't it? ;) And there's more. You can't separate application data from your files on tmpfs in swap. But you can do that on a regular filesystem. You can dedicate /tmp directory to a separate partition/disk. Or you can balance it among several partitions (see `mhddfs`). You can't do that with tmpfs. > we might need a daemon monitoring /tmp and doing ondemand resizing. Since tmpfs+swap is mostly slower than regular filesystem and may generate more writes... I can't think of any cases where such daemon would be better than a usual /tmp on disk. But if you need it somewhy... check swapd. PS: I'm curious can swap-files break suspend-to-disk even for users having a separate swap partition? -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caovenepqrpbawuscncvvnd_dumd5te4hbtp4tpn-r-e4mb3...@mail.gmail.com
Re: Summary: Moving /tmp to tmpfs makes it useless
2012/6/10 Wouter Verhelst wrote: >> A lot of people (including you) said that tmpfs makes things faster. But >> there were no examples of popular use-cases becoming faster because >> of /tmp on tmpfs, so I had nothing to quote. > > You're not even trying. > > if tmpfs is faster than (say) ext4, then anything which uses /tmp will > obviously speed up. That's not true. Only applications, that are limited by /tmp speed will become faster then. Do you know such applications? > Can I provide a use case where this will matter? Not necessarily. But > then, can you provide a use case where this will *not* matter? Really? Yes. Everything. Every popular /tmp usage that most users expect to work is limited either by CPU (gcc compiling) or by network speed (browser or flash temporaries), or is just too fast already (bash heredoc). So moving /tmp to tmpfs does not make them faster, but can break them instead (if there's not enough space to store a streamed video, for example). >> Nobody could provide examples or numbers of how much /tmp on tmpfs >> reduces amount of writes, and tests showed that tmpfs+swap may even >> increase amount of writes (hence not always good for SSD), > > True, but then swapping to an SSD is the "best" idea since "640kB is > enough for everyone" :-) Hm, it's a bad idea to use tmpfs with swap... And it's not a good idea to use tmpfs without swap, since it would be too small and may even trigger OOM killer. When is it good to use tmpfs then? ;) >> tmpfs does not have 5% overflow safety, > > Because it doesn't need it. > The 5% overflow safety exists for two reasons: > - to avoid excessive fragmentation (which is not relevant for tmpfs) > - to allow you to clean up when the filesystem does fill up. You missed one more reason. When user fills the entire /tmp on disk, it does not break system services, since root can still use those 5%. User cannot break the system filling /tmp on disk. But he can do that if he fills /tmp on tmpfs. So /tmp on tmpfs adds one more point of failure for servers. -- Serge -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOVenErV3+M2eMsQLmgR3aYJxKhY2Y3JsTLUz=k70C=sf52...@mail.gmail.com
Bug#677289: ITP: libnetty3.1-java -- Java NIO client/server socket framework
Package: wnpp Severity: wishlist Owner: Charles Plessy * Package name: libnetty3.1-java Version : 3.1.0.CR1 Upstream Author : Red Hat Middleware LLC, and individual contributors * URL : http://www.jboss.org/netty * License : LGPL-2.1+ Programming Lang: Java Description : Java NIO client/server socket framework Description: Java NIO client/server socket framework Netty is a Java NIO client/server framework which enables quick and easy development of network applications such as protocol servers and clients. It greatly simplifies and streamlines network programming such as TCP and UDP socket server. Debian has Netty 3.2, but unfortunately it is significantly different from Netty 3.1, which we need for Eucalyptus, an open-source cloud system that implements the industry-standard Amazon Web Services (AWS) cloud APIs. See http://wiki.debian.org/pkg-eucalyptus for more details about our packaging progresses. -- Charles Plessy Debian pkg-eucalyptus-maintainers team http://wiki.debian.org/pkg-eucalyptus Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612230831..50386.reportbug@aqwa.igloo
Re: Re: Is Debian affected by the recent MySQL sql/password.c flow?
Hi, On Mon, Jun 11, 2012 at 10:53:50PM +0200, Peter Pöschl wrote: > Seems you overlooked this: > > > Debian Unstable 64-bit 5.5.23-2 I just tried on my 32bit machine, and didn't get in in some 50.000 attempts. Also, the squeeze versions are listed under "unaffected", which is what reduces the stress level. Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612214337.ga26...@spruce.wiehl.oeko.net
Re: Packaging entirely via git
On Tue, Jun 12, 2012 at 2:48 PM, Luis Alejandro Martínez Faneyth wrote: > El 12/06/12 12:40, Enrico Weigelt escribió: >> >> Hi folks, >> >> >> is there already a way for maintaining debian packages entirely >> with git - without the orig tarball ? I use something like this in the gbp.conf: [DEFAULT] builder = /home/mzagrabe/bin/git-pdebuild upstream-branch = master debian-branch = debian upstream-tag= v%(version)s -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3v28jvwwcen57+ouszs4mcdhdurgzu7ifun2jxg+1z...@mail.gmail.com
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-devel-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: 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: Packaging entirely via git
El 12/06/12 12:40, Enrico Weigelt escribió: > > Hi folks, > > > is there already a way for maintaining debian packages entirely > with git - without the orig tarball ? > > As more and more projects are moving to git, this IMHO would make > things easier for those projects. > > > I'm currently (re)packaging wwwoffle, and optimially I'd just like > to push a signed tag (to the debianized branch) and let the > machinery run ;-) > > > cu As far as i know, git-buildpackage can build the .orig from an "upstream" git branch. You would need to pull the changes from upstream to that branch though. -- Luis Alejandro Martínez Faneyth Blog: http://www.huntingbears.com.ve/ Twitter/Identi.ca: @LuisAlejandro ED51 8FE7 4107 715D 0464 8366 F614 5A95 E78D AA2E CODE IS POETRY signature.asc Description: OpenPGP digital signature
Re: Packaging entirely via git
Enrico Weigelt writes: > Hi folks, > > > is there already a way for maintaining debian packages entirely > with git - without the orig tarball ? Not what you mean -- although there is pristine-tar to enable one to discard the actual tarball and recreate it from git later. > As more and more projects are moving to git, this IMHO would make > things easier for those projects. > > I'm currently (re)packaging wwwoffle, and optimially I'd just like > to push a signed tag (to the debianized branch) and let the > machinery run ;-) You should probably read the thread starting here: http://lists.debian.org/debian-devel/2012/05/msg00828.html as you can see, you're not the first to think that. It seems like a pretty good idea, if the issues can be solved. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgps0LUejpf50.pgp Description: PGP signature
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-devel-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: [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-devel-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: [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-devel-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
Bug#677271: ITP: dbus-test-runner -- Runs tests under a new DBus session
Package: wnpp Severity: wishlist Owner: Thomas Bechtold * Package name: dbus-test-runner Version : 0.0.5 Upstream Author : Ted Gould * URL : https://launchpad.net/dbus-test-runner/ * License : GPL-3 Programming Lang: C Description : Runs tests under a new DBus session A simple little executable for running a couple of programs under a new DBus session. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612183836.6188.53006.report...@salbei.fritz.box
Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability
On Sun, Jun 10, 2012 at 10:01:29AM +0200, 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. At last. I've always thought having changelog and copyright in /usr is incorrect and they belong with other metadata. And when I saw discussions about M-A and binNMUs I've instantly understood that it is the real solution for that problem. I'm not sure about "as long as it's in machine parseable format" though. (maybe we'll get signed .debs and other RPM goodies one day too) -- WBR, wRAR signature.asc Description: Digital signature
Re: Handling of changelogs and bin-nmus
Guillem Jover wrote: > 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 Why "artificial"? Isn't it a completely natural and consistent view to say that the main changelog documents changes to the source package? Binary rebuilds aren't really changes at all in this sense; the main reason they need to be tracked explicitly at this level is to generate consistent version numbers for the different binaries. Unlike entries documenting source package changes, binNMU changelog entries are not kept in future versions of the package. Doesn't that alone show there is a real significant distinction? [ Note: not crossposted everywhere like the original ] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1339522369.21597.113.camel@glyph.nonexistent.invalid
Bug#677263: ITP: jsapigen -- Generate C interface bindings for SpiderMonkey JavaScript API
Package: wnpp Severity: wishlist Owner: Vincent Sanders * Package name: jsapigen Version : 0.5.1 Upstream Author : Thomas Zimmermann * URL : http://jsapigen.sourceforge.net/ * License : GPL3+ Programming Lang: C Description : Generate C interface bindings for SpiderMonkey JavaScript API jsapigen provides a simple interface definition language for describing the connection between native C code and the JavaScript environment. It converts such IDL descriptions to C code which is then compiled and linked into an application during the build process. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612164814.12417.70388.report...@happy.kyllikki.org
Re: incomplete de translation of maintainer guide
Hi Enrico, On 12.06.2012 19:15, Enrico Weigelt wrote: > just seen that the German translation of the maintainer guide is > quite incomplete. > > Perhaps I could find some time for fixing it, if anybody explains > me how to do that ;-) Thanks for volunteering. Please ask on the debian-l10n-ger...@lists.debian.org mailing list. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd77ac3.7080...@debian.org
incomplete de translation of maintainer guide
Hi folks, just seen that the German translation of the maintainer guide is quite incomplete. Perhaps I could find some time for fixing it, if anybody explains me how to do that ;-) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612171543.gd25...@mailgate.onlinehome-server.info
Packaging entirely via git
Hi folks, is there already a way for maintaining debian packages entirely with git - without the orig tarball ? As more and more projects are moving to git, this IMHO would make things easier for those projects. I'm currently (re)packaging wwwoffle, and optimially I'd just like to push a signed tag (to the debianized branch) and let the machinery run ;-) cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612171034.gc25...@mailgate.onlinehome-server.info
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-devel-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
Re: wwwoffle
* Paul Wise schrieb: Hi, > Please read through some of these pages: > > http://www.debian.org/doc/manuals/maint-guide/ > http://mentors.debian.net/intro-maintainers Thanks. I'll dig into it. Meanwhile I'm almost finished with git importing and patch sorting, and created a .deb via git-buildpackage. Uploaded it to github, maybe somebody likes to have a look at it: https://github.com/metux/wwwoffle/ cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612164238.gb25...@mailgate.onlinehome-server.info
Re: Bug#677230: ITP: adhcp -- DHCP implementation in Ada
also sprach Ben Hutchings [2012.06.12.1736 +0200]: > dhclient could do with some good competition; it's slow to recover from > a link drop (or suspend/resume) and its configuration format is not very > user-friendly. But it does seem premature to include ADHCP. udhcpc and dhcpcd also work. -- .''`. martin f. krafft 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 save the plankton - eat a whale. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Bug#677230: ITP: adhcp -- DHCP implementation in Ada
On Tue, 2012-06-12 at 15:59 +0100, Steve McIntyre wrote: > On Tue, Jun 12, 2012 at 04:33:00PM +0200, Adrian-Ken Rueegsegger wrote: > >Hi, > > > >On 06/12/2012 03:45 PM, Steve McIntyre wrote: > >> > >> One question: why? > > > >Is the question about why ADHCP in general or why ADHCP in Debian? > > > >If it is the former: the initial motivation for the development of ADHCP > >was the need for a simple and robust implementation of the DHCP protocol. > > Fair enough. > > >If it is the latter: I believe having a simple and robust DHCP > >implementation would be beneficial for the Debian project in general. > > How does Debian gain by including yet another implementation of a > common low-level system networking tool, written in a rarely-used (in > Debian) language? In fact, a tool that (according to your own upstream > web page at http://www.codelabs.ch/adhcp/) hasn't even been formally > released yet. > > Apart from not being written in your language of choice, is there > anything wrong with the existing implementations that would cause a > Debian user to want to switch? dhclient could do with some good competition; it's slow to recover from a link drop (or suspend/resume) and its configuration format is not very user-friendly. But it does seem premature to include ADHCP. Ben. -- Ben Hutchings Computers are not intelligent. They only think they are. signature.asc Description: This is a digitally signed message part
Re: Lets (eventually) find a good solution for /tmp
Don is right. I'd like to step up a level and think about the situation. The real issue here is that having /tmp be just another directory in a writable partition filesystem, like / or /home or whatever, means that /tmp gets all the associated properties. One such property (A) is that files can be large and can bleed off to disk smoothly without thrashing the system, both of which are problems with tmpfs. On the other hand, another property (B) is that a great deal of effort is going into ensuring that files get written to disk in a timely fashion, that data and metadata survives crashes, and that structures on disk are consistent, up-to-date, and if necessary, quick to check. We want /tmp to have (A), but it need not have (B). So this is a technical question. Can we implement a filesystem which provides properties A, but which (C) has zero data surviving after a crash or umount, and takes advantage of property C to make things faster. This seems like a much easier problem than the problems that journaling filesystems and their ilk solve. But even though it may be an easy problem, to my knowledge, no one has implemented a solution. IDEAS One thought would be to make a fuse filesystem which keeps small files in the fuse process itself (like tmpfs) and puts big files on a big filesystem but *unlinks* the files so their only reference is via an open handle held by the fuse process itself. The files are thus backed on disk as usual, and can be large, but when the fuse process dies *bam* they're gone, and the usual recovery mechanisms scavenge their space after a crash. Another thought would be to hack tmpfs to keep only big files in some backing filesystem, perhaps using handles to unlinked files as above, thus having the advantages of tmpfs for small files while also handling large files well. --Barak. -- Barak A. Pearlmutter Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/E1SeSpB-00060c-Cg@port-kdr.hamilton.local
Re: Bug#677230: ITP: adhcp -- DHCP implementation in Ada
On Tue, Jun 12, 2012 at 04:33:00PM +0200, Adrian-Ken Rueegsegger wrote: >Hi, > >On 06/12/2012 03:45 PM, Steve McIntyre wrote: >> >> One question: why? > >Is the question about why ADHCP in general or why ADHCP in Debian? > >If it is the former: the initial motivation for the development of ADHCP >was the need for a simple and robust implementation of the DHCP protocol. Fair enough. >If it is the latter: I believe having a simple and robust DHCP >implementation would be beneficial for the Debian project in general. How does Debian gain by including yet another implementation of a common low-level system networking tool, written in a rarely-used (in Debian) language? In fact, a tool that (according to your own upstream web page at http://www.codelabs.ch/adhcp/) hasn't even been formally released yet. Apart from not being written in your language of choice, is there anything wrong with the existing implementations that would cause a Debian user to want to switch? -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612145924.gc22...@einval.com
Re: Bug#677230: ITP: adhcp -- DHCP implementation in Ada
Hi, On 06/12/2012 03:45 PM, Steve McIntyre wrote: > k...@codelabs.ch wrote: >> Package: wnpp >> Severity: wishlist >> Owner: "Adrian-Ken Rueegsegger" >> >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> * Package name: adhcp >> Version : 0.3 >> Upstream Author : codelabs.ch >> * URL : http://www.codelabs.ch/adhcp/ >> * License : GPL-2+ >> Programming Lang: Ada >> Description : DHCP implementation in Ada >> >> ADHCP is an implementation of the DHCP protocol in Ada. Currently the project >> provides client and relay services for DHCPv4. >> >> The ADHCP DHCPv4 client (adhcp_client) is D-Bus aware and can be used on most >> modern Linux distributions as replacement for other clients such as >> ISC’s >> dhclient or busybox’s udhcpc. > > One question: why? Is the question about why ADHCP in general or why ADHCP in Debian? If it is the former: the initial motivation for the development of ADHCP was the need for a simple and robust implementation of the DHCP protocol. If it is the latter: I believe having a simple and robust DHCP implementation would be beneficial for the Debian project in general. Regards, Adrian -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd7531c.8020...@codelabs.ch
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
On Tue, Jun 12, 2012 at 01:15:51PM +0200, Bjørn Mork wrote: Aneurin Price writes: In anything resembling a 'normal' system (ie. the kind where one might be using the defaults) I would say that the tmpfs correlation is so strong as to be very nearly 1:1, and this seems like the crux of the matter; that is after all the reason that these applications are failing when /tmp is switched to tmpfs. I agree that's likely for any system using a default disk layout, so my comment was irrelevant for this discussion. I agree as well. This is the main reason why I didn’t like tmpfs to be the default. In most desktop cases you won’t have disk space problems. Even with multiple partitions you can easily spare 20 - 30 GB for a separate tmp partition. I still think that the easy tmpfs resizing (no meta data update, no LVM requirements, can use available space on other file systems) makes it superior for /tmp. But most users won't know that they can do this, so we might need a daemon monitoring /tmp and doing ondemand resizing. While you can resize tmpfs easily, you will never get sizes you would get with disks. And you must backup tmpfs with RAM and swap, so you can’t simply say, I resize my tmpfs to 20 GB if you only have 4 GB RAM and 8 GB swap (but a 2 TB disk). Since you can’t change the partition layout on the fly to grow the swap partition, your daemon would have to create swap files and activate them according to the tmpfs needs. But there will you place these files? You must make sure that the daemon deletes them if they are not needed anymore. After a system crash they must be deleted, or your system will have less and less disk space because orphaned swap files are filling the disk. Will this be worth the trouble? I don’t think so. If you see an advantage having /tmp on tmpfs, you can manually do so. Then you know what you have done. I don’t care if we get a new /tmpfs together with /tmp, so the user has both choices to set TMDPIR according to his needs. We may even patch some applications creating small shortlived temporary files to use /tmpfs instead in Debian. But by default we should not give up disk based /tmp for a default installation. Stephan -- | Stephan Seitz E-Mail: s...@fsing.rootsland.net | | Public Keys: http://fsing.rootsland.net/~stse/keys.html | smime.p7s Description: S/MIME cryptographic signature
Re: Bug#677230: ITP: adhcp -- DHCP implementation in Ada
k...@codelabs.ch wrote: >Package: wnpp >Severity: wishlist >Owner: "Adrian-Ken Rueegsegger" > >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA256 > >* Package name: adhcp > Version : 0.3 > Upstream Author : codelabs.ch >* URL : http://www.codelabs.ch/adhcp/ >* License : GPL-2+ > Programming Lang: Ada > Description : DHCP implementation in Ada > >ADHCP is an implementation of the DHCP protocol in Ada. Currently the project >provides client and relay services for DHCPv4. > >The ADHCP DHCPv4 client (adhcp_client) is D-Bus aware and can be used on most >modern Linux distributions as replacement for other clients such as ISCâs >dhclient or busyboxâs udhcpc. One question: why? -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1serp4-0006nu...@mail.einval.com
Bug#677230: ITP: adhcp -- DHCP implementation in Ada
Package: wnpp Severity: wishlist Owner: "Adrian-Ken Rueegsegger" -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: adhcp Version : 0.3 Upstream Author : codelabs.ch * URL : http://www.codelabs.ch/adhcp/ * License : GPL-2+ Programming Lang: Ada Description : DHCP implementation in Ada ADHCP is an implementation of the DHCP protocol in Ada. Currently the project provides client and relay services for DHCPv4. The ADHCP DHCPv4 client (adhcp_client) is D-Bus aware and can be used on most modern Linux distributions as replacement for other clients such as ISC’s dhclient or busybox’s udhcpc. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJP1zMgAAoJEP/osUKX3goFDogQAIfdJjxolmqjV8dUwMU8j4bx WMzJucBQDD3eYNNhmf6Oh72GeYIPDc3T30D58EK8p7O9gFCbV39gwrj3Y+YeZ2Ts 5yWP27A8WV11siY9YOfF/EjagbOgT9W7i0blr0opSNrqQ0a061hFFlIRreog+j95 kFBOqKurbIgJj5rAr2TFTkPIDeC3bDxeQXy3q7UAMzWV5i+uwd65SYH86HbCcSrF SRrW7SflkSAvXUiav9IcwkSoJjF44VKYSWdbKsyFpKuJtVwrNlhx61slN0lHsk8h cHQWtIAitkn3dcmQZlAwbVGeBH9++QF9rL8Zl8A6G75cREd1aqRrJ+Ky6KNSaFHr vG70SEE2+rGWMp9wrCNUVgVB9J3YuUq1/53azcJvqJwaRy/C0e+GzQKQEJQBumDe oiS0hy5v7Y6UQK9SeYsUbza07b/BpAjPInBjOplAI8iPcJBx/oHQOQj+1GO+4Boj r3hcQuI73TSXHGMgFLhXEOa3xJIuHmA1xOUoY4vAjSmbSVHNWv2rvLKo6UR5vqnG mKNsBfp7hJbZdTtKCqMV0+E6+2E8cGfvB5SETNiKaWlCSZ2Ij/A/lwUA+4S8NwJ6 xU3IGmbEBttgp4bnCw82CRHLzMgAmcQY80Rbs336jA5f3/F3qi+AQmri7qqihqJz Gp+M1miOs72QoUY45zLK =jhkj -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612121637.15695.60706.report...@dt-ita-113896.hsr.ch
Re: Planned changes to Debian Maintainer uploads
Bernd Zeimetz writes: > Which bad things happened that we have to change the current process? As far as I see, it's more about "what good things didn't happen" why we have to change the process. That is also addresses a few corner cases that could've gone bad, but never did is a side-effect. -- |8] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5nssmbn.fsf@algernon.balabit
Re: Planned changes to Debian Maintainer uploads
Hi, On Sun, Jun 10, 2012 at 01:57:49PM +0200, Ansgar Burchardt wrote: > > The ftp team wants to change how allowing Debian Maintainers to upload > packages works. The current approach with the DM-Upload-Allowed field > has a few issues we would like to address: I have read three responses to this mail which were somehow asking for any abuse. The fact that you are introducing restrictions to the current procedure implies that it is not good as it is. Could you please give some reasons why you are considering such changes? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120612132633.gp9...@an3as.eu
Re: Migration path for 'Multi-Arch:allowed' packages
Hi Mike, On Mon, 11 Jun 2012 15:40:59 -0400, Michael Gilbert wrote: > We've been getting a few bug reports from users attempting to install > multiarch wine who have yet to manually enable multiarch itself. > Obviously that is a failure on their part, and is easily correctable. > However, I wonder if we can't make such migrations a bit more > straightforward? I fail to see how it is a failure on the part of the users. How are they supposed to know that wine is now a multiarch-only package on *-amd64? One might expect unstable-tracking users to find out for themselves, but what will happen when users upgrade from Squeeze? We could ask for a specific mention in the release notes, but we'll still end up with bug reports from users who haven't read them... > 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? Having dpkg produce more informative error messages won't help users upgrading with apt-get or aptitude. I just rebuilt a Squeeze amd64 system to try the upgrade, and the only solutions offered are either to hold the wine package, or remove it - so dpkg never gets a chance to attempt to process the upgrade. > Also, limitations in the existing testing migration tools are making > wine not considered for wheezy, since those tools don't check whether > dependencies for 'Multi-Arch: allowed' packages are satisfied by > packages on other architectures. Short of packaging Wine64, might it be possible to have wine-bin on amd64 and kfreebsd-amd64 be a dummy package containing only a wine script which provides appropriate instructions, registered as a very-low-priority alternative using the existing infrastructure? Regards, Stephen signature.asc Description: PGP signature
Re: Is Debian affected by the recent MySQL sql/password.c flow?
On 12-06-12 at 12:33pm, Salvo Tomaselli wrote: > > So because it turned out that the information indeed was public, you > > find it ok to ask in public if it is public. > > he posted a link on the 1st email... how is a link "non public"? The link was public. The discussion here about potential issues in Debian was not. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Re: Planned changes to Debian Maintainer uploads
On 06/12/2012 12:24 AM, Joey Hess wrote: > Ian Jackson wrote: >>> - It allows DMs to grant permissions to other DMs. >> >> It is far from clear that forbidding this is the right thing to do. > > As far as I know, we did this intentionally. When a DM is the maintainer > of a package, they should be able to move it to team maintenance without > needing to find some DD who cares about the package, who may not exist. > > I've never heard of this being abused. > Me neither. I've even seen various cases where one of the uploaders of a package with various uploaders (from a team...) got DM upload permissions and the other team members became DMs later - obviously they got the same permissions then as soon as they were in the Keyring. Which bad things happened that we have to change the current process? -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd73087.40...@bzed.de
Re: Idea: mount /tmp to tmpfs depending on free space and RAM
Aneurin Price writes: > In anything resembling a 'normal' system (ie. the kind where one might > be using the defaults) I would say that the tmpfs correlation is so > strong as to be very nearly 1:1, and this seems like the crux of the > matter; that is after all the reason that these applications are > failing when /tmp is switched to tmpfs. I agree that's likely for any system using a default disk layout, so my comment was irrelevant for this discussion. I still think that the easy tmpfs resizing (no meta data update, no LVM requirements, can use available space on other file systems) makes it superior for /tmp. But most users won't know that they can do this, so we might need a daemon monitoring /tmp and doing ondemand resizing. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87lijsok60@nemi.mork.no
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-devel-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: 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 Tue, 12 Jun 2012 12:30:41 +0200
pkg (1.0-1) unstable; urgency=low
* Some change.
-- Guillem Jover 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-devel-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: Is Debian affected by the recent MySQL sql/password.c flow?
> So because it turned out that the information indeed was public, you > find it ok to ask in public if it is public. he posted a link on the 1st email... how is a link "non public"? -- Salvo Tomaselli -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206121233.35003.tipos...@tiscali.it
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-devel-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
