e2dis: a Jigdo-like tool for Ext2+ FS images
BTW, I've just announced [1] the availability of the code which (given some attention and care) may be turned into a Jigdo-like suite for Ext2+ FS images. (The casuality of fragmentation on such filesystems greatly reduces the applicability of the FS-agnostic Jigdo tool.) Perhaps, this may lessen the burden of the distribution of Debian virtualization images. (Should it become a part of the current practice.) Alternatively, this tool may allow for “smarter” virtualization images' backups. Or, it may be used to save the bandwidth when sending a whole virtualization image, e. g., to demonstrate a hard to reproduce bug. [1] http://thread.gmane.org/gmane.comp.file-systems.ext4/27269 -- FSF associate member #7257 -- 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/86ei0o76wz@gray.siamics.net
Bug#637761: ITP: cavalry -- Mounts a web site.
Package: wnpp Severity: wishlist Owner: Misha Strong * Package name: cavalry Version : 1.0.14 Upstream Author : Nice Versa (Pty) Ltd. * URL : http://niceversa.dyndns.info/ * License : GPL Programming Lang: Pascal Description : Mounts a web site. Do you have an FTP server? Good. Now you can use it store all your personal files! Our program will use very little computer power. You can use it for: * Documents * CGI-scripts It could also provide a backup of your stuff: Jack: "Oh, my computer broke." John: "Why not just download your files?" It is designed for a 56K modem, but will operate also on wireless. -- 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/20110814083403.17879.73871.reportbug@mitty
Bug#637765: ITP: pcsc-cyberjack -- REINER SCT cyberJack USB chipcard reader user space driver
Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler
* Package name: pcsc-cyberjack
Version : 3.99.5final.SP02
Upstream Author : Matthias Bruestle, Harald Welte, Martin Preuss
(supp...@reiner-sct.com)
* URL : http://www.reiner-sct.de/
* License : LGPL 2.1+
Programming Lang: C
Description : REINER SCT cyberJack USB chipcard reader user space driver
Package: libifd-cyberjack6
Architecture: any
Depends: pcscd, ${misc:Depends}, ${shlibs:Depends}
Suggests: pcsc-tools
Recommends:
Description: REINER SCT cyberJack USB chipcard reader user space driver
This package includes the IFD driver for the cyberJack contactless
(RFID) and contact USB chipcard reader.
Package: fxcyberjack
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
Recommends: libifd-cyberjack6
Description: Graphical diagnostics and maintenance tool for Reiner SCT
Cyberjacks
This package contains the graphical tool which allows diagnosing
typical driver setup problems. It is also able to flash new software to
current cyberJack readers.
Suggestions for improvements of the descriptions are very welcome.
--
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/20110814084456.28637.10568.report...@faui43f.informatik.uni-erlangen.de
Re: e2dis: a Jigdo-like tool for Ext2+ FS images
On Sun, Aug 14, 2011 at 03:07:24PM +0700, Ivan Shmakov wrote: > BTW, I've just announced [1] the availability of the code which > (given some attention and care) may be turned into a Jigdo-like > suite for Ext2+ FS images. > > (The casuality of fragmentation on such filesystems greatly > reduces the applicability of the FS-agnostic Jigdo tool.) > > Perhaps, this may lessen the burden of the distribution of > Debian virtualization images. (Should it become a part of the > current practice.) > > Alternatively, this tool may allow for “smarter” virtualization > images' backups. Or, it may be used to save the bandwidth when > sending a whole virtualization image, e. g., to demonstrate a > hard to reproduce bug. > > [1] http://thread.gmane.org/gmane.comp.file-systems.ext4/27269 It seems to me that if you instead physically reordered blocks, actual data extents could be made contiguous, allowing use of standard Jigdo. (Of course, that might be not worth the extra effort...) -- 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/20110814101532.ga6...@angband.pl
Re: mentors.debian.net runs the debexpo code now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Ivan, On 13.08.2011 17:36, Ivan Shmakov wrote: > >> I wonder, is it possible to add a bit more magic to debexpo, so that > >> the comments made via the Web interface would be forwarded to the > >> list, and vice versa? ... > This task is indeed in my queue, but I won't probably be able to > get to it this year. I am also interested to implement a mailing list <-> Expo bridge as that's very important I think and necessary for future plans I have with Expo. I was doing some contributions to Expo already in the last few weeks, but I can't say when/if I find time to start such a larger sub-task. If you are interested to implement it, I would very welcome that, but we should coordinate our plans here. I am not sure if we really need a such a big dependency as a Gmane like service. Its probably enough to subscribe to debian-mentors (e.g. to a server side mbox) and track RFS threads by a non-standard header or magic subject / pseudo tag similar to the BTS control server. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOR7ECAAoJEMcrUe6dgPNtQUgP/RGPNlnozjTabO+FN4Z73x7v 4oIs8EVgGYUQcHqJ1EolWUFpHXxhQw6GkZNprqA9rHDGHbIDyDcArfC1i7Y+l9TR P43hDXeLUP/YW4JMieeoKogzb+VzKiLquZRj/Z1K8nseTKJpdiT9us1iUBttMRvB H8lhnNMM0qVChIABSA20qeYFXguETN/n0jli2n43l94SWHRPAZwbTaZ2JHiqldqU SVrdiRmCzFltPmqMGeRkMz9h2gPzJ3pGzXjq4kA6eAlKEsGMrQTrXnXOOHHAxfXi 1dK/no3TTENwIZIwEH79TfE9hw9XXZV4K2wd86Z4qT9iqFecUilytk6LyJFycH6J LPVZPs0ebUH4mOhUumCbwyq1WufxbGczpo3DHyBWU4+DL/6GvmF20gizPZI7fLon h7LM4wHsclvQWSlfcqflfv2nHt0ZTM1uxLD4COS/rfZ5ILjJU6OO3MDKhbB+zZkK idSKThryjhCVflYduIh766J3tjR92rk883l+9v5MKDN9jTXHa3rWVgytHsHYI+hu xhqtWCClbFGJN/C+n7VOnvPstPuyIyS9mwtO0FL8VEDboCY+uEeN+yTK1KwK16dp fLiXE2rlgqV20P7N12moki6det5949GihVvzNuefQxEi8BmA0qu6pegWOuAlD+P7 Ysg3C8VaE7QJvQJKCXhv =X6V7 -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/4e47b102.9040...@toell.net
Re: e2dis: a Jigdo-like tool for Ext2+ FS images
> Adam Borowski writes: > On Sun, Aug 14, 2011 at 03:07:24PM +0700, Ivan Shmakov wrote: >> BTW, I've just announced [1] the availability of the code which >> (given some attention and care) may be turned into a Jigdo-like >> suite for Ext2+ FS images. >> (The casuality of fragmentation on such filesystems greatly reduces >> the applicability of the FS-agnostic Jigdo tool.) > It seems to me that if you instead physically reordered blocks, > actual data extents could be made contiguous, allowing use of > standard Jigdo. Thanks for the suggestion. Unfortunately, the Jigdo's assumption of the continuity of the blocks comprising a file covers the reassembly phase just as well. The blocks of an image may still be reordered to get the desired effect, but they'd have to be reordered back at the time of reassembly, thus requiring a separate relation (file) to do so. Perhaps, the ordering of the blocks on a filesystem can be altered (consistent with the service data of the filesystem itself) to remove fragmentation, but I'm not sure on that, and my limited knowledge of the Ext2FS library doesn't allow me to devise a way to do that. (But I'd ask about it in linux-ext4@.) … On the other hand, the “chunk mapping” model I've used in the current version of the e2dis code is a superset of the model implemented by Jigdo. Therefore, I don't think it'd be infeasible to implement Jigdo support in the image download and reassembly tool I'm planning to develop for e2dis. (BTW, I've posted a very basic image reassembly tool to alt.sources about three weeks ago [2]. It's not compatible with the format used by e2dis, though.) [2] news:86zkk8xhh4@gray.siamics.net > (Of course, that might be not worth the extra effort...) Jigdo has to “discover” octet sequences on an image with hashing, which is computationally expensive. IIRC, Debian's genisoimage(1) was altered to prepare a Jigdo's .template file as part of the image generation, which is much more efficient. I believe that a similar approach could be, and should be, used for the other filesystems as well. […] >> [1] http://thread.gmane.org/gmane.comp.file-systems.ext4/27269 -- FSF associate member #7257 -- 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/86aabc6sf5@gray.siamics.net
Re: mentors.debian.net runs the debexpo code now
> Arno Töll writes: > On 13.08.2011 17:36, Ivan Shmakov wrote: I wonder, is it possible to add a bit more magic to debexpo, so that the comments made via the Web interface would be forwarded to the list, and vice versa? >> This task is indeed in my queue, but I won't probably be able to get >> to it this year. > I am also interested to implement a mailing list <-> Expo bridge as > that's very important I think and necessary for future plans I have > with Expo. I was doing some contributions to Expo already in the > last few weeks, but I can't say when/if I find time to start such a > larger sub-task. > If you are interested to implement it, I would very welcome that, but > we should coordinate our plans here. Indeed. However, as I've already noted, I won't be able to get to that task until at (the very) least the next year. > I am not sure if we really need a such a big dependency as a Gmane > like service. I've referenced Gmane as an example of the successful engine used for turning the (news, but mail is quite similar) messages into Web pages and RSS feeds. I don't know their code base all that close, but, IIRC, it's free software, and my opinion is that it'd be pity if we won't be able to reuse it, at least in part. > Its probably enough to subscribe to debian-mentors (e.g. to a server > side mbox) (Just don't use the Unix mbox format for that.) > and track RFS threads by a non-standard header or magic subject / > pseudo tag similar to the BTS control server. Why not the standard Message-Id:, In-Reply-To:, and References: headers? -- FSF associate member #7257 -- 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/8662m06s1o@gray.siamics.net
Bug#637805: general: can't mount a usb drive as a non-root user
Package: general Severity: normal Tags: lfs whan i plug a usb hard drive when logged as a non-root user, i have this error message: Error mounting: mount exited with exit code 1: helper failed with: Error opening '/dev/sdc1': Permission denied Failed to mount '/dev/sdc1': Permission denied Please check '/dev/sdc1' and the ntfs-3g binary permissions, and the mounting user ID. More explanation is provided at http://ntfs-3g.org/support.html#unprivileged the system seems to allow only root to mount the drive. when i try to mount the drive as root (in CLI:sudo mount /dev/sdc1 /media/mount_directory ) it works... -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- 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/20110814172657.2056.95771.reportbug@broussavane
Processed: tagging 637805
Processing commands for cont...@bugs.debian.org: > tags 637805 - lfs Bug #637805 [general] general: can't mount a usb drive as a non-root user Removed tag(s) lfs. > 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.131334751931336.transcr...@bugs.debian.org
Re: The archive now supports xz compression
On 11/08/11 at 19:52 +, Philipp Kern wrote: > On 2011-08-11, Adam Borowski wrote: > >> Think of both user systems and the Debian buildds which will waste more > >> time - an especially bad problem on slower architectures. > > The gain is especially meaningful for slower architectures, as they tend to > > have less disk space and slower network links (arm tends to be used in > > phones). No extra memory is needed -- decompression is not done in parallel > > with memory-hungry stages of dpkg's work. The decompression, merely 2.5 > > times slower than with gzip, is a tiny fraction of what dpkg takes. > > It takes a lot longer to compress on slower architectures (i.e. on the > buildds), though. You could've built a whole package in that time. > (Resorting > to your style of argument.) Wouldn't it be better to get more buildds for those archs, then? That would be a totally appropriate use of Debian money... Of course, it might require finding more buildd maintainers. But I must admit that I have no idea what buildd admins spend time on, and how it's possible to help them. For example, if we tried to have more identical buildds, instead of just one of each model, would it reduce the workload of buildd admins significantly? 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/20110814191902.ga3...@xanadu.blop.info
Re: The archive now supports xz compression
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote: > On 11/08/11 at 19:52 +, Philipp Kern wrote: > > On 2011-08-11, Adam Borowski wrote: > > >> Think of both user systems and the Debian buildds which will waste more > > >> time - an especially bad problem on slower architectures. > > > The gain is especially meaningful for slower architectures, as they tend > > > to > > > have less disk space and slower network links (arm tends to be used in > > > phones). No extra memory is needed -- decompression is not done in > > > parallel > > > with memory-hungry stages of dpkg's work. The decompression, merely 2.5 > > > times slower than with gzip, is a tiny fraction of what dpkg takes. > > It takes a lot longer to compress on slower architectures (i.e. on the > > buildds), though. You could've built a whole package in that time. > > (Resorting > > to your style of argument.) > Wouldn't it be better to get more buildds for those archs, then? > That would be a totally appropriate use of Debian money... > > Of course, it might require finding more buildd maintainers. But I must > admit that I have no idea what buildd admins spend time on, and how it's > possible to help them. For example, if we tried to have more identical > buildds, instead of just one of each model, would it reduce the workload > of buildd admins significantly? Replying more generally than the problem at hand, given that you did the same. :) The problem on those arches is finding stable buildds. We want boards that support more RAM that they normally do (e.g. on MIPS) or some with SATA disks and good throughput (e.g. on ARM). So you get to use development boards, which you can only get hosted by the company doing them (e.g. for ARM), or which are not stable unless heavily patched (because they normally use a custom kernel by the vendor, e.g. for MIPS). And then there are the boards which were just buggy CPU-wise (older Loongson ones). Andi Barth bought some, but it's unhelpful if you're able to crash them as a normal user due to a pipelining bug. The situation is getting better for those machines we have. DSA would like to run Debian kernels on them, but it seems to be hard. Hence you get to run some kernels with specific patchsets to be as near to a released kernel as possible, with some extensions to let the hardware run stable (or boot at all). Yes, there is a point where you don't want to add more buildds instead of getting faster ones. There's a bunch of locking in the wanna-build database, which used to be much worse, but which is still present in some way. There's the overhead of managing the machines for DSA. But the addition of four(?) additional builders hosted at ARM, which were identical, was great. Especially if they are all set up alike, you can just put up a clusterssh session to handle them. It's just that we now lack a bit of redundancy because all of them are hosted at the same location… Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#601596: RFH: festival -- General multi-lingual speech synthesis system
retitle 601596 O: festival -- General multi-lingual speech synthesis system thanks Dear Debian developers and contributors, (Apologies for the cross post) On Wed, Oct 27, 2010 at 12:46:36PM -0500, Kumar Appaiah wrote: > I request assistance with maintaining the festival (and speech-tools) > package. The package is in a "good" state as of now, but it does have > a TODO list and could do with some love. While I try to do my best > with festival, since I am not familiar with the various sound > subsystems the package seems to depend on, I would be much more > comfortable if someone else steps in to oversee, assist and, > eventually, take over maintenance of the package. > > If a team is willing to take over, or a team is formed for this package. > > This mail has been sent with permission from the other co-maintainers > as well. > > Thanks! > > The package description is: > Festival offers a full text to speech system with various APIs, as well an > environment for development and research of speech synthesis techniques. It > includes a Scheme-based command interpreter. > . > Besides research into speech synthesis, festival is useful as a stand-alone > speech synthesis program. It is capable of producing clearly understandable > speech from text. It has almost been 10 months since the RFA, and since filing it, neither have we been able to step up in maintaining the package better, nor did we receive any offers for help. Therefore, regretfully, we have decided to orphan festival (and, in a subsequent e-mail, speech-tools as well). Since festival is a fairly important package, it deserves more care and attention in keeping it up to date. So, it would be great if an individual or team could step up to fill the void. Needless to say, we would be glad to help out in the team as well as we can. xThanks. Jaldhar, Kartik and Kumar (erstwhile maintainers of festival and speech-tools) -- Kumar Appaiah signature.asc Description: Digital signature
Re: The archive now supports xz compression
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote: > Of course, it might require finding more buildd maintainers. But I must > admit that I have no idea what buildd admins spend time on, and how it's > possible to help them. "A life in the day of a buildd maintainer" would not be a bad continuation to the IRC Q&A sessions we've already had. -- 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/20110814215211.ga26...@havelock.liw.fi
Re: e2dis: a Jigdo-like tool for Ext2+ FS images
Ivan Shmakov wrote: > > Jigdo has to âdiscoverâ octet sequences on an image with > hashing, which is computationally expensive. Yes. > IIRC, Debian's genisoimage(1) was altered to prepare a Jigdo's > .template file as part of the image generation, which is much > more efficient. I believe that a similar approach could be, and > should be, used for the other filesystems as well. That would be absolutely the best way to go, yes. I added the code into mkisofs and genisoimage, but it has since been abstracted out into libjte, part of the cdrkit package in Debian. -- 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/e1qshvk-00057x...@mail.einval.com
Re: The archive now supports xz compression
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote: > On 11/08/11 at 19:52 +, Philipp Kern wrote: > > On 2011-08-11, Adam Borowski wrote: > > >> Think of both user systems and the Debian buildds which will waste more > > >> time - an especially bad problem on slower architectures. > > > The gain is especially meaningful for slower architectures, as they tend > > > to > > > have less disk space and slower network links (arm tends to be used in > > > phones). No extra memory is needed -- decompression is not done in > > > parallel > > > with memory-hungry stages of dpkg's work. The decompression, merely 2.5 > > > times slower than with gzip, is a tiny fraction of what dpkg takes. > > > > It takes a lot longer to compress on slower architectures (i.e. on the > > buildds), though. You could've built a whole package in that time. > > (Resorting > > to your style of argument.) > > 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. 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: Release Update: Goals, Arches, Rolling, Removals
* Luk Claes , 2011-08-13, 23:34: As noted in our previous mail [0DAY:DDA], bug #625449 has been opened against developers-reference. This now seems to be drawing itself to a conclusion. We would still welcome use of delayed queues where appropriate, but this also formalises the policy over the previous few years which allows DELAYED/0 for uploads fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress. If you decide to NMU without delay a package maintained by me[0], please don't bother doing it, but orphan the package instead. I won't be interested in maintaining such a package anymore. [0] That is, with the Maintainer field set to me. The conclusion in the bug was to do have a delay btw... so your comment does not make sense to me. Your comment doesn't make sense to me either. For the reference, this is the change that has been made to Developer's Reference: --- pkgs.dbk(revision 8901) +++ pkgs.dbk(revision 8902) @@ -1947,6 +1947,11 @@ +Upload fixing only release-critical bugs older than 7 days, with no maintainer activity on the bug for 7 days and no indication that a fix is in progress: 0 days + + + + Upload fixing only release-critical bugs older than 7 days: 2 days Are you trying to say that delay of 0 days is something substantially different than no delay? Or that the change is contrary to the bug conclusions and was done by mistake? -- Jakub Wilk -- 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/20110814223316.ga9...@jwilk.net
Re: Introducing Build-Recommends / Build-Core-Depends?
[Andreas Barth] > Introducing Build-Recommends / Build-Core-Depends > > We should be able to specify in the package saying "only these > build-dependencies are needed to get a functionally working package". > For such an build, the packages which are not needed for building > working core packages are annoted in an additional header (e.g. > Build-Recommends), but are still specified in Build-Depends to not > break the old tools. I think I really prefer the option of doing per-binary-package Build-Depends. The presence of a Build-Depends field for a specific binary package already implies that if you have those specific build-deps available, you can build at least that one package. I guess the way to bootstrap would be to hold the package until you have enough build-deps to build at least one binary package from it, then do so, with some way to tell dpkg-buildpackage to not abort if the source package level build-deps are not all available. Why is a separate field needed at the source package level? It is implied by the existence of at least one Build-Depends field at the binary package level. The only reason you'd need a separate field is if you're talking about building two different variants of a single _binary_ package. Is that really useful? It is sign at least in many cases that it may be useful to split the binary packages further. (And, come to think of it, for build deps like docbook processors, we already have Build-Depends-Indep. I wonder if we're using it everywhere we should be.) -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110814225455.ga7...@p12n.org
Re: The archive now supports xz compression
On Sun, Aug 14, 2011 at 09:19:02PM +0200, Lucas Nussbaum wrote: > On 11/08/11 at 19:52 +, Philipp Kern wrote: > > On 2011-08-11, Adam Borowski wrote: > > >> Think of both user systems and the Debian buildds which will waste more > > >> time - an especially bad problem on slower architectures. > > > The gain is especially meaningful for slower architectures, as they tend > > > to > > > have less disk space and slower network links (arm tends to be used in > > > phones). No extra memory is needed -- decompression is not done in > > > parallel > > > with memory-hungry stages of dpkg's work. The decompression, merely 2.5 > > > times slower than with gzip, is a tiny fraction of what dpkg takes. > > > > It takes a lot longer to compress on slower architectures (i.e. on the > > buildds), though. You could've built a whole package in that time. > > (Resorting > > to your style of argument.) > > Wouldn't it be better to get more buildds for those archs, then? > That would be a totally appropriate use of Debian money... While having more buildds is always nice, it doesn't seem to me that they would be necessary just to switch to xz. I gathered some data: * A repack of the whole archive (amd64+all main, ~40GB) took close to three hours on a 6xPhenomII 2.8GHz box (ar p|gzip/bzip2 -d|xz). 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%. * armel Cortex-A8 600MHz does xz consistently 12.1 times slower than one core of the above box (on a big compressible and a big uncompressible file), that's ~2.6 times slower per-MHz. Glancing at build logs of a few randomly chosen packages, I see armel builds taking respectively 16.9, 13.1, 18.8 and 15.1 times longer. Not sure what are the actual speeds of buildds, but it looks like armel would be affected by less than the above 5%. * 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. Raw data: http://angband.pl/tmp/rexz/gzip.gz and http://angband.pl/tmp/rexz/bzip2.gz (these numbers are data.tar.* alone) An empty package is bigger (180%: 36 vs 20 bytes). Packages with sizes <1000 bytes: 85%. Packages with sizes <1 bytes: 76%. * Compression time seems to be linear for all sizes that can be measured without tricks. * It is possible to repack .deb files after they are built. * Busybox (and thus d-i) can be compiled with xz support. Size-wise it's a clear gain (dpkg.deb saves 883008 bytes, apt.deb 751967 ...). This is the only place where the memory cost could possibly matter, though. * Other distributions that could run debootstrap have all since switched to xz[1], so it's mandatory there already. A possible concern would be deboostrapping from an outdated install of those. There seems to be a lot of confusion like "do we have any guideline for the sort of space savings which justify using xz?". The d-d-a post in particular seems to suggest only big packages should be switched; my data suggests that switching many small packages is not significantly different from switching a single big one. Thus, I'd say it'd be simpler to just switch everything. [1]. Among major ones, it seems only Gentoo ships non-xz images, but xz is included in their "system set" (our "essential"). -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Re: The archive now supports xz compression
On Sun, Aug 14, 2011 at 11:01:11PM +0100, Roger Leigh wrote: > 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. Not a bad idea. I don't believe it is necessary -- in the estimate I've written in this thread the cost is below 5% of average build time, but if you consider that 5% to be unacceptable, repacking would work. -- 1KB // Yo momma uses IPv4! signature.asc Description: Digital signature
Bug#637835: ITP: squeak-plugins-scratch -- Squeak plugins for the Scratch programming environment
Package: wnpp Severity: wishlist Owner: Miriam Ruiz * Package name: squeak-plugins-scratch Version : 1.4.0.2~svn.r80 Upstream Author : Scratch on Linux * URL : http://info.scratch.mit.edu/Scratch_on_Linux * License : MIT/X Programming Lang: C Description : Squeak plugins for the Scratch programming environment Scratch is an easy, interactive, collaborative programming environment designed for creation of interactive stories, animations, games, music, and art -- and sharing these on the web. . Scratch is designed to help young people (ages 8 and up) develop 21st century learning skills. As they create Scratch projects, young people learn important mathematical and computational ideas, while also gaining a deeper understanding of the process of design. . This package contains the plugins needed by Scratch and its derivatives This package might also be related to #471927 -- 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/20110814235411.30011.67807.reportbug@danu.local
Re: The archive now supports xz compression
Raphael Hertzog wrote: > Nope, sorry. I was referring to things like GNOME shipping only .tar.xz. > I mean they would not take such a decision if getting an xz decompressor > was a pain on many systems. There is a large distance between systems on which users are likely to build gnome from scratch (which involves installing many dependencies anyway), and systems on which users may want to run debootstrap. The latter can include embedded systems that don't have a compiler and are not of a common architecture, which makes xz difficult to install. It would be best if debootstrap's dependencies remained limited to things that are commonly enabled in busybox. -- see shy jo signature.asc Description: Digital signature
Re: The archive now supports xz compression
#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. Regards, Eduard. -- 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/20110815000109.ga11...@rotes76.wohnheim.uni-kl.de
Re: support for installing unconfigured systems (VM images, Debian Live images, preinstalled mobile/tablet images)
On Aug 14, Ben Hutchings wrote: > > Yes, because the upstream maintainers decided that the current scheme > > cannot work and will remove support for it. > > I do not know how long it will be feasible to keep it as a Debian patch. > It works today for many users. I don't see why it would stop working > for them. This was my objection as well, but it was not well received. > > > This is implemented in the biosdevname package, which I think we should > > I never bothered packaging it because AFAIK it is not needed with recent > > kernels (and recent hardware?). > The kernel will continue to generate names using the formats eth%d, > wlan%d etc. There needs some userland program to generate the new > device names, whether it's in the udev package or another package. Yes, with appropriate rules udev should be able to rename the interfaces without biosdevname. -- ciao, Marco -- 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/20110815000938.ga22...@bongo.bofh.it
Re: Bug#601596: RFH: festival -- General multi-lingual speech synthesis system
Would you found a TTS team? and invite all TTS packager to join it? -- YunQiang Su -- 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/CAKcpw6XUKSML+O-2a1Q+m1DoaLivBMY=jsmev8ittv716aw...@mail.gmail.com
Re: Bug#601596: RFH: festival -- General multi-lingual speech synthesis system
On Mon, Aug 15, 2011 at 09:33:50AM +0800, YunQiang Su wrote:
> Would you found a TTS team?
> and invite all TTS packager to join it?
This would be the ideal solution. I'd love it for people interested to
come forward in this effort.
Thanks!
Kumar
--
/*
* Oops. The kernel tried to access some bad page. We'll have to
* terminate things with extreme prejudice.
*/
die_if_kernel("Oops", regs, error_code);
-- From linux/arch/i386/mm/fault.c
--
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/20110815030313.ga21...@bluemoon.alumni.iitm.ac.in
Bug#637849: ITP: python-ordereddict -- Drop-in substitute for Python 2.7's collections.OrderedDict
Package: wnpp Severity: wishlist Owner: Janos Guljas * Package name: python-ordereddict Version : 1.1 Upstream Author : Raymond Hettinger * URL : http://pypi.python.org/pypi/ordereddict/ * License : MIT/X Programming Lang: Python Description : Drop-in substitute for Python 2.7's collections.OrderedDict Drop-in substitute for Python 2.7's new collections.OrderedDict. The recipe has big-oh performance that matches regular dictionaries (amortized O(1) insertion/deletion/lookup and O(n) iteration/repr/copy/equality_testing). -- 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/20110815035250.24353.69948.reportbug@mac
Recent upgrade problems
Hi there. I ran synaptic and it did the following (from /var/log/apt/history.log) Start-Date: 2011-08-15 03:06:42 Commandline: synaptic Install: xulrunner-5.0:amd64 (5.0-6, automatic), libmozjs5d:amd64 (5.0-6, automatic) Upgrade: python-coherence:amd64 (0.6.6.2-5, 0.6.6.2-6), openprinting-ppds:amd64 (20110617-1, 20110803-1), python-debian:amd64 (0.1.20, 0.1.21), uuid-runtime:amd64 (2.19.1-4, 2.19.1-5), libmount1:amd64 (2.19.1-4, 2.19.1-5), libblkid1:amd64 (2.19.1-4, 2.19.1-5), foomatic-db-engine:amd64 (4.0.7-2, 4.0.8-1), libmozjs-dev:amd64 (1.9.1.19-3, 5.0-6), util-linux:amd64 (2.19.1-4, 2.19.1-5), foomatic-filters:amd64 (4.0.7-1, 4.0.9-1), libcpufreq0:amd64 (007-1, 007-2), libfreetype6:amd64 (2.4.4-2, 2.4.6-1), libxfont1:amd64 (1.4.3-2, 1.4.4-1), iceweasel:amd64 (3.5.19-3, 5.0-6), cpufrequtils:amd64 (007-1, 007-2), bsdutils:amd64 (2.19.1-4, 2.19.1-5), libfreetype6-dev:amd64 (2.4.4-2, 2.4.6-1), libmx-1.0-2:amd64 (1.2.0-1, 1.3.0-1), uuid-dev:amd64 (2.19.1-4, 2.19.1-5), libuuid1:amd64 (2.19.1-4, 2.19.1-5), xpdf:amd64 (3.02-19, 3.02-21), foomatic-db:amd64 (20110617-1, 20110803-1), mount:amd64 (2.19.1-4, 2.19.1-5), xulrunner-dev:amd64 (1.9.1.19-3, 5.0-6), freetype2-demos:amd64 (2.4.4-2, 2.4.6-1) End-Date: 2011-08-15 03:09:25 Then I rebooted. I'm using KDE 3.5.12 (trinity). I tried the amarok play global shortcut, but it has stopped working (it worked before the reboot). I wanted to report a bug in iceweasel 5, to see if it could handle my html5 test page http://www.philipashmore.com/timeline/ It fails to comply with the mdc spec regarding adding options to a select group in JavaScript. https://developer.mozilla.org/en/DOM/HTMLSelectElement#add%28%29 I first tried reportbug but that crashed with a memory corruption issue. Also, while I'm at it, I can't open html links in iceweasel, but that's been true for a while. Sorry for dumping this mess in your laps. Regards, Philip -- 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/4e489ca3.8050...@philipashmore.com
Re: The archive now supports xz compression
]] 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. -- 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/87d3g7mgqj@qurzaw.varnish-software.com
Re: Introducing Build-Recommends / Build-Core-Depends?
On Sun, 14 Aug 2011 17:54:55 -0500 Peter Samuelson wrote: > [Andreas Barth] > > Introducing Build-Recommends / Build-Core-Depends > > > > We should be able to specify in the package saying "only these > > build-dependencies are needed to get a functionally working package". > > For such an build, the packages which are not needed for building > > working core packages are annoted in an additional header (e.g. > > Build-Recommends), but are still specified in Build-Depends to not > > break the old tools. > > I think I really prefer the option of doing per-binary-package > Build-Depends. That doesn't break build-dependency loops. The whole point is that when bootstrapping a new architecture, certain packages must be built in a restricted mode which is *not* uploaded to the main archive but which provides sufficient support to build the other side of the dependency loop. Packages are then rebuilt when all it's build-dependencies are ready. Please lookup the link provided by Andreas to Wookey's talk at DebConf11. > Why is a separate field needed at the source package level? Please read the original post in this thread again. This is not about how packages are split in the archive. This is not about per-binary. This is source:binary dependency loops when bootstrapping (or cross-building) and entire set of packages from scratch. > It is > implied by the existence of at least one Build-Depends field at the > binary package level. The only reason you'd need a separate field is > if you're talking about building two different variants of a single > _binary_ package. Is that really useful? The variant is installed locally so that the packages which depend on it can be built. Then the original package can be rebuilt when it's build dependencies exist, along with packages which were built against (or using) the "interim" version. This can all be done but it involves making manual changes in various packages to allow for the variant build. > It is sign at least in many > cases that it may be useful to split the binary packages further. > > (And, come to think of it, for build deps like docbook processors, > we already have Build-Depends-Indep. I wonder if we're using it > everywhere we should be.) It's not just about documentation - that could be handled by DEB_BUILD_OPTIONS="nodocs" as Build-Depends-Indep is the opposite. It's not about building just the architecture-independent bits, it's about building the architecture-dependent stuff when the build-dependencies have not yet been built. (Often because those build-dependencies themselves have runtime dependencies on the library which is being built - and therefore cannot be installed - and the library uses those binaries to as part of it's build. Classic dependency:build-dependency loop which makes bootstrapping impossible without changes in the package(s).) Source: libfoo Build-Depends: bar Package: libfoo3 Package: libfoo-bin Source: bar Package: bar Depends: libfoo-bin Other examples include poppler:cups:poppler:cups which doesn't involve documentation at all - see Wookey's talk at DebConf11 for all the gory detail. (Link in Andreas' original post.) -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp85vvhJ5bxt.pgp Description: PGP signature
