Bug#471585: ITP: passage -- life as a tiny videogame
Package: wnpp Severity: wishlist Owner: Debian Games Team <[EMAIL PROTECTED]> * Package name: passage Version : 3 Upstream Author : Jason Rohrer * URL : http://hcsoftware.sourceforge.net/passage/ * License : Public Domain Programming Lang: C++ Description : life as a tiny videogame Unsure about the long description, will need to somehow distill the game creators statement: http://hcsoftware.sourceforge.net/gravitation/statement.html I do know the word pixelated will be necessary. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#471584: ITP: gravitation -- a game about mania, melancholia, and the creative process
Package: wnpp Severity: wishlist Owner: Debian Games Team <[EMAIL PROTECTED]> * Package name: gravitation Version : 3 Upstream Author : Jason Rohrer * URL : http://hcsoftware.sourceforge.net/gravitation/ * License : Public Domain Programming Lang: C++ Description : a game about mania, melancholia, and the creative process Unsure about the long description, will need to somehow summarise the game creators statement: http://hcsoftware.sourceforge.net/gravitation/statement.html I do know the word pixelated will be necessary. -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#471583: ITP: codeigniter -- A powerful PHP framework with a very small footprint
Package: wnpp Severity: wishlist Owner: James Barrett <[EMAIL PROTECTED]> * Package name: codeigniter Version : 1.6.1 Upstream Author : [EMAIL PROTECTED] * URL : http://codeigniter.com/ * License : Other Programming Lang: PHP Description : A powerful PHP framework with a very small footprint CodeIgniter is built for PHP coders who need a simple and elegant toolkit to create full-featured web applications. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
Anthony Towns dijo [Tue, Mar 18, 2008 at 03:39:05PM +1000]: > (...) > and the real question is where you say "if you really want the 23rd CD > for mipsel, you're probably smart/dedicated enough to use jigdo". I completely agree with this. I don't think we must carry every CD for every arch forever! BTW... 30 CDs are too many CDs. Just too fucking many. We could also cut down on them - i.e. produce only the first 8 CDs per arch, and have the rest only as DVDs. Yes, many people still do not have DVD drives handy, but then again, 8 CDs + network access + a bit of patience for the most obscure bits of software should be enough for anybody... > The other thing we /could/ do is encourage people who've done successful > Debian installs to help contribute by participating in a torrent after > the fact -- you could do all sorts of things like have a FUSE filesystem > that takes a (partial) mirror and a jigdo file and lets you see fake iso > files, which you then seed via bittorrent, eg. You could automate that, > so it's just a question like the popcon one: "Do you wish to participate > as a torrent seed for other people installing Debian? Yes [No]" Ugh. Do you really want ISPs all over the world to start associating Debian with evil communist pirate P2P filesharers? > Hrm. In the real world, does jigdo actually saturate broadband bandwidth? > It's been a long time since I've tried it, but I vaguely remember it > not actually being very speedy. Ah, it was the "stop downloading, add > files to image" that used to slow things down, but seem less of an issue > now. The repeated wgets probably still aren't great for that matter, > since it serialises downloading and establishing connections. It does. I ran Jigdo for i386 DVD 1 some months ago for a person that requested it from me. We have ftp.mx.debian.org in our university network, and I have theoretically a 100Mbps link to it (really it's about 8Mbps, but who am I to complain?). It was a busy night for my router. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
Paul Cager dijo [Mon, Mar 17, 2008 at 12:29:04AM +]: > [...] > > 1. Is it worth making full sets of CDs at all? Can we rely on people > >having a net connection or being able to use DVDs if they want > >*everything*? > > 2. Is it worth producing all the CDs/DVDs/whatever for all the > >architectures? > > 3. For some arches, should we just provide the first couple of CDs > >and a full set of DVDs? This is a bit of a compromise option - if > >a given machine will not boot from DVD, but can boot from CD and > >get the rest of its packages from a network share then all's good. > > 4. ??? - what else would be a sane option? > > (I'd better disclose a conflict of interest - I sell Debian CDs and DVDs). > > I'd quite like there to be full sets for i386 and amd64. I think an > inexperienced user could find it quite discouraging to have to > install using a mapped drive. > > What about a modification of 3? For the less popular arches we > provide the first couple of CD images, but the other CDs are only > available as jigdo downloads. Does that make sense? You'd still > have to create every CD image, of course, but the mirrors would have > to carry much less data / traffic. Official mirrors only carry the individual .debs and the Jigdo description files :) So I think your proposal is dealt with. Of course, some people provide pre-cooked ISO files for download. /me throws question at the void: Would it be feasible to get something akin to an inverse-FUSE that presents ISO files in the presence of the individual debs and Jigdo files? Yes, it would probably be much more processor-intensive than just downloading a file, so I might be talking nonsense... -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#471443: ITP: gnome-hdaps-applet -- HDAPS system applet for GNOME 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/08 03:51, Adam Sloboda wrote: > Package: wnpp > Severity: wishlist > Owner: Adam Sloboda <[EMAIL PROTECTED]> > > > * Package name: gnome-hdaps-applet > Version : 20060120 > Upstream Author : Jon Escombe <[EMAIL PROTECTED]> > * URL : http://www.dresco.co.uk/hdaps/ > * License : GPL > Programming Lang: C > Description : HDAPS system applet for GNOME 2 > > This applet shows status of hard disk protection for ThinkPad laptops. Please add a definition of HDAPS to the long description. - -- Ron Johnson, Jr. Jefferson LA USA -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH4IBvS9HxQb37XmcRAhAtAKCrGSLIYTdgin6gVvuY06Et1VqIIACg1KgN VfKKrxR4EoBbHQGP+qq04/A= =FZea -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
source:Version and ancient dpkg-dev
According to the changelog, substvars source:Version is added in dpkg-dev 1.13.19. A package which uses source:Version in its debian/control and doesn't set its value explicitly can't be built with ancient dpkg-dev. The problem is that dpkg-dev in the build-essential list is dpkg-dev (>= 1.13.5), which is not new enough. I think the build-essential list should be updated. -- Oohara Yuuma <[EMAIL PROTECTED]> If we know when, can we do it right? --- TAITO "Ray Crisis" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471575: ITP: liblog-handler-perl -- A simple handler to log messages to a log file
Package: wnpp Severity: wishlist Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: liblog-handler-perl Version : 0.38 Upstream Author : Jonny Schulz <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Log-Handler/ * License : Perl Programming Lang: Perl Description : A simple handler to log messages to a log file This module is just a simple object oriented log file handler and very easy to use. It's possible to define a log level for your programs and control the amount of informations that will be logged to the log file. In addition it's possible to configure how you wish to open the log file - transient or permanent - and lock and unlock the log file by each write operation. If you wish you can assign the handler to check the inode of the log file (not on Windows). That could be very useful if a rotate mechanism moves and zip the log file. - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH4HGO5SXWIKfIlGQRAh9FAJ9kweJ6MJbTjkXNHC4xJdf3mq3vqQCfWe21 VQNGgf1HZCkk7/FxJCi9Wyo= =J8nF -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471574: ITP: libdevel-backtrace-perl -- Object-oriented backtrace
Package: wnpp Severity: wishlist Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libdevel-backtrace-perl Version : 0.05 Upstream Author : Christoph Bussenius <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Devel-Backtrace/ * License : Perl Programming Lang: Perl Description : Object-oriented backtrace Provides various methods for accessing backtrace information. - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH4HCg5SXWIKfIlGQRAr+pAKCSxHvjkLaDKu/pgHsUgaLUma23tQCfcEGF tHBhW5O92CSfjtYqjE0inrQ= =+usY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471573: ITP: libconfig-ini-simple-perl -- Simple reading and writing from an INI file
Package: wnpp Severity: wishlist Owner: "Roberto C. Sanchez" <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libconfig-ini-simple-perl Version : 0.02 Upstream Author : C. J. Kirsle <[EMAIL PROTECTED]> * URL : http://search.cpan.org/dist/Config-INI-Simple/ * License : Perl Programming Lang: Perl Description : Simple reading and writing from an INI file Config::INI::Simple is for very simplistic reading and writing of INI files. A new object must be created for each INI file (an object keeps all the data read in from an INI which is used on the write method to write to the INI). It also keeps all your comments and original order intact. - -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-k7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH4HAT5SXWIKfIlGQRAkg7AKCqGJRazYH7WumPwn5YUdt+8kEfHQCglO66 XzniRDF33HrLBd0IQmvYw18= =6X58 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 buildd?
On Tue, Mar 18, 2008 at 09:09:41PM +0100, Reinhard Tartler wrote: > Luk Claes <[EMAIL PROTECTED]> writes: > > >> Similar the ia64 buildd admin, see #464932. Or is there anything I could > >> do myself about this? > > > > Hmm, you do realise that lcd4linux is mentioned in P-a-s because it > > includes sys/io.h, right? So this is not similar at all... > > Oh, this is indeed news to me. Well, if this was communicated to me, I > would have looked in adding some #ifdefs to the source so that this > wouldn't be an issue on itanium. > > Can lcd4linux be pushed to testing despite of the 'missing' ia64 build > please, then? Why don't you add those #ifdefs, upload it, and talk to the P-a-s maintainers to build it on ia64 again? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471536: ITP: archfs -- rdiff-backup virtual filesystem
Package: wnpp Severity: wishlist Owner: Adam Sloboda <[EMAIL PROTECTED]> * Package name: archfs Version : 0.5.1 Upstream Author : Filip Gruszczyński <[EMAIL PROTECTED]> * URL : http://www.example.org/ * License : GPL Programming Lang: C Description : rdiff-backup virtual filesystem This FUSE virtual filesystem allows you to mount your backup created with rdiff-backup and browse each version as any other directory. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.22-rc7-hrt1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#471443: ITP: gnome-hdaps-applet -- HDAPS system applet for GNOME 2
Package: wnpp Severity: wishlist Owner: Adam Sloboda <[EMAIL PROTECTED]> * Package name: gnome-hdaps-applet Version : 20060120 Upstream Author : Jon Escombe <[EMAIL PROTECTED]> * URL : http://www.dresco.co.uk/hdaps/ * License : GPL Programming Lang: C Description : HDAPS system applet for GNOME 2 This applet shows status of hard disk protection for ThinkPad laptops. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.22-rc7-hrt1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to hijack apt-file (and looking for co-maintainers)
Hi, apt-file has quite a few open bugs. The maintainer of apt-file has been inactive for over 1,5 years and has not responded to my offer to adopt apt-file. Last maintainer upload was in April 2006 with two NMUs since then. I intent to hijack apt-file unless somebody objects within 1 week. If somebody wants to help maintaining it, feel free to contact me. Cheers, Stefan signature.asc Description: This is a digitally signed message part.
Bug#471561: ITP: uuwaf -- University of Ulster Web Application Framework
Package: wnpp Severity: wishlist Owner: Colin Turner <[EMAIL PROTECTED]> * Package name: uuwaf Version : 1.0.0 Upstream Author : Colin Turner <[EMAIL PROTECTED]> * URL : http://foss.ulster.ac.uk/projects/uuwaf/ * License : GPL Programming Lang: PHP Description : University of Ulster Web Application Framework UUWAF is an underlying PHP framework for the University of Ulster's sofware. It is already packaged and ready to go after this step (and a sponsor) are found. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.24.2 (SMP w/2 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Problems with ia64 and lcd4linux (Was: s390 buildd?)
[Reinhard Tartler] > Can lcd4linux be pushed to testing despite of the 'missing' ia64 build > please, then? It can't be pushed like that, and forcing it into testing with architecture skew will increase the work load on the release masters in the future when they need to clean up the mess shortly before the release. You got two options: 1) Fix the source to build again on ia64. This is fairly quick and it will take 2-10 days to propagate into testing after it is done. 2) Ask the ftpmasters to remove the ia64 binaries from the archive. This take a random amount of time, as the ftpmasters need to get through their todo list and down to your removal request. If they discover that it is easy to solve by adding some #ifdefs to the source, I suspect they will ask you to use option 1) instead. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 buildd?
Luk Claes <[EMAIL PROTECTED]> writes: >> Similar the ia64 buildd admin, see #464932. Or is there anything I could >> do myself about this? > > Hmm, you do realise that lcd4linux is mentioned in P-a-s because it > includes sys/io.h, right? So this is not similar at all... Oh, this is indeed news to me. Well, if this was communicated to me, I would have looked in adding some #ifdefs to the source so that this wouldn't be an issue on itanium. Can lcd4linux be pushed to testing despite of the 'missing' ia64 build please, then? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: squeeze and epwutils both ship a "squeeze" binary
On jeu, 2008-03-06 at 10:42 +0100, Yves-Alexis Perez wrote: > On Wed, Mar 05, 2008 at 08:12:55PM +, Julien Cristau wrote: > > 'Conflicts' is not an appropriate way to resolve a conflict for a > > program name. See policy 10.1: > > Two different packages must not install programs with different > > functionality but with the same filenames. (The case of two programs > > having the same functionality but different implementations is handled > > via "alternatives" or the "Conflicts" mechanism. See Section 3.9, > > `Maintainer Scripts' and Section 7.3, `Conflicting binary packages - > > `Conflicts'' respectively.) If this case happens, one of the programs > > must be renamed. The maintainers should report this to the > > `debian-devel' mailing list and try to find a consensus about which > > program will have to be renamed. If a consensus cannot be reached, > > _both_ programs must be renamed. > > Hi Masayuki, > > what do you think about that? Squeeze (the archive manager) is the package > name, the binary name, the library name, and most important the software > name). Having to rename it is a pain because users know it by this name and > not by a name like, say squeeze-archiver or something like that. > > OTOH, squeeze (the archive manager) just entered the archive while squeeze > (the dict files compressor) is there since a long time. > > popcon shows few users for epwutils (and a bit fewer for squeeze) so renaming > wont touch too many people in either case: > > http://preview.tinyurl.com/39363v > > (sorry for this, I don't think there's a way to have shorts url in popcon.php > so I used tinyurl). > > Do you think renaming squeeze to squeeze-dict (or something like that) will be > painful? > > I'm CC:ing -devel as per policy. As there wasn't any reply on this, would you consider the attached NMU ok? It only renames the binary, as there is no other conflict, no manpage. -- Yves-Alexis diff -u epwutil-1.1/debian/changelog epwutil-1.1/debian/changelog --- epwutil-1.1/debian/changelog +++ epwutil-1.1/debian/changelog @@ -1,3 +1,10 @@ +epwutil (1.1-7.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Rename squeeze to epwutil-squeeze in package. + + -- Yves-Alexis Perez <[EMAIL PROTECTED]> Tue, 11 Mar 2008 08:48:00 +0100 + epwutil (1.1-7) unstable; urgency=low * Bumped to Standards-Version: 3.7.3. diff -u epwutil-1.1/debian/rules epwutil-1.1/debian/rules --- epwutil-1.1/debian/rules +++ epwutil-1.1/debian/rules @@ -43,7 +43,7 @@ #$(MAKE) install DESTDIR=`pwd`/debian/epwutil install bookinfo `pwd`/debian/epwutil/usr/bin install catdump `pwd`/debian/epwutil/usr/bin - install squeeze `pwd`/debian/epwutil/usr/bin + install squeeze `pwd`/debian/epwutil/usr/bin/epwutil-squeeze # Build architecture-independent files here. signature.asc Description: This is a digitally signed message part
Re: s390 buildd?
On Tue, Mar 18, 2008 at 02:37:39PM +0100, Reinhard Tartler wrote: > Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > > > [Steve Langasek] > >> The s390 buildd maintainer presumes to mark all packages as > >> 'Not-for-us' if he doesn't feel like building them for the arch, > >> without bothering to reach a consensus first together with the > >> maintainer, the ftp masters, or the maintainers of the P-a-s > >> overrides. > > > > Is the unilateral flagging of not-for-us being addressed in any way? > > Similar the ia64 buildd admin, see #464932. Or is there anything I could > do myself about this? That package is only n-f-u on s390, it's in p-a-s for some other architectures. It seems to indeed FTBFS on a couple of architectures, so why do you think the p-a-s is wrong? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 buildd?
Reinhard Tartler wrote: > Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > >> [Steve Langasek] >>> The s390 buildd maintainer presumes to mark all packages as >>> 'Not-for-us' if he doesn't feel like building them for the arch, >>> without bothering to reach a consensus first together with the >>> maintainer, the ftp masters, or the maintainers of the P-a-s >>> overrides. >> Is the unilateral flagging of not-for-us being addressed in any way? > > Similar the ia64 buildd admin, see #464932. Or is there anything I could > do myself about this? Hmm, you do realise that lcd4linux is mentioned in P-a-s because it includes sys/io.h, right? So this is not similar at all... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Free laptop...? Here is how.....
I’m doing the same but with a different company Anyway to help me with referrals for my referral link? http://laptops.freepay.com/?r=43388891 Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: Proposing a new source control header to link to upstream BTSs
#include * Martín Ferrari [Tue, Mar 18 2008, 11:51:45AM]: > On Tue, Mar 18, 2008 at 5:17 AM, Ralf Treinen <[EMAIL PROTECTED]> wrote: > > > > It would be good if this process could be automated, however I suspect > > > this header is not the solution. > > > > Granted, but then you are speaking about giving better tool support for > > manually forwarding bugs, which is not the same thing as automatically > > forwarding bugs. > > > > Better tool support would of course be welcome. > > As I said in a previous email, I chose the wrong word, when I said > automatically forwarding bugs, I meant being able to instruct the bts > command to forward a bug already in the BTS to upstream, probably > preparing a boilerplate text and firing $EDITOR, etc. What I want to > achieve is having metadata that then can be used by new tools or > augment existing ones. Do that please but keep your fingers off the Packages files. The value of your meta information is not worth the costs of its distribution to every user's local system. Just keep such data available on an visible location like it's done with DEHS, for example. Regards, Eduard. -- Smur: du brauchst nen Level 9 Analyzer weasel: fällt dir da konkret n name ein? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, Mar 18, 2008 at 5:17 AM, Ralf Treinen <[EMAIL PROTECTED]> wrote: > > It would be good if this process could be automated, however I suspect > > this header is not the solution. > > Granted, but then you are speaking about giving better tool support for > manually forwarding bugs, which is not the same thing as automatically > forwarding bugs. > > Better tool support would of course be welcome. As I said in a previous email, I chose the wrong word, when I said automatically forwarding bugs, I meant being able to instruct the bts command to forward a bug already in the BTS to upstream, probably preparing a boilerplate text and firing $EDITOR, etc. What I want to achieve is having metadata that then can be used by new tools or augment existing ones. -- Martín Ferrari
Re: Proposing a new source control header to link to upstream BTSs
On Tue, Mar 18, 2008 at 4:53 AM, Andreas Tille <[EMAIL PROTECTED]> wrote: > Sometimes innovation comes silent. I remember times when we > have hidden Homepage information behind 'XCBS-URL'. So why > not using > > XCBS-UpstreamBTS > > or something like that and experiment with this and see how it > might evolve? I assumed that it should start like this, but I guess that asking for opinions on -devel before adding custom fields was expected. -- Martín Ferrari
Re: What CDs and DVDs should we produce for lenny?
On Tue, Mar 18, 2008 at 02:21:45AM -0700, Don Armstrong <[EMAIL PROTECTED]> was heard to say: > On Tue, 18 Mar 2008, Anthony Towns wrote: > > I guess there's an inequality like: > > > > images on mirrors <= images on torrents <= images via jigdo > > Is there any way we can construct the torrent image on the fly from > the jigdo file? [That is, transform the packages that make up bits > x<->y into what they'd be on the iso?] Or maybe you could use debtorrent to download the files to fill out the jigdo image? (Disclaimer: I haven't used debtorrent so I don't know how efficient using it this way would be) Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 buildd?
Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > [Steve Langasek] >> The s390 buildd maintainer presumes to mark all packages as >> 'Not-for-us' if he doesn't feel like building them for the arch, >> without bothering to reach a consensus first together with the >> maintainer, the ftp masters, or the maintainers of the P-a-s >> overrides. > > Is the unilateral flagging of not-for-us being addressed in any way? Similar the ia64 buildd admin, see #464932. Or is there anything I could do myself about this? -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: s390 buildd?
[Steve Langasek] > The s390 buildd maintainer presumes to mark all packages as > 'Not-for-us' if he doesn't feel like building them for the arch, > without bothering to reach a consensus first together with the > maintainer, the ftp masters, or the maintainers of the P-a-s > overrides. Is the unilateral flagging of not-for-us being addressed in any way? Some options might be to - Change the behavior of the current s390 buildd admin, if required by taking this to the Technical Committee - Replace the s390 buildd admin - Replace the s390 buildd and admin - Drop s390 as a release architecture as it is failing to build packages that previously was build on that architecture. Are any of these or other options being implemented to solve this issue? Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On 18/03/2008, Mattias Wadenstein <[EMAIL PROTECTED]> wrote: > > On Tue, 18 Mar 2008, Don Armstrong wrote: > > > On Tue, 18 Mar 2008, Anthony Towns wrote: > >> I guess there's an inequality like: > >> > >> images on mirrors <= images on torrents <= images via jigdo > > > > Is there any way we can construct the torrent image on the fly from > > the jigdo file? [That is, transform the packages that make up bits > > x<->y into what they'd be on the iso?] > > > > I don't know enough about the mkisofs process to say whether this is > > possible, but it'd be very useful if it were. > > > In theory yes, and this would be quite useful. The code for this needs to > be written though. > > It would also be useful for me who runs the main cd torrent seeder in that > I could just have an up-to-date debian archive and snapshot (minor rsync > update), instead of syncing 300+ gigs of data before all the seeds are > started up. > > > /Mattias Wadenstein Hey, I'm interested in this as a problem solving exercise. I'm a beginner in the entire system, but curious. Torrents use md5 sums, chunks and a tracker to point at available portions of the file. The similarities to jigdo are there, so surely it should be possible to mash them together somehow. First question: What torrent tracker software does Debian use? BNBT? Rivettracker? cheers, Owen.
Re: What CDs and DVDs should we produce for lenny?
On Tue, 18 Mar 2008, Richard Atterer wrote: [Followups set to debian-cd] On Tue, Mar 18, 2008 at 10:32:29AM +0100, Mattias Wadenstein wrote: It would also be useful for me who runs the main cd torrent seeder in that I could just have an up-to-date debian archive and snapshot (minor rsync update), instead of syncing 300+ gigs of data before all the seeds are started up. Are you concerned about increased seek times, Matthias? IIRC people like Attila Nagy mentioned from time to time that jigdo thrashed their disks a bit more than regular .iso downloads. Yes, that is one concern. On the server side a plain iso download puts much less load on the system. On the other hand, shipping hundreds of gigs around to mirrors puts quite alot of load too. So I think we should keep the plain http downloads for the useful/popular set (netinst, i386/amd64 dvd isos and lower number cd isos, perhaps CD1/DVD1 for other arches that can boot from CD/DVD), the rest can probably be dropped from the mirrors. They can still be carried by cdimage.d.o/cdimage just like oldstable isos etc, but no need for putting them into the mirrored directory. /Mattias Wadenstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
[Followups set to debian-cd] > On Tue, Mar 18, 2008 at 10:32:29AM +0100, Mattias Wadenstein wrote: > >It would also be useful for me who runs the main cd torrent seeder in > >that I could just have an up-to-date debian archive and snapshot (minor > >rsync update), instead of syncing 300+ gigs of data before all the seeds > >are started up. Are you concerned about increased seek times, Matthias? IIRC people like Attila Nagy mentioned from time to time that jigdo thrashed their disks a bit more than regular .iso downloads. On Tue, Mar 18, 2008 at 10:20:12AM +, Steve McIntyre wrote: > I've written code for jigdoofus (exactly the FUSE-based idea that aj > suggested) already, but it needs some more work yet. My eventual hope was > that it might allow lots of our normal archive mirrors to become CD ISO > mirrors or torrent seeders. But I got distracted from it quite a while > back... IIRC jigdoofus uncompressed the data on the fly, which made it a bit slow, right? What's the right solution to cache the data from the .template file? Write the pieces to disk uncompressed? Re-compress them with something like LZO? Hmm, a FastCGI solution would also be possible for serving the files via HTTP (but not BitTorrent). I'm tempted... Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On Tue, Mar 18, 2008 at 10:32:29AM +0100, Mattias Wadenstein wrote: >On Tue, 18 Mar 2008, Don Armstrong wrote: > >>On Tue, 18 Mar 2008, Anthony Towns wrote: >>>I guess there's an inequality like: >>> >>> images on mirrors <= images on torrents <= images via jigdo >> >>Is there any way we can construct the torrent image on the fly from >>the jigdo file? [That is, transform the packages that make up bits >>x<->y into what they'd be on the iso?] >> >>I don't know enough about the mkisofs process to say whether this is >>possible, but it'd be very useful if it were. > >In theory yes, and this would be quite useful. The code for this needs to >be written though. > >It would also be useful for me who runs the main cd torrent seeder in that >I could just have an up-to-date debian archive and snapshot (minor rsync >update), instead of syncing 300+ gigs of data before all the seeds are >started up. I've written code for jigdoofus (exactly the FUSE-based idea that aj suggested) already, but it needs some more work yet. My eventual hope was that it might allow lots of our normal archive mirrors to become CD ISO mirrors or torrent seeders. But I got distracted from it quite a while back... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Who needs computer imagery when you've got Brian Blessed? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On Tue, 18 Mar 2008, Mike Hommey wrote: > On Tue, Mar 18, 2008 at 02:21:45AM -0700, Don Armstrong <[EMAIL PROTECTED]> > wrote: > > On Tue, 18 Mar 2008, Anthony Towns wrote: > > > I guess there's an inequality like: > > > > > > images on mirrors <= images on torrents <= images via jigdo > > > > Is there any way we can construct the torrent image on the fly from > > the jigdo file? [That is, transform the packages that make up bits > > x<->y into what they'd be on the iso?] > > > > I don't know enough about the mkisofs process to say whether this is > > possible, but it'd be very useful if it were. > > That would most likely require a custom bittorrent server, but it doesn't > seem impossible to me. That could be an interesting subject for GSoC. If someone were to write a general library that did this, it would be trivial to wrap a apache handler around it that fed out iso images for the less popular architectures too. Does someone who knows more about iso9660 and torrents want to write this up for GSoC? Don Armstrong -- I leave the show floor, but not before a pack of caffeinated Jolt gum is thrust at me by a hyperactive girl screaming, "Chew more! Do more!" The American will to consume more and produce more personified in a stick of gum. I grab it. -- Chad Dickerson http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On Tue, 18 Mar 2008, Don Armstrong wrote: On Tue, 18 Mar 2008, Anthony Towns wrote: I guess there's an inequality like: images on mirrors <= images on torrents <= images via jigdo Is there any way we can construct the torrent image on the fly from the jigdo file? [That is, transform the packages that make up bits x<->y into what they'd be on the iso?] I don't know enough about the mkisofs process to say whether this is possible, but it'd be very useful if it were. In theory yes, and this would be quite useful. The code for this needs to be written though. It would also be useful for me who runs the main cd torrent seeder in that I could just have an up-to-date debian archive and snapshot (minor rsync update), instead of syncing 300+ gigs of data before all the seeds are started up. /Mattias Wadenstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On Tue, Mar 18, 2008 at 02:21:45AM -0700, Don Armstrong <[EMAIL PROTECTED]> wrote: > On Tue, 18 Mar 2008, Anthony Towns wrote: > > I guess there's an inequality like: > > > > images on mirrors <= images on torrents <= images via jigdo > > Is there any way we can construct the torrent image on the fly from > the jigdo file? [That is, transform the packages that make up bits > x<->y into what they'd be on the iso?] > > I don't know enough about the mkisofs process to say whether this is > possible, but it'd be very useful if it were. That would most likely require a custom bittorrent server, but it doesn't seem impossible to me. That could be an interesting subject for GSoC. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, 18 Mar 2008, Raphael Hertzog wrote: On Tue, 18 Mar 2008, Andreas Tille wrote: XCBS-UpstreamBTS I'm opposed to this as well. Homepage and Vcs-* were almost required and provide the basic pointers about a package but the control file is not a general-purpose information file. Well, could you please draw a border line between "almost required" and "general-purpose"? For some time we had XCBS-debtag information in the control file and learned that this is suboptimal. So why not trying an experiment? I doubt that it adds a large amount of data to the packages file in practice based on my experience how long it takes to adopt such a feature. My estimation is that we will have to deal with a one liner for about 100 package in the end of 2008 at maximum. If people start to use this information in some tools it is fine. If not we might drop it again as we did with the debtags stuff. Please work on something like Mole/CRMI if you want to associate much more metadata to packages. http://wiki.debian.org/Mole http://wiki.debian.org/CRMI I admit this might lead to a more powerful solution. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What CDs and DVDs should we produce for lenny?
On Tue, 18 Mar 2008, Anthony Towns wrote: > I guess there's an inequality like: > > images on mirrors <= images on torrents <= images via jigdo Is there any way we can construct the torrent image on the fly from the jigdo file? [That is, transform the packages that make up bits x<->y into what they'd be on the iso?] I don't know enough about the mkisofs process to say whether this is possible, but it'd be very useful if it were. Don Armstrong -- The major difference between a thing that might go wrong and a thing that cannot possibly go wrong is that when a thing that cannot possibly go wrong goes wrong it usually turns out to be impossible to get at or repair. -- Douglas Adams _Mostly Harmless_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, 18 Mar 2008, Andreas Tille wrote: >XCBS-UpstreamBTS > > or something like that and experiment with this and see how it > might evolve? I'm opposed to this as well. Homepage and Vcs-* were almost required and provide the basic pointers about a package but the control file is not a general-purpose information file. Please work on something like Mole/CRMI if you want to associate much more metadata to packages. http://wiki.debian.org/Mole http://wiki.debian.org/CRMI Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, Mar 18, 2008 at 04:29:41PM +1100, Brian May wrote: > Ralf Treinen wrote: >> I do not think that automatically forwarding bugs would be a good idea. > Right now it is a pain to forward a bug, say to a sourceforge bug > report, because it involves several steps: [...] > It would be good if this process could be automated, however I suspect > this header is not the solution. Granted, but then you are speaking about giving better tool support for manually forwarding bugs, which is not the same thing as automatically forwarding bugs. Better tool support would of course be welcome. Cheers -Ralf. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
On Tue, 18 Mar 2008, Christian Perrier wrote: without preventing innovative initiatives such as this one Sometimes innovation comes silent. I remember times when we have hidden Homepage information behind 'XCBS-URL'. So why not using XCBS-UpstreamBTS or something like that and experiment with this and see how it might evolve? Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Blueray software, was: What CDs and DVDs should we produce for lenny?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/17/08 23:38, Anthony Towns wrote: > On Mon, Mar 17, 2008 at 08:16:55AM -0500, Ron Johnson wrote: >> On 03/17/08 04:47, Philip Charles wrote: >> [snip] >>> worrying about. Even then bluray disc(s) will take up about the same >>> space as a CD set. >> > > 21GB on CD is 21GB on Bluray. Physical space isn't an issue for us. On the host, you must mean. Ok. - -- Ron Johnson, Jr. Jefferson LA USA "Working with women is a pain in the a**." My wife -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH33KvS9HxQb37XmcRAoyXAJ9z58lWv+tf3hCWiFWd9d/Ww8kAQgCg5YDD XT4IhSP7ZpBw6/Fv+Q3PCsI= =QfmU -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposing a new source control header to link to upstream BTSs
Quoting Neil Williams ([EMAIL PROTECTED]): > Please can this 'trend' be stopped here and now? > > The Packages.gz file is already enormous (especially for Emdebian > purposes or other low resource units) and adding yet more fields to Couldn't there be an opportunity somewhere to have some possible hook in dpkg/apt/whatever that could drop specific fields on control files when the Packages file is written/updated on disk? This could be set by local admins...or there could be a default per-architecture...whatever. That would then achieve the goal of reducing the Packages.gz file size in low resources environments (why not even drop the long description when resources are very scarce?) without preventing innovative initiatives such as this one -- signature.asc Description: Digital signature
