Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]
Tollef Fog Heen writes: > ]] Ben Finney > > | The VCS browser link for ‘python-coverage’ used to work before the > | changes this year. Now it leads to a 404 response. > > Fixed. Confirmed fixed, thank you. -- \ “Roll dice!” “Why?” “Shut up! I don't need your fucking | `\ *input*, I need you to roll dice!” —Luke Crane, demonstrating | _o__) his refined approach to play testing, 2009 | Ben Finney -- 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/87ty9hdgpi@benfinney.id.au
Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]
]] Ben Finney | The VCS browser link for ‘python-coverage’ used to work before the | changes this year. Now it leads to a 404 response. | | http://bzr.debian.org/loggerhead/collab-maint/python-coverage/python-coverage.debian/> Fixed. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hb5hlx03@qurzaw.varnish-software.com
Re: Anonymous read-only access and Vcs-* [Re: Alioth status update, take 3]
Tollef Fog Heen writes: > ]] Sven Hoexter > > | On the other hand there are all these packages in stable with broken > | Vcs fields now. Still not nice but assuming that most contributions > | will be based on what's in unstable that might be bearable. > > What VCS fields are broken? The VCS browser link for ‘python-coverage’ used to work before the changes this year. Now it leads to a 404 response. http://bzr.debian.org/loggerhead/collab-maint/python-coverage/python-coverage.debian/> -- \ “There's no excuse to be bored. Sad, yes. Angry, yes. | `\Depressed, yes. Crazy, yes. But there's no excuse for boredom, | _o__) ever.” —Viggo Mortensen | Ben Finney -- 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/87y5yuc7l7@benfinney.id.au
Re: /usr/share/doc/ files and gzip/xz/no compression
On Monday, August 15, 2011, Russell Coker wrote: > On Tue, 16 Aug 2011, Chris Knadle wrote: > > > After all, it isn't called gzless. > > > > Actually, that's not far off. Right now these functions are > > spread across 4 different binaries, each of which is in a > > different package. > > Probably the best thing to do would be to just incorporate the > functionality in the less package. > > zless works with uncompressed files and is well known to work that > way. I'm sure that lots of people run "zless *" without regard to > whether there are compressed or uncompressed files in the > directory. I commonly do that. Not just with zless but even more commonly with zfgrep. [And this hints that this issue is larger than just 'less'.] Apparently bzmore and xzless are likewise able to read plaintext files, so these binaries are also doing file type recognition. > Having zless and less do the same thing and support a > wide variety of compression methods would be ideal. It's not as > if anyone would use less to view the binary contents of a gzip > data stream. I think you're onto a good idea. It seems like it should be possible to build one 'less' such that it will read all of the compressed file types, and have zless xzless and bzless all point to 'less' via softlinks. (Or hardlinks, if they're in the same directory, similar to how used to be done with separate 'git-' binaries after they were consolidated into one 'git' binary.) I'm trying to think of what undesired effects this might have. One unexpected consequence would be that calling 'less' by default wouldn't skip over compressed file types that it would know how to handle. If it were desired to be able to skip over compressed files, 'less' could be crafted to change behavior based on the filename that was actually called (as was likewise done with git), thus zless bzless and xzless would open compressed files, but 'less' itself could avoid doing so. Or add yet another command-line option as to whether to open compressed file types or not. -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Re: /usr/share/doc/ files and gzip/xz/no compression
On Tue, Aug 16, 2011 at 01:06:34PM +1000, Russell Coker wrote: > On Tue, 16 Aug 2011, Chris Knadle wrote: > > > After all, it isn't called gzless. > > > > Actually, that's not far off. Right now these functions are spread > > across 4 different binaries, each of which is in a different package. > > Probably the best thing to do would be to just incorporate the functionality > in the less package. You mean like lesspipe(1)? Seems like it might need to be updated to handle *.xz, but other than that looks like it fits the bill. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega signature.asc Description: Digital signature
Re: /usr/share/doc/ files and gzip/xz/no compression
On Tue, 16 Aug 2011, Chris Knadle wrote: > > After all, it isn't called gzless. > > Actually, that's not far off. Right now these functions are spread > across 4 different binaries, each of which is in a different package. Probably the best thing to do would be to just incorporate the functionality in the less package. zless works with uncompressed files and is well known to work that way. I'm sure that lots of people run "zless *" without regard to whether there are compressed or uncompressed files in the directory. Having zless and less do the same thing and support a wide variety of compression methods would be ideal. It's not as if anyone would use less to view the binary contents of a gzip data stream. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201108161306.34484.russ...@coker.com.au
Re: /usr/share/doc/ files and gzip/xz/no compression
On Monday, August 15, 2011, Ben Hutchings wrote: > On Tue, 2011-08-16 at 10:43 +1000, Russell Coker wrote: > > On Tue, 16 Aug 2011, Iustin Pop wrote: > > > There is also information on Wikipedia about various > > > compression benchmarks, but IMHO if we want to switch from > > > gzip then bzip2 doesn't make sense for /usr/share/doc. > > > > I'd like to see zless work transparently with bzip and xz > > compressed files. There's really no need for three different > > wrapper programs when the zless program can just consult the > > magic db to determine which decompression program to use. > > [...] > > +1 > > After all, it isn't called gzless. Actually, that's not far off. Right now these functions are spread across 4 different binaries, each of which is in a different package. File Package == === /bin/bzless -> bzmorebzip2 /bin/bzmore bzip2 /bin/zless gzip /usr/bin/less -> /bin/less less /bin/lessless /usr/bin/xzless xz-utils -- Chris -- Chris Knadle chris.kna...@coredump.us signature.asc Description: This is a digitally signed message part.
Re: /usr/share/doc/ files and gzip/xz/no compression
On Tue, 2011-08-16 at 10:43 +1000, Russell Coker wrote: > On Tue, 16 Aug 2011, Iustin Pop wrote: > > There is also information on Wikipedia about various compression > > benchmarks, but IMHO if we want to switch from gzip then bzip2 > > doesn't make sense for /usr/share/doc. > > I'd like to see zless work transparently with bzip and xz compressed files. > There's really no need for three different wrapper programs when the zless > program can just consult the magic db to determine which decompression > program > to use. [...] +1 After all, it isn't called gzless. Ben. signature.asc Description: This is a digitally signed message part
Re: /usr/share/doc/ files and gzip/xz/no compression
On Tue, 16 Aug 2011, Iustin Pop wrote: > There is also information on Wikipedia about various compression > benchmarks, but IMHO if we want to switch from gzip then bzip2 > doesn't make sense for /usr/share/doc. I'd like to see zless work transparently with bzip and xz compressed files. There's really no need for three different wrapper programs when the zless program can just consult the magic db to determine which decompression program to use. A switch inevitably involves a period of time where we have a mixture of compression methods in use. Even after that there will be a variety of old data (I'm sure that I'm not the only person who has been using gzip for most things because it's usually good enough and it's a matter of habit). As most Unix commands aren't consciously typed having multiple variants of zless would be a real drag. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ -- 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/201108161043.04786.russ...@coker.com.au
Re: Introducing Build-Recommends / Build-Core-Depends?
Le Mon, Aug 15, 2011 at 11:12:36AM +0100, Steve McIntyre a écrit : > Andreas Barth wrote: > > > >Generic options are usually better IMHO, but well - YMMV. > > Often, yes. But also often at extra cost. Where is the added benefit > here - i.e. what are the use cases? I'm 100% behind making the > bootstrap phase more simple, but I can't see many others... I think Build-Recommends would be well suited for skipping or disabling regression tests when ‘test dependancies’ are not available. With “DEB_BUILT_OPTIONS=nocheck”, the tests are skipped, but the packages needed to run the tests are still installed, which means that if they are not available, the package can not be built. Here is an example: bioperl-run contains BioPerl wrappers for common command-line tools. t-coffee contains the T-COFFEE command-line tool to align nucleotidic sequences. bioperl-run's regression tests try the wrapper for T-COFFEE, and therefore bioperl-run Build-Depends on t-coffee. t-coffee fails to build from source on armel (where its regression test fails). If t-coffee is removed from armel (where it probably never worked), bioperl-run can not be rebuilt there. This chain of build dependancies is weak, but brings the benefit of running full regression tests at build time and include the results in the build logs. I think that DEP 8 is complementary to this, but can not replace this feature in the short term. A Build-Recommends field would allow packages to be resilient to the absence of one of the components featured in their regression tests. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med 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/20110816001145.ge19...@merveille.plessy.net
Re: /usr/share/doc/ files and gzip/xz/no compression
* Andreas Barth [2011-08-15 23:59 +0200]: > * Lars Wirzenius (l...@liw.fi) [110815 23:27]: > > On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote: > > > * Lars Wirzenius [2011-08-15 18:33 +0100]: > > > > raw gz xz > > > > 584163 134 file sizes (MiB) > > > >0421 450 savings compared to raw (MiB) > > > > -421 0 29 savings compared to current gz (MiB) > > > In other words, it's 130 MiB against xz's 134 MiB. I'll leave it to > > others to decide if it's a significatn difference. > > bzip2 is definitly a more conservative choice than xz. If it's > smaller, than it's superior to xz. bzip2 has a better compression on average for some filetypes, xz[1] has a better compression on average for others: gzip bzip2 xz bzip2+xz[3] text files[2] 94312922 73496587 77783076 73496587 other files 16577181 14609893 14275484 14275484 sum110890103 88106480 92058560 87772071 Among the "other files" are also a lot of text files, if we would compress Debian packages instead, xz would win presumably. Anyway, I don't think this difference of 4 MiB on a desktop system is significant. I would prefer to avoid bloating the set of pseudo essential packages without a good reason and I think users should be able to decompress all files in /u/s/d. There are plans to let dpkg depend on liblzma2 instead of xz and it already depends on libbz2-1.0. If dpkg's dependency on libbz2 is planned to be removed in future, I would prefer to let libbz2 vanish from the pseudo essential set and use xz also for /u/s/d, otherwise I would prefer using bzip2 over xz for /u/s/d. Carsten [1] I did not use -e nor -9, but the difference should not be that big on files in /usr/share/doc. [2] find ... -regex '.*\(changelog\|copyright\|README\|TODO\|NEWS\).*[.]gz' [3] bzip2 for text files and xz for other files. This is of course nothing we should consider doing. -- 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/20110815230257.ga27...@furrball.stateful.de
Re: /usr/share/doc/ files and gzip/xz/no compression
On Mon, Aug 15, 2011 at 11:59:07PM +0200, Andreas Barth wrote: > * Lars Wirzenius (l...@liw.fi) [110815 23:27]: > > On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote: > > > * Lars Wirzenius [2011-08-15 18:33 +0100]: > > > > raw gz xz > > > > 584163 134 file sizes (MiB) > > > >0421 450 savings compared to raw (MiB) > > > > -421 0 29 savings compared to current gz (MiB) > > > In other words, it's 130 MiB against xz's 134 MiB. I'll leave it to > > others to decide if it's a significatn difference. > > bzip2 is definitly a more conservative choice than xz. If it's > smaller, than it's superior to xz. AFAIK, bzip2 has much worse decompression performance than xz: I have taken dpkg's changelog, concatenated it to itself 10 times (11MB size), and: gzip: 0.377s, down to 2.7MB gunzip: 0.077s bzip2: 1.45s, down to 1.8M bunzip2: 0.420s xz: 4.4s(!), down to 204K(!) xz -d: 0.035s So here bzip is an order of magnitude slower at decompression. I've repeated the test on uncompressible data (/dev/urandom), 10MB, and the numbers are even worse for bzip2: gzip: 0.410s / 0.060s bzip2: 2.400s / 0.960s xz:4.040s / 0.027s So while xz is costly for compression, it's faster than even gzip for decompression. bzip2's cost for decompresion (huge!) is what kept me personally from using it seriously before xz appeared. There is also information on Wikipedia about various compression benchmarks, but IMHO if we want to switch from gzip then bzip2 doesn't make sense for /usr/share/doc. regards, iustin signature.asc Description: Digital signature
Re: /usr/share/doc/ files and gzip/xz/no compression
* Lars Wirzenius (l...@liw.fi) [110815 23:27]: > On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote: > > * Lars Wirzenius [2011-08-15 18:33 +0100]: > > > raw gz xz > > > 584163 134 file sizes (MiB) > > >0421 450 savings compared to raw (MiB) > > > -421 0 29 savings compared to current gz (MiB) > In other words, it's 130 MiB against xz's 134 MiB. I'll leave it to > others to decide if it's a significatn difference. bzip2 is definitly a more conservative choice than xz. If it's smaller, than it's superior to xz. 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/20110815215907.gd15...@mails.so.argh.org
Re: /usr/share/doc/ files and gzip/xz/no compression
On Mon, Aug 15, 2011 at 11:04:51PM +0200, Carsten Hey wrote: > * Lars Wirzenius [2011-08-15 18:33 +0100]: > > raw gz xz > > 584163 134 file sizes (MiB) > >0421 450 savings compared to raw (MiB) > > -421 0 29 savings compared to current gz (MiB) > > Years ago I compared sizes of compressed files in /usr/share/doc using > different compression methods too, possibly restricting to specific file > types (for example changelog and copyright). > > > I'm OK with allowing use of xz for compressing the files. > > IIRC bzip2 had a better compression. Compressing dpkg's changelog on Adding bzip2 support to my script and re-running gives me Total size of *.gz files in /usr/share/doc converted into *.bz2: 135179633 In other words, it's 130 MiB against xz's 134 MiB. I'll leave it to others to decide if it's a significatn difference. -- Freedom-based blog/wiki/web hosting: http://www.branchable.com/ -- 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/20110815212515.ga24...@havelock.liw.fi
Re: /usr/share/doc/ files and gzip/xz/no compression
* Lars Wirzenius [2011-08-15 18:33 +0100]: > raw gz xz > 584163 134 file sizes (MiB) >0421 450 savings compared to raw (MiB) > -421 0 29 savings compared to current gz (MiB) Years ago I compared sizes of compressed files in /usr/share/doc using different compression methods too, possibly restricting to specific file types (for example changelog and copyright). > I'm OK with allowing use of xz for compressing the files. IIRC bzip2 had a better compression. Compressing dpkg's changelog on stable seems confirm this: $ zcat /usr/share/doc/dpkg/changelog.gz | bzip2 | wc -c 145586 $ zcat /usr/share/doc/dpkg/changelog.gz | xz | wc -c 167844 Regards Carsten -- 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/20110815210451.ga25...@furrball.stateful.de
Re: /usr/share/doc/ files and gzip/xz/no compression
On 15/08/11 at 19:41 +0200, Andreas Barth wrote: > * Lars Wirzenius (l...@liw.fi) [110815 19:36]: > > 584163 134 file sizes (MiB) > > Thanks for comparing these numbers. That tells me that at least in the > average case we just can continue with gz, and not care much about the > relativly small difference to xz. I wouldn't call -20% a relatively small difference. The question is: are there downsides to switching to xz for /usr/share/doc? For example, in the past, some PDF readers could not directly open .pdf.gz files, so one had to uncompress the file manually first, which was pretty annoying. I just checked, and evince, okular and xpdf can open .pdf.xz files. But maybe other tools have similar issues. - Lucas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815191525.ga1...@xanadu.blop.info
Re: /usr/share/doc/ files and gzip/xz/no compression
* Lars Wirzenius (l...@liw.fi) [110815 19:36]: > 584163 134 file sizes (MiB) Thanks for comparing these numbers. That tells me that at least in the average case we just can continue with gz, and not care much about the relativly small difference to xz. 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/20110815174146.gc15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Joey Hess (jo...@debian.org) [110815 18:32]: > Andreas Barth wrote: > > Also, the binary packages in the debian/control template could have > > Build-Depends specified which means that they should only be built if > > those packages are actually installed (so we could do an automated > > graph analyis, and also dh and cdbs could just drop them, so that > > debian/rules doesn't need to reflect the dependencies) > > So there would need to be an interface in dpkg to get a list of binary > packages to build. In order for this not to make debhelper slow, it > would need to be a startlingly fast interface, for something that needs > to read the status file. :/ Or DEB_BUILD_OPTIONS could have something set > for this case and the status file lookup avoided in the general case. I'd rather consider the second case - accept a slower debhelper on partial builds. > debhelper would need to disable dh_install --fail-missing in this case > too. Happily dh_movefiles is not used by default, as if some packages > are not built, this could result in files that were normally > put in those packages instead being moved into another package. Ok - we should add that to "if the maintainer enables this mechanismn, he needs to make sure that ..." (and in lots of cases, that's not an issue). Does that sound ok? > > To mark such packages and to be able to decide when to re-schedule the > > build, all binary-packages get the additional header > > Build-Depends: minmal package_version > > Is "package_version " supposed to be a list of the packages and > versions used in the minimal build? Yes. We basically have a list of such packages anyways within the buildd log these days, but adding it here wouldn't hurt. 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/20110815173754.gb15...@mails.so.argh.org
Re: Introduction of a "lock" group
On Mon, Aug 15, 2011 at 06:00:50PM +0100, Roger Leigh wrote: > On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote: > > On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: > > > Are these any other downsides we need to consider? One issue is the > > > existence of badly broken programs³, which make stupid assumptions > > > about lockfiles. > > > > What about programs that need to write lock files which are already > > setgid something else? I don't have an example off the top of my head, > > but it would surprise me if there were none of these. > > IIRC Fedora have a setgid lock locking helper for this, which lockdev > uses internally. I'd need to check the details on a Fedora VM. IIRC > it checks if you have write perms on the device being locked, and so > individual programs don't need to be setgid lock unless they are not > using liblockdev. The use of an external helper means this is significantly slower than an open(…, O_CREAT) + flock(). While this works for some workloads, it doesn't for all. As my other question was: /var/lock (or /run/lock) was a good solution for transient, "cheap" locks for coordination between some cooperative programs. It would be ideal if we have a recipe for this after the permissions change. thanks, iustin signature.asc Description: Digital signature
/usr/share/doc/ files and gzip/xz/no compression
On Mon, Aug 15, 2011 at 05:16:55PM +0900, Charles Plessy wrote:
> Le Mon, Aug 15, 2011 at 01:48:50AM +0200, Adam Borowski a écrit :
> >
> > * A year ago, I repacked CD1, .xz took 66% space needed by .gz. This time,
> > on the whole archive, gains are somewhat smaller: 72%. I guess that CD1
> > is code-heavy while packages of lower priorities tend to have more data.
>
> Also, many files in /usr/share/doc are gzipped as per §12.3; that can prevent
> to get the full benefit of xz compression. In some of my packages containing
> mostly such files, the benefit of switching to xz is almost null. I wonder if
> it still makes sense to compress these files by default:
>
> - Most systems have enough space to keep them uncompressed,
> - others systems just do not install these files,
> - some filesystems are compressed on the fly,
> - the binary packages themselves are compressed.
On the other hand, many computers now have an SSD drive, for speed,
which is relatively small. Further, most users will likely need files in
/usr/share/doc rarely, if ever, so not compressing things risks wasting
a bunch of disk space for no particular benefit.
To get some actual numbers, I wrote the attached script. On my laptop
running squeeze, it reports:
Total size of *.gz files in /usr/share/doc: 170542915
Total size of uncompressed *.gz files in /usr/share/doc: 611945610
Total size of *.gz files in /usr/share/doc converted into *.xz: 140588208
That indicates that compressing documentation with xz instead of gz
does not save a whole lot (but does save some), but not compressing at
all wastes a lot. Putting the numbers into a table for easier comparison:
raw gz xz
584163 134 file sizes (MiB)
0421 450 savings compared to raw (MiB)
-421 0 29 savings compared to current gz (MiB)
So I would definitely vote for continuing to compress files in
/usr/share/doc. (Note that these numbers cover only files that are
currently *.gz, not all files in /usr/share/doc. See script for
details.)
I'm OK with allowing use of xz for compressing the files.
--
Freedom-based blog/wiki/web hosting: http://www.branchable.com/
#!/bin/sh
set -e
gzsum=$(find /usr/share/doc -type f -name '*.gz' -printf '%s\n' |
awk '{ s += $1 } END { print s }')
echo "Total size of *.gz files in /usr/share/doc: $gzsum"
rawsum=$(find /usr/share/doc -type f -name '*.gz' -exec zcat '{}' + | wc -c)
echo "Total size of uncompressed *.gz files in /usr/share/doc: $rawsum"
xzsum=$(find /usr/share/doc -type f -name '*.gz' -print0 |
xargs -0n1 -I'{}' -- sh -c 'zcat {} | xz | wc -c' |
awk '{ s += $1 } END { print s }')
echo "Total size of *.gz files in /usr/share/doc converted into *.xz: $xzsum"
Re: Introduction of a "lock" group
On Mon, Aug 15, 2011 at 05:35:54PM +0100, Colin Watson wrote: > On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: > > Fedora has moved to having /var/lock (now /run/lock) owned by > > root:lock 0775 rather than root:root 01777. This has the advantage > > of making a system directory writable only by root or setgid lock > > programs, rather than the whole world. However, due to the > > potential for privilege escalation¹² it may be desirable to adopt > > what has been done subsequently in Fedora: > > /var/lock root:root 0755 > > /var/lock/lockdev root:lock 0775 > > /var/lock/subsys root:root 0755 > > > > This mail is to discuss these issues: > > > > 1) Addition of a "lock" group as a system group > > > >This is a trivial change but requires approval. > > Would such a system group need to be statically allocated, or could it > be dynamically allocated? (Generally the latter is better if possible, > of course - I haven't had to add a global static group for years, and I > like it that way - but one might wish to consider things like bind > mounts of /run/lock into chroots, which would no longer be > NSS-agnostic.) I was initially thinking that static would be the best approach. But if the general consensus is that /var/lock/lockdev etc. aren't going to be around in the long term, then dynamic would be better-- we can then switch lockdev and other UUCP-style lock users to direct locking and remove it. There is compatibility with ancient UUCP software to consider though, but how important is that? They have had years to switch to using liblockdev. > > Are these any other downsides we need to consider? One issue is the > > existence of badly broken programs³, which make stupid assumptions > > about lockfiles. > > What about programs that need to write lock files which are already > setgid something else? I don't have an example off the top of my head, > but it would surprise me if there were none of these. IIRC Fedora have a setgid lock locking helper for this, which lockdev uses internally. I'd need to check the details on a Fedora VM. IIRC it checks if you have write perms on the device being locked, and so individual programs don't need to be setgid lock unless they are not using liblockdev. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Introduction of a "lock" group
On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: > Fedora has moved to having /var/lock (now /run/lock) owned by > root:lock 0775 rather than root:root 01777. This has the advantage > of making a system directory writable only by root or setgid lock > programs, rather than the whole world. However, due to the > potential for privilege escalation¹² it may be desirable to adopt > what has been done subsequently in Fedora: > /var/lock root:root 0755 > /var/lock/lockdev root:lock 0775 > /var/lock/subsys root:root 0755 > > This mail is to discuss these issues: > > 1) Addition of a "lock" group as a system group > >This is a trivial change but requires approval. Would such a system group need to be statically allocated, or could it be dynamically allocated? (Generally the latter is better if possible, of course - I haven't had to add a global static group for years, and I like it that way - but one might wish to consider things like bind mounts of /run/lock into chroots, which would no longer be NSS-agnostic.) > Are these any other downsides we need to consider? One issue is the > existence of badly broken programs³, which make stupid assumptions > about lockfiles. What about programs that need to write lock files which are already setgid something else? I don't have an example off the top of my head, but it would surprise me if there were none of these. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110815163554.ga3...@riva.dynamic.greenend.org.uk
Re: Introducing Build-Recommends / Build-Core-Depends?
Andreas Barth wrote: > Also, the binary packages in the debian/control template could have > Build-Depends specified which means that they should only be built if > those packages are actually installed (so we could do an automated > graph analyis, and also dh and cdbs could just drop them, so that > debian/rules doesn't need to reflect the dependencies) So there would need to be an interface in dpkg to get a list of binary packages to build. In order for this not to make debhelper slow, it would need to be a startlingly fast interface, for something that needs to read the status file. :/ Or DEB_BUILD_OPTIONS could have something set for this case and the status file lookup avoided in the general case. debhelper would need to disable dh_install --fail-missing in this case too. Happily dh_movefiles is not used by default, as if some packages are not built, this could result in files that were normally put in those packages instead being moved into another package. I don't think other parts of debhelper have problems if some binary packages are skipped. > To mark such packages and to be able to decide when to re-schedule the > build, all binary-packages get the additional header > Build-Depends: minmal package_version Is "package_version " supposed to be a list of the packages and versions used in the minimal build? -- see shy jo signature.asc Description: Digital signature
Re: Introduction of a "lock" group
On Mon, Aug 15, 2011 at 06:03:59PM +0200, Iustin Pop wrote: > On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: > > Hi folks, > > > > Fedora has moved to having /var/lock (now /run/lock) owned by > > root:lock 0775 rather than root:root 01777. This has the advantage > > of making a system directory writable only by root or setgid lock > > programs, rather than the whole world. However, due to the > > potential for privilege escalation¹² it may be desirable to adopt > > what has been done subsequently in Fedora: > > /var/lock root:root 0755 > > /var/lock/lockdev root:lock 0775 > > /var/lock/subsys root:root 0755 > > If /var/lock won't be 1777 anymore, where should then applications store > application-specific lock files (e.g. synchronisation between daemons) > if they can't/won't run as setgid lock? > > Is the intention that the init script creates a /var/lock/$NAME > directory, chgrp's it to the right GIDs and only then start the daemons? I'll have to inspect what Fedora is doing more closely to give you a definitive answer. If you always start the daemon as root, it can continue to use /var/lock without trouble if it does its file handling before changing to a less privileged user. Creating a daemon-specific subdirectory is also fine, though you could nowadays also use /run/ for daemon- specific things, including locks. Or even /var/lib/ if they should persist. In some respects, /var/lock is a bit of an anachronism; /var/run exists for pidfiles, and actual UUCP-style lockfiles are badly broken--we should be moving to direct device locks. If it's a daemon-specific lock, rather than one with system-wide effects such as device locking, it probably doesn't belong under /var/lock. If we eliminate device locking using lockfiles, what's left to go under /var/lock? [I don't always agree with Lennart Poettering, but his views on /var/lock and device lockfiles being obsolete are, I think, entirely correct.] Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Introduction of a "lock" group
On Mon, Aug 15, 2011 at 04:11:49PM +0100, Roger Leigh wrote: > Hi folks, > > Fedora has moved to having /var/lock (now /run/lock) owned by > root:lock 0775 rather than root:root 01777. This has the advantage > of making a system directory writable only by root or setgid lock > programs, rather than the whole world. However, due to the > potential for privilege escalation¹² it may be desirable to adopt > what has been done subsequently in Fedora: > /var/lock root:root 0755 > /var/lock/lockdev root:lock 0775 > /var/lock/subsys root:root 0755 Hi, If /var/lock won't be 1777 anymore, where should then applications store application-specific lock files (e.g. synchronisation between daemons) if they can't/won't run as setgid lock? Is the intention that the init script creates a /var/lock/$NAME directory, chgrp's it to the right GIDs and only then start the daemons? thanks, iustin signature.asc Description: Digital signature
Re: Introduction of a "lock" group
* Roger Leigh (rle...@codelibre.net) [110815 17:12]: > Are these any other downsides we need to consider? One issue is the > existence of badly broken programs³, which make stupid assumptions > about lockfiles. This will break all existing programms on an partial upgrades. There are three ways to deal with it: 1. Don't adjust permissions on existing systems 2. Add Breaks to all relevant programs 3. Adjust permissions on existing systems one release later 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/20110815153144.ga15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
On Mon, Aug 15, 2011 at 13:42:20 +0200, Andreas Barth wrote: > I'm not sure I could speak about "cases", but an obvious use case > aside from bootstrapping is backporting, where I could just drop off > dependencies I'm not going to use instead of looking at the code and > figuring out if it's easier to backport yet another library or change > the code. Just because I know that removing dependencies not in > Build-Core-Depends will just work. > You don't actually know that, unless you're suggesting we expand our support matrix by a few orders of magnitude to support any and all combinations of packages built with some random combination of their optional build-deps. "Works enough to get to the next stage of the bootstrap" isn't the same as "just works". Cheers, Julien -- 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/20110815152448.gy32...@radis.liafa.jussieu.fr
Bug#637892: ITP: python-formalchemy -- auto-generation and customizable form
Package: wnpp Severity: wishlist Owner: XuZhiXiang I'm a new packager in debian, and I wanna make this package * Package name: python-formalchemy Version : 1.4.1 Upstream Author : Alexandre Conrad, Jonathan Ellis, Gaël Pasgrimaud * URL : http://docs.formalchemy.org/ * License : MIT Programming Lang: Python Description : auto-generation and customizable form FormAlchemy greatly speeds development with SQLAlchemy mapped classes (models) in a HTML forms environment. It also provides support for CouchDB and a Pylons administration interface. FormAlchemy eliminates boilerplate by autogenerating HTML input fields >From a given model. FormAlchemy will try to figure out what kind of HTML code should be returned by introspecting the model's properties and generate ready-to-use HTML code that will fit the developer's application. Of course, FormAlchemy can't figure out everything, i.e, the developer might want to display only a few columns from the given model. Thus, FormAlchemy is also highly customizable. By the way, this package seems in requested packages list. here is the bug. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526936 As a new maintainer, I'm not so sure what need to do next, any help will be appreciated. -- 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/20110815152246.23352.8141.report...@debox.lan
Introduction of a "lock" group
Hi folks, Fedora has moved to having /var/lock (now /run/lock) owned by root:lock 0775 rather than root:root 01777. This has the advantage of making a system directory writable only by root or setgid lock programs, rather than the whole world. However, due to the potential for privilege escalation¹² it may be desirable to adopt what has been done subsequently in Fedora: /var/lock root:root 0755 /var/lock/lockdev root:lock 0775 /var/lock/subsys root:root 0755 This mail is to discuss these issues: 1) Addition of a "lock" group as a system group This is a trivial change but requires approval. 2) Alignment of /var/lock with Fedora This will require patching of lockdev (should already be in git). It would also require programs patching to use the new paths if not using lockdev. Are these any other downsides we need to consider? One issue is the existence of badly broken programs³, which make stupid assumptions about lockfiles. ¹http://lists.freedesktop.org/archives/systemd-devel/2011-April/001828.html ²https://bugzilla.redhat.com/show_bug.cgi?id=581884 ³http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637856 Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Bug#637887: ITP: pkg-printing-tools -- various packaging tools for the Debian Printing Team
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: pkg-printing-tools Version : 0.1 Upstream Author : Didier Raboud License : GPL-3+ Programming Lang: Perl, etc. Description : various packaging tools for the Debian Printing Team This native package will centralize much of the current duplication that exists trough the various printing-related packages. -- 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/20110815143614.7603.37723.reportbug@Tamino
Re: The archive now supports xz compression
Hi, I'm happy to hear xz support. Some font packages can get huge profit with this (e.g. fonts-vlgothic: 4924KB -> 2132KB (half! :) On Thu, 11 Aug 2011 19:52:46 + (UTC) Philipp Kern wrote: > It takes a lot longer to compress on slower architectures (i.e. on the > buildds), though. If there's a problem with slowness and CPU usage for some architecture, how about enabling xz compression with specifying architecture such as only all, i386 and amd64? i386 and amd64 have enough CPU power, and most of the users use those arch, so it's efficient. "all" has arch-independent data, compression would be done in i386 or amd64 on maintainers' desk, so no harm. If maintainer should decide to use xz compression or not, we should modify many debian/rules file to enable it. It's such a pain. - xz compression enable by default (no pain for package maintainers) - for limited arch - all, i386, amd64 (efficient) (or add kfreebsd-i386, kfreebsd-amd64, hurd-i386) -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- 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/20110815212256.a52100b5a48eb482504e2...@debian.or.jp
Re: mentors.debian.net: login problems
Excerpts from Jonathan Wiltshire's message of Mon Aug 15 06:54:21 -0400 2011: > On Mon, Aug 15, 2011 at 01:49:04PM +0300, Andrew O. Shadoura wrote: > > Since mentors.d.n was upgraded, I can't log in. Even if I reset my > > password, I can't log in with a temporary one. > > > > Any ideas what can it be? > > Please contact the service maintainers directly: > http://mentors.debian.net/contact Jonathan, thanks for sending Andrew to the right place. As it happens, the supp...@mentors.debian.net was bouncing due to a problem in the transition. I have fixed this, so that is now (and still) a good way to reach us. Andrew, I think that's an issue with the forgot password functionality. Christoph Haas was investigating, and so we should have a fix out within 1-2 days; sorry about the mess there. -- Asheesh. -- 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/1313412074-sup-3...@rose.makesad.us
Re: Introducing Build-Recommends / Build-Core-Depends?
* Carsten Hey (cars...@debian.org) [110815 14:36]: > * Andreas Barth [2011-08-15 13:46 +0200]: > > * Carsten Hey (cars...@debian.org) [110815 13:36]: > > > An optional "Build-Depends:" field per binary package as you described > > > is essentially the same as the following, with the notable difference, > > > that the below could appear as it is in the output of, i.e., apt-cache > > > showsrc without requiring maintainers of all those packages to invent > > > a new syntax just to enable users and developers to look up information. > > > > > > Build-Depends[foo-stage1]: debhelper > > > Build-Depends[foo-stage2]: debhelper, libx11-dev > > > Build-Depends: debhelper, libx11-dev, libgnome2-dev > > > > No, it's not. > > > > There is an really large difference: This here means the maintainer > > needs to write down by hand what the path to build the package is. > > There seems to be a misunderstanding, caused by choosing an unfortunate > example, here is an other one: > > Source: emacs23 > Build-Depends: gnome, kde, ncurses-dev > Build-Depends[emacs23-nox]: ncurses-dev That's just re-ordering the way the entries are specified. I don't mind either way, but I'd consider it more natural to have it at the binary packages. 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/20110815124054.gs2...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Andreas Barth [2011-08-15 13:46 +0200]: > * Carsten Hey (cars...@debian.org) [110815 13:36]: > > An optional "Build-Depends:" field per binary package as you described > > is essentially the same as the following, with the notable difference, > > that the below could appear as it is in the output of, i.e., apt-cache > > showsrc without requiring maintainers of all those packages to invent > > a new syntax just to enable users and developers to look up information. > > > > Build-Depends[foo-stage1]: debhelper > > Build-Depends[foo-stage2]: debhelper, libx11-dev > > Build-Depends: debhelper, libx11-dev, libgnome2-dev > > No, it's not. > > There is an really large difference: This here means the maintainer > needs to write down by hand what the path to build the package is. There seems to be a misunderstanding, caused by choosing an unfortunate example, here is an other one: Source: emacs23 Build-Depends: gnome, kde, ncurses-dev Build-Depends[emacs23-nox]: ncurses-dev If necessary, debhelper could ensure that the binary packages's dependencies are included in the Build-Depends line. apt-cache showsrc emacs23 currently displays something similar to: Package: emacs23 Binary: emacs, emacs23-lucid, emacs23-nox, emacs23, ... ... Build-Depends: gnome, kde, ncurses-dev ... If per-package build dependencies are added, it could look like this with my proposal: Package: emacs23 ... Build-Depends: gnome, kde, ncurses-dev Build-Depends[emacs23-nox]: ncurses-dev ... With your proposal it would either miss information, invent yet an other syntax, or use multiple fields per source package with the same name but a different semantic: Package: emacs23 ... Build-Depends: gnome, kde, ncurses-dev Build-Depends: ncurses-dev ... Regards Carsten -- 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/20110815123553.gc14...@furrball.stateful.de
Re: Introducing Build-Recommends / Build-Core-Depends?
* Carsten Hey (cars...@debian.org) [110815 13:36]: > An optional "Build-Depends:" field per binary package as you described > is essentially the same as the following, with the notable difference, > that the below could appear as it is in the output of, i.e., apt-cache > showsrc without requiring maintainers of all those packages to invent > a new syntax just to enable users and developers to look up information. > > Build-Depends[foo-stage1]: debhelper > Build-Depends[foo-stage2]: debhelper, libx11-dev > Build-Depends: debhelper, libx11-dev, libgnome2-dev No, it's not. There is an really large difference: This here means the maintainer needs to write down by hand what the path to build the package is. My proposal just documents dependencies, and let the rest to be done by graph checkers. That means way more documented. That is the core difference. It does only by hand what needs to be done by hand, and writing up the path bit by bit isn't. 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/20110815114621.gz15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Steve McIntyre [2011-08-15 11:12 +0100]: > Andreas Barth wrote: > >Generic options are usually better IMHO, but well - YMMV. > > Often, yes. But also often at extra cost. Where is the added benefit > here - i.e. what are the use cases? I'm 100% behind making the > bootstrap phase more simple, but I can't see many others... Backporting a subset of the binary packages in a source package is one, e.g., I might want to run the latest emacs23-nox on a server, but not emacs23. Regards Carsten -- 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/20110815114258.gb14...@furrball.stateful.de
Re: Introducing Build-Recommends / Build-Core-Depends?
* Steve McIntyre (st...@einval.com) [110815 12:30]: > Andreas Barth wrote: > >Generic options are usually better IMHO, but well - YMMV. > > Often, yes. But also often at extra cost. No doubt about that. > Where is the added benefit > here - i.e. what are the use cases? I'm not sure I could speak about "cases", but an obvious use case aside from bootstrapping is backporting, where I could just drop off dependencies I'm not going to use instead of looking at the code and figuring out if it's easier to backport yet another library or change the code. Just because I know that removing dependencies not in Build-Core-Depends will just work. > Also, "Build-Recommends" is an atrocious name. :-) "Names are only names" ;) 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/20110815114220.gy15...@mails.so.argh.org
Re: use flags? (was: Re: Introducing Build-Recommends / Build-Core-Depends?)
* Steve McIntyre (st...@einval.com) [110815 12:27]: > Eugene V. Lyubimkin wrote: > >Source: fbreader > >Build-Depends-Core: debhelper (>= 7), libbz2-dev > >Build-Depends-Qt3: libqt3-mt-dev > >Build-Depends-Qt4: libqt4-dev > >Build-Depends-Gtk2: libgtk2.0-dev > I can see this turning into a large mess. What's the benefit for > Debian for all the extra work here? If you want massively differing > builds on every machine, Gentoo exists already... Ack. 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/20110815113943.gx15...@mails.so.argh.org
Re: Introducing Build-Recommends / Build-Core-Depends?
* Andreas Barth [2011-08-13 13:28 +0200]: > Also, the binary packages in the debian/control template could have > Build-Depends specified which means that they should only be built if > those packages are actually installed ... An optional "Build-Depends:" field per binary package as you described is essentially the same as the following, with the notable difference, that the below could appear as it is in the output of, i.e., apt-cache showsrc without requiring maintainers of all those packages to invent a new syntax just to enable users and developers to look up information. Build-Depends[foo-stage1]: debhelper Build-Depends[foo-stage2]: debhelper, libx11-dev Build-Depends: debhelper, libx11-dev, libgnome2-dev > Building with core Dependencies only > > If doing an build of the core functionality only, norecommends is > added to the environment DEB_BUILD_OPTIONS. How do I build foo-stage1, but not foo-stage2? With a binary option like the above, it does not seem to be possible, unless dpkg-buildpackage decides based on the installed packages which packages it builds. Doing so might require using equivs if in early bootstrapping stages a part of the build dependencies is manually compiled instead of installed via dpkg, and it might waste time if dpkg-buildpackage decides to build a large binary package that is not needed yet. The most obvious ways to specify which packages should be build seem to be mybikeisred=[foo-stage1,...] added to the environment DEB_BUILD_OPTIONS or a new optional environment variable DEB_BUILD_PACKAGES which would contains a comma separated list of to be built packages and an additional make target binary-pkg-foo-stage1 in debian/rules. To prevent building packages needed for bootstrapping only by default, a new field in the source package's paragraph of the control file could be used, e.g., "NotBuiltByDefault: foo-stage1, foo-stage2". Not adding such a field to the binary package's paragraph instead has the same reason as described at the beginning of my mail. Regards Carsten -- 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/20110815113559.ga14...@furrball.stateful.de
Re: mentors.debian.net: login problems
On Mon, Aug 15, 2011 at 01:49:04PM +0300, Andrew O. Shadoura wrote: > Since mentors.d.n was upgraded, I can't log in. Even if I reset my > password, I can't log in with a temporary one. > > Any ideas what can it be? Please contact the service maintainers directly: http://mentors.debian.net/contact -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -- 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/20110815105421.gg25...@lupin.home.powdarrmonkey.net
mentors.debian.net: login problems
Hello, Since mentors.d.n was upgraded, I can't log in. Even if I reset my password, I can't log in with a temporary one. Any ideas what can it be? -- WBR, Andrew signature.asc Description: PGP signature
Re: Introducing Build-Recommends / Build-Core-Depends?
Andreas Barth wrote: >* Colin Watson (cjwat...@debian.org) [110813 15:27]: >> On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote: >> > During bootstraping a new architecture, there are sometimes ugly >> > build-dependency-loops (usually involving generating documentation >> > for the core build utilities means you need to have the architecture >> > already available; same with graphical tools). During DebConf, Wookey >> > had a talk which lead to us discussing some ideas how to support that. >> > Most packages are not affected at all by that, and current behaviour >> > isn't changing as long as package source files are not changed. >> >> Wookey's proposal was to have Build-Depends-Stage1 (etc. - I may have >> misspelled this slightly), and for a bootstrap-aware autobuilder to >> build its way through each of the stages until it reaches the real >> Build-Depends. I personally prefer this approach because it makes it >> clearer that the final build-depends is what we really want to reach, >> and that binaries uploaded to the real Debian archive still need to have >> all those build-dependencies in place. > >Wookeys proposal is less generic and more centric to bootstrapping. >Which has its advantages, and its disadvantages. > >I'm not saying that this proposal is better. It is different, and has >a different set of advantages. Plusside is that it's more generic, so >you could do more with debian/control fields, debhelper and cdbs, and >less with specific additions to debian/rules. > >Generic options are usually better IMHO, but well - YMMV. Often, yes. But also often at extra cost. Where is the added benefit here - i.e. what are the use cases? I'm 100% behind making the bootstrap phase more simple, but I can't see many others... Also, "Build-Recommends" is an atrocious name. :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead -- 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/e1qsu9s-0001w7...@mail.einval.com
Bug#637866: ITP: rastertosag-gdi -- printer driver for Ricoh Aficio SP1100s/SP1100
Package: wnpp Severity: wishlist Owner: Didier Raboud Package name: rastertosag-gdi Version : 0.1 Upstream Author : palz URL : http://www.openprinting.org/driver/rastertosag-gdi/ License : GPL Programming Lang: Python Description : printer driver for Ricoh Aficio SP1100s/SP1100 The rastertosag-gdi driver is an open source Linux driver for the Ricoh Aficio SP1100s/SP1100s printers. These are some of the few Ricoh printers which do not understand PostScript or PCL, but only a proprietary raster format. -- 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/20110815102217.8951.18994.reportbug@Tamino
Re: use flags? (was: Re: Introducing Build-Recommends / Build-Core-Depends?)
Eugene V. Lyubimkin wrote: > >If we accept the idea there's now more than one way to build the >package, I would like us do not limit the number of ways to '2' but >rather extend the prospoal to set up something similar to Gentoo's USE >flags. The advantages of that idea: > >- porters/buildds/local administrators will have the greater flexibility > to choose what the want to (re)build; >- for the architecture bootstrap this could be used for packages that > need to be rebuilt more than once with growing set of features > build-by-build (don't know if such packages exist). > >The disadvantage is obvious: harder to implement. > >I imagine it to look something like: > >Source: fbreader >Build-Depends-Core: debhelper (>= 7), libbz2-dev >Build-Depends-Qt3: libqt3-mt-dev >Build-Depends-Qt4: libqt4-dev >Build-Depends-Gtk2: libgtk2.0-dev > >Like in the original proposal, sets of build-depends are to be chosen by >DEB_BUILD_OPTIONS, for example DEB_BUILD_OPTIONS=use=gtk2,qt4. In >absence of 'use' flag (i.e. by default), all 'optional' packages are >built. And like in the original proposal, there's a header in the >resulting .changes (and possibly in something else) which determines what >was the value of the 'use' flag when building, like > >Built-With: gtk2,qt4. > >For the compatibility, dpkg-genchanges would combine all Build-Depends-* >to a single Build-Depends. I can see this turning into a large mess. What's the benefit for Debian for all the extra work here? If you want massively differing builds on every machine, Gentoo exists already... -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead -- 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/e1qsu6z-0001ot...@mail.einval.com
Re: The archive now supports xz compression
On Mon, Aug 15, 2011 at 11:25:42AM +0200, Luca Capello wrote: > What about zless & Co.? Are they available for xz as well? xz-utils contains xzless, xzcat etc. -- WBR, wRAR signature.asc Description: Digital signature
Bug#637862: ITP: mp3fs -- FUSE filesystem for transcoding FLAC to MP3 on the fly
Package: wnpp Severity: wishlist Owner: Alessio Treglia * Package name: mp3fs Version : 0.30 Upstream Author : Kristofer Henriksson * URL : http://mp3fs.sourceforge.net * License : GPL Programming Lang: C Description : FUSE filesystem for transcoding FLAC to MP3 on the fly MP3FS is a read-only FUSE filesystem which transcodes audio formats (currently FLAC) to MP3 on the fly when opened and read. . It is also a novel alternative to traditional MP3 encoder applications. Users can use their favorite file browser to select the files they want encoded and copy them somewhere. -- 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/20110815092537.4451.4395.reportbug@alessio-laptop
Re: The archive now supports xz compression
Hi there! On Mon, 15 Aug 2011 10:16:55 +0200, Charles Plessy wrote: > Also, many files in /usr/share/doc are gzipped as per §12.3; [...] > - Most systems have enough space to keep them uncompressed, Which alone is not a good reason to not compress them. > Perhaps we could consider allowing xz compression or no compression at all for > the files in /usr/share/doc, especially when they are all contained in a > dedicated package that is not dispensable. What about zless & Co.? Are they available for xz as well? Thx, bye, Gismo / Luca pgpRNIe0i86Gz.pgp Description: PGP signature
Re: The archive now supports xz compression
On Mon, Aug 15, 2011 at 06:38:28AM +0200, Tollef Fog Heen wrote: > ]] Adam Borowski > > | Does someone have an estimate how many core-hours would an archive rebuild > | on such a machine take? Folks on IRC quoted numbers like "340", "240 on a > | very fast box", "more like 1500" -- too divergent for my liking. The > | first number, 340, would mean switching to xz exclusively would increase > | average build time by ~5%. > > About 14 on a 2x6-core Intel Xeon X5650 (2.67GHz) (with HT), lots of > memory, fast disks. Ie, 250-300ish core-hours, sounds good. -- 1KB // Yo momma uses IPv4! -- 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/20110815091655.ga28...@angband.pl
Re: The archive now supports xz compression
Hi, 2011/8/15 Eduard Bloch : > #include > * Roger Leigh [Sun, Aug 14 2011, 11:01:11PM]: >> On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote: >> > On 11/08/11 at 19:52 +, Philipp Kern wrote: > >> > Wouldn't it be better to get more buildds for those archs, then? >> > That would be a totally appropriate use of Debian money... >> >> Possibly a stupid question here but: Given that we are now autosigning >> builds, why can't the slower arches use gzip, and then after upload >> they could be recompressed with xz (and resigned) on a faster arch? >> This would allow xz compression on all arches, but not require slow >> arches to actually do the xz compression themselves. > > Yeah, but if we got that far then we could easily create a remote > compressing service for such systems. Can be easily achieved by > configuring xz as service in inetd.conf and hacking dpkg-dev to run > something like "socket -q localRocketFastSystem" instead of xz on the > build machine. Maybe we don't have to hack dpkg-dev. Maybe could replace xz with netcat on slow build machines. Cheers, Balint -- 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/cak0odpwvrqkcvzfvys0sspnxqsiuu-kzrz5kjztoutoydaw...@mail.gmail.com
Re: The archive now supports xz compression
Le Mon, Aug 15, 2011 at 01:48:50AM +0200, Adam Borowski a écrit : > > * A year ago, I repacked CD1, .xz took 66% space needed by .gz. This time, > on the whole archive, gains are somewhat smaller: 72%. I guess that CD1 > is code-heavy while packages of lower priorities tend to have more data. Also, many files in /usr/share/doc are gzipped as per §12.3; that can prevent to get the full benefit of xz compression. In some of my packages containing mostly such files, the benefit of switching to xz is almost null. I wonder if it still makes sense to compress these files by default: - Most systems have enough space to keep them uncompressed, - others systems just do not install these files, - some filesystems are compressed on the fly, - the binary packages themselves are compressed. Perhaps we could consider allowing xz compression or no compression at all for the files in /usr/share/doc, especially when they are all contained in a dedicated package that is not dispensable. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med 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/20110815081655.gb2...@merveille.plessy.net
Re: Inactive maintainer for teamspeak packages
On Sat, Aug 13, 2011 at 10:27:08AM +0200, Stephan Windmüller wrote: > For more than a half year I am monitoring the state of the non-free > teamspeak packages. A new upstream version is available for more than a > year (bug #594318) and there is also a grave bug with an attached patch > (bug #598304). > > However, there has been no reply by the maintainer of the packages. All > bugs are unmodified for at least 300 days. I tried to contact him in > January but since then he did not reply. > > Does anyone know something about this maintainer or the states of these > packages? Just for your information: the MIA team is aware of the situation and trying to solve it. Getting the packages in better shape (by offering help, possibly NMUing) is appreciated. We're trying to find a nice way out long-term. By the way, you can contact the MIA team at m...@qa.debian.org if you have concerns about maintainers being inactive or unresponsive. Hints to improve archive quality and quality of life of overworked maintainers are always welcome. Hauke -- .''`. Jan Hauke Rahmwww.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Processed: Re: Bug#637805: general: can't mount a usb drive as a non-root user
Processing commands for cont...@bugs.debian.org: > reassign 637805 ntfs-3g Bug #637805 [general] general: can't mount a usb drive as a non-root user Bug reassigned from package 'general' to 'ntfs-3g'. > thanks Stopping processing here. Please contact me if you need assistance. -- 637805: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637805 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13133917823488.transcr...@bugs.debian.org
Bug#637805: general: can't mount a usb drive as a non-root user
reassign 637805 ntfs-3g thanks This either belongs to btfs-3gor some local problem that would make /dev/sdc* devices to not have the right permissions Reassigning. At least, please provide more information. Output from "ls -l /dev/sdc*" as well as "id" is imho the minimum. signature.asc Description: Digital signature
