Re: Testez l'installateur Debian....
Bonjour, Suite à l'appel au test (d'accord je ne suis pas en avance mais vieux motard que jamais), j'aimerais tester le nouvel installateur Debian comme j'ai l'habitude de l'utiliser, c'est-à-dire via un boot réseau (sur des machines dans disquettes ni CD-ROM). Pb: sur l'image ISO, point d'images pour TFTP. Est-ce que cela existe encore ? si oui, où les trouve-t-on ? Fred. PS1: j'ai essayé d'accéder au CVS de l'installateur mais le serveur me renvoie tout le temps des messages d'erreur :-(( PS2: la doc sur l'image ISO est celle de l'ancien installateur, c'est normal docteur ??
Re: MIPS port backlog, autobuilder machines and some arrogance
On Wed, Nov 19, 2003 at 02:32:53PM +1100, Martin Michlmayr - Debian Project Leader wrote: And since we're on topic: people interested in SGI hardware (for example to work on debian-installer) in the USA, please get in contact with me. Hmm, regarding to Goswin Brederlow debian-installer build fine yesterday on our SGI and I'll test it today on my private Indy. Perl is building fine as well now on mips, although it is marked as not-for-us. See http://m68k.bluespice.org/cgi/package_status?mips_pkg=perlsearchtype=go paco:/home/ij# ls -l *.deb -rw-r--r--1 root root35172 Nov 18 22:24 libcgi-fast-perl_5.8.2-2_all.deb -rw-r--r--1 root root 651210 Nov 18 22:32 libperl-dev_5.8.2-2_mips.deb -rw-r--r--1 root root 1002 Nov 18 22:31 libperl5.8_5.8.2-2_mips.deb -rw-r--r--1 root root 766386 Nov 18 22:27 perl-base_5.8.2-2_mips.deb -rw-r--r--1 root root 4320256 Nov 18 22:31 perl-debug_5.8.2-2_mips.deb -rw-r--r--1 root root 5901334 Nov 18 22:25 perl-doc_5.8.2-2_all.deb -rw-r--r--1 root root 2158282 Nov 18 22:26 perl-modules_5.8.2-2_all.deb -rw-r--r--1 root root32032 Nov 18 22:31 perl-suid_5.8.2-2_mips.deb -rw-r--r--1 root root 3325030 Nov 18 22:38 perl_5.8.2-2_mips.deb -- Ciao... // Ingo \X/
Minneapolis, MN USA BSP + Keysigning
Thanks to Chad Walstrom for really coming up with the idea! ** PLEASE RSVP privately to [EMAIL PROTECTED] ** I need to know how many people and if you are planning on a laptop (wireless or wired) or a full computer (I've only got so much space). What: Bug Squashing Party (BSP) and Keysigning Start: Saturday, 13 Dec 2003 12:00:00 CDT Stop: assert(not_exhausted(personal-state)) /* core dump */ Where: Scott Dier's Residence (Coon Rapids, MN, USA) 10675 Quince St NW #100 Coon Rapids, MN 55433 [black helicopter parking is across the street] One way to get here from there: Take Hwy 10 to Foley Blvd., go south. Take a right at 99th Ave NW Take a right at Woodcrest At Foley continue straight, the road becomes Quince at this point. Be careful of the transformer box to the left at this two-way stop, it can sometimes hide cars. Take a right at the 2nd street (its an access road) Find a parking spot in guest parking, if none are avaliable, park in the driveway to unload and then we will find some parking for you. There is no mass transit near my house that runs extended hours. I can provide a shuttle to/from Northtown Mall if required. ** PLEASE RSVP ** If you can't seem to convince MapQuest to get you good directions, feel free to email me and I can help out or call 763-390-3261. Thanks! -- Scott Dier [EMAIL PROTECTED] KC0OBS http://www.ringworld.org/ Free USA from energy dependence, http://www.apolloalliance.org/ pgpm5DTIlbQIn.pgp Description: PGP signature
Re: Minneapolis, MN USA BSP + Keysigning
Important directions correction below: * Scott Dier [EMAIL PROTECTED] [031119 00:01]: One way to get here from there: Take Hwy 10 to Foley Blvd., go south. Take a right at 99th Ave NW Take a right at Woodcrest At Foley continue straight, the road becomes Quince at this ^ Should read Egret, not Foley point. Be careful of the transformer box to the left at this two-way stop, it can sometimes hide cars. Take a right at the 2nd street (its an access road) Find a parking spot in guest parking, if none are avaliable, park in the driveway to unload and then we will find some parking for you. -- Scott Dier [EMAIL PROTECTED] KC0OBS http://www.ringworld.org/ Free USA from energy dependence, http://www.apolloalliance.org/ pgpnH62iNz57u.pgp Description: PGP signature
First pass all buildds before entering unstable
Hi, just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. This would get us rid of all those packages in unstable with Does not build on ... and several dependencies could be easier solved. Moreover it would enhance the preasure on developers to care for this kind of bugs. I guess this would be not really hard to implement. Just ignore me if this is a stupid idea Andreas.
Re: Bug#220301: ITP: entropy -- Emerging Network To Reduce Orwellian Potency Yield
On Tue, Nov 18, 2003 at 11:18:39PM -0500, Joe Drew wrote: This doesn't really tell me anything about ENTROPY. How about anti-censorship network client? That would do. The acronym ENTROPY should be defined in the first line of the long description. Right, better than the short description. [snip] This is a good, though perhaps too detailed, long description. Taken directly from the web page... (I'm lazy) A general (non-ITP-related) question: Is ENTROPY related to Freenet in any way? It supports the freenet protocol, yes. But it's written in C, not Java. I actually havent had a chance to package it yet, I've been too busy at work. If anyone else wants to take this one, feel free, just let me know. I'll retitle it to RFP in a week or two if I dont get a chance to get to it. Mike. -- Mike Beattie [EMAIL PROTECTED] ZL4TXK, IRLP Node 6184 In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. - Douglas Adams
Re: First pass all buildds before entering unstable
Am 19.11.03 um 07:42:18 schrieb Andreas Tille: After each buildd was able to build a package the whole set with all architectures enters unstable at once. Yeah, cool. That would get rid of many buggy packages. And many clean ones. Some buildd are horribly behind time. No offence meant, it's not necessarily sloppy maintainers, rather it's slow computers and extremely complex packages. Take workrave, for instance. Perfectly stable, as far as I can tell. Not built recently on m68k (because of libgnomeuimm2.0-dev), not built on alpha for a very long time (same reason). It's not in testing, which is bad enough, with your idea only ancient versions would be in unstable. Don't get me wrong. I actually quite like the thought. It just won't work. Perhaps limit it to when it's built for i386, powerpc, hppa and arm. (That's were I got all my architecture-dependent bugs from, and they are all quite current.) Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
20043
/ 8 2004 2004 33---6 . 117 1 2 3 33101510623 020--3825041238250413 : 38250932 mailto:[EMAIL PROTECTED] http://www.gzxinghui.com
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 08:48:10AM +0100, Michael Piefel wrote: Am 19.11.03 um 07:42:18 schrieb Andreas Tille: After each buildd was able to build a package the whole set with all architectures enters unstable at once. I like the idea. Yeah, cool. That would get rid of many buggy packages. And many clean ones. Some buildd are horribly behind time. No offence meant, it's not necessarily sloppy maintainers, rather it's slow computers and extremely complex packages. I don't think the speed of some of our buildd would be the point. Sooner or later the new packages will be compiled on our buildd: better before entering Debian than after and.. Take workrave, for instance. Perfectly stable, as far as I can tell. Not built recently on m68k (because of libgnomeuimm2.0-dev), not built on alpha for a very long time (same reason). It's not in testing, which is bad enough, with your idea only ancient versions would be in unstable. I think this is not what Andreas ment: I suppose he was trying to drop FTBFS bugs for those new packages missing correct Build-* fields. Packages that cannot be built because of correct source fields but missing dependencies, should not receive bugs (AFAICT) Don't get me wrong. I actually quite like the thought. It just won't work. Perhaps limit it to when it's built for i386, powerpc, hppa and arm. (That's were I got all my architecture-dependent bugs from, and they are all quite current.) IMHO it would indeed work, if only we consider meaningful buildd reports (for what is our purpose). ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: First pass all buildds before entering unstable
In article [EMAIL PROTECTED] you wrote: Take workrave, for instance. Perfectly stable, as far as I can tell. Not built recently on m68k (because of libgnomeuimm2.0-dev), not built on alpha for a very long time (same reason). It's not in testing, which is bad enough, with your idea only ancient versions would be in unstable. http://m68k.bluespice.org/cgi/package_status?m68k_pkg=libgnomeuimm2.0-devsearchtype=go - libgnomeuimm2.0-dev not registered http://m68k.bluespice.org/cgi/package_status?m68k_pkg=libgnomeuimm2.0searchtype=go - libs/libgnomeuimm2.0_2.0.0-4: Installed by younie-crest [optional:out-of-date] Previous state was Uploaded until 2003 Nov 18 11:28:19 http://m68k.bluespice.org/cgi/package_status?m68k_pkg=workravesearchtype=go - gnome/workrave_1.4.1-1: Failed by schmitz-q650 [optional:out-of-date] Reasons for failing: [Category: none] uninstallable b-d E: Couldn't find package libgnomeuimm2.0-dev Previous state was Building until 2003 Nov 07 02:46:31 Maybe you want to request a rebuild on [EMAIL PROTECTED] -- Ciao... // Ingo \X/
Re: Tabs v.s. spaces
Darren Salt [EMAIL PROTECTED] wrote: I find myself wondering if Duff's Device is implementable in Python... The closest beast I can think of would generate the unrolled loop at runtime and use 'exec' to run it. But this is a bit off topic for d-d. -- Florent
Re: First pass all buildds before entering unstable
Andreas Tille wrote: Hi, just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. No!!! it would delay to much the entry of some important packages in unstable. It would maybe improve some architectures, but definitely would reduce extensive testing of newer versions. Unstable IMHO should be more near to upstream-side as possible, to improve GNU/Linux at whole, not only the Debian distributions. BTW: How many developers have access and know how to test packages in *all* other architectures? So it would be more pressure on developers with architectures specific knowelenge. ciao giacomo
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote: Hi, just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. I don't think people would like it if their package stayed in incoming for multiple weeks because there's a backlog on some architecture. People are bickering enough as it is when packages don't move into testing that we don't need this extra reason for them to bicker :-) This would get us rid of all those packages in unstable with Does not build on ... Unstable is there for that kind of things. And to detect other kinds of bugs, too. If you're going to keep packages in incoming like this, people won't be able to test it until it's built on all architectures. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Tabs v.s. spaces
On Tue, Nov 18, 2003 at 09:58:54PM -0800, Steve Lamb wrote: | Cameron Patrick wrote: | I don't think it is. Python doesn't have a switch/case equivalent. It'd | have to be done with a bunch of if's or something. | | Well, depends. Do you consider its dictionary to be a switch? Nope, no fall-through in that one, so it doesn't help. It /is/ nifty though :-) Cameron.
Re: Debian packages of 7.4
Stephen Frost [EMAIL PROTECTED] writes: It would be really nice to have 7.4 in sarge.. Personally I think there should probably be enough time given the lack of messages on d-d-a regarding freezes and the like. 7.4 adds alot of nice things and speeds up a number of operations, etc. Further to that... would it be acceptable to upload the new stable libpqxx release (2.0.0) built against 7.4 once 7.4 has entered unstable. It would be fantastic to have the new libpqxx in sarge, too. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
New Tutorials: Slideshows in Flash MX plus Thanksgiving Video
Wildform Newsletter: The Resource for Wildform Product News Wednesday, November 19, 2003 http://www.wildform.com == NEW: 1. New Tutorial: Flash MX Slideshow with Listeners 2. New Tutorial: Flash MX Slideshow with Pause Button 3. New Tutorial: EXIF to Flash MX 4. Featured Gallery Sites 5. New Wild FX Reviews 6. Complimentary Video: Thanksgiving Video Clip 7. Sites We Like We have some great new tutorials written by the Actionscript expert, Helen Triolo. We also have a complimentary clip from the Wildform Video Library in honor of Thanksgiving holiday. Have a very happy Thanksgiving! Best wishes, The Wildform Team == 1. NEW TUTORIAL: FLASH MX SLIDESHOW WITH LISTENERS Flash MX Slideshow with Listeners By Helen Triolo http://www.wildform.com/tutorials/slideshowcomponent/ This tutorial and sample FLA explains how to use Macromedia Flash MX to sequentially load jpgs and display them with fade-in transitions, using a broadcasting Slideshow component. For more tutorials please visit: http://www.wildform.com/tutorials/ = 2. NEW TUTORIAL: FLASH MX SLIDESHOW WITH PAUSE BUTTON Flash MX Slideshow with Pause Button By Helen Triolo http://www.wildform.com/tutorials/slideshowcomponent2/ This tutorial and sample FLA explains how to add a stop/restart button to the slideshow described in the tutorial above. = 3. NEW TUTORIAL: EXIF TO FLASH MX EXIF To Flash By Helen Triolo http://www.wildform.com/tutorials/exiftoflash/ This tutorial and sample FLA describes how to read EXIF data (or any CSV-formatted data) from a jpg into Flash For more tutorials please visit: http://www.wildform.com/tutorials/ == 4. FEATURED GALLERY SITE THE BEST OF HUBBLE http://wires.news.com.au/special/mm/030811-hubble.htm Uses Flix and Linx. From news.com.au. RYAN FORSMAN http://www.onewaypublishing.net/forsman/ Click on player video to view Flix-encoded video in a Flix custom player. BROOKSIDE.ORG http://www.wildform.com/resources/flashtexteffectsgallery.php#brook Wild FX is a great solution. We were able to add sparkle to our website with your application. -- Russ Block, Webmaster, BrooksideGlen.org Visit our gallery: http://www.wildform.com/resources/gallery.php == 5. NEW WILD FX REVIEWS We were super impressed by the ability to create text animations and effects in seconds that would've taken some considerable time to create manually...During our testing of Wild FX we found that it produced exceptionally small file sizes and clean output. --Dave Paris, http://www.flashtrix.com Wild FX Pro is incredible software! This software is s easy to use and offers fantastic effects at such an unbelievably low price. Thanks so much for such a great product. -- Dave Williams, Virtual Renderings == 6. COMPLIMENTARY VIDEO: THANKSGIVING CLIP All of us here at Wildform wish you a very happy Thanksgiving! http://www.wildform.com/cm/turkey_displaying_4_col_mos.zip (.Avi, 1.78 MB download. This download will be available until November 30, 2003) Visit the Wildform Video Library for great video clips http://www.wildform.com/videolibrary/ == 7. SITES WE LIKE ERIC CONVEYS AN EMOTION http://www.emotioneric.com/ INFOURM http://www.infourm.com Design magazine recently update. FLASHEUR FORMAT PRODUCTIONS http://www.flasheur.fr.st/ French design site. MOLUVs PICKS http://www.moluv.com Nice design resource site. FIND TUTORIALS http://www.findtutorials.com/ == ADVERTISEMENT ADVERTISEMENT ADVERTISEMENT R Blank Interactive Design provides high-performance solutions including e-learning engines, PC and web applications, and immersive web sites - for businesses and agencies through a range of services including design, development, consulting and training. R Blank is a certified Macromedia Flash Developer and Designer. For more information, please visit: www.rblank.com R Blank Interactive Design also hosts LA Flash, the Macromedia User Group for LA and Santa Monica area Flash developers. Meetings are monthly, there is no charge for membership, and we have great online resources. For more information please visit: www.rblank.com/laflash == PRIVACY Wildform does NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy. = Wildform http://www.wildform.com Purchase Page
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 09:44:31AM +0100, Giacomo A. Catenazzi wrote: No!!! it would delay to much the entry of some important packages in unstable. It would maybe improve some architectures, but definitely would reduce extensive testing of newer versions. In which way would it improve some architectures and not the overall Debian quality? why would it reduce extensive testing of newer versions? Rejecting a package which is not buildable on a spacific architecture, because of an unpstream or maintainer fault, is a semi-automatic testing that can be implemented. If we let it in and then we auto-build it, we get a new package with FTBFS (i.e RC) bugs and slow down release even more. If we auto-build it first and, if no upstream/package faults, we let it in, we get less RC bugs. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote: I don't think people would like it if their package stayed in incoming for multiple weeks because there's a backlog on some architecture. Neither i. This is why i would like to receive baklogs mailed to maintainer if autobuild fails. But i would like to receive backlogs even for pre-autobuilds, so that i could fix the problem, contact the upstream etc. BTW, i think that the correct workflow would be: Move package from incoming to autobuild. If all architectures build, continue (as before this change); else, if not builded but is not upstrea/maintainer fault, continue (as before this change). Else reject the package. Unstable is there for that kind of things. And to detect other kinds of bugs, too. If you're going to keep packages in incoming like this, people won't be able to test it until it's built on all architectures. If we stay as it is, we'll continue to get slowed by badly built packages/softwares. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgpykhdfZUnbE.pgp Description: PGP signature
debian-devel@lists.debian.org
QQ ! ,--2.0 - -QQ QQ - - - - http://www.hefeng-it.com/product1.htm http://www.hefeng-it.com/download.htm
Re: Some observations regardig the progress towards Debian 3.1
Adrian wrote: Your proposal wouldn't have been able to shorten the move of KDE 3 into testing by one single day. Yes, my comment was misplaced wrt what you said, this problem still has to be addressed. My proposal, however, is more targetted to packages which would build with, say, KDE2, but are held into unstable because here they are build with KDE3. KDE may not be a good example. libgc is a much better example, although the number of packages held here is quite low compared to KDE. testsuites must be written, and testsuites for GUI programs are even more work. Fortunately several of the packages we ship already have one. And for the bunch of non-gui programs, we could surely add some minimal testing, say to ensure it does not segfault on trivial use cases. Just like what we already do for manpages. GUI programs are another story, but that's not a reason not to do it for non-GUI ones. There might be new problems e.g. with inter-library dpendencies for libraries without versioned symbols if your proposal would be implemented. Hm ? I'm not sure I understand what the problem you mention is. An example: unstable: Package: libfoo0 Depends: libbar1 Package: mypackage Depends: libfoo0, libbar1 testing: Package: libbar0 s/testing/pre-testing/ IOW: The program in mypackage is in this situation linked with two different so-versions of libbar at the same time. That's a good point. In my mind the libfoo0 package just rebuilt would only show up in pre-testing. We need to keep the original package in unstable, while increasing its version at the same time. That could be done either by a rebuild, or, less costly, by a simple unpack/edit-changelog/repack. In that case, if we had libfoo0_1.0-1 in pre-testing, and libfoo0_1.0-2 in unstable, we'd end up with libfoo0_1.0-2.0.1 in pre-testing, and libfoo0_1.0-2.0.2 in unstable, whether the latter was rebuilt or just repacked. Regards, -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Re: debian-installer beta 1
On Sun, Nov 16, 2003 at 10:42:11PM +0100, David Weinehall wrote: On Mon, Nov 17, 2003 at 07:52:32AM +1100, Brian May wrote: 1. Linux 2.6.0? Not released yet. Yes, it has a _lot_ of nice features, but it is beta software.. It (or patches to 2.4.22) is also needed if you decide to buy a modern machine right now. I've had to dig up an old plain IDE disk to stage a Linux install to my dual SATA drives in my new machine. Otherwise the beta installer worked fine. The strange thing with SATA support is that I couldn't get the modules in debian's 2.6.0-test9 kernel to recognize my drives, but a self compiled 2.6.0-test9-bk19 kernel with the SATA drivers (for promise and via) compiled in did work. -- Bart.
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Luca - De Whiskey's - De Vitis wrote: If we let it in and then we auto-build it, we get a new package with FTBFS (i.e RC) bugs and slow down release even more. If we auto-build it first and, if no upstream/package faults, we let it in, we get less RC bugs. Exactly this was the idea. I'm unsure whether experimental could serve as this kind of staging area. Kind regards Andreas.
perl 5.8.2-2 mips buildd
hi, i see that perl 5.8.2-2 is marked Not-For-Us on mips buildd. why it is in this state? it blocks the build of a lot of software. cheers dom -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. I cannot see any real advantage for that, but for avoiding a FTBFS reports proliferation. Also a. Packages could become FTBFS later, when their dependency pkgs change. b. They are already kept off testing (if there is a regression), so what's the problem? c. Very few packages are seriuosly broken on some archs. Their problems are generally due either to compiler/binutils problems or upstream coding. In both cases removing them on some archs could be a profitable solution for releasing. -- Francesco P. Lovergine
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Francesco P. Lovergine wrote: b. They are already kept off testing (if there is a regression), so what's the problem? The problem is that other packages which might depend from a package which is broken on one architecture will not move into testing. If you would keep those packages out of unstable you can be sure that you build your own package based on packages which have all the same version in unstable. This is the relevant bit of the suggestion. See the lot of packages which can not enter testing because a dependency is not fulfilled on a certain architecture. Kind regards Andreas.
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 11:10:14AM +0100, Andreas Tille wrote: On Wed, 19 Nov 2003, Luca - De Whiskey's - De Vitis wrote: If we let it in and then we auto-build it, we get a new package with FTBFS (i.e RC) bugs and slow down release even more. If we auto-build it first and, if no upstream/package faults, we let it in, we get less RC bugs. Exactly this was the idea. I'm unsure whether experimental could serve as this kind of staging area. A FTBFS for a new package is not a RC error. Only regressions are RC. -- Francesco P. Lovergine
Re: MIPS port backlog, autobuilder machines and some arrogance
Ingo Juergensmann [EMAIL PROTECTED] wrote: [...] Perl is building fine as well now on mips, although it is marked as not-for-us. See http://m68k.bluespice.org/cgi/package_status?mips_pkg=perlsearchtype=go paco:/home/ij# ls -l *.deb -rw-r--r--1 root root35172 Nov 18 22:24 libcgi-fast-perl_5.8.2-2_all.deb -rw-r--r--1 root root 651210 Nov 18 22:32 libperl-dev_5.8.2-2_mips.deb -rw-r--r--1 root root 1002 Nov 18 22:31 libperl5.8_5.8.2-2_mips.deb [...] Can somebody please give it a kick or an upload? Afaict Perl's testing migration is only blocked by missing builds for mips and mipsel. cu andreas
Re: First pass all buildds before entering unstable
Luca - De Whiskey's - De Vitis wrote: (...) Why developers should care more about packages not entering into unstable that packages not entering into testing? I worry about indirect delays. Scenario: developer A@ do good job with packages A, but A requires packages B. What should A do? Waiting and not lose the motivation? Help B@, maybe with a NMU, but still waiting the canonical time for NMU (on normal time)? Do A@ have knows enought about B to help? (Maybe B is in a other language, for glibc, XFree86,.. specific architectures knowelenge are maybe required,... If you want to implement such pre-autobuild I would like to see: - relaxed NMU time - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. - .. ciao giacomo
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 11:10:14AM +0100, Andreas Tille wrote: Exactly this was the idea. I'm unsure whether experimental could serve as this kind of staging area. I would keep experimental only for experiments (:P), while i see your proposal as a new step to be included in our packages workflow; thus i would use unstable. Moreover, experimental is not autobuilded because of high chances of broken packages in it. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Bug#221632: ITP: jaabc2ps -- Converts abc text music notation to postscript sheet music
Package: wnpp Severity: wishlist * Package name: jaabc2ps Version : 1.1.0 Upstream Author : John Atchley [EMAIL PROTECTED] * URL : http://www.guitarnut.com/ * License : GPL Description : Converts abc text music notation to postscript sheet music Produces postscript sheet music and tinwhistle and stringed-instrument tablature from abc music notation (text) files. A child of abcm2ps version 0.9.5, many features have been added. abcm2ps is a child of abc2ps. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux babasse 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote: I worry about indirect delays. Scenario: developer A@ do good job with packages A, but A requires packages B. What should A do? Waiting and not lose the motivation? Help B@, maybe with a NMU, but still waiting the canonical time for NMU (on normal time)? Do A@ have knows enought about B to help? (Maybe B is in a other language, for glibc, XFree86,.. specific architectures knowelenge are maybe required,... IMHO, We should not warry about indirect delay/problems. It's not A's fault, thus A should be warranted to be released (in a way or in another): A not being in testing because of B is part of the game. The problem which must be handled is B, and who or how to handle it is too case specific to be considered here. We have 'help' tag on BTS and specific mailing lists to ask for help on specific topic. BTW, when i did NMU i based the delay either on the best practice and on the need of the fix. I thought it to be reasonable. - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. I do not understand this: what do you mean? ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: First pass all buildds before entering unstable
Luca - De Whiskey's - De Vitis [EMAIL PROTECTED] wrote: On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote: I don't think people would like it if their package stayed in incoming for multiple weeks because there's a backlog on some architecture. Neither i. This is why i would like to receive baklogs mailed to maintainer if autobuild fails. But i would like to receive backlogs even for pre-autobuilds, so that i could fix the problem, contact the upstream etc. [...] backlog: Package is stuck in queue of autobuilder, no build failure. e.g. linuxtv-dvb_1.0.1-6 was uploaded on Oct 31 and Mips still has not _tried_ not build it. cu andreas
Re: Debian communication and attitude [was: Re: Example of really nasty DD behavior]
On Sun, Nov 16, 2003 at 12:44:03PM +0100, Henning Makholm wrote: No, but if you don't do it, you forfeit your right to whine about duplicate work when it turns out that you're not the only one who has been doing work without telling anybody about it. So, _both_ people involved should have ITPd, early. -- Jon Dowland http://jon.dowland.name/
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Giacomo A. Catenazzi wrote: I worry about indirect delays. Scenario: developer A@ do good job with packages A, but A requires packages B. What should A do? Waiting and not lose the motivation? But the problem can be the other way around: A builds his package against package of B which has no chance to enter testing. This is frustrating. Or even A builds his package against a version of package B which is fine but will be overriden by a new version of B which has an FTBFS bug before the old version of package B had a chance to enter testing. Help B@, maybe with a NMU, but still waiting the canonical time for NMU (on normal time)? Perhaps. Or rather B might be try harder to get his package into unstable. If you want to implement such pre-autobuild I would like to see: - relaxed NMU time - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. - .. Hmmm, why not, but this is not necessaryly connected to my suggestion. Kind regards Andreas. -- Sie schaffen eine Wüste und nennen es Frieden. -- Publius Cornelius Tacitus (55-120)
Re: Build-depends for Rekall?
Tom [EMAIL PROTECTED] writes: This seems on topic for the list's stated purpose: Discussion about technical development topics. I'm trying to build rekall from rekallrevealed.org. It seems like it's going to have lots of build dependencies. If anyone has ever built it on debian, or can provide a probable list of build-depends I'll need, I'd appreciate it. I've already done an apt-get build-depends kcontrol. I haven't made any special effort to get postgres or mysql build-depends on my system. (I intend to use it with the xbase driver for tiny personal databases). Thanks Use a clean chroot with just base and build-essential. After that you have to look for build errors or warnings thats some feature gets disabled due to missing libs or programs. MfG Goswin
Re: First pass all buildds before entering unstable
Andreas Tille [EMAIL PROTECTED] writes: Hi, just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. This would get us rid of all those packages in unstable with Does not build on ... and several dependencies could be easier solved. Moreover it would enhance the preasure on developers to care for this kind of bugs. I guess this would be not really hard to implement. Just ignore me if this is a stupid idea You are ignoring all the packages that don't build and never have been build for some architecture. Mainly that happens if some build-depends, like the compiler needed, wasn't yet ported. All the packages that are excluded from an arch indirectly because some other package is not for that arch would need to be changed to specifically exclude that arch. And once the actualy faulty package gets ported the change has to be reversed. There is a reason testing script only require archs that did previously build. MfG Goswin
Re: Some observations regardig the progress towards Debian 3.1
On Tue, Nov 18, 2003 at 10:15:25AM -0600, John Goerzen wrote: On Sat, Nov 15, 2003 at 05:35:19PM +, Andrew Suffield wrote: On Sat, Nov 15, 2003 at 05:42:20PM +0100, Adrian Bunk wrote: - Debian 3.0 doesn't support much of the hardware curently available - the old 2.4.18 kernel on the boot floppies doesn't even boot on many new computers (some Promise IDE chipsets require a more recent 2.4 ^^^ kernel), and much hardware from nearly all currently abailable ^^ This is false. All the promise IDE chipsets are adequetely supported by 2.4.18, albeit not in anything above ata-33 mode. The only problem is that autodetection fails for some of the newer ones, and you have to manually specify the controller ports. That's false. Bull. I've used several on 2.4.18 through 2.4.21 for years, and I'm fairly certain I covered all the chipsets (there aren't many). Don't try to tell me that it doesn't work. I still can't use my Promise drive in DMA mode (must use -d 0 with hdparm) because heavy write activity causes the kernel to hang. We are not talking about Promise hard drives (I didn't know they sold IDE drives, I've only seen SCSI ones under their label). And that does sound like a hard drive bug (or a bad cable) to me, I've seen a few drives do that before. This is not evidence of a lack of controller support. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Bug#217017: ITP: Sagasu - GNOME tool to find strings in a set of files
Sorry for my late reply: Am Don, 2003-10-23 um 15.17 schrieb Joe Drew: * Package name: sagasu Er, what does this add over the standard Search for files GNOME action? - use of Perl regex - max. directory recursion depth -- Daniel Gubser [EMAIL PROTECTED]
Re: perl 5.8.2-2 mips buildd
Domenico Andreoli, 2003-11-19 11:30:17 +0100 : i see that perl 5.8.2-2 is marked Not-For-Us on mips buildd. why it is in this state? it blocks the build of a lot of software. I'm currently building it by hand. Roland. -- Roland Mas Qu'est-ce qui est petit, jaune et vachement dangereux ? Un canari avec le mot de passe de root.
Re: Is vrms really still a Virtual Richard M. Stallman?
Roland Stigge wrote: debian-legalint I don't think this is a good idea. non-free doesn't mean illegal.
Re: Some observations regardig the progress towards Debian 3.1
On Wed, Nov 19, 2003 at 10:41:05AM +0100, Yann Dirson wrote: testsuites must be written, and testsuites for GUI programs are even more work. Fortunately several of the packages we ship already have one. Most do not. And for the bunch of non-gui programs, we could surely add some minimal testing, say to ensure it does not segfault on trivial use cases. Just like what we already do for manpages. Could? Yes. Do you have any notion of how much work this would be? It's somewhere in the region of lots. Actually writing real test suites for them all would be more of a Herculean task. GUI programs are another story, but that's not a reason not to do it for non-GUI ones. Right. It's a reason not to do any of it (test suites, or the building/migration goo) for GUI programs. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: First pass all buildds before entering unstable
Luca - De Whiskey's - De Vitis wrote: On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote: - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. I do not understand this: what do you mean? I don't like automatic system without possibility to have human overide. I want to be able to upload packages in unstable also if there are errors on some architectures, but only on very EXCEPTIONAL cases. OT: In testing happens that a packages will not uploaded in testing because package is buggier, but often the it is buggier because it is in unstable for a long time. You could not tell (AFAIK) that a bug was also present in the old testing version, but passed unnoticed. For this reason, I would like that smarted people (vs stupid script [Stupid from KISS definition]) can eventualy overide/upload packages in unstable. Surelly we need a strict policy about when and how it is allowed. ciao giacomo
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 07:42:18AM +0100, Andreas Tille wrote: just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. This would get us rid of all those packages in unstable with Does not build on ... and several dependencies could be easier solved. Moreover it would enhance the preasure on developers to care for this kind of bugs. This seems like a solution in search of a problem. What problem are you actually trying to solve? Start by describing it, then we can try dreaming up ways to solve it. [Given your vague description of what this would accomplish, I have a few guesses about what you might be trying to do, and I think there are probably less intrusive and more effective approaches]. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Goswin von Brederlow wrote: You are ignoring all the packages that don't build and never have been build for some architecture. Mainly that happens if some build-depends, like the compiler needed, wasn't yet ported. But this is no FTBFS bug than. I just want to keep packages which will have FTBFS bugs which can be automatically detected out of the door. Currently we have more than 100 FTBFS bugs. It is hard to say which of them could be detected at upload time. But if there is an automatic method to sort out packages even before they enter unstable we should do so to stop their influence to other dependant packages. There is a reason testing script only require archs that did previously build. Well, but this is done automatically. I do not want to change anything here. Kind regards Andreas. -- Sie schaffen eine Wüste und nennen es Frieden. -- Publius Cornelius Tacitus (55-120)
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Andrew Suffield wrote: This seems like a solution in search of a problem. What problem are you actually trying to solve? Start by describing it, then we can try dreaming up ways to solve it. [Given your vague description of what this would accomplish, I have a few guesses about what you might be trying to do, and I think there are probably less intrusive and more effective approaches]. Sorry if my English is not as brilliant to explain the problem clearly to everybody. So I try a simple example: http://qa.debian.org/developer.php?excuse=postgresql If there would be a recent perl for each architecture postgresql would have entered testing. I guess there was a working perl before there was trouble with MIPS buildd which wuold have enabled postgresql to enter testing. Feel free to search for other examples whose show stoppers are FTBFS bugs. Kind regards Andreas. -- Sie schaffen eine Wüste und nennen es Frieden. -- Publius Cornelius Tacitus (55-120)
New kernel headers break LVM build
LVM1 includes kernel headers in its build - yeah, I know, but it does interface (rather too) tightly into the kernel. The problem now is that the linux-kernel-headers package has Linux 2.6 files in it rather than 2.4 and LVM(1) is not supported in 2.6. so it doesn't build. This isn't a new problem with LVM. ie: not upgrading to 1.0.7 isn't the answer as 1.0.7 won't build in this environment either. Bug: #221663 The only solution I can think of is for the lvm10 package to build-depend on (eg) kernel-source-2.4.19, then in the build script untar the header files, make the arch symlink (ugh) and compile against that. Does anyone else have any nicer ideas? apart from getting everyone to migrate to LVM2 :-) -- patrick
Re: Is vrms really still a Virtual Richard M. Stallman?
On Wed, 2003-11-19 at 14:41, Florian Weimer wrote: debian-legalint I don't think this is a good idea. non-free doesn't mean illegal. In contrast to the common German denotation of the word legal (allowed), consider the one implied by the usage of legal in names like debian-legal (rechtlich, gesetzlich). bye, Roland signature.asc Description: This is a digitally signed message part
Re: Some observations regardig the progress towards Debian 3.1
+++ Yann Dirson [03-11-18 22:54 +0100]: On Tue, Nov 18, 2003 at 07:29:29PM +0100, Adrian Bunk wrote: But that last point raises another issue: does anyone really use testing ? Would anyone use pre-testing after all ? I used testing for a couple of years on my laptop and non-critical machines. I found it a satisfactory compromise between the 'too old' of stable and the massive churn, ever-changing packages and general need-for undating and maintenance of unstable. The primary reason I changed was the 'no security for testing' problem. So I have moved them both to unstable, but it's a lot of extra work and downloads for little gain (I get new packages sooner which is interesting but rarely actually useful) - the only other advantage I get (and the secondary reason I changed) is that I can do test-builds of my packages before uploading on an unstable machine. Doing my builds on a testing machine, then uploading to unstable can mean I introduce packages compiled against the wrong library versions. Source-only uploads would solve this and I could do test-compiles on some debian machine. So I'd say yes, testing is useful to real people, especially those with low-bandwidth net connections but for whom stable is a bit too old. The only thing we need to change to make it more widely useful is to make security updates happen for it in a timely fashion. That would be a sensible use of resources I think. More people using testing ought to help keep it releasable. Is testing actually worth the effort? I suppose many of use have a number of problems to mention. Could we just (attempt to) list them all, and see if they can be fixed easily ? Or if they require some in-depth restructuring ? I'll start with: - build-deps are ignored, causing unbuildable stuff = handle build-deps in exactly the same way deps are Could someone explain to me why this is the case? Was it an attempt to get things into testing faster that if build-deps were honoured, or was it just expediency. It does seem more sensible to enforce build-deps too to me, but I may be missing something. - insufficiently-narrowed deps, causing stuff to migrate where it should not = this looks like a real non-trivial problem to me. Ideas anyone ? Obviously it can be tricky for a maintainer to get right as they can't necessarily try all (any!) of the possibilities but it should be aspired-to. On the other hand, in my experience build-deps are sometimes unecessaily-narrowed and require new versions of things for no particular reason I can determine. I suspect the shlibdeps automation contributes to this? testing with its lack of security fixes, aprox. 500 RC bugs and daily changing packages is not usable for production systems. What's the problem with daily changing packages ? By nature, only different packages can change each day. That could make it a good compromise between stable and unstable, eg. for people in need for up-to-date desktops. But precisely, one of the problems for those people, is that _some_ packages _do_not_ change rapidly enough... It's all a compromise, but it's a useful compromise IMHO. It makes sense to me to view testing as a releasable version of unstable and try to keep it that way as much as possible. Build-deps being added to the unstable-testing migration criteria seems to me to be the most fundamental change needed to make that more true, and security support to make it practical for people to use/test in the real world. All the above IMHO as I don't claim to have a deep understanding of all the dependency and trnsitionning issues. I do have an interest in consistent buildability for embedded Debian though. Wookey -- Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK Tel +44 (0) 1223 811679 work: http://www.aleph1.co.uk/ play: http://www.chaos.org.uk/~wookey/
Hercules Stingray 128 3D Driver
Would you have a Win2K/WinXP driver? Thanks. WILLIAM E. FOSTER Chief, Information Technology Security DCS/Plans and Programs mailto:[EMAIL PROTECTED] comm: 703 695-3539 DSN: 225-3539 Ivy.gif
Re: New kernel headers break LVM build
On Wed, Nov 19, 2003 at 02:18:34PM +, Patrick Caulfield wrote: The only solution I can think of is for the lvm10 package to build-depend on (eg) kernel-source-2.4.19, then in the build script untar the header files, make the arch symlink (ugh) and compile against that. Does anyone else have any nicer ideas? apart from getting everyone to migrate to LVM2 :-) Fix LVM1 to keep copies of the headers it needs in it's source tree.
Re: Is vrms really still a Virtual Richard M. Stallman?
Roland Stigge wrote: On Wed, 2003-11-19 at 14:41, Florian Weimer wrote: debian-legalint I don't think this is a good idea. non-free doesn't mean illegal. In contrast to the common German denotation of the word legal (allowed), consider the one implied by the usage of legal in names like debian-legal (rechtlich, gesetzlich). Sorry, I don't understand what you are trying to say. Let me rephrase my statement. non-free does not mean not conforming to the law.
Re: Trouble Compiling Simple Glade.
Hi, debian-devel is a list for development of the Debian distribution, not a general programming list. For a more appropriate list, look on the glade website at glade.gnome.org. I'm afraid I can't help you with this problem, but I do offer some advice: use libglade to load the glade xml dynamically from your program rather than generating c code from the glade xml and then editing that - you will then find it far easier to modify your interface in the future. -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
Re: Hercules Stingray 128 3D Driver
On Wed, 2003-11-19 at 09:14, Foster William MSgt AF/XPI-ES wrote: Would you have a Win2K/WinXP driver? Thanks. WILLIAM E. FOSTER Chief, Information Technology Security DCS/Plans and Programs mailto:[EMAIL PROTECTED] comm: 703 695-3539 DSN: 225-3539 Sorry this is a mailing list for the Development of the Debian Linux Distribution. If you would like help with Windoze anything, please look elsewhere. By the way, messages sent to any [EMAIL PROTECTED] is very much a Debian Linux thing. Please choose your recipients more carefully. -- greg, [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Oh, how your melodic chewing of cotton balls cancels the stamp on my papyrus telegram from the Queen of England. signature.asc Description: This is a digitally signed message part
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 03:12:42PM +0100, Andreas Tille wrote: On Wed, 19 Nov 2003, Andrew Suffield wrote: This seems like a solution in search of a problem. What problem are you actually trying to solve? Start by describing it, then we can try dreaming up ways to solve it. [Given your vague description of what this would accomplish, I have a few guesses about what you might be trying to do, and I think there are probably less intrusive and more effective approaches]. Sorry if my English is not as brilliant to explain the problem clearly to everybody. So I try a simple example: http://qa.debian.org/developer.php?excuse=postgresql If there would be a recent perl for each architecture postgresql would have entered testing. I guess there was a working perl before there was trouble with MIPS buildd which wuold have enabled postgresql to enter testing. And if we hadn't had perl 5.8.1 in unstable, then we would never have spotted its binary incompatibility with 5.8.0. Upstream released 5.8.2 precisely because the problem had been discovered in Debian unstable. Under your proposal, we would have remained unaware of the problem for much longer, which would have been a bad thing. This is in fact an excellent example of how fixing build problems isn't enough to ensure a quality distribution, and how it's often important to parallelize fixing build problems and other problems rather than serializing the two tasks. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: perl 5.8.2-2 mips buildd
On Wed, Nov 19, 2003 at 11:05:49AM +0100, Domenico Andreoli wrote: i see that perl 5.8.2-2 is marked Not-For-Us on mips buildd. why it is in this state? it blocks the build of a lot of software. I'm told that getting it past the test suite requires a newer kernel, which our mips buildds don't currently have installed. -- Colin Watson [EMAIL PROTECTED]
Re: [debian-devel] Re: Is vrms really still a Virtual Richard M. Stallman?
A levelezm azt hiszi, hogy Florian Weimer a kvetkezeket rta: Let me rephrase my statement. non-free does not mean not conforming to the law. Non-free does mean not conforming to the internal law of the project. -- GNU GPL: csak tiszta forrsbl
Re: [debian-devel] Re: Is vrms really still a Virtual Richard M. Stallman?
Magosnyi rpd wrote: A levelezm azt hiszi, hogy Florian Weimer a kvetkezeket rta: Let me rephrase my statement. non-free does not mean not conforming to the law. Non-free does mean not conforming to the internal law of the project. The Social Contract mandates that Debian offers non-free software for download, so you can hardly argue that doing so breaks Debian's own laws.
Bug#221679: ITP: libglib-perl -- Perl interface to the Glib and GLib's GObject libraries
Package: wnpp Severity: wishlist * Package name: libglib-perl Version : 1.011 Upstream Author : Gtk2-Perl Team [EMAIL PROTECTED] * URL : http://search.cpan.org/~mlehmann/Glib-1.011/ * License : LGPL-2 Description : Perl interface to the Glib and GLib's GObject libraries This module provides perl access to GLib and GLib's GObject libraries. GLib is a portability and utility library; GObject provides a generic type system with inheritance and a powerful signal system. Together these libraries are used as the foundation for many of the libraries that make up the Gnome environment, and are used in many unrelated projects.
Re: [debian-devel] Re: Is vrms really still a Virtual Richard M. Stallman?
On Wed, Nov 19, 2003 at 04:04:49PM +0100, Florian Weimer wrote: Magosányi Árpád wrote: A levelez??m azt hiszi, hogy Florian Weimer a következ??eket írta: Let me rephrase my statement. non-free does not mean not conforming to the law. Non-free does mean not conforming to the internal law of the project. The Social Contract mandates that Debian offers non-free software for download, so you can hardly argue that doing so breaks Debian's own laws. Ehhh? Thus, although non-free software isn't a part of Debian, we support its use, and we provide infrastructure (such as our bug-tracking system and mailing lists) for non-free software packages. -- Excerpt from the social-contract This definitely does not _mandate_ that Debian offers non-free software, it says that we currently do so. Something mandatory is something that has to be done. Debian does not _have_ to offer non-free software (at least not to the best of my knowledge. If we do, I might have to go looking for a new project to be a part of...) Note: I'm not arguing against your protest regarding Debian's own laws, but rather your incorrect use of the word mandate. Regards: David -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Bug#221687: ITP: libextutils-pkgconfig -- simplistic perl interface to pkg-config
Package: wnpp Severity: wishlist * Package name: libextutils-pkgconfig Version : 1.00 Upstream Author : muppet [EMAIL PROTECTED] * URL : http://gtk2-perl.sourceforge.net/ * License : LGPL Description : simplistic perl interface to pkg-config The pkg-config program retrieves information about installed libraries, usually for the purposes of compiling against and linking to them. . ExtUtils::PkgConfig is a very simplistic interface to this utility, intended for use in the Makefile.PL of perl extensions which bind libraries that pkg-config knows. It is really just boilerplate code that you would've written yourself.
Bug#221684: ITP: libextutils-depends-perl -- easily build XS extensions that depend on XS extensions
Package: wnpp Severity: wishlist * Package name: libextutils-depends-perl Version : 0.102 Upstream Author : Paolo Molaro [EMAIL PROTECTED] * URL : http://gtk2-perl.sf.net/ * License : ? (Mailed upstream) Description : easily build XS extensions that depend on XS extensions This module tries to make it easy to build Perl extensions that use functions and typemaps provided by other perl extensions. This means that a perl extension is treated like a shared library that provides also a C and an XS interface besides the perl one. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux Asfaloth 2.4.21-rc2-ac2 #2 Don Mai 22 14:13:00 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: New kernel headers break LVM build
On Wed, Nov 19, 2003 at 03:33:53PM +0100, Christoph Hellwig wrote: On Wed, Nov 19, 2003 at 02:18:34PM +, Patrick Caulfield wrote: The only solution I can think of is for the lvm10 package to build-depend on (eg) kernel-source-2.4.19, then in the build script untar the header files, make the arch symlink (ugh) and compile against that. Does anyone else have any nicer ideas? apart from getting everyone to migrate to LVM2 :-) Fix LVM1 to keep copies of the headers it needs in it's source tree. including asm directories for all 18 architectures. Ah well; if it's already gross, making it hugely gross is not much of a descent. -- patrick
Re: Tabs v.s. spaces
Cameron Patrick wrote: Nope, no fall-through in that one, so it doesn't help. It /is/ nifty though :-) Uh, there was a fall through there. Notice that if x has a value that isn't in the dictionary the if will fall through to the else. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpM33yGILlrf.pgp Description: PGP signature
Re: Some observations regardig the progress towards Debian 3.1
I like this idea of pre-testing. It would allow to cut down the versionned dependencies caused by automatic detection and allow a quicker move to testing. The issue I see however is that a package rebuilded that way would go into testing without being tested by anyone. What if a given package fail to work when compiled with libs in testing? I agree that would be a missing versionning in the build-dep, but who would detect it? I'm afraid that such mistakes would lead to the disparition of the package from testing until its versionned build-dep comes into testing, which would be even more problematic than outdated content of testing, IMHO. Thanks, Mt. signature.asc Description: Digital signature
Re: New kernel headers break LVM build
You might be able to get away w/ simply including the lvm-specific kernel headers in your package, as long as the lower level asm stuff that it uses haven't changed their interface in 2.6. OTOH, it also might introduce subtle bugs. Maybe you're better off build-dep'ing. Sigh. I should probably rebuild lvm2 to see if the new kernel-headers package breaks it; I currently include 2.4 kernel headers in the package. On Wed, 19 Nov 2003 15:53:58 +, Patrick Caulfield wrote: On Wed, Nov 19, 2003 at 03:33:53PM +0100, Christoph Hellwig wrote: On Wed, Nov 19, 2003 at 02:18:34PM +, Patrick Caulfield wrote: The only solution I can think of is for the lvm10 package to build-depend on (eg) kernel-source-2.4.19, then in the build script untar the header files, make the arch symlink (ugh) and compile against that. Does anyone else have any nicer ideas? apart from getting everyone to migrate to LVM2 :-) Fix LVM1 to keep copies of the headers it needs in it's source tree. including asm directories for all 18 architectures. Ah well; if it's already gross, making it hugely gross is not much of a descent.
will we freeze?
On Tue, Nov 18, 2003 at 08:58:17AM -0500, Stephen Frost wrote: It would be really nice to have 7.4 in sarge.. Personally I think there should probably be enough time given the lack of messages on d-d-a regarding freezes and the like. 7.4 adds alot of nice things and speeds up a number of operations, etc. Will a freeze be announced? Is that how it has been done in the past? -- gram signature.asc Description: Digital signature
Re: will we freeze?
On Wed, Nov 19, 2003 at 10:43:22AM -0600, Graham Wilson wrote: On Tue, Nov 18, 2003 at 08:58:17AM -0500, Stephen Frost wrote: It would be really nice to have 7.4 in sarge.. Personally I think there should probably be enough time given the lack of messages on d-d-a regarding freezes and the like. 7.4 adds alot of nice things and speeds up a number of operations, etc. Will a freeze be announced? Is that how it has been done in the past? Yes. Check the debian-devel-announce archives June-2001 to June-2002 for mails with subject Woody Freeze Plans or Release Status Update by aj if you want to know how it (did not;-) work last time. cu andreas
Re: Some observations regardig the progress towards Debian 3.1
On Wed, Nov 19, 2003 at 02:03:08PM +, Wookey wrote: Doing my builds on a testing machine, then uploading to unstable can mean I introduce packages compiled against the wrong library versions. Source-only uploads would solve this and I could do test-compiles on some debian machine. Off topic - you can have an unstable chroot on your testing machine for this, eg. with pbuilder. - insufficiently-narrowed deps, causing stuff to migrate where it should not = this looks like a real non-trivial problem to me. Ideas anyone ? Obviously it can be tricky for a maintainer to get right as they can't necessarily try all (any!) of the possibilities but it should be aspired-to. On the other hand, in my experience build-deps are sometimes unecessaily-narrowed and require new versions of things for no particular reason I can determine. I suspect the shlibdeps automation contributes to this? Hm, the shlibdeps automation should not have an influence on build-deps, which belong to *source* packages only. One thing I see about this, however, is that sometimes a rebuild with more recent libs is required to get rid of some bug. And since there's no guaranty that a buildd has all latest versions (see http://people.debian.org/~dirson/buildinfo/ for a demo), I (and probably others) tend to add versionned builddeps as =, whereas it should probably be an unversionned build-dep, together with a version range in build-conflicts. There may also be the case where one cannot exactly determine from changelogs (debian _and_ upstream) what version of a builddep is needed, and make a safe bet. Regards, -- Yann Dirson[EMAIL PROTECTED] |Why make M$-Bill richer richer ? Debian-related: [EMAIL PROTECTED] | Support Debian GNU/Linux: Pro:[EMAIL PROTECTED] | Freedom, Power, Stability, Gratuity http://ydirson.free.fr/| Check http://www.debian.org/
Re: perl 5.8.2-2 mips buildd
On Wed, Nov 19, 2003 at 06:03:39PM +0100, Karsten Merker wrote: On Wed, Nov 19, 2003 at 02:58:16PM +, Colin Watson wrote: On Wed, Nov 19, 2003 at 11:05:49AM +0100, Domenico Andreoli wrote: i see that perl 5.8.2-2 is marked Not-For-Us on mips buildd. why it is in this state? it blocks the build of a lot of software. I'm told that getting it past the test suite requires a newer kernel, which our mips buildds don't currently have installed. Yes, at least on mipsel it needs a newer kernel. On mips there was an additional problem with glibc, for which a patch was in the works but I currently do not know whether it is already in the current unstable glibc. Thiemo? Should be: glibc (2.3.2.ds1-8) unstable; urgency=low [...] - Fix msqid_ds on MIPS. Dpatch from Guido Guenther, patch by Thiemo Seufer (Closes: #215273, #200215, #217593). [...] -- Daniel Jacobowitz [EMAIL PROTECTED] Tue, 28 Oct 2003 18:29:09 -0500 -- Colin Watson [EMAIL PROTECTED]
Re: First pass all buildds before entering unstable
Andreas Tille [EMAIL PROTECTED] writes: On Wed, 19 Nov 2003, Goswin von Brederlow wrote: You are ignoring all the packages that don't build and never have been build for some architecture. Mainly that happens if some build-depends, like the compiler needed, wasn't yet ported. It gets fetches, unpaked and then checkbuilddepends find problems. and puts it in Dep_wait. But this is no FTBFS bug than. I just want to keep packages which will have FTBFS bugs which can be automatically detected out of the door. Currently we have more than 100 FTBFS bugs. It is hard to say which of them could be detected at upload time. But if there is an automatic method to sort out packages even before they enter unstable we should do so to stop their influence to other dependant packages. There is a reason testing script only require archs that did previously build. Well, but this is done automatically. I do not want to change anything here. You can only detect if the package is uploaded. Anything else would need intelligend parsing of buildd logs. Checking only archs with previously build depends screens out any of the above cases, you should do the same in yor proposal. MfG Goswin
make-kpkg question
I'm building kernels for an embedded x86 product, and I'm falling in love with make-kpkg. My only problem is that make-kpkg --added-modules pcmcia-cs kernel_image modules_image doesn't do a depmod on the pcmcia-cs modules against the built kernel. I assume others have not run into this problem as default debian startup scripts do a depmod on the system...however, in an embedded product, every second that can be spared is needed. My goal is to just have make-kpkg build up images that can be just installed on a separate file-system (Compact Flash in my case) without any other work.. Am i just missing something here, or is this truley just a 'feature request' bug that should be submitted to the maintainers of make-kpkg?
Re: First pass all buildds before entering unstable
Giacomo A. Catenazzi [EMAIL PROTECTED] writes: Luca - De Whiskey's - De Vitis wrote: On Wed, Nov 19, 2003 at 11:21:18AM +0100, Giacomo A. Catenazzi wrote: - the developers (maybe requiring not only uploader) could override the waiting status in pre-unstable queue. I do not understand this: what do you mean? I don't like automatic system without possibility to have human overide. I want to be able to upload packages in unstable also if there are errors on some architectures, but only on very EXCEPTIONAL cases. OT: In testing happens that a packages will not uploaded in testing because package is buggier, but often the it is buggier because it is in unstable for a long time. You could not tell (AFAIK) that a bug was also present in the old testing version, but passed unnoticed. Test it and tag the bug sarge. MfG Goswin
Re: MIPS port backlog, autobuilder machines and some arrogance
On Mon, Nov 17, 2003 at 03:56:44PM +0100, Goswin von Brederlow wrote: DDs have to sign and upload a package with a backdoor. On the buildd I can install a gcc or other tool that will silently add a backdoor to anything getting compiled and the buildd admin will sign and upload the package for me. Much more anonymous. The whole point of signing packages is that it is not anonymous at all, but traceable back to the signer. Assuming the keyholder protects his key adequately, there is reasonable assurance that the keyholder and the signer are the same person. -- - mdz
Re: MIPS port backlog, autobuilder machines and some arrogance
On Wed, Nov 19, 2003 at 06:43:00AM +0100, Ingo Juergensmann wrote: Perl is building fine as well now on mips, although it is marked as not-for-us. See http://m68k.bluespice.org/cgi/package_status?mips_pkg=perlsearchtype=go This might be due to the fact that the autobuilders don't run recent enough kernels. I offered to binary NMU perl at least two weeks ago, but I was told that this will be taken care of soon. Cheers, -- Guido signature.asc Description: Digital signature
Re: First pass all buildds before entering unstable
On Wed, 19 Nov 2003, Andreas Tille wrote: just an idea from a completely uneducated person regarding buildd: What about if each freshly uploaded package which contains architecture any packages would enter kind of a staging area first and buildds grab these files from there. After each buildd was able to build a package the whole set with all architectures enters unstable at once. This would get us rid of all those packages in unstable with Does not build on ... and several dependencies could be easier solved. Moreover it would enhance the preasure on developers to care for this kind of bugs. I guess this would be not really hard to implement. You just described one of the many features of testing.
Bug#221709: ITP: at76c503a-source -- at76c503a driver source
Package: wnpp Severity: wishlist * Package name: at76c503a-source Version : 0.11.beta5 * URL : Oliver Kurth oku at masqmail dot cx * License : GPL Description : at76c503a driver source . Alternative driver for the Atmel AT76C503A based USB WLAN adapters. This driver is for linux kernel versions 2.4.X. . Currently, the driver has some limitations: * no promiscous, monitor or station mode and no support for libpcap, i.e. it does not work with Kismet or Airsnort and it cannot act as an WLAN access point. This is a restriction imposed by the current firmware. * The firmware for Intersil radios is old (Atmel doesn't update it anymore) and has more restrictions. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux bogon 2.4.23-pre5-ben0-bogon #1 Mon Nov 17 15:45:41 CET 2003 ppc Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
Hi, On Sun, Nov 16, 2003 at 11:20:21AM -0600, Steve Langasek wrote: On Sun, Nov 16, 2003 at 04:30:26PM +0100, Martin Schulze wrote: Kenshi Muto wrote: At Tue, 11 Nov 2003 11:59:24 +0100, Martin Schulze wrote: Preparation of Debian GNU/Linux 3.0r2 = An up-to-date version is at http://master.debian.org/~joey/3.0r2/. I am preparing the second revision of the current stable Debian distribution (woody) which will probably be released soon. This report is to allow people to comment on it and intervene whenever this is required. If you disagree with one bit or another, please reply to this mail and explain why these things should be handled differently. There is still time to reconsider. Please, please wait. Before you release r2, we must solve Japanese Watanabe font problem. See http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00142.html If I understood you correctly, you want me to remove these packages: ttf-kochi-mincho ttf-kochi-mincho-naga10 ttf-xwatanabe-mincho watanabe-vfont ttf-xtt-wadalab-gothic (source ttf-xtt) ttf-xtt-watanabe-mincho (source ttf-xtt) from the stable distribution due to license problems, right? That is possible. I'm not sure there's any reason to believe that there are licensing problems with these fonts. The official reply from Hitachi on this question, as posted at http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00323.html, This does not sound like something the real lawyer reviewed. seems quite unambiguous: they acknowledge that there are no laws on the books, in Japan or elsewhere, which give them grounds to claim that these fonts infringe their intellectual property rights. Rather, they have referenced previous out-of-court settlements as precedent. I agree. Unless Japanese law is created in a much different manner than it is in the rest of the world, the results of out-of-court settlements do not constitute legal precedents; they may provide insight into the legal counsel's assessment of their chances of winning a suit, but there are other factors that contribute to such an assessment besides the letter of the law -- most notably, the respective depths of the parties' pockets. If the party who is using HITACHI font is commercial entity, they may likely to pay some money to avoid costly litigation if settlement includes no actual financial impact. It does not even say how much they gained. I do not think the Japanese law is created in a much different manner. I don't believe that Debian should ingratiate itself to corporations who throw their weight around to carve out intellectual property without the sanction of the courts. Unless and until Hitachi is taking legal action against our distributors or users in Japan, I think Debian ought to ignore these apparently baseless claims. I agree. One question to ask is is this useful fonts? If not, we have totally different ground to remove this package based on uselessness :-) If we ever remeve this package, reason should not be We must do this because HITACH said so. That is dangerous path. Osamu
Re: perl 5.8.2-2 mips buildd
On Wed, Nov 19, 2003 at 05:42:29PM +, Colin Watson wrote: [...] - Fix msqid_ds on MIPS. Dpatch from Guido Guenther, patch by Thiemo Seufer (Closes: #215273, #200215, #217593). [...] ...additionally the current 2.4.22 mips kernel packages have the necessary fixes. The mips buildd needs a kernel update and we have binaries for this, mipsel kernels don't need to be updated since msqid64_ds already has the correct padding. -- Guido signature.asc Description: Digital signature
Re: Preparation of Debian GNU/Linux 3.0r2 (II)
Steve Langasek wrote: If I understood you correctly, you want me to remove these packages: ttf-kochi-mincho ttf-kochi-mincho-naga10 ttf-xwatanabe-mincho watanabe-vfont ttf-xtt-wadalab-gothic (source ttf-xtt) ttf-xtt-watanabe-mincho (source ttf-xtt) from the stable distribution due to license problems, right? That is possible. I'm not sure there's any reason to believe that there are licensing problems with these fonts. The official reply from Hitachi on this question, as posted at http://lists.debian.org/debian-legal/2003/debian-legal-200310/msg00323.html, seems quite unambiguous: they acknowledge that there are no laws on the books, in Japan or elsewhere, which give them grounds to claim that these fonts infringe their intellectual property rights. Rather, they have referenced previous out-of-court settlements as precedent. Unless Japanese law is created in a much different manner than it is in the rest of the world, the results of out-of-court settlements do not constitute legal precedents; they may provide insight into the legal counsel's assessment of their chances of winning a suit, but there are other factors that contribute to such an assessment besides the letter of the law -- most notably, the respective depths of the parties' pockets. I don't believe that Debian should ingratiate itself to corporations who throw their weight around to carve out intellectual property without the sanction of the courts. Unless and until Hitachi is taking legal action against our distributors or users in Japan, I think Debian ought to ignore these apparently baseless claims. So... the situation won't be changed for r2 and we can discuss this for r3. Regards, Joey -- Never trust an operating system you don't have source for!
Re: Bug#220301: ITP: entropy -- Emerging Network To Reduce Orwellian Potency Yield
Scripsit Mike Beattie [EMAIL PROTECTED] This is a good, though perhaps too detailed, long description. Taken directly from the web page... (I'm lazy) The description left me wondering whether this is just anonter peer-to-peer filesharing network, or there is something else to it. Either way, it should probably be mentioned in the description. If it *is* just another p2p, then explicitly mentioning this in the beginning of the description will save the reader the trouble of recognising the concept in an explanation from basic principles. If it is something else than just another p2p, the difference should probably be stated explicitly. -- Henning Makholm Det är alldeles för ansvarsfullt att skaffa en flickvän. Det är ju som att skaffa en hundvalp.
Re: Debian communication and attitude [was: Re: Example of really nasty DD behavior]
Scripsit Jonathan Dowland [EMAIL PROTECTED] On Sun, Nov 16, 2003 at 12:44:03PM +0100, Henning Makholm wrote: No, but if you don't do it, you forfeit your right to whine about duplicate work when it turns out that you're not the only one who has been doing work without telling anybody about it. So, _both_ people involved should have ITPd, early. Only if they want whining rights. It's perfectly legitimate to package some software as a personal learning experience, and afterwards, if and when the packaging happens to work, decide to contribute the package to the Debian archive. -- Henning MakholmWhat the hedgehog sang is not evidence.
Re: MIPS port backlog, autobuilder machines and some arrogance
On Wed, 19 Nov 2003 19:20:09 +0100, Guido Guenther wrote: On Wed, Nov 19, 2003 at 06:43:00AM +0100, Ingo Juergensmann wrote: Perl is building fine as well now on mips, although it is marked as not-for-us. See http://m68k.bluespice.org/cgi/package_status?mips_pkg=perlsearchtype=go This might be due to the fact that the autobuilders don't run recent enough kernels. I offered to binary NMU perl at least two weeks ago, but I was told that this will be taken care of soon. Cheers, Well, when it would be a real kernel issue, I wonder why I was able to successfully built perl 5.8.2-2 on 2.4.19-r4k-ip22? ;-) But I think we have either to wait until the buildd maintainer takes care of it or lolando finishes building perl on casals.d.o. ;-)) Ciao... Ingo
Re: MIPS port backlog, autobuilder machines and some arrogance
Martin Michlmayr - Debian Project Leader, on 2003-11-19, 14:32, you wrote: * Ingo Juergensmann [EMAIL PROTECTED] [2003-11-16 15:40]: Yes, a fairly powerful machine has recently been donated to Debian and we're currently working out where to host it. Where is it located? In the States; not really worth shipping to Germany. However, I'll see whether we can find some nice systems in Germany as well. As I already said at LinuxTag in Karlsruhe earlier this year, my employer is willing to host machines for Debian in Germany. So if need be, I can offer rackspace and connectivity in Ulm or Frankfurth. Joerg -- Joerg joergland Wendland GPG: 51CF8417 FP: 79C0 7671 AFC7 315E 657A F318 57A3 7FBD 51CF 8417 signature.asc Description: Digital signature
Re: Is vrms really still a Virtual Richard M. Stallman?
Scripsit Florian Weimer [EMAIL PROTECTED] Roland Stigge wrote: debian-legalint I don't think this is a good idea. Me neither. A virtual debian-legal would be something that analyzed licenses: $ debian-legalint COPYRIGHT.foo COPYRIGHT.foo:33: warning: mentions specific protocol standard COPYRIGHT.foo:57: talks about best efforts to contact upstream COPYRIGHT.foo:64: US export control laws $ echo $? 1 $ debian-legalint /usr/share/common-licences/GPL echo success success $ debian-legalint xterm /usr/share/doc/xterm/copyright:557: warning: obnoxious BSD advertising clause /usr/share/doc/xterm/copyright:571: warning: obnoxious BSD advertising clause $ While such a tool would certainly be useful, I'm afraid that it is an AI-complete problem. -- Henning Makholm En tapper tinsoldat. En dame i spagat. Du er en lykkelig mand ...
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 07:04:45PM +0100, Guido Guenther wrote: Package: wnpp Severity: wishlist * Package name: at76c503a-source Version : 0.11.beta5 * URL : Oliver Kurth oku at masqmail dot cx * License : GPL Description : at76c503a driver source That is my email addrss in the URL field... not the site to download. It is really http://at76c503a.berlios.de/ My name is correct for upstream, but you should also add Joerg Albert. . Alternative driver for the Atmel AT76C503A based USB WLAN adapters. This driver is for linux kernel versions 2.4.X. . Currently, the driver has some limitations: * no promiscous, monitor or station mode and no support for libpcap, i.e. it does not work with Kismet or Airsnort and it cannot act as an WLAN access point. This is a restriction imposed by the current firmware. * The firmware for Intersil radios is old (Atmel doesn't update it anymore) and has more restrictions. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux bogon 2.4.23-pre5-ben0-bogon #1 Mon Nov 17 15:45:41 CET 2003 ppc Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 I already filed an ITP for it, but I did not yet package it, for lack of time. It would be nice if I can work as co-maintainer for this package. There may also be issues with the firmware: the source is /not/ GPL'ed, but the hex files from Atmel are. I am not sure if this is possible, and if it is a problem for Debian to get it into main. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:06:32PM +0100, Guido Guenther wrote: Hi Oliver, On Wed, Nov 19, 2003 at 07:43:30PM +0100, Oliver Kurth wrote: That is my email addrss in the URL field... not the site to download. It is really http://at76c503a.berlios.de/ My name is correct for upstream, but you should also add Joerg Albert. Sure. It is (and always was) correct in the package (including Joergs Name). I just tried to keep things short in the ITP. Okay, but you placed an email into the URL field. I already filed an ITP for it, but I did not yet package it, for lack of time. It would be nice if I can work as co-maintainer for this package. You're very welcome! Thanks :-) There may also be issues with the firmware: the source is /not/ GPL'ed, but the hex files from Atmel are. I am not sure if this is possible, and if it is a problem for Debian to get it into main. This looks bad: /* license agreement. Any un-authorized use, duplication, * transmission, distribution, or disclosure of this software is expressly * forbidden. Do you have an agreement with Atmel to distribute the firmware? With this license the package can't even go into non-free. This is okay. Atmel allows to distribute those files, I have got a message from one of their developers, it should also be on the mailing list of the sf driver. I will try to find it again. The problem is just that they do not give the source for these files, and this may be a problem for Debian. Not for Atmel. Cc to debian-devel. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
vhi
vhi
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:01:40PM +0100, Oliver Kurth wrote: Okay, but you placed an email into the URL field. Cut'n'Paste erro. It's correct in the package. This is okay. Atmel allows to distribute those files, I have got a message from one of their developers, it should also be on the mailing list of the sf driver. I will try to find it again. I think this won't be sufficient. We also must be allowed to modify it to put the package into main. The current license violates at least clause 2 and 3 of the DFSG so there's no chance to put it into main. We might be able to put it into non-free if we're at least allowed to redistribute the files. Cheers, -- Guido signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 07:52:22PM +0100, Oliver Kurth wrote: There may also be issues with the firmware: the source is /not/ GPL'ed, but the hex files from Atmel are. I am not sure if this is possible, and if it is a problem for Debian to get it into main. IANAL, but... If the hex files are GPLed, they are probably not distributable -- hex .c files probably do not fall into the GPL's definition of source code (the preferred form of making alterations); without the driver source we do not have the source code and such can't distribute it without violating GPL. Check with debian-legal, perhaps? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:26:56PM +0100, Guido Guenther wrote: On Wed, Nov 19, 2003 at 08:01:40PM +0100, Oliver Kurth wrote: Okay, but you placed an email into the URL field. Cut'n'Paste erro. It's correct in the package. Fine. This is okay. Atmel allows to distribute those files, I have got a message from one of their developers, it should also be on the mailing list of the sf driver. I will try to find it again. I think this won't be sufficient. We also must be allowed to modify it to put the package into main. The current license violates at least clause 2 and 3 of the DFSG so there's no chance to put it into main. We might be able to put it into non-free if we're at least allowed to redistribute the files. I am sure these lines in the files can be removed, by bugging the Atmel people, or at least 'override' it with an 'It is okay' message from them. But you do not seem to see my point: the human readable sources of the firmware files are _not_ open. The hex files, ie. the compiled form, in ACSII format they say _are_ GPL'ed (despite the disclaimer in those files, see above). Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:41:32PM +0100, Steinar H. Gunderson wrote: On Wed, Nov 19, 2003 at 07:52:22PM +0100, Oliver Kurth wrote: There may also be issues with the firmware: the source is /not/ GPL'ed, but the hex files from Atmel are. I am not sure if this is possible, and if it is a problem for Debian to get it into main. IANAL, but... If the hex files are GPLed, they are probably not distributable -- hex .c files probably do not fall into the GPL's definition of source code (the preferred form of making alterations); without the driver source we do not have the source code and such can't distribute it without violating GPL. Check with debian-legal, perhaps? Maybe there can be an exception because the code is not run on the host but on the device? CC'ing debian-legal. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:00:48PM +, Henning Makholm wrote: Scripsit Oliver Kurth [EMAIL PROTECTED] But you do not seem to see my point: the human readable sources of the firmware files are _not_ open. The hex files, ie. the compiled form, in ACSII format they say _are_ GPL'ed (despite the disclaimer in those files, see above). What you're missing is that if one applies the GPL is applied to compiled code alone, it does not give any permission to distribute at all. GPL allows compiled code to be distributed only if it is accompanied with source, which these firmware files are not according to the GPL's own definition. So in this context GPL is equivalent to no permission to distribute. That may not be a problem for the original author (who, owning the copyright, can permit himself to distribute no matter what the license he offers to others say), but it is certainly a problem for Debian. Sourceless GPLed code cannot be distributed even in non-free. Sigh. So if Atmel says these files are no longer GPL'ed, but are just freely distributable, it could at least go to non-free? Sounds ridiculous. (Law is too complicated to me, so I stick to programming ;-) ) Is there any way to get this into main, maybe regarding the fact that this code is not run on the host but just on the device? I think Atmel would be open to change the license, but I do not think they will give the source to their holy (and btw buggy) firmware. Also CC'ing deebian-legal. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
Scripsit Oliver Kurth [EMAIL PROTECTED] But you do not seem to see my point: the human readable sources of the firmware files are _not_ open. The hex files, ie. the compiled form, in ACSII format they say _are_ GPL'ed (despite the disclaimer in those files, see above). What you're missing is that if one applies the GPL is applied to compiled code alone, it does not give any permission to distribute at all. GPL allows compiled code to be distributed only if it is accompanied with source, which these firmware files are not according to the GPL's own definition. So in this context GPL is equivalent to no permission to distribute. That may not be a problem for the original author (who, owning the copyright, can permit himself to distribute no matter what the license he offers to others say), but it is certainly a problem for Debian. Sourceless GPLed code cannot be distributed even in non-free. -- Henning Makholm Jeg kunne ikke undgå at bemærke at han gik på hænder.
Re: First pass all buildds before entering unstable
On Wed, Nov 19, 2003 at 03:43:31AM -0600, Luca - De Whiskey's - De Vitis wrote: On Wed, Nov 19, 2003 at 11:02:17AM +0100, Wouter Verhelst wrote: I don't think people would like it if their package stayed in incoming for multiple weeks because there's a backlog on some architecture. Neither i. This is why i would like to receive baklogs mailed to maintainer if autobuild fails. But i would like to receive backlogs even for pre-autobuilds, so that i could fix the problem, contact the upstream etc. Uh, I think we're not speaking the same English here. When I say this architecture has a backlog, I mean this architecture can't keep up with building. You can get the logs, they're at http://buildd.debian.org/ -- mails to package maintainers are superfluous; non-buildd people shouldn't be bothered with such stuff, as it isn't their problem in 99% of the cases. BTW, i think that the correct workflow would be: Move package from incoming to autobuild. If all architectures build, continue (as before this change); else, if not builded but is not upstrea/maintainer fault, continue (as before this change). Else reject the package. Unstable is there for that kind of things. And to detect other kinds of bugs, too. If you're going to keep packages in incoming like this, people won't be able to test it until it's built on all architectures. If we stay as it is, we'll continue to get slowed by badly built packages/softwares. So we slow the system down even more by holding packages for no real reason? I fail to see how that would help. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:25:44PM +, Henning Makholm wrote: Scripsit Oliver Kurth [EMAIL PROTECTED] If the hex files are GPLed, they are probably not distributable -- hex .c files probably do not fall into the GPL's definition of source code Maybe there can be an exception because the code is not run on the host but on the device? Who do you imagine making such an exception? The only one who can make an exception from the GPL's conditions is the copyright holder. And he can make whatever exceptions he likes, irrespective of where the code runs. See, the copyright holder has no problem if those files are distributed. They will not care. I can also reconfirm this by asking them. So the problem is if this can still comply with the DFSG. So the exception should be made by Debian. If this is not possible, maybe one workaround could be to make the paxkage without the firmmware files, and put them elsewhere on the web. So like libdvdread does it. Greetings, Oliver -- .''`. : :' :Oliver Kurth [EMAIL PROTECTED] `. `' Debian GNU/Linux maintainer - www.debian.org `- When sending passwords, please use my gpg key. That's what it's good for. signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
Scripsit Oliver Kurth [EMAIL PROTECTED] If the hex files are GPLed, they are probably not distributable -- hex .c files probably do not fall into the GPL's definition of source code Maybe there can be an exception because the code is not run on the host but on the device? Who do you imagine making such an exception? The only one who can make an exception from the GPL's conditions is the copyright holder. And he can make whatever exceptions he likes, irrespective of where the code runs. -- Henning Makholm Uh ... a picture of me with my hair pinned up in a towel and standing in front of a grid without a trace of makeup? *Are you out of your rock-happy mind?*
Re: Trouble Compiling Simple Glade.
On Wed, Nov 19, 2003 at 15:44:54 +1100, Peter Gatt wrote: [EMAIL PROTECTED]:~/Projects/project1$ ./autogen.sh \**Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. processing . Running aclocal ... aclocal: configure.in: 12: macro `AM_PATH_GTK' not found in library You don't have a package installed which defines this macro. Install libgtk2.0-dev (assuming you are using sarge or sid) or gnome-common (if you are using a system that still has a GNOME 1.4 environment). HTH, Ray -- A Microsoft Certified System Engineer is to information technology as a McDonalds Certified Food Specialist is to the culinary arts. Michael Bacarella commenting on the limited value of certification.
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, 19 Nov 2003, Oliver Kurth wrote: Sigh. So if Atmel says these files are no longer GPL'ed, but are just freely distributable, it could at least go to non-free? Yes. Sounds ridiculous. (Law is too complicated to me, so I stick to programming ;-) ) Thats part and parcel of the GPL... if the company doesn't include the prefered form for modification, no one else can distribute it. Is there any way to get this into main, maybe regarding the fact that this code is not run on the host but just on the device? I think Atmel would be open to change the license, but I do not think they will give the source to their holy (and btw buggy) firmware. Ugh. That's always annoying. Perhaps just a non-free package containing the firmware? (assuming we get permision to freely distribute it.) Is the firmware even necessary for the driver to work? One wonders why they don't just open up the source to the firmware drivers since they aren't planning on making any more updates to it. Don Armstrong -- A one-question geek test. If you get the joke, you're a geek: Seen on a California license plate on a VW Beetle: 'FEATURE'... -- Joshua D. Wachs - Natural Intelligence, Inc. http://www.donarmstrong.com http://www.anylevel.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: Bug#221709: ITP: at76c503a-source -- at76c503a driver source
On Wed, Nov 19, 2003 at 08:36:31PM +0100, Oliver Kurth wrote: I am sure these lines in the files can be removed, by bugging the Atmel people, or at least 'override' it with an 'It is okay' message from them. O.k., we can upload to non-free then. But you do not seem to see my point: the human readable sources of the firmware files are _not_ open. The hex files, ie. the compiled form, in ACSII format they say _are_ GPL'ed (despite the disclaimer in those files, see above). I fully see your point. Without the source code to the firmware we can't upload into main IMHO. -- Guido signature.asc Description: Digital signature
Re: Help with init replacement
On Tue, 18 Nov 2003, Marc A. Pelletier wrote: Now /that/ is interresting and smart and is indeed likely the most promising avenue for quick and dirty daemond integration in debian; the problem is that from what I have understood, update-rc.d suffers from, by design, exactly the same problem that rc.d style inits suffer from: no proper way of specifying dependencies and ordering other than by asigning a cardinal and a set of update-rc.d needs either another interface layer, or a sister command to register dependencies, alright. Want to take on the job? It must be made _very_ generic, a dependency-rc.d (or whatever) that would allow us to plug daemond, as well as the other dependency-based init script systems is very welcome. Don't forget invoke-rc.d either, and if you are mucking with init itself, also telinit. The *correct* way of doing all this, of course, is for packages to create their own service definition file and install them (possibly through some Nope. The correct way is to have a proper init system layer that can handle static and dynamic dependencies. I actually like the idea of service definition files, as long as they are generic (but I quite dislike the idea that one would probably need to run a update-dependency-rc.d or whatever script to transfer what is in the files to whatever init system is in use). every package that possibly wants to add themselves to the bootstrap. In No. You just have to add a compatibility service that runs the non-dependency-based services as the stock sysv-init rc.d does. Oh, OF COURSE this doesn't give you all the imediate benefits, but it won't break the entire system. other words, that can't be done before some time after daemond /already/ is the de facto init process. THAT won't happen easily. OTOH, _IF_ a proper layer is written, tested and deployed, it is feasible to switch all the packages to something that works with it in optimal mode for the release after sarge. We already have at least one very good dependency-based initscript system in Debian, so daemond is not alone in its troubles. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
