Re: ITO: xkeycaps
Re: J.H.M. Dassen (Ray) in <[EMAIL PROTECTED]> > I intend to orphan xkeycaps. > > If you are interested in taking over this package, do let me know. I'm using this package and I'd take it. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sunday 20 February 2005 23:57, Dirk Eddelbuettel wrote: > Clint Byrum spamaps.org> writes: > But then it doesn't matter anymore. These days, Debian is > "infrastructure". We no longer make releases. We provide the basis from > which others make releases -- Ubuntu, Prodigy, Knoppix, Custom debian > dists etc pp. em. at least for CDD's this is false, CDD-releases build on Debian releases as the only differences between a CDD and Debian are: - the initial set of installed packages - the default configuration of those packages (- some additions/changes not _yet_ added/merged back into Debian proper) CDD's are currently based on Debian-stable (which is the reason Skoleinux, for example. is still using kde 2.2), and eagerly anticipating the release of Sarge -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpaHE3oNI8da.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > Clint Byrum spamaps.org> writes: > > Now, can someone please tell me how messages like the one below, and > > others, aren't indicative that debian should drop s390, mipsel, and > > maybe hppa from the list of architectures? How about we release for > > i386, sparc, and powerpc, and let the others release on their own > > schedule? This business of supporting 11 architectures and making sure > > they're all 100% right before releasing is just about the worst idea > > ever. > > Couldn't agree more. > > Our chances of actually releasing one day could only increase if we > dropped arches such as mipsel, s390, m68k, ... and concentrated on > those that actually mattered: i386, powerpc, amd64 -- and I'll gladly > add a few more. I'll believe that when you can point me to an actual occasion where something not being built on /only/ one of those "less mattering" architectures you want to drop (as opposed to the three latter ones) effectively stalled the release. As it is, architecture-specific problems occur on all architectures, not just the "less important" ones. Claiming the contrary only proves you don't know what you're talking about. The problem being talked about (not enough disk space on the buildd host) is serious, but can be fixed; and /nothing/ prevents it from happening to other architectures in the future. > But a total of eleven is insane. It is sometimes hard to get them all to work, yes. It also vastly increases the quality of the Free Software in our archive, as we discover bugs that appear only on one architecture. It also ensures that GNU/Linux still actually runs on the platforms we support, which is often of great importance of embedded developers. It also ensures that gcc remains working (what better way to test a compiler than to compile 10G worth of software with it?), and so on. [...] > Still, the hours we maste on fixing, building, maintaining, ... code > on unused platforms is hysterical waste of resources. The only resource that is being wasted, is one of disk space (well, and network traffic for mirror updates). How is that a major problem, considering that mirrors will be allowed to pick their architecture in the future? > Resources we don't really have. On porting, we usually have all the resources we really need. > It would be better to concentrate on a core of packages, and > platforms, and then get on with it. One day it will break the > infrastructure provision, at which point someone will fork our > high-priority core packages. You're welcome to do so, if you really must. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: > Also, really huge stuff, like KDE, cannot be uploaded as frequently as > perhaps the maintainers would like because it kills the slower buildd's > for a few days. Hypothetical daily KDE builds would also insanely increase the amount of network traffic being used by the mirror pulse and people upgrading their home boxes, so it isn't just a buildd problem. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 12:09:16AM -0300, Henrique de Moraes Holschuh wrote: > On Sun, 20 Feb 2005, Brian Nelson wrote: > > Also, really huge stuff, like KDE, cannot be uploaded as frequently > > as perhaps the maintainers would like because it kills the slower > > buildd's for a few days. > > The answer to that is to setup a dist-cc cluster for these archs, > where only the master node is in the slow arch, and everything else is > a fast arch. That would require cross-compilers on the other hosts in the distcc cluster, and (unless I don't understand how dist-cc works; never had a look at it) a mechanism to install build-dependencies on those hosts in addition to the one on the 'slow' node. There are a few reasons why we usually avoid cross-compilers for buildd purposes. For one, as one cannot as easily test a cross-compiler by running a test suite, it may have been miscompiled -- but you wouldn't notice; this would result in strange, hard to debug behaviour by the resulting cross-compiled packages. For another, satisfying build-dependencies for cross-compiling is pretty hard, as anyone using dpkg-cross can tell you. Our answer simply is (or at least, should be) to increase the number of buildd hosts if we can't keep up, and to request the maintainers of large packages that they don't do daily updates, which is a bad idea anyway. If maintainers insist on doing daily updates, we stop building their package. See mozilla-snapshot (even though it's no longer in the archive these days). -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Le Lun 21 Février 2005 11:38, Wouter Verhelst a écrit : > On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: > > Also, really huge stuff, like KDE, cannot be uploaded as frequently > > as perhaps the maintainers would like because it kills the slower > > buildd's for a few days. > > Hypothetical daily KDE builds would also insanely increase the amount > of network traffic being used by the mirror pulse and people > upgrading their home boxes, so it isn't just a buildd problem. that's true, though this is because partial uploads are not possible I mean that you have no way to say for huge source packages : you only need to build this , this, this and this pacakge. since the changes I've made won't affect the others. I know this raises practical problems (the worst of it not beeing able to construct the same packages that are on the archive when starting from source+diff). But if one day BW is critical, there is a path to explore here. -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpXPKHIGiGGX.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Wouter Verhelst wrote: > On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: > > Also, really huge stuff, like KDE, cannot be uploaded as frequently as > > perhaps the maintainers would like because it kills the slower buildd's > > for a few days. > > Hypothetical daily KDE builds would also insanely increase the amount of > network traffic being used by the mirror pulse and people upgrading > their home boxes, so it isn't just a buildd problem. Those would need to go into experimental, where no buildd problem exists by definition. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 12:04:37PM +0100, Pierre Habouzit wrote: > I know this raises practical problems (the worst of it not beeing able > to construct the same packages that are on the archive when starting > from source+diff). But if one day BW is critical, there is a path to > explore here. Oh, absolutely; but let's not forget that we can't even correctly specify how we only want to build arch-dep vs arch-indep packages currently... -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Thiemo Seufer] > Those would need to go into experimental, where no buildd problem > exists by definition. I'm told there are some autobuilders for experimental, and believe your definition of experimental need some adjustment. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
In article <[EMAIL PROTECTED]> you wrote: > Hypothetical daily KDE builds would also insanely increase the amount of > network traffic being used by the mirror pulse and people upgrading > their home boxes, so it isn't just a buildd problem. Perhaps it helps, if the buildds for slow systems introduce some delay before startng the build, and not building if another architecture failed at all. That way if a package is often uploaded or hase obvious errors, the build for that is skipped. BTW: is s390 one of those slow architectures? I bet IBM dont want to hear that? Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 21 Feb 2005, Wouter Verhelst wrote: > That would require cross-compilers on the other hosts in the distcc Not from what I know of dist-cc. You just need dist-cc, and nothing else. dist-cc just offloads the number-crunching, so it uses no data from the non-master node. AFAIK anyway (which is NOT much on dist-cc matters). > There are a few reasons why we usually avoid cross-compilers for buildd I know. But dist-cc is not a cross-compiler. And unlike a buildd farm like m68k has, it will cut down the ammount of time it takes for a BIG package to be compiled. -- "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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: useless trivia, oldest opened bug in Debian
On Sat, 2005-02-19 at 23:06 -0600, Micah Anderson wrote: >#957: dpkg 957 802533782 open [EMAIL PROTECTED] wishlist > Do I get a medal when I fix this in the next week or two? :) I've been working on an implementation over the weekend that's to my liking. Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Petter Reinholdtsen wrote: > [Thiemo Seufer] > > Those would need to go into experimental, where no buildd problem > > exists by definition. > > I'm told there are some autobuilders for experimental, And how would missing builds there be a problem? > and believe your definition of experimental need some adjustment. :) Daily build+upload of a package prevents it from migrating ever to testing. IMHO uploading daily builds to unstable is inappropriate, especially since packages in unstable are supposed to be in a generally releasable state, and daily changes in a package are unlikely to meet that standard. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
* Petter Reinholdtsen ([EMAIL PROTECTED]) [050221 12:30]: > [Thiemo Seufer] > > Those would need to go into experimental, where no buildd problem > > exists by definition. > I'm told there are some autobuilders for experimental, and believe > your definition of experimental need some adjustment. :) Thiemo knows that pretty well :) However, if they are overloaded/broken/whatever, the real implications are quite limited, and it doesn't matter for purposes like preparation of the next stable release. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
> There are a few reasons why we usually avoid cross-compilers for buildd > purposes. For one, as one cannot as easily test a cross-compiler by > running a test suite, it may have been miscompiled -- but you wouldn't > notice; this would result in strange, hard to debug behaviour by the > resulting cross-compiled packages. For another, satisfying This can be solved by using emulation tools (like qemu). Unfortunately qemu doesn't support m68k as a target yet. It would not only help for cross buildd's, but also allow maintainers to debug arch specific problems in their package on their laptop :) > build-dependencies for cross-compiling is pretty hard, as anyone using > dpkg-cross can tell you. > Yes, this is not solved yet, although emdebian and scratchbox are making progress in this area. Someday this problem will be mastered, at least for archs which have qemu support. The critical part is executing target code in maintainer and build scripts. This can be done using qemu user emulation. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Peter 'p2' De Schrijver] > This can be solved by using emulation tools (like > qemu). Unfortunately qemu doesn't support m68k as a target yet. It > would not only help for cross buildd's, but also allow maintainers > to debug arch specific problems in their package on their laptop :) For m68k, there is uae, http://www.freiburg.linux.de/~uae/> which is claimed to run Linux when the MMU patch is applied. I was once able to boot the kernel but unable to mount the root directory. Unfortunately, uae lack a working network interface, and has limited use here. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 11:49:46AM +0100, Thiemo Seufer wrote: > Wouter Verhelst wrote: > > On Sun, Feb 20, 2005 at 05:21:50PM -0800, Brian Nelson wrote: > > > Also, really huge stuff, like KDE, cannot be uploaded as frequently as > > > perhaps the maintainers would like because it kills the slower buildd's > > > for a few days. > > > > Hypothetical daily KDE builds would also insanely increase the amount of > > network traffic being used by the mirror pulse and people upgrading > > their home boxes, so it isn't just a buildd problem. > > Those would need to go into experimental, where no buildd problem > exists by definition. http://experimental.ftbfs.de/ (but I agree that the problem is much less important there; and I personally don't really care about it as much as I do about unstable -- the latter contains packages that should at one point try to get released, while the former does not) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, Feb 21, 2005 at 12:16:38PM +0100, Bernd Eckenfels wrote: > In article <[EMAIL PROTECTED]> you wrote: > > Hypothetical daily KDE builds would also insanely increase the > > amount of network traffic being used by the mirror pulse and people > > upgrading their home boxes, so it isn't just a buildd problem. > > Perhaps it helps, if the buildds for slow systems introduce some delay > before startng the build, and not building if another architecture > failed at all. That way if a package is often uploaded or hase obvious > errors, the build for that is skipped. We've considered that, but it hasn't happened yet. > BTW: is s390 one of those slow architectures? I bet IBM dont want to hear > that? The problem with s390 is that you can't just go to eBay and buy yourself an s390; or even if you could, that you would still require some hosting for it (a fridge-sized machine isn't exactly cheap to host in a data center, and I'd prefer your electricity bill to contain the machine's power needs over mine), so we rely on s390 owners to donate us a virtual machine on their box, which may or may not use the full CPU power of the machine it's hosted on. The same isn't true for (e.g.) m68k, which results in the latter being better supported (in some ways, such as one of the m68k buildd hosts (jt7) having 256M of RAM and 120G of disk space) than s390. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, 2005-02-21 at 13:36 +0100, Wouter Verhelst wrote: > On Mon, Feb 21, 2005 at 12:16:38PM +0100, Bernd Eckenfels wrote: > > In article <[EMAIL PROTECTED]> you wrote: [snip] > The problem with s390 is that you can't just go to eBay and buy yourself > an s390; or even if you could, that you would still require some hosting > for it (a fridge-sized machine isn't exactly cheap to host in a data > center, and I'd prefer your electricity bill to contain the machine's > power needs over mine), so we rely on s390 owners to donate us a virtual > machine on their box, which may or may not use the full CPU power of the > machine it's hosted on. What about Hercules? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. GGLX : Gnome GNU Linux X.Org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, Feb 21, 2005 at 12:33:24AM +0100, Goswin von Brederlow wrote: > Dropping some archs would only have one benefit. There would be mirror > space to include amd64. Well, that's quite a compelling reason. It's embarassing that amd64 won't be official in sarge. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Steve Langasek] > The four most common porting problems for software are endianness > (differs between i386/amd64 and powerpc), word size (differs between > i386/powerpc and amd64), char signedness (differs between i386/amd64 > and powerpc), and use of non-PIC code in shared libs (which is a > problem on *all* non-i386 platforms). I'd add unaligned data access (broken or at least problematic on most non-i386). Again, though, it's not something s390 or mipsel have special problems with. Peter signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Henrique de Moraes Holschuh] > Not from what I know of dist-cc. You just need dist-cc, and nothing > else. dist-cc just offloads the number-crunching, so it uses no data > from the non-master node. AFAIK anyway (which is NOT much on dist-cc > matters). Right. distcc runs the C preprocessor on the master and just sends preprocessed source and compiled code across the network. So the slave nodes could just as well be using a cross-arch gcc/gas, no external dependencies. The main problem with distcc across architectures is the FUD surrounding whether gcc-as-cross-compiler spits out the same code as gcc-as-native-compiler. The gcc team seem to be very hesitant to make any guarantees about that, as it's not something they test much. Without better information than guesswork, I'd say you might minimise your chances of cross-gcc bugs by using a host with the same endianness and bit width. signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Pierre Habouzit] > I mean that you have no way to say for huge source packages : you > only need to build this , this, this and this pacakge. since the > changes I've made won't affect the others. As far as mirror bandwidth goes (including end user bandwidth *from* the mirrors), that's a problem for rsync/zsync to solve. Of course, that doesn't help with buildd time, which is still a bottleneck in certain cases. Peter signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Le Lun 21 Février 2005 14:13, Peter Samuelson a écrit : > [Pierre Habouzit] > > > I mean that you have no way to say for huge source packages : you > > only need to build this , this, this and this pacakge. since the > > changes I've made won't affect the others. > > As far as mirror bandwidth goes (including end user bandwidth *from* > the mirrors), that's a problem for rsync/zsync to solve. yes and no because when you build a new package : 1- binary backages do not have the same name (so rsync/apt-get are lost) 2- if you build them for real, they won't be exactly the same (think of /usr/share/doc/your-package/changelog.Debian.gz e.g.) anyway, I'm not sure we really want to do such things ... -- ·O· Pierre Habouzit ··O OOOhttp://www.madism.org pgpMUWItfsl2T.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
[Pierre Habouzit] > > As far as mirror bandwidth goes (including end user bandwidth *from* > > the mirrors), that's a problem for rsync/zsync to solve. > > 1- binary backages do not have the same name (so rsync/apt-get are lost) It's still a problem for rsync/zsync to solve. I didn't mean to say they had already solved it. zsync already seems to be moving in the direction of application-specific hacks - I don't see why "call an external script to produce a list of files to check the checksums against" should not be one such hack. Since zsync (unlike rsync) does all the heavy lifting on the receiving side, this seems very feasible. > 2- if you build them for real, they won't be exactly the same (think >of /usr/share/doc/your-package/changelog.Debian.gz e.g.) zsync already reaches inside a gzip file and effectively rsyncs the uncompressed version. No reason it couldn't be made a bit smarter so as to look inside the components of a .deb ar file. This being a fairly interesting use case for zsync, I expect it's already being considered, if not implemented. Peter signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
> The main problem with distcc across architectures is the FUD > surrounding whether gcc-as-cross-compiler spits out the same code as > gcc-as-native-compiler. The gcc team seem to be very hesitant to make > any guarantees about that, as it's not something they test much. > Without better information than guesswork, I'd say you might minimise > your chances of cross-gcc bugs by using a host with the same endianness > and bit width. I guess differences in floating point implementations might be an issue too for expressions containing floats which can be evaluated at compile time. Cheers, Peter (p2). signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 07:25:02AM -0600, Peter Samuelson wrote: > zsync already reaches inside a gzip file and effectively rsyncs the > uncompressed version. No reason it couldn't be made a bit smarter so > as to look inside the components of a .deb ar file. This being a > fairly interesting use case for zsync, I expect it's already being > considered, if not implemented. at least considered ;) seriously, if zsync stabilizes (which will take a while) it would provide us with a way (together with some other stuff) to sync our mirrors while taking only a fraction of the bandwidth currently needed. this can't be bad. but it would mean we have to store .zsync files besides the debs (+ ~1% size) and talk the mirror admins into running an update script that is way more complex than two-phase rsync and needs a wee bit more processing power on their side. anyway, it's too early to speculate about stuff like that... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: ITO: xkeycaps
On Mon, Feb 21, 2005 at 11:00:03 +0100, Christoph Berg wrote: > I'm using this package and I'd take it. Thank you Christoph, it's yours. Ray -- "My golden rule of computing is reboot your system every morning." Jon C.A. DeKeles, Technical Director, ZDNet AnchorDesk in http://www.zdnet.com/anchordesk/story/story_4100.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Petter Reinholdtsen <[EMAIL PROTECTED]> writes: > But at the moment, there are very few problems with the autobuilders, > it seem. The packages with missing builds on some archs are listedon > http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz>, > and it is not bad compared to earlier. > > Missing archiectures blocking packages: arm(86) mips(84) ia64(74) > alpha(65) mipsel(64) m68k(61) sparc(60) powerpc(59) s390(51) hppa(46) > i386(5) > > Of course, the relative order and package count in this list varies a > lot over time. Not to mention that i386 only gets a very small percentage of packages to build and still has 5 blockers. That compares to 50-500 blockers for other archs, hence my earlier statement of i386 being the worst. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296279: ITP: tarp -- small script adding progress bar support for GNU tar
Package: wnpp Severity: wishlist Owner: Grzegorz Bizon <[EMAIL PROTECTED]> * Package name: tarp Version : 0.9 Upstream Author : Michal Kwiatkowski <[EMAIL PROTECTED]> * URL : http://joker.linuxstuff.pl * License : GPL Description : small script adding progress bar support for GNU tar Simple perl script adding progress bar support for GNU tar. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-rc3 Locale: LANG=pl_PL.ISO-8859-2, LC_CTYPE=pl_PL.ISO-8859-2 (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Wouter Verhelst <[EMAIL PROTECTED]> writes: > On Mon, Feb 21, 2005 at 12:09:16AM -0300, Henrique de Moraes Holschuh wrote: >> On Sun, 20 Feb 2005, Brian Nelson wrote: >> > Also, really huge stuff, like KDE, cannot be uploaded as frequently >> > as perhaps the maintainers would like because it kills the slower >> > buildd's for a few days. >> >> The answer to that is to setup a dist-cc cluster for these archs, >> where only the master node is in the slow arch, and everything else is >> a fast arch. > > That would require cross-compilers on the other hosts in the distcc > cluster, and (unless I don't understand how dist-cc works; never had a > look at it) a mechanism to install build-dependencies on those hosts in > addition to the one on the 'slow' node. Actualy I think dist-cc requires a cross-gcc on the other nodes and then sends the preprocessed C/C++ source to those nodes and the binary objects back. All the configure tests, linking and testcases would be done on the real host. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Peter Samuelson <[EMAIL PROTECTED]> writes: > [Pierre Habouzit] >> > As far as mirror bandwidth goes (including end user bandwidth *from* >> > the mirrors), that's a problem for rsync/zsync to solve. >> >> 1- binary backages do not have the same name (so rsync/apt-get are lost) > > It's still a problem for rsync/zsync to solve. I didn't mean to say > they had already solved it. zsync already seems to be moving in the > direction of application-specific hacks - I don't see why "call an > external script to produce a list of files to check the checksums > against" should not be one such hack. Since zsync (unlike rsync) does > all the heavy lifting on the receiving side, this seems very feasible. Apt-get knows the old filename (in its cache) and the new one. It also knows about the relationship (old version / new version). "All" it has to do is use the old file as template. >> 2- if you build them for real, they won't be exactly the same (think >>of /usr/share/doc/your-package/changelog.Debian.gz e.g.) Think of compiler doing optimisation with random heuristics producing different code each time. Or differen compiler revisions creating different code. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Robert Lemmen <[EMAIL PROTECTED]> writes: > On Mon, Feb 21, 2005 at 07:25:02AM -0600, Peter Samuelson wrote: >> zsync already reaches inside a gzip file and effectively rsyncs the >> uncompressed version. No reason it couldn't be made a bit smarter so >> as to look inside the components of a .deb ar file. This being a >> fairly interesting use case for zsync, I expect it's already being >> considered, if not implemented. > > at least considered ;) > > seriously, if zsync stabilizes (which will take a while) it would > provide us with a way (together with some other stuff) to sync our > mirrors while taking only a fraction of the bandwidth currently needed. > this can't be bad. but it would mean we have to store .zsync files > besides the debs (+ ~1% size) and talk the mirror admins into running an > update script that is way more complex than two-phase rsync and needs a > wee bit more processing power on their side. anyway, it's too early to > speculate about stuff like that... It only shifts processing power from the upstream mirror to the client mirror. No increase. If mirrors in turn shut down rsync support they should see an overall decrease in cpu and I/O consumption. (the enduser clients get the load). And even if mirrors still do rsync the users themself can use zsync and reduce the bandwith used by the mirror. That alone is worth it for both mirrors and users. > cu robert MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Thiemo Seufer <[EMAIL PROTECTED]> writes: > Those would need to go into experimental, where no buildd problem > exists by definition. > > > Thiemo Except for the 11 archs with experimental buildds. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
zaptel_1.0.4-2 in experimental
Hi, A new version of the zaptel package can be found in experimental, it tries to fix various bugs, I would appreciate any help to test it. Thanks a lot, -- Santiago Ruano RincÃn Grupo GNU/Linux Universidad del Cauca Avatar LTDA. Llave pÃblica GPG ID = 6FECCDE0 Huella digital = 3821 4FB5 774A 611D 31E4 B268 414B 8423 6FEC CDE0 signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: How to force an update if package names changed?
Quoting Hendrik Frenzel <[EMAIL PROTECTED]>: > Provides: pack-gui-lang-de, pack-gui-lang > Conflicts: pack-gui-lang-de Adding the following line to the ones above should do it: Replaces: pack-gui-lang-de -- $400 million in gold bullion Honduras president radar [Hello to all my fans in domestic surveillance] tritium cryptographic Kennedy Semtex CIA Nazi explosion AK-47 security Cocaine [See http://www.aclu.org/echelonwatch/index.html for more about this] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Bernd Eckenfels <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]> you wrote: >> Hypothetical daily KDE builds would also insanely increase the amount of >> network traffic being used by the mirror pulse and people upgrading >> their home boxes, so it isn't just a buildd problem. > > Perhaps it helps, if the buildds for slow systems introduce some delay > before startng the build, and not building if another architecture failed at > all. That way if a package is often uploaded or hase obvious errors, the > build for that is skipped. What would help save many hours on slow systems is having a script automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources according to Build-Depends to prevent useless buildd attempts and failures and manual work to retry them. An attempt to build something big can take 3-4 hours to install Build-Depends, see they aren't sufficient and to purge them again. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: useless trivia, oldest opened bug in Debian
Scott James Remnant <[EMAIL PROTECTED]> writes: > On Sat, 2005-02-19 at 23:06 -0600, Micah Anderson wrote: > >>#957: dpkg 957 802533782 open [EMAIL PROTECTED] wishlist >> > Do I get a medal when I fix this in the next week or two? :) I've been > working on an implementation over the weekend that's to my liking. > > Scott You get a gravestone for the bug in the nethack style if you tell me when you're done. :) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Petter Reinholdtsen wrote: [snip] > But at the moment, there are very few problems with the autobuilders, > it seem. The packages with missing builds on some archs are listedon > http://developer.skolelinux.no/info/cdbygging/distdiff-all.html.gz>, > and it is not bad compared to earlier. > > Missing archiectures blocking packages: arm(86) mips(84) ia64(74) > alpha(65) mipsel(64) m68k(61) sparc(60) powerpc(59) s390(51) hppa(46) > i386(5) This looks worse than it is, btw., because of erraneous builds for some architectures which aren't removed from the archive, despite removal requests being filed. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296279: ITP: tarp -- small script adding progress bar support for GNU tar
Re: Grzegorz Bizon in <[EMAIL PROTECTED]> > * Package name: tarp > * URL : http://joker.linuxstuff.pl > Description : small script adding progress bar support for GNU tar > > Simple perl script adding progress bar support > for GNU tar. Hi, I'd say this is way to small to justify a package for it. Did you try to contact the tar maintainer to get it included there? Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Bug#296279: ITP: tarp -- small script adding progress bar support for GNU tar
[EMAIL PROTECTED] wrote: >Package: wnpp >Severity: wishlist >Owner: Grzegorz Bizon <[EMAIL PROTECTED]> > > >* Package name: tarp > Version : 0.9 > Upstream Author : Michal Kwiatkowski <[EMAIL PROTECTED]> >* URL : http://joker.linuxstuff.pl >* License : GPL > Description : small script adding progress bar support for GNU tar > > Simple perl script adding progress bar support > for GNU tar. Please, no! leo:~$ ls -al tarp.pl -rw-rw-r-- 1 steve pcs 7305 Feb 19 15:42 tarp.pl We don't need Yet Another Tiny Package in the archive for a 7KB perl wrapper script. If you find this useful, please ask the tar maintainer to include it in the tar package via a wishlist bug instead... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "C++ ate my sanity" -- Jon Rabone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
md5 checksum errors in several packages
Hi all, I have a local mirror of sarge here at work for making custom install cds. My mirror is a copy of the mirror at heanet (ftp.ie.debian.org). I have noticed incorrect checksums on 8 packages and I am posting the details here in case this is a serious problem. Hopefully someone more knowledgeable than me can help to clear it up. I have listed the packages with the md5 reported by "apt-cache show" and the md5 reported by "extract -H md5" package apt-cache show md5 report extract -H md5 report w-bassman_1.0-20_i386.deb aee0f950de62c57d516560270efd8e80 bd7e02f254bf869488fcf8c56a4d87c2 wmlongrun_0.3.0-pre1-3_i386.deb d2f33f7c93cb2be3c293e5bcb29028d3 80b72a6637022a948e7f2725183064a8 all xpilot packages are version _4.5.5beta.20031222-1_all.deb xpilotcd04e8872fc9375e0b6506628c3f5836 5945b7d5a4d63b599fec69b3d72da473 xpilot-client-common 87bade342c8edc3d75c8e0ca1e8a2d8e c367036dfca3b881500b1dfe9a328cba xpilot-client-nas 8bc6be97109427a8b496949659d56dea bcd3bf92b10f75330ffcf5886be43ed5 xpilot-client-nosound 3cfe83e6a25995d17d568737c3c4b48e 7686f00ee13ff34f314bb69c51b2e9a6 xpilot-client-rplay ac7c4d380f0fd9e2e29fbf9ce8aeb8e6 e135be164ccfdeba78ec92d570389f18 xpilot-server ac360c2e263a07ee586976c1106c78db 8029601fcdfbcccba23ab179577263bc cc'ing the package developers too. cheers, johno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debian-devel-changes question/request
Marek Habersack wrote: > It's just a simple question/request. Would it be possible to include > custom headers in the messages sent to debian-devel-changes that would > contain the package name, version and distribution, like so: > > X-Debian-Package: foo > X-Debian-PackageVersion: 1.2.3-1 > X-Debian-PackageDist: unstable > > Parts of the information can be parsed from the subject line, provided that > the subject isn't munged by some anti-spam software, but I think it would be > easier to automate processing of such mails wherever needed (yes, I need it > for a small project of mine, that's why I'm asking :) - but I think it could > be useful in general). Thoughts? man formail man procmail man procmailrc man procmailex There's no need for it to be done for all subscribers. You can do this on your own. Regards, Joey -- A mathematician is a machine for converting coffee into theorems. Paul Erdös Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote: > Bernd Eckenfels <[EMAIL PROTECTED]> writes: > > > In article <[EMAIL PROTECTED]> you wrote: > >> Hypothetical daily KDE builds would also insanely increase the amount of > >> network traffic being used by the mirror pulse and people upgrading > >> their home boxes, so it isn't just a buildd problem. > > > > Perhaps it helps, if the buildds for slow systems introduce some delay > > before startng the build, and not building if another architecture failed at > > all. That way if a package is often uploaded or hase obvious errors, the > > build for that is skipped. > > What would help save many hours on slow systems is having a script > automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources > according to Build-Depends to prevent useless buildd attempts and > failures and manual work to retry them. > > An attempt to build something big can take 3-4 hours to install > Build-Depends, see they aren't sufficient and to purge them again. s/something big/something with lots of build-dependencies/ There are small KDE applications that require most of the KDE dependency chain to be installed, while on the other hand XFree86's build dependency list is (relatively) small. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296279: ITP: tarp -- small script adding progress bar support for GNU tar
#include * Christoph Berg [Mon, Feb 21 2005, 04:13:09PM]: > > Simple perl script adding progress bar support > > for GNU tar. > > Hi, > > I'd say this is way to small to justify a package for it. Did you try > to contact the tar maintainer to get it included there? Agreed. However, I though about writting cp/mv versions that display progress bars and allow interactive "resuming" of copy operations. I think such things together with ptar could go into some kind of "interactive-command-line-tools" package. Regards, Eduard. -- Geistliche sind daran interessiert, die Völker in Unwissenheit zu erhalten, man würde sonst, da das Evangelium einfach ist, ihnen sagen: Wir wissen das alles so gut wie ihr. -- Charles-Louis Baron de Montesquieu (Gedanken, Über die Religion) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296279: ITP: tarp -- small script adding progress bar support for GNU tar
Re: Eduard Bloch in <[EMAIL PROTECTED]> > Agreed. However, I though about writting cp/mv versions that display > progress bars and allow interactive "resuming" of copy operations. I > think such things together with ptar could go into some kind of > "interactive-command-line-tools" package. rsync has progress bars, even when used locally. (for copying files, no idea about moving - there's a reason there are file managers out there like endeavour2 etc.) Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: The ghost of libc-dev
On Mon, Feb 21, 2005 at 03:28:10AM +, Henning Makholm wrote: > Scripsit Bill Allombert <[EMAIL PROTECTED]> > > Actually, there might be no need for virtual packages, since the tool > > will be run at compile time and can look up which libc is in use. > > Libc would not be the only thing decided. Imagine you're creating > libbar-dev and one of the .h files you ship contains > >#include > > When the -dev package is built, dpkg says that /usr/include/foo.h > comes from libfoo3-dev, which Provides libfoo-dev, libfoo3.1-dev and > obsoletepackagename-dev. If you were an automated -dev detector, which > package name would you let libbar-dev Depend on? You can't tell > without knowing something about which binary and source compatibility > policy libfoo tries to follow. In this case, one of two things, depending on how it's written: * libfoo3-dev (the actual package name) * Whatever the "headers" file (vis: shlibs) says The latter is more flexible, and may in fact be the only right answer, but could get very long and tedious to build for some packages. Maybe it needs to have a simple way of handling 'default'... > >> However, for as long as we have to trace the dependencies by hand, I > >> see little benefit in requiring an explicit dependency on a libc-dev. > > > There is little benefit, yes. However I feel it is cleaner that way. The > > -dev package #include files from another -dev package and that warrant a > > dependency. It is cleaner to not make libc-dev an exception. > > I have no objections if you as a maintainer of a library package > wishes to include libc-dev among the dependencies of your -dev. I > don't think it hurts anybody much. But should it be a bug if somebody > else does differently for his package? I don't think so. The origional issue that brought all of this up is the number of packages that have 'libc6-dev', rather than some form of allowing 'libc-dev', and the fact that on most architectures, there *isn't* any way to specify things short of a full-bore "all libc*-dev for all archs" that isn't *effectively* pure-virtual because libc6-dev is not a real package. Which effectively makes the libc-dev packages close to (if not quite) useless. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: md5 checksum errors in several packages
Ben Armstrong wrote: I question, then, the integrity of ftp.ie.debian.org or your own mirror. Just checking one of my own packages, I obtained a copy from my local mirror, and this is the result: $ extract -H md5 xpilot-client-nosound_4.5.5beta.20031222-1_i386.deb MD5 - 3cfe83e6a25995d17d568737c3c4b48e This agrees with the md5 checksum reported by apt-cache show. This also agrees with the md5 checksum extracted from my local copy of this .deb on my system used for the original upload, and the checksum as shown in the .changes file. Ben p.s. Please continue to CC me on any replies relevant to my own packages, as I am not subscribed to debian-devel at this time. Thank you Ben, I'll see if I can get the attention of someone at heanet to check this out. I'm quite worried now since I've been using this mirror for a long time. regards, johno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: md5 checksum errors in several packages
John, On Mon, 2005-02-21 at 15:24 +, John O'Sullivan wrote: > My mirror is a copy of the mirror at heanet (ftp.ie.debian.org). I > have noticed incorrect checksums on 8 packages and I am posting the > details here in case this is a serious problem. I question, then, the integrity of ftp.ie.debian.org or your own mirror. Just checking one of my own packages, I obtained a copy from my local mirror, and this is the result: > package apt-cache show md5 report > extract -H md5 report > xpilot-client-nosound 3cfe83e6a25995d17d568737c3c4b48e > 7686f00ee13ff34f314bb69c51b2e9a6 $ extract -H md5 xpilot-client-nosound_4.5.5beta.20031222-1_i386.deb MD5 - 3cfe83e6a25995d17d568737c3c4b48e This agrees with the md5 checksum reported by apt-cache show. This also agrees with the md5 checksum extracted from my local copy of this .deb on my system used for the original upload, and the checksum as shown in the .changes file. Ben p.s. Please continue to CC me on any replies relevant to my own packages, as I am not subscribed to debian-devel at this time. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: md5 checksum errors in several packages
Thats pretty much what the guy in HEAnet just said to me but the length of the files is the same. He says that the tcp checksums aren't accurate enough for 100% correctness. I'm emailing him some details now. cheers, johno Ben Armstrong wrote: John, Have you considered the possibility that the packages are corrupt due to truncation which may have happened because you (or your mirror) ran out of space at some point in the past while downloading these packages? The package names are late in the alphabet, which might account for why only these few packages are affected. Also, the corruption need not have been recent. My xpilot package has not changed in a very long time, which might account for the persistence of a very old one-time corruption event. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: md5 checksum errors in several packages
John, Have you considered the possibility that the packages are corrupt due to truncation which may have happened because you (or your mirror) ran out of space at some point in the past while downloading these packages? The package names are late in the alphabet, which might account for why only these few packages are affected. Also, the corruption need not have been recent. My xpilot package has not changed in a very long time, which might account for the persistence of a very old one-time corruption event. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: md5 checksum errors in several packages
John O'Sullivan <[EMAIL PROTECTED]> writes: > Ben Armstrong wrote: > >>I question, then, the integrity of ftp.ie.debian.org or your own mirror. >> >>Just checking one of my own packages, I obtained a copy from my local >>mirror, and this is the result: >> $ extract -H md5 xpilot-client-nosound_4.5.5beta.20031222-1_i386.deb >> MD5 - 3cfe83e6a25995d17d568737c3c4b48e >> >>This agrees with the md5 checksum reported by apt-cache show. This also >>agrees with the md5 checksum extracted from my local copy of this .deb >>on my system used for the original upload, and the checksum as shown in >>the .changes file. >> >>Ben >>p.s. Please continue to CC me on any replies relevant to my own >>packages, as I am not subscribed to debian-devel at this time. >> >> > Thank you Ben, > I'll see if I can get the attention of someone at heanet to check this > out. I'm quite worried now since I've been using this mirror for a > long time. > > regards, > johno Check project/trace to see where they mirror from (if they support trace) and go up the chain till you hit a mirror with the correct file. That should be most helpfull. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SoBeFOTO Has Received Your Email - PLEASE READ MESSAGE
We thank you for contacting us. We will be answering your question and/or concern just as soon as possible. We do our best to answer on the same day, but it can take up to 48 hours, so if you need immediate assistance, please call us at 954-585-6114. In the meantime, please visit our eBay Store and see all of the items that we are offering at http://stores.ebay.com/SoBeFOTO?refid=store -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: md5 checksum errors in several packages
Sorry for the false alarm. Those files were only corrupted. HEAnet have resynced them now and all is good. Sorry for wasting ppls time. johno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Buildds automatically dep-waiting on build-depends
On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote: > Bernd Eckenfels <[EMAIL PROTECTED]> writes: > > In article <[EMAIL PROTECTED]> you wrote: > What would help save many hours on slow systems is having a script > automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources > according to Build-Depends to prevent useless buildd attempts and > failures and manual work to retry them. This has come up before and I wanted to have a look at it but I haven't had any spare time to even have a look let alone come up with a solution to this yet. But yes, one day I'll try and have a look if someone more familiar with wanna-build hasn't fixed it by then. Simon. -- Just another wannabie | "Bet ya five dollars I get | Just another fool --+ off" - Pusher to Mulder (3x17) +--- This message was brought to you by the letter E and the number 7. htag.pl 0.0.22 -- http://www.earth.li/projectpurple/progs/htag.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296210: ITP: xchat-systray -- xchat systray notification icon
On Sun, 2005-02-20 at 19:16 -0600, David Moreno Garza wrote: > Package: wnpp > Severity: wishlist > Owner: David Moreno Garza <[EMAIL PROTECTED]> > > > * Package name: xchat-systray > Version : 2.4.5 > Upstream Author : Patrizio Bassi <[EMAIL PROTECTED]> > * URL : http://www.blight.tk/ > * License : GPL > Description : xchat systray notification icon > > Plugin for IRC client X-Chat which adds an icon in your systray > that flashes when you got highlighted message. Configurable > events and actions. Integrates with KDE, GNOME and XFce4. > > -- System Information: > Debian Release: 3.1 > APT prefers experimental > APT policy: (500, 'experimental'), (250, 'unstable') > Architecture: powerpc (ppc) > Kernel: Linux 2.6.9-powerpc > Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Could you provide a default configuration file? (with the icon path set) cheers, Hp. -- Hanspeter Kunz Artificial Intelligence Laboratory Ph.D. Student Department of Information Technology Email: [EMAIL PROTECTED] University of Zurich Tel: +41.(0)44.63-54306 Andreasstrasse 15, Office 2.12 http://ailab.ch/people/hkunzCH-8050 Zurich, Switzerland Spamtraps: [EMAIL PROTECTED] [EMAIL PROTECTED] --- Integrity has no need for rules. signature.asc Description: This is a digitally signed message part
Bug#296324: ITP: qoscc -- a highly flexible software oscilloscope with OSS, ALSA and JACK support
Package: wnpp Severity: wishlist Owner: Guillaume Pellerin <[EMAIL PROTECTED]> * Package name: qoscc Version : 0.2.0 Upstream Author : tincan * URL : http://www.svenqueisser.de/qoscc.html * License : GPL Description : a highly flexible software oscilloscope with OSS, ALSA and JACK support QOscC is a highly flexible and configurable software Oscilloscope with a large number of features. This includes support for any number of audio devices (ALSA, OSS or JACK), each with any number of channels. Each scope display can be configured individually to different display types and variants. e.g. you can chose from standard y-t mode (as on an usual oscilloscope), xy mode (e.g. for measuring the phase shift between two signals) of the FFT mode (to view a spectrum plot of the signal). This software is intended for electronic hobyists, who cannot afford a hardware oscilloscope or need a simple spectrum analyzer as well as for musicans for doing basic signal analysis. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.5piem Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: md5 checksum errors in several packages
On Mon, 2005-02-21 at 17:31 +, John O'Sullivan wrote: > Sorry for the false alarm. Those files were only corrupted. HEAnet have > resynced them now and all is good. Sorry for wasting ppls time. I'm just happy that people are looking for this sort of thing. It is encouraging that if were a real compromise to occur, it would not go unnoticed. Ben -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296279: ITP: tarp -- small script adding progress bar support for GNU tar
#include
* Christoph Berg [Mon, Feb 21 2005, 04:46:14PM]:
> Re: Eduard Bloch in <[EMAIL PROTECTED]>
> > Agreed. However, I though about writting cp/mv versions that display
> > progress bars and allow interactive "resuming" of copy operations. I
> > think such things together with ptar could go into some kind of
> > "interactive-command-line-tools" package.
>
> rsync has progress bars, even when used locally. (for copying files,
But it has some drawbacks:
- it always reads the target file (which slows down the process, even
if the user definitely knows that the previous transfer was not
corrupted, just interrupted)
- it creates a second file which makes the beast fail when you don't
have enough free space for two copies
> no idea about moving - there's a reason there are file managers out
> there like endeavour2 etc.)
Hm. Just tried it for few minutes, it is nice, but sucks too:
- does not use ARGV[1] as the start directory
- does not use integrate our mime system well. Open with presents a
stupid empty box. "see" is choosen as default viewer but the Open
action does not open any file ("see" called manually works)
- scroll wheel not working in the image viewer, no "next image" button
- the background around the images is pink (
- the breaks for "scanning directory" are a joke - no real user
seriously wants to wait 30seconds for some tool to rescan a directory
that has already been displayed.
- multibyte (UTF-8) is broken
- the "devices" overview says my / is not mounted
- the delete buttons tells me crap about "Write protection beeing on".
WTF? Apparently this "write protect" flag has been set, but not by
me.
My diagnosis so far: nice GUI, it has a future, but there are bugs,
bugs, bugs.
Whatever, I was talking about console utils with a little bit more
verbosity and not a GUI with
Regards,
Eduard.
--
Opposition:
die Kunst, so geschickt dagegen zu sein, daß man später dafür
sein kann.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > > But a total of eleven is insane. > > It is sometimes hard to get them all to work, yes. > > It also vastly increases the quality of the Free Software in our > archive, as we discover bugs that appear only on one architecture. That's an overstatement. Simply having two architectures (i386 and ppc) would be enough to reveal nearly all portability bugs. And for the more obscure architectures, virtually all of the testing comes from the build of the package. How many people out there are actually using e.g. KDE on mips enough to actually find any portability bugs? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote: > On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: > > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > > > But a total of eleven is insane. > > > > It is sometimes hard to get them all to work, yes. > > > > It also vastly increases the quality of the Free Software in our > > archive, as we discover bugs that appear only on one architecture. > > That's an overstatement. Simply having two architectures (i386 and ppc) > would be enough to reveal nearly all portability bugs. > Actually, my long experience is that it takes more than 2; but at, say, 4 systems (both byte orders, both 32 and 64 bits) you get most of them. More important at that point is getting better compiler coverage; gcc and friends is *not* the only compiler suite in the world, and different compilers uncover a different spectrum of bugs. - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Brian Nelson writes: > That's an overstatement. Simply having two architectures (i386 and ppc) > would be enough to reveal nearly all portability bugs. It required several architectures to uncover all of the portability bugs in Chrony. ppc was not one of them. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to force an update if package names changed?
Am Sonntag, den 20.02.2005, 11:02 +0100 schrieb Goswin von Brederlow: > Hendrik Frenzel <[EMAIL PROTECTED]> writes: > > If I have a source pack-1.1 from which some packages including > > pack-gui-lang-de-1.1_2 (Provides: pack-gui-lang) are build. > > > > Now i want to build the languages in seperade packages say > > pack-lang-de-1.1. How can it be done to force an update between the > > package from the main source (pack-gui-lang-de-1.1_2) to the package > > from the seperated lang source (pack-lang-de-1.1_?)? > > > > Provides: pack-gui-lang-de, pack-gui-lang > > Conflicts: pack-gui-lang-de > > You forgot Replaces as suggested in policy. Already done. Ive forgotten to write it here. > Create a dummy package for the old one that Depends on the new and add > a versioned Conflict to the old one. My next idea was something like this, but I didn't try it already. Thanks for the hint. Bye Hendrik -- I am chaos. I am the substance from which your artists and scientists build rhythms. I am the spirit with which your children an clowns laugh in happy anarchy. I am chaoss. I am alive and tell you, that you are free. - Eris, Goddess of Chaos, Discord and Confusion signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Brian Nelson wrote: > On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: > > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > > > But a total of eleven is insane. > > > > It is sometimes hard to get them all to work, yes. > > > > It also vastly increases the quality of the Free Software in our > > archive, as we discover bugs that appear only on one architecture. > > That's an overstatement. Simply having two architectures (i386 and ppc) > would be enough to reveal nearly all portability bugs. > > And for the more obscure architectures, virtually all of the testing > comes from the build of the package. That's incorrect, at least from my experience. > How many people out there are > actually using e.g. KDE on mips enough to actually find any portability > bugs? I use some kde programs on mips and haven't found portability bugs so far. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
Peter Samuelson <[EMAIL PROTECTED]> writes: > [Steve Langasek] >> The four most common porting problems for software are endianness >> (differs between i386/amd64 and powerpc), word size (differs between >> i386/powerpc and amd64), char signedness (differs between i386/amd64 >> and powerpc), and use of non-PIC code in shared libs (which is a >> problem on *all* non-i386 platforms). > > I'd add unaligned data access (broken or at least problematic on most > non-i386). Again, though, it's not something s390 or mipsel have > special problems with. > Seconded; I recently ran into this (#291471). I think the great number of architectures is a real plus for Debian and does good work uncovering portability bugs; buildd outages are annoying, but no reason to consider dropping an archictecture (unless, of course, the buildd is not able to keep up at all). Cheers, Rotty -- Andreas Rottmann | [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://yi.org/rotty | GnuPG Key: http://yi.org/rotty/gpg.asc Fingerprint | DFB4 4EB4 78A4 5EEE 6219 F228 F92F CFC5 01FD 5B62 It's *GNU*/Linux dammit! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
FW: FW: your private invitation 3-63434K2
Welcome to Americas newest insurance referral network. We offer term-life coverage at up to 70% off. Just cl.ck here: http://www.up6.org/link.php?id=erci&ID=11 We survey the top life-insurance companies and provide the best-rates available today. Smokers will qualify for special rates. - Cl.ck here: http://www.up6.org/link.php?id=erci&ID=11 Get Your Insurance Quote Today. http://www.up6.org/link.php?id=erci&ID=11 squad utensil [2-3] http://www.up6.org/link.php?id=erci&ID=11 Give us a shot, youve got nothing to lose: http://www.up6.org/link.php?id=erci&ID=11 Regards, Diana Lavern -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296279: ITP: tarp -- small script adding progress bar support for GNU tar
Eduard Bloch <[EMAIL PROTECTED]> writes: > #include > * Christoph Berg [Mon, Feb 21 2005, 04:46:14PM]: >> Re: Eduard Bloch in <[EMAIL PROTECTED]> >> > Agreed. However, I though about writting cp/mv versions that display >> > progress bars and allow interactive "resuming" of copy operations. I >> > think such things together with ptar could go into some kind of >> > "interactive-command-line-tools" package. >> >> rsync has progress bars, even when used locally. (for copying files, > > But it has some drawbacks: > > - it always reads the target file (which slows down the process, even >if the user definitely knows that the previous transfer was not >corrupted, just interrupted) -w doesn't but thats not continuing. > - it creates a second file which makes the beast fail when you don't >have enough free space for two copies I was thinking about that quite a few times. rsync should have an in-place mode. The extend of this could depend: - all of the existing file has to match otherwise a copy is made - parts of the existing file that don't match are moved (either to their final position or to a temp file) Another drawback of rsync: no support to copy device content (i.e. backup /dev/hda to backup-server:disks/client-hda) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
John Hasler <[EMAIL PROTECTED]> writes: > Brian Nelson writes: >> That's an overstatement. Simply having two architectures (i386 and ppc) >> would be enough to reveal nearly all portability bugs. > > It required several architectures to uncover all of the portability bugs in > Chrony. ppc was not one of them. > -- > John Hasler What no signed/unsigned char portability bugs? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote: >On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: >> On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: >> > But a total of eleven is insane. >> >> It is sometimes hard to get them all to work, yes. >> >> It also vastly increases the quality of the Free Software in our >> archive, as we discover bugs that appear only on one architecture. > >That's an overstatement. Simply having two architectures (i386 and ppc) >would be enough to reveal nearly all portability bugs. False. Unaligned data access is a portability problem, and I've never seen a bus error on any of my PPCs or i386s[0], but I have on UltraSparc. [0] Actually, I did have my current machine (an i686) have a problem with a bus error, but that was because *somebody* (who shall remain nameless) accidentally unplugged the hard disk while the computer was running. Needless to say, the kernel did not take kindly to this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296357: ITP: libcgi-simple-perl -- simple totally OO CGI interface that is CGI.pm compliant
Package: wnpp Severity: wishlist * Package name: libcgi-simple-perl Version : 0.077 Upstream Author : Dr James Freeman <[EMAIL PROTECTED]> * URL : http://search.cpan.org/~jfreeman/Cgi-Simple-0.077/ * License : Perl Artistic License Description : simple totally OO CGI interface that is CGI.pm compliant CGI::Simple provides a relatively lightweight drop in replacement for CGI.pm. It shares an identical OO interface to CGI.pm for parameter parsing, file upload, cookie handling and header generation. This module is entirely object oriented, however a complete functional interface is available by using the CGI::Simple::Standard module. Essentially everything in CGI.pm that relates to the CGI (not HTML) side of things is available. There are even a few new methods and additions to old ones! If you are interested in what has gone on under the hood see the Compatibility with CGI.pm section at the end. In practical testing this module loads and runs about twice as fast as CGI.pm depending on the precise task Homepage: http://search.cpan.org/~jfreeman/Cgi-Simple-0.077/ -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10-ck5 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Clanlib 0.7
Hi all, This is just a note for anyone who's looking for a project. I was just trying to compile some software, and it bombed out because I didn't have the right ClanLib version installed. I looked into the matter a little, and found a nearly two-year-old bug (#188449) asking for the library to be updated to the latest version. For people not familiar with it, ClanLib is a moderately popular high-level game programming library used by a number of different games. It has had a tendency to break API compatibility in the past, and it appears that the latest release is binary and source incompatible, so a lot of recent software is not compilable on Debian at all. Because the incompatibility is two-way, anyone who packages this will have to make allowances for installing both versions at once. Unofficial packages are available (see the bug), but will have to be reviewed for policy compliance and so on. And no, of course I don't have time to take care of this myself, or I'd have done it instead of posting a message here. It would be great if someone could get this into sarge, though, or people will be getting frustrating compile errors on Debian systems (barring a sudden change in how we release) for years and years to come. Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | "Next, consider a circle passing through infinity; that | | is, a straight line.." | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgpXnQdJa8IjX.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ...
Jim Gettys <[EMAIL PROTECTED]> writes: > On Mon, 2005-02-21 at 11:13 -0800, Brian Nelson wrote: >> On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: >> > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: >> > > But a total of eleven is insane. >> > >> > It is sometimes hard to get them all to work, yes. >> > >> > It also vastly increases the quality of the Free Software in our >> > archive, as we discover bugs that appear only on one architecture. >> >> That's an overstatement. Simply having two architectures (i386 and ppc) >> would be enough to reveal nearly all portability bugs. >> > > Actually, my long experience is that it takes more than 2; but at, say, > 4 systems (both byte orders, both 32 and 64 bits) you get most of them. Errr, yeah, I was thinking of amd64 as well but forgot to explicitly say so. > More important at that point is getting better compiler coverage; gcc > and friends is *not* the only compiler suite in the world, and different > compilers uncover a different spectrum of bugs. Yeah, definitely. If our goal is making our software as portable and bug-free as possible, we'd be better off running fewer arches but with a greater variety of compilers. Now if there were only any viable free alternatives to GCC... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#287839: ITP: mxml -- small XML parsing library
On Friday 31 December 2021 08:38 am, Eduardo Marcel Macan wrote: I call dibs on his time machine ;-) Daniel -- /--- Daniel Burrows <[EMAIL PROTECTED]> --\ | Microsoft, n: | | A company that makes pretty good mice. | \- A duck! -- http://www.python.org / pgphFDVekdxD3.pgp Description: PGP signature
Re: Let's remove mips, mipsel, s390, ...
Goswin von Brederlow <[EMAIL PROTECTED]> writes: > John Hasler <[EMAIL PROTECTED]> writes: > >> Brian Nelson writes: >>> That's an overstatement. Simply having two architectures (i386 and ppc) >>> would be enough to reveal nearly all portability bugs. >> >> It required several architectures to uncover all of the portability bugs in >> Chrony. ppc was not one of them. >> -- >> John Hasler > > What no signed/unsigned char portability bugs? I did see one before that only manifested itself on arm: http://bugs.debian.org/191992 Not sure why arm would be the only one though... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, 2005-02-21 at 16:12 -0800, Brian Nelson wrote: > Yeah, definitely. If our goal is making our software as portable and > bug-free as possible, we'd be better off running fewer arches but with a > greater variety of compilers. > > Now if there were only any viable free alternatives to GCC... > Well, in the goal of better software, I'm willing to use closed source compilers. I like finding bugs that way, *before* getting bug reports... And yes, the ARM compiler has some *strange* defaults... Whomever picked their defaults didn't do ARM favors, even if it if they might be conformant to the C standard - Jim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296369: ITP: spin -- Powerfull model checking and software verification tool
Package: wnpp Severity: wishlist Owner: Eike Dehling <[EMAIL PROTECTED]> * Package name: spin Version : 4.2.4 Upstream Author : Bell-Labs <[EMAIL PROTECTED]> * URL : http://www.spinroot.com/ * License : Free(as in, no license) for non-commercial use, commercial use requires this license: http://cm.bell-labs.com/cm/cs/what/spin/spin_license.html Description : Powerfull model checking and software verification tool Spin is a tool for model checking / software verification. It can check a model described in it's C-like modeling language to verify assertions. It can handle multiple concurrent processes, embedded C code and several forms of inter-process communication. It will also use optimization techniques to scale to checking big models. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.3 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#296369: ITP: spin -- Powerfull model checking and software verification tool
On Tue, Feb 22, 2005 at 02:31:03AM +0100, Eike Dehling wrote: > Package: wnpp > Severity: wishlist > Owner: Eike Dehling <[EMAIL PROTECTED]> > > > * Package name: spin > Version : 4.2.4 > Upstream Author : Bell-Labs <[EMAIL PROTECTED]> > * URL : http://www.spinroot.com/ > * License : Free(as in, no license) for non-commercial use, > commercial use requires this license: > > http://cm.bell-labs.com/cm/cs/what/spin/spin_license.html This license is non-free, and probably not sufficient to allow redistribution in non-free, either. Please see: http://lists.debian.org/debian-legal/2004/01/msg00267.html -- Glenn Maynard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Brian Nelson debian.org> writes: > On Mon, Feb 21, 2005 at 11:33:35AM +0100, Wouter Verhelst wrote: > > On Sun, Feb 20, 2005 at 10:57:47PM +, Dirk Eddelbuettel wrote: > > > But a total of eleven is insane. > > > > It is sometimes hard to get them all to work, yes. > > > > It also vastly increases the quality of the Free Software in our > > archive, as we discover bugs that appear only on one architecture. > > That's an overstatement. Simply having two architectures (i386 and ppc) > would be enough to reveal nearly all portability bugs. Fair point. But you'll get shouted down just for raising this ... > And for the more obscure architectures, virtually all of the testing > comes from the build of the package. How many people out there are > actually using e.g. KDE on mips enough to actually find any portability > bugs? That is an important point, and nobody else really picked it up. Almost all other contributors to this thread engaged in attempts to stifle the debate and claim "that the parrot wasn't dead, but resting". But to the best of my knowledge, Marco's (blog) post from a few months ago which showed download from ftp.it.debian.org by architecture stands undisputed: essentially all users are on i386 clearly dominating all other arches, with a fraction of users in maybe two, three, four other arches --- and comparitively nobody in the other fringe arches we keep around for no good reason. And I still believe it delays our releases. As you say, there are no KDE users on mips. So guys, we need a new framework. Maybe we should pick up on Petter's suggestion of stricter buildd requirements. Maybe we should only build base and essential packages for the minor architectures [ after, apt-source is there for everybody to go further ]. We can still provide the debian-installer for everything with a power cord provided we have the resources to code, maintain, debug, document, improve, ... and all those platforms. Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote: > What would help save many hours on slow systems is having a script > automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources > according to Build-Depends to prevent useless buildd attempts and > failures and manual work to retry them. Why do the build servers install all the dependencies only to find out that some installed versions are insufficient for the build? Surely this can be determined _before_ installing the dependencies? No new information is available after install that wasn't available before. Is the problem that you use apt-get to install the current version, and then check what you got? Because you can't tell apt-get to install at least version X else fail? Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: > But to the best of my knowledge, Marco's (blog) post from a few months > ago which showed download from ftp.it.debian.org by architecture stands > undisputed: essentially all users are on i386 clearly dominating all other > arches, with a fraction of users in maybe two, three, four other arches --- > and comparitively nobody in the other fringe arches we keep around for no > good reason. And I still believe it delays our releases. As you say, there > are no KDE users on mips. So guys, we need a new framework. > > Maybe we should pick up on Petter's suggestion of stricter buildd > requirements. > Maybe we should only build base and essential packages for the minor > architectures [ after, apt-source is there for everybody to go further ]. We > can still provide the debian-installer for everything with a power cord > provided we have the resources to code, maintain, debug, document, improve, > ... > and all those platforms. IMHO, we are in an awkward position. There are *some* users in the other architectures. Not, many but some. If we drop those architectures then we will have *no* users in other architectures. This debate reminds me of the way that large corporations go for the largest market segment and leave the small fry without anyone catering to their needs. Debian is not a desktop architecture for some of these other architectures, but that doesn't mean it isn't valuable. It is clear that there is a problem with buildd resource efficiency and the fact that large packages delay our release undesirably because of the high buildd latency. I would hate to see Debian throw out the baby. The problem with apt-source is that, if I understand it correctly, it only performs native builds. This isn't necessarily possible for some people. Speaking as an ARM user on embedded systems, there is no chance I'm going to build natively on the targets I support. It does seem prudent to find a way to permit a release on x86 and ppc before all architectures are complete. Especially if this tactic will give Debian the ability to release more often. Is it so bad to allow the smaller architectures to lag as long as problems are fixed? Cheers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: > undisputed: essentially all users are on i386 clearly dominating all other > arches, with a fraction of users in maybe two, three, four other arches --- > and comparitively nobody in the other fringe arches we keep around for no > good reason. And I still believe it delays our releases. As you say, there You can believe in the tooth fairy, too, but it doesn't make it true. Since you're trying to convince others to join your tooth fairy worshipping religion, it might be useful to provide some evidence to back your belief. I believe we haven't seen any evidence that all our architectures has delayed any release. DI was a potential sticking point, but it's already sorted due to the hard work by the relevant porters while we're still waiting for other technical issues to work themselves out. - Matt signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ...
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Brian Nelson debian.org> writes: >> And for the more obscure architectures, virtually all of the testing >> comes from the build of the package. How many people out there are >> actually using e.g. KDE on mips enough to actually find any portability >> bugs? > > That is an important point, and nobody else really picked it up. Almost all > other contributors to this thread engaged in attempts to stifle the debate > and claim "that the parrot wasn't dead, but resting". > > But to the best of my knowledge, Marco's (blog) post from a few months > ago which showed download from ftp.it.debian.org by architecture stands > undisputed: essentially all users are on i386 clearly dominating all other > arches, with a fraction of users in maybe two, three, four other arches --- > and comparitively nobody in the other fringe arches we keep around for no > good reason. As long as the fringe architectures are not slowing down releases, and the mirrors have the bandwidth and disk space for them, I don't have a problem keeping them around. I have yet to see anyone give a compelling reason to keep them, but if they aren't hurting anyone, who cares? However, I do think that not including amd64 (while keeping mips and friends) in the sarge release due to mirroring problems is ridiculous. > And I still believe it delays our releases. As you say, there are no > KDE users on mips. So guys, we need a new framework. It's not clear to me how much supporting all of these arches delays our releases. I believe that some delay is inherent, but I'm skeptical whether it's significant compared to other sources of delay. I don't recall ever hearing a RM state that supporting all of these arches was slowing down the release cycle. And I think that's significant. The real problem seems to me, aside from the mysterious difficulties of setting up testing-security and t-p-u, seems to be that it's very hard to consistently keep the flow of packages into testing. There are too many inter-dependencies, packages are uploaded too frequently, and bugs appear at too great of a rate. Or at least that's my impression as an outside observer. Portability and buildd problems undoubtedly play a role in there, but I suspect it's a relatively minor role. Can someone more involved in the release process confirm or deny this? -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
they're so lonely
Find yerself a queen on real soon http://underpartnerbrachycatalectic.com/sse/ rm0ve : underpartnerbrachycatalectic.com/yap/ The metalliferous adiabatic ks comeback . She rev blackball anton luke dextrose . likewise sse woeful loft accolade diane . amp apprentice chou bater . The beowulf puzzle hyperbola finessing deploy . She axe sheehan alvarez . And copeland demonstrate get limpet spavin . She coward bantam repressive .and commotion incumbent quantico bath gutsy . The homework baseboard saturday botanist . barbour bricklay phosphide burden deferrable artful .and brisk potbelly jacob annuity direct declare . cobra biddy cavilling bifurcate beehive . The clio course meyer alex . She chlorophyll onward resistor option cetera . The bream byronic malta smart . trichinella schumacher archetypical prairie cockatoo appall . debian-devel@lists.debian.org
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Matthew Palmer debian.org> writes:
> On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote:
> > undisputed: essentially all users are on i386 clearly dominating all other
> > arches, with a fraction of users in maybe two, three, four other arches ---
> > and comparitively nobody in the other fringe arches we keep around for no
> > good reason. And I still believe it delays our releases. As you say, there
>
> You can believe in the tooth fairy, too, but it doesn't make it true. Since
> you're trying to convince others to join your tooth fairy worshipping
> religion, it might be useful to provide some evidence to back your belief.
Sorry, you just scored against your own team.
I was quoting a post with actual download numbers that actually demonstrate
that the vast majority of users are on i386: see http://blog.bofh.it/id_66.
For your convenience, I quote the numbers here again along with a quick
percentage calculation:
> md <- read.table("/tmp/md.txt", header=TRUE, row.names=1)
> md <- cbind(md, percent=round(100*md[,1]/md["total",1], 4))
> md
files.downloaded percent
i386 1285422 70.5079
all 504789 27.6886
powerpc17754 0.9738
ia64 10111 0.5546
sparc 3336 0.1830
arm 850 0.0466
alpha507 0.0278
hppa 204 0.0112
mipsel91 0.0050
m68k 15 0.0008
mips 7 0.0004
s390 4 0.0002
total1823090 100.
> I believe we haven't seen any evidence that all our architectures has
> delayed any release. DI was a potential sticking point, but it's already
> sorted due to the hard work by the relevant porters while we're still
> waiting for other technical issues to work themselves out.
It delays our releases in the sense that it affects our resources:
- available maintainer and developer time,
- cpu cycles (witness Wouter's request to compile big packages rarely),
- network bandwith (witness the discussion on mirror efficiency),
- mirrror capacity (witness the sad state of amd64),
- security response time (more builds to do)
and that it
- increases the load on infrastructure (t-p-u, security)
- scarce resource such as release managers, ftp admins, ...
if we have to look after arches that are *not really used*.
As you say so cogently: "it might be useful to provide some evidence to back
your belief".
Consider the ball in your court, and please prove with tangible numbers
how the approximate benefit from the minor arches is "roughly" equivalent
to that of arches being used. Hand-waving ("find more bugs") won't do.
Dirk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ...
On Mon, Feb 21, 2005 at 04:30:27PM +0100, Wouter Verhelst wrote: > On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote: > > Bernd Eckenfels <[EMAIL PROTECTED]> writes: > > > > > In article <[EMAIL PROTECTED]> you wrote: > > >> Hypothetical daily KDE builds would also insanely increase the amount of > > >> network traffic being used by the mirror pulse and people upgrading > > >> their home boxes, so it isn't just a buildd problem. > > > > > > Perhaps it helps, if the buildds for slow systems introduce some delay > > > before startng the build, and not building if another architecture failed > > > at > > > all. That way if a package is often uploaded or hase obvious errors, the > > > build for that is skipped. > > > > What would help save many hours on slow systems is having a script > > automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources > > according to Build-Depends to prevent useless buildd attempts and > > failures and manual work to retry them. > > > > An attempt to build something big can take 3-4 hours to install > > Build-Depends, see they aren't sufficient and to purge them again. > > s/something big/something with lots of build-dependencies/ > > There are small KDE applications that require most of the KDE dependency > chain to be installed, while on the other hand XFree86's build > dependency list is (relatively) small. would it make sense to examine the queue to see if any packages have similar build dependencies and then move them to the top of the queue so they build immediately after the current one? or to re-sequence the queue to group package with similar build dependencies. -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! (__) (oo) /--\/ / ||| * /\---/\ ~~ ~~ "Have you mooed today?"... signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > But to the best of my knowledge, Marco's (blog) post from a few months > ago which showed download from ftp.it.debian.org by architecture stands > undisputed: essentially all users are on i386 clearly dominating all other > arches, with a fraction of users in maybe two, three, four other arches --- > and comparitively nobody in the other fringe arches we keep around for no > good reason. And I still believe it delays our releases. As you say, there > are no KDE users on mips. So guys, we need a new framework. But the point is, who cares? These things don't slow the release. You "believe" it does, but without a shred of actual evidence, and no agreement from the people whose job it is to get the releases done. I think what slows releases is that you aren't fixing RC bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > I was quoting a post with actual download numbers that actually demonstrate > that the vast majority of users are on i386: see http://blog.bofh.it/id_66. But that doesn't show what you said you believe, which is that supporting other archs slows the release. > - available maintainer and developer time, Easy to say. How many RC bugs have you fixed recently, and if we dropped the other archs, how many would you have fixed? > - cpu cycles (witness Wouter's request to compile big packages > rarely), So you're saying that if we dropped the mips buildd's we'd have more cycles for other archs? > - network bandwith (witness the discussion on mirror efficiency), Mirrors don't have to (and don't need to) copy all the archs. They can support whichever ones they want. Nor could this possibly slow release. > - mirrror capacity (witness the sad state of amd64), But dropping an arch can't improve the capacity of a mirror which doesn't carry it, and they can always simply not carry it if they want to. Nor could this possibly slow release. > - security response time (more builds to do) Which DSAs came out later than they should have because of this supposed delay? Nor could this possibly slow release. > and that it > - increases the load on infrastructure (t-p-u, security) How much does it? Do we have an infrastructure which is short on capacity for these things? > - scarce resource such as release managers, ftp admins, ... > if we have to look after arches that are *not really used*. All of whom have said that this doesn't actually slow them at all. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Marc Singer <[EMAIL PROTECTED]> writes: > It does seem prudent to find a way to permit a release on x86 and > ppc before all architectures are complete. Especially if this > tactic will give Debian the ability to release more often. Is it so > bad to allow the smaller architectures to lag as long as problems > are fixed? This would only make sense if we had a complete x86 and ppc release, but not a complete mips release. In practical terms, this doesn't happen. It's not like we do all the x86 work, and then the rest. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 08:56:27PM -0800, Thomas Bushnell BSG wrote: > Marc Singer <[EMAIL PROTECTED]> writes: > > > It does seem prudent to find a way to permit a release on x86 and > > ppc before all architectures are complete. Especially if this > > tactic will give Debian the ability to release more often. Is it so > > bad to allow the smaller architectures to lag as long as problems > > are fixed? > > This would only make sense if we had a complete x86 and ppc release, > but not a complete mips release. In practical terms, this doesn't > happen. It's not like we do all the x86 work, and then the rest. I agree completely. This makes sense iff the lesser used arches affect release. As I posted in another message, this discussion about removing arch's seems to me to be a red herring. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 04:39:22AM +, Dirk Eddelbuettel wrote: > Matthew Palmer debian.org> writes: > > On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: > > > undisputed: essentially all users are on i386 clearly dominating all > > > other > > > arches, with a fraction of users in maybe two, three, four other arches > > > --- > > > and comparitively nobody in the other fringe arches we keep around for no > > > good reason. And I still believe it delays our releases. As you say, > > > there > > > > You can believe in the tooth fairy, too, but it doesn't make it true. Since > > you're trying to convince others to join your tooth fairy worshipping > > religion, it might be useful to provide some evidence to back your belief. > > Sorry, you just scored against your own team. Why, by asking for evidence that multiple architectures delays releases? You have a really oddball scoring system. > > I believe we haven't seen any evidence that all our architectures has > > delayed any release. DI was a potential sticking point, but it's already > > sorted due to the hard work by the relevant porters while we're still > > waiting for other technical issues to work themselves out. > > It delays our releases in the sense that it affects our resources: > - available maintainer and developer time, What's to say that someone who spends time on a minority architecture would spend it on Debian proper if that architecture wasn't in Debian? I would say that the inverse is the case: developers with an interest in minority architecture come to Debian and help out with non-arch-specific things as well as their pet arch, while if Debian didn't support that arch they'd probably go elsewhere. > - cpu cycles (witness Wouter's request to compile big packages rarely), More computers wastes CPU cycles? > - network bandwith (witness the discussion on mirror efficiency), Do you have any actual evidence that lower bandwidth would benefit Debian in any material way? > - mirrror capacity (witness the sad state of amd64), So you're saying that we need to reduce our architecture count to increase our architecture count? > - security response time (more builds to do) Security autobuilders are on their way. You could make the argument that if we only had a couple of architectures we wouldn't really need security autobuilders, but I think that automating everything that can be automated is a Good Thing. > and that it > - increases the load on infrastructure (t-p-u, security) WTF? t-p-u would be needed if we had one arch. > - scarce resource such as release managers, ftp admins, ... RMs and ftpmasters aren't arch-specific, apart from the odd occasion when an ftpmaster needs to remove out-of-date binaries for unbuilt architectures. Note, however, that two ftpmasters are presidios of their own niche architecture. If we dropped them, they'd probably go off and do their own (non-Debian) thing. > As you say so cogently: "it might be useful to provide some evidence to back > your belief". > > Consider the ball in your court, and please prove with tangible numbers You'll need to go and collect the ball from behind you where it landed after you missed it before you send it back to me. - Matt signature.asc Description: Digital signature
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Matthew Palmer debian.org> writes: [ a lot of stuff but omitting one critical argument of mine ] Thanks for cutting and completely ignoring the part where I demonstrated the lack of usage beyond i386 and maybe four or five other arches. I rest my case. These arches have little benefit, but as everybody shouts at me that they have exactly zero cost, we're still winning with a net benefit. If only I could believe in Santa like the rest of us. Dirk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, 22 Feb 2005, Dirk Eddelbuettel wrote: > Thanks for cutting and completely ignoring the part where I > demonstrated the lack of usage beyond i386 and maybe four or five > other arches. You used package download results from one (1!) debian mirror to demonstrate the supposed lack of usage. However, those download stats only point to who is actually downloading packages with that architecture from only that mirror in a single month. The very fact that people are willing to maintain buildds and make appropriate patches for the architectures indicates that people actually are using them. When (and if) an arch fails to have a critical mass of people who care about it enough to actually take care of it, then it should be jettisoned. However, that appears not to have happened yet. This is almost exactly like an argument for ejecting packages that don't appear to be very popular but are being actively maintained by a maintainer who supposedly uses the package in question.[1] Don Armstrong 1: Hell, I use and maintain a few packages that aren't too terribly popular. -- I don't care how poor and inefficient a little country is; they like to run their own business. I know men that would make my wife a better husband than I am; but, darn it, I'm not going to give her to 'em. -- The Best of Will Rogers http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 03:15:58AM +, Dirk Eddelbuettel wrote: > But to the best of my knowledge, Marco's (blog) post from a few months > ago which showed download from ftp.it.debian.org by architecture stands > undisputed: essentially all users are on i386 clearly dominating all other > arches, with a fraction of users in maybe two, three, four other arches --- I've written back then something about that. Maybe you could dig the archives for my comment on this. For example, Italy was never a strong country for m68ks (Amigas) as f.e. Germany was. Of course you'll find that after a decade there would be virtually no users left. Picking out just one country mirror gives a wrong image. Anyway, with statistics you can usually prove whatever you like. It's just a matter of interpretation. > and comparitively nobody in the other fringe arches we keep around for no > good reason. And I still believe it delays our releases. Then give facts and prove your believing. > As you say, there > are no KDE users on mips. So guys, we need a new framework. Wasn't there someone in this thread that is actually using KDE on mips? So, your statement is simply wrong. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On 21 Feb 2005 20:54:36 -0800, Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: >Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: >> - security response time (more builds to do) > >Which DSAs came out later than they should have because of this >supposed delay? Nor could this possibly slow release. There are rumours that the noticeable multi-week gap last fall when no DSAs were released at all were caused by some buildd failure on one of the lesser-userd arches and the security team decided to defer advisories until security builds could be released for all arches. I have a dedicated opinion about this time of service the major arches received during this time, but I do not want to voice it here as I am only talking about a rumour and I do not want to start yet another flame war. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Let's remove mips, mipsel, s390, ...
On Tue, Feb 22, 2005 at 02:29:33PM +1100, Hamish Moffatt wrote: > On Mon, Feb 21, 2005 at 03:53:44PM +0100, Goswin von Brederlow wrote: > > What would help save many hours on slow systems is having a script > > automatically set "Dep-Wait: libbfoo (>> 1.2-3)" for all new sources > > according to Build-Depends to prevent useless buildd attempts and > > failures and manual work to retry them. > Why do the build servers install all the dependencies only to find out > that some installed versions are insufficient for the build? Because the current buildd system is outdated in the meanwhile. It should be replaced by a new framework. > Surely this can be determined _before_ installing the dependencies? > No new information is available after install that wasn't available > before. Bastian Blank worked on a database that handles all these build-deps on the central wanna-build replacement. The idea is to give out just those packages that really can be built. See the very first draft on multibuild. Unfortunately multibuild got stuck and I'm not willing anymore to invest more time into that project, because I'm on the way to leave the project at all. But beside that, I believe that multibuild is the right way to go... -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Tue, Feb 22, 2005 at 05:24:28AM +, Dirk Eddelbuettel wrote: > Matthew Palmer debian.org> writes: > [ a lot of stuff but omitting one critical argument of mine ] > Thanks for cutting and completely ignoring the part where I demonstrated > the lack of usage beyond i386 and maybe four or five other arches. So, when you're such a great fan of i386, why don't you just drop all other archs from your arch: line then? Et voila... problem solved for you. Oh, maybe that could violate the SC, but who cares about other socials anyway. It's only you who counts. -- Ciao... // Ingo \X/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
Dirk Eddelbuettel <[EMAIL PROTECTED]> writes: > Thanks for cutting and completely ignoring the part where I demonstrated > the lack of usage beyond i386 and maybe four or five other arches. "lack of usage" here means "much rarer usage" of course. .001 is not zero. And your point was supposedly that supporting these archs delays the release. Proving they are used by absolutely nobody still doesn't prove that it delays the release. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: useless trivia, oldest opened bug in Debian
On Mon, Feb 21, 2005 at 11:40:07AM +, Scott James Remnant wrote: > On Sat, 2005-02-19 at 23:06 -0600, Micah Anderson wrote: > > >#957: dpkg 957 802533782 open [EMAIL PROTECTED] wishlist > > > Do I get a medal when I fix this in the next week or two? :) I've been > working on an implementation over the weekend that's to my liking. If you do that *and* manage to keep to what you have already said about it (the bit about providing a fix "post-sarge"), you *definitely* get a medal :-) Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Let's remove mips, mipsel, s390, ... (Was: [Fwd: Re: GTK+2.0 2.6.2-3 and buildds running out of space])
On Mon, Feb 21, 2005 at 07:10:36AM -0600, Peter Samuelson wrote: > The main problem with distcc across architectures is the FUD > surrounding whether gcc-as-cross-compiler spits out the same code as > gcc-as-native-compiler. The gcc team seem to be very hesitant to make > any guarantees about that, as it's not something they test much. > Without better information than guesswork, I'd say you might minimise > your chances of cross-gcc bugs by using a host with the same endianness > and bit width. Running such a system in parallel with the current systems (and comparing the outputs) might be a good test for gcc-as-cross-compiler, then... Just a thought. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
