Re: gfreeamp playlist inquiry
On Fri, Oct 22, 2004 at 11:42:57PM -0400, Kevin Mark wrote: On Fri, Oct 22, 2004 at 10:05:30PM -0400, Siqueland-Gresch wrote: Hello and good evening from Rhode Island ! Go Red Sox! I have been using the Freeamp program for years and I am in love with its simplicity. No gimmicks. Just functionality. I love that it has a simple playlist window on the left and the songs of the playlist on the right. Now the only thing missing to my happiness is that the playlists on the left become so many and that they cannot be subdivided. It would be so nice if it would be possible to have the ability to create a playlist named JAZZ which opens up on clicking to its subdivisions: Miles Davis, Coltrane , etc. And then closes/folds up on clicking it again. Has anyone ever built a freeamp module which would enable Freeamp to do that ? what I get from skimming your message is that you want the Freeamp developer to consider your request for a new feature. Your ability to ask for features in the software programs that you use is one of the advantages of libre/free software. You can file a bug report at the debian site or with the bug tool for a new feature. You can also contact the debian maintainer and the original developer about this. Their info should be availble. But unfortunatley this list is about discussion of issues specific to debian as a whole and not to discussion of one program or package. I'd suggest to check the site for a better forum like debian-user. Also note that freeamp was renamed to zinf due to trademark infringment or something a couple years ago. -- Blast you and your estrogenical treachery!
Re: an idea for next generation APT archive caching
On Thu, Oct 21, 2004 at 02:59:17PM -0500, Manoj Srivastava wrote: Hi, I can mostly live with the current apt-proxy, except for the fact that it does not seem to want to play nice with debbootstrap: debbootstrap just hangs. Happens here too.. my apt-proxy and debootstrap client (pbuilder) are on different machines. I've done this before, so I think it's new with apt-proxy v2. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Ubuntu discussion at planet.debian.org
On Fri, Oct 22, 2004 at 10:28:29PM -0500, Manoj Srivastava wrote: This is a fallacy. In the past, when we did freeze unstable, it never forced me to do anything but twidle my thumbs for months until things got moving again. The reason that freezing unstable did not make me fix any more bugs, since the bugs were not in packages I was in any way an expert in. Freezes just used to be a frustrating, prolonged period in which I did no Debian work at all, waiting for unstable to thaw back out. And why not, instead of freezing unstable, make it build against testing, when er try to freeze testing ? Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Mike
Re: Ubuntu discussion at planet.debian.org
On Fri, 22 Oct 2004 19:57:15 +0200, Eduard Bloch [EMAIL PROTECTED] said: include hallo.h * Romain Francoise [Fri, Oct 22 2004, 06:04:12PM]: Is the entire world on crack and I just failed to notice until now? Don't worry, we're preparing an internal General Resolution to address this crack problem, but you're not supposed to know about it. This is how we fix problems in Debian: hide them, then propose General Resolutions. And your point is..? That a GR on technical issues is moronic? It is our right to hide things. We do not hide problems, we hide possible solutions. The problem is well known, but there are This is even stupider than I thought possible. different ways to solve it. And before you think about writing another message, think about the reason for having the debian-private ML. It certainly is not to have moronic conversations like this. We should certainly not be hiding stupidity in Debian ranks. manoj -- Lay on, MacDuff, and curs'd be him who first cries, Hold, enough!. Shakespeare Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Ubuntu discussion at planet.debian.org
On Fri, 22 Oct 2004 11:36:13 +0200, Eduard Bloch [EMAIL PROTECTED] said: include hallo.h * Jérôme Marant [Fri, Oct 22 2004, 10:20:51AM]: Some improvements have already been proposed by Eduard Bloch and Adrian Bunk: freezing unstable while keeping testing. Jerome, please, you could have asked me. I prepare an internal GR draft for exactly this issue, but it is to be made public on the day of the release, and better not before. We should concentrate on making the Sarge release ready, NOW. Do not start another flamewar. A ^%$#^ GR? to decide on technical issues like release management? This is incredibly stupid. We used to never decide technical issues by popular opinion -- and, anyway, a GR on release policy is a no-op. The proper way to go about changing the release mechanism has already been demonstrated by AJ -- he went off and implemented testing on his own, shadowing the real archive, wrote up the testing scripts, and came back with numbers, and proof of concept, not a meaningless vote. You know, all this politicking, as opposed to writing code, is probably the prime factor behind any decline in the quality of the distribution. manoj -- Q: What's the difference betweeen USL and the Graf Zeppelin? A: The Graf Zeppelin represented cutting edge technology for its time. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Security updates for sarge?
On Fri, 22 Oct 2004, Martin Schulze wrote: Jan Niehusmann wrote: Question to the security team: What's holding back security support for sarge? (This is not a complaint - I'm just curious) It still (as written on -project one or two weeks ago) lacks the infrastructure as in a working buildd network that processes the target ``testing-security''. This is something that two people in Debian can set up. (This is only information, please don't start a flamware about it). I've asked this question informally a few times, but I'll ask it again: Is there anything that those of us who are not these two people can do to help with this, short of not bothering them about it? Don Armstrong -- If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money it values more, it will lose that, too. -- W. Somerset Maugham http://www.donarmstrong.com http://rzlab.ucr.edu
Re: Does the Debian gpg key infrastructure support multiple sub-keys?
On Fri, 22 Oct 2004 21:49:26 -0500, Graham Wilson [EMAIL PROTECTED] said: On Fri, Oct 22, 2004 at 09:09:53PM -0300, Henrique de Moraes Holschuh wrote: On Fri, 22 Oct 2004, Rob Browning wrote: If I added a new sign/encrypt sub-key to my Debian key, would I be able to use that to sign and upload packages? Would the Debian Yes, mostly. Some stuff (db.d.o and vote.d.o come to mind, but I am not sure about that) require you to always sign using the master key. db.debian.org for sure requires you to use your master key to do things like changing your SSH public key, or your password. Last time I voted I asked Manoj about it, and he said he was babysitting GnuPG to handle subkeys I believe. Manoj, what is the status of a newer, more function GnuPG on master for devotee? I hand ported the Sid version of gpg at the time of the last vote and installed it on master -- so it ought to be OK. And post Sarge, when master is updated, we should be golden. ;-) manoj -- Madison's Inquiry: If you have to travel on the Titanic, why not go first class? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: an idea for next generation APT archive caching
On Wed, Oct 20, 2004 at 02:11:44AM +0200, martin f krafft wrote: Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this could be interesting, maybe it's just crap. Your call. My position on special-purpose proxy caches for APT is that general-purpose proxy caches (like squid) seem to work fine for me. What advantages do they have for others? -- - mdz
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Mon, Oct 18, 2004 at 07:22:12PM +0200, Wesley W. Terpstra wrote: Can this go into main? This risks serious practical problems. If your package is routinely built with a compiler other than the Debian default, problems which would arise from doing so can go easily undetected. Someday, someone else will need to upload your package (e.g., the security team), but the package could fail to build, fail to work or change in subtle ways. -- - mdz
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Tue, Oct 19, 2004 at 09:16:17AM -0700, John H. Robinson, IV wrote: The only difference is in *performance*. If there are other differences, then there is a bug in one of the two compilers. First, both of the compilers involved are known to have bugs. Second, this is not necessarily true. There are common types of performance optimisations which can change behaviour by violating assumptions made by the code. In this case the bug is not in the compiler but in the input, but that case loses too. -- - mdz
Re: NMU for libpaper
An NMU for a wishlist bug is questionable IMHO. The bug report for hylafax-client is vague; it says that there are (tiny) differences between default and ISO A4 in the pagesizes file but fails to explain why that's a problem. Rather than NMU just for this bug, you could try to contact the Rather than NMU just for this bug, also NMU for the 3 l10n bugs sitting in the BTS...:-)
Re: Ubuntu discussion at planet.debian.org
Manoj Srivastava [EMAIL PROTECTED] writes: What do you think we'd get by combining both (testing + unstable freeze)? If you freeze unstable anyway, you are blocking the updates -- and thus have all the problems of this style of interrupted development. If unstable is frozen, what is the point of Testing? Testing scripts are a gatekeeper against mistakes from unstable. Upload debian-specific changes to unstable doesn't necessarily mean there won't be side effects that shall not enter testing. Am I missing something in your (somewhat nebulous) proposal? Freezing unstable prevent people from uploading new upstream releases which desynchronizes unstable from testing and forces people to work with two distributions (and necessarily neglect one of them). As soon as testing is strictly equal to unstable regarding package versions, testing is roughly ready for release. -- Jérôme Marant http://marant.org
Re: Security updates for sarge?
[Don Armstrong] Is there anything that those of us who are not these two people can do to help with this, short of not bothering them about it? I'm not sure how to help on the infrastructure. But if you want to help with securing sarge/testing, you can help Joey Hess and the rest of us checking all CAN-reports and DSAs to find out which of these applies to sarge and which do not. As I said in an earlier email. Debian-edu is trying to form a security team for testing, to work in parallell with the team working on stable. We hope this will take some of the load from the current security team. To avoid the problems with keeping secret information hidden, this team will focus on the publicly known security issues, and leave the secret problems to the Debian/stable security team. This will make security fixes for Debian/testing appear later then fixes for Debian/stable, but would definitely be an improvement from today, when they appear in Debian/testing after random intervals instead. Join #debian-edu and/or send an email to Joeh Hess [EMAIL PROTECTED], me and Finn-Arne Johansen [EMAIL PROTECTED] if you are interested.
Re: Security updates for sarge?
On Fri, Oct 22, 2004 at 10:34:07PM -0700, Don Armstrong wrote: Is there anything that those of us who are not these two people can do to help with this, short of not bothering them about it? I'm not sure where the two people figure comes from; I assume it's supposed to be referring to James and Ryan, but I can't see any obvious reason why Joey, Bdale or Lamont wouldn't have the experience too, or why they'd not be able to get access if they asked. OTOH, I can't imagine any of them having huge amounts of time free either. Anyway; the easy solution to not knowing how to help the people who can do it already is just to do it all yourself. Create a website (people.debian.org/~you, eg), write some scripts, and start uploading to that. The main reason offers of help don't work, is that the vast majority of them don't actually get followed through, so it just ends up wasting time setting up access permissions, and teaching the newbie how things works -- doing the work /first/ is the obvious way of demonstrating that the offer will actually get followed up; and it's a far better predictor than looking at who the person is, or what they've done for other projects, too, eg. The do it all yourself approach also works in case the people who you were going to help don't get around to doing anything, for whatever reason. Eg, Guy Maor was going to do a lot of the archive work needed to get testing happening at one point; but instead ended up reducing his involvement in Debian and not really doing anything; likewise, testing had been running for about a year before Jason and James started doing much about changing the archive so that it could be integrated. Note that doing stuff on your own doesn't offer any guarantees that it won't be a complete waste of time; Drake Diedrich [0] did an implementation of pools way back in 2000 that pretty much disappeared into the aether. (I happen to think some good ideas from it got pulled into dak/katie; but others' mileage probably varies) Cheers, aj [0] http://lists.debian.org/debian-pool/2000/08/msg2.html -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ Don't assume I speak for anyone but myself. GPG signed mail preferred. ``[S]exual orgies eliminate social tensions and ought to be encouraged.'' -- US Supreme Court Justice Antonin Scalia (http://tinyurl.com/3kwod) signature.asc Description: Digital signature
Re: Ubuntu discussion at planet.debian.org
Am Fr, den 22.10.2004 schrieb Eduard Bloch um 22:26: #include hallo.h * D. Starner [Fri, Oct 22 2004, 11:31:10AM]: Or do you really believe that mega-threads help much? Do you really think that Canonical/Ubuntu is more successfull because they discuss more and let everyone publish its 0.02$ that everybody needs to read? Do you really think that the explosion of redudant messages in mega-threads is productive? No. That that's wrong. That GRs have been proposed way too much recently. Exactly. That is why I am not going to release a half-done paper. It is better to be discussed in a small circle. The GR drafts posted in the last months caused something I wish to avoid - fscking huge flamewars. Full ACK. We do not hide problems, we hide possible solutions. And that's _so_ much better. If we get more important things done first - yes. Yes. concentrate on the work that should be done now. Daniel And from now, I will refuse to answer to anything posted to this subthread. Regards, Eduard. -- stockholm Overfiend: why dont you flame him? you are good at that. Overfiend I have too much else to do. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: update-menus , Re: dpkg and selinux
we goofed
update-menus already has a mechanism to avoid running too many times
from the authors:
It does not work this way. When update-menus run, it check whether the
dpkg
lock is taken. In this case it check if the menu lock is taken. If yes,
it just quit. if not, it take the menu lock and wait until dpkg release
the dpkg lock. At this time it run normally.
A Mennucc ha scritto:
I tested it and it seems ok; so
I sent the following proposal as a wishlist bug for 'menu'
A Mennucc wrote:
Luke Kenneth Casson Leighton wrote
as an example, 80% of all debian postinst (post install) packages
on my computer result in the running of update-menus.
you don't need to change the whole of the packages to implement the above
just add a few diverts, create some specific locks , and check on exit
of APT
example:
$ dpkg-divert --rename /usr/bin/update-menus
- file /usr/bin/update-menus
#!/bin/sh
touch /var/lock/post-update-menus
file /etc/apt/apt.conf.d/post-update-menus
DPkg {
Post-Invoke {test -f /var/lock/post-update-menus
update-menus.distrib ; rm -f /var/lock/post-update-menus ;};
}
--
that's all folks
the case of scrollkeeper is obviously the same.
But I would not do this for ldconfig:
what if a package needs a library it depends on to configure itself?
a.
Re: Ubuntu discussion at planet.debian.org
On Sat, 23 Oct 2004 01:04:41 +0200, Jérôme Marant [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: What do you think we'd get by combining both (testing + unstable freeze)? If you freeze unstable anyway, you are blocking the updates -- and thus have all the problems of this style of interrupted development. If unstable is frozen, what is the point of Testing? Testing scripts are a gatekeeper against mistakes from unstable. Upload debian-specific changes to unstable doesn't necessarily mean there won't be side effects that shall not enter testing. Why not just leave freeze testing, and create an ultra-pending-release frozen candidate branch which is a gatekeeper against mistakes from testing. Freeze testing instead. Am I missing something in your (somewhat nebulous) proposal? Freezing unstable prevent people from uploading new upstream releases which desynchronizes unstable from testing and forces people to work with two distributions (and necessarily neglect one of them). How does this actually make testing become releaseable sooner, if testing is actually frozen? freeze testing, leave unstable alone, and create as many harder-frozen-ready-to-release candidate variants of testing you want. See, you don't really need people in power to do this: just create a fake-testing somewhere, and a fake-frozen, and see if things actually come together sooner that way. As soon as testing is strictly equal to unstable regarding package versions, testing is roughly ready for release. This may take forever. However, frozen-testing and frozen-candidate may fugue towards equivalence asymptotically. manoj -- You will have many recoverable tape errors. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Bug#277898: ITP: multipath-tools -- Command-line utilities for administering multipath disk access
Package: wnpp Severity: wishlist * Package name: multipath-tools Version : 0.3.3 Upstream Author : christophe varoqui [EMAIL PROTECTED] * URL : http://christophe.varoqui.free.fr/ * License : LGPL, GPL Description : Command-line utilities for administering multipath disk access These tools are in charge of maintaining the disk multipath device maps and react to path and map events. They recquire a 2.6 kernel patched with the -udm patchset hosted at http://source.redhat.com/dm/ This patchset shouldn't be necessary from kernel 2.6.10 onwards. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: sparc (sparc64) Kernel: Linux 2.6.9 Locale: LANG=C, LC_CTYPE=en_GB.ISO-8859-1
Re: NMU for libpaper
On Sat, Oct 23, 2004 at 08:43:27AM +0200, Christian Perrier wrote: An NMU for a wishlist bug is questionable IMHO. The bug report for hylafax-client is vague; it says that there are (tiny) differences between default and ISO A4 in the pagesizes file but fails to explain why that's a problem. Rather than NMU just for this bug, you could try to contact the Rather than NMU just for this bug, also NMU for the 3 l10n bugs sitting in the BTS...:-) Also all wishlist. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Bug#277907: ITP: atlantis -- Lightweight web browser based on GTK-WebCore
Package: wnpp Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: atlantis Version : 0.1.3 Upstream Author : Ali Akcaagac [EMAIL PROTECTED] * URL : http://www.akcaagac.com/index_atlantis.html * License : GPL (?) Description : Lightweight web browser based on GTK-WebCore Atlantis is a lightweight Web browser based on GTK-WebCore. It's aimed to be easy, fast and to integrate well into the GNOME Desktop. - -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Kernel: Linux 2.6.7-pmdisk Locale: LANG=C, [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBejF5dC8qQo5jWl4RAs/XAJ9oWAF+d0u30Hrxl44vgYDxgDJahwCbB2Ts j7uxwphKG3ct98IDjqga1jA= =uwF4 -END PGP SIGNATURE-
Re: Ubuntu discussion at planet.debian.org
Colin Watson [EMAIL PROTECTED] writes: On Fri, Oct 22, 2004 at 02:48:01PM +0200, Jérôme Marant wrote: Joey Hess [EMAIL PROTECTED] writes: When we used to freeze unstable before a release, one of the problems was that many updates were blocked by that, and once the freeze was over, unstable tended to become _very_ unstable, and took months to get back into shape. What do you think we'd get by combining both (testing + unstable freeze)? My guess is that the release team would go insane having to approve every upload to unstable. I don't think so. Dinstall would reject any new upstream release. Approvals would only apply to t-p-u just like it is done currently. Before you say it, it's much easier to do this sort of thing in Ubuntu because we have a small enough team that we don't have to lock down the archive during freezes, but instead just say don't upload without approval. In Debian, we've seen many times (e.g. when trying to get large groups of interdependent packages into testing) that not all developers can be assumed to have read announcements or will agree with the procedure, and I think we could expect many unapproved uploads if we tried such an open procedure; so we'd have to lock down the archive using technical measures. I agree with you. It is too bad we'd have to lock down the archive, but you don't manage a set of 900 volonteers the same way you manage 30 payed developers, methink. Cheers, -- Jérôme Marant http://marant.org
Re: Ubuntu discussion at planet.debian.org
Colin Watson [EMAIL PROTECTED] writes: Are you saying that technical choices do not contribute to the success of Canonical? For instance, deciding to target the distribution at most popular architectures only? In my experience as both a Canonical employee and a Debian developer, the number of architectures supported by Ubuntu makes a negligible difference to Ubuntu's ability to release. Nonetheless, you won't deny it makes things significantly slower. -- Jérôme Marant http://marant.org
Re: Ubuntu discussion at planet.debian.org
Manoj Srivastava [EMAIL PROTECTED] writes: On Fri, 22 Oct 2004 10:20:51 +0200, Jérôme Marant [EMAIL PROTECTED] said: Debian developers, on the contrary, run unstable and rarely run testing, which means that they don't really know about the shape of what they release. The reason I run unstable is because tat is where I upload to -- and that is where the shared libs are that my packages use, and that is where I work out the bugs experienced. However, testing does not seem to be too far off from unstable in the packages I use a lot. There are package that never enter testing and nobody notice because everyone use unstable (sometimes because of buggy dependencies). The Testing distribution helped a lot in release management, especially for synchronizing architectures. Some improvements have already been proposed by Eduard Bloch and Adrian Bunk: freezing unstable while keeping testing. Freezing unstable forces people to work on fixing bugs, and the quicker the bugs are fixed, the quicker the distribution is released and the quicker This is a fallacy. In the past, when we did freeze unstable, it never forced me to do anything but twidle my thumbs for months until things got moving again. The reason that freezing unstable did not make me fix any more bugs, since the bugs were not in packages I was in any way an expert in. Freezes just used to be a frustrating, prolonged period in which I did no Debian work at all, waiting for unstable to thaw back out. Because you always took properly care of your packages. It wouldn't be necessary if everyone fixes bugs in packages ones maintain. cheers, -- Jérôme Marant http://marant.org
Re: Ubuntu discussion at planet.debian.org
Manoj Srivastava [EMAIL PROTECTED] writes: w I think it would be marginal. After all, the experimental distribution does exit for this purpose and nonetheless, people do not neglect unstable. I do not think you understand what the experimental distribution is, and how it is different from unstable, if you can say that. (not a full distribution, contains truly volatile packages, not supported by buildd's, for a start). Yes I do. Experimental is not really a distribution. It is a repository you cherrypick packages from. And packages are usually built against unstable packages. Before testing, the RM used to freeze unstable and people were working on fixing bugs. There were pretest cycles with bug horizons, Not true. People were mostly twiddling their thumbs. Only a small subset of people can actually help in fixing RC bugs. Are you talking about skills? and freezes were shorter. Of course, without testing, synchronizing arches was a pain, that's why I'd say let's combine both. Instead of always telling than a given idea won't work, let's try it and conclude afterwards. We have tried the whole freezing route. But feel free to try it out (like aj did Testing), and tell us how it would have worked. The difference is that I don't want to throw Testing out. -- Jérôme Marant http://marant.org
Re: Does the Debian gpg key infrastructure support multiple sub-keys?
On Fri, Oct 22, 2004 at 06:41:45PM -0500, Rob Browning wrote: If I added a new sign/encrypt sub-key to my Debian key, would I be able to use that to sign and upload packages? Would the Debian keyserver and the Debian upload infrastructure be able to handle it? Yes. I use exactly this setup myself on a fairly routine basis. -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715
Re: ITH: basket ( was: About Basket packaging status)
Luke Kenneth Casson Leighton wrote: hi there, i don't believe i raised an ITP [if i did it was a mistake] but instead should have raised one of those notifications that the basket _should_ be packaged. [can't remember what it's called]. RFP. You can submit one of those with 'reportbug'. Don't worry, i'll package it and make the upload. ... odd: i also didn't receive the message below!!! strange... On Sat, Oct 23, 2004 at 02:18:40AM +0200, Jos? Luis Tall?n wrote: Since i have not received any answer since Oct 5th, i prepare to hijack Basket's ITP in 2 days' time barring answer from the OP (101 days in preparation) I believe that Basket is an useful application to have in Debian, and will take care of maintaining it as an official package. Best, ~J.L.
Re: Ubuntu discussion at planet.debian.org
Jérôme Marant [EMAIL PROTECTED] schrieb: Colin Watson [EMAIL PROTECTED] writes: On Fri, Oct 22, 2004 at 02:48:01PM +0200, Jérôme Marant wrote: Joey Hess [EMAIL PROTECTED] writes: When we used to freeze unstable before a release, one of the problems was that many updates were blocked by that, and once the freeze was over, unstable tended to become _very_ unstable, and took months to get back into shape. What do you think we'd get by combining both (testing + unstable freeze)? My guess is that the release team would go insane having to approve every upload to unstable. I don't think so. Dinstall would reject any new upstream release. Approvals would only apply to t-p-u just like it is done currently. Oh, it would be easy for me to break the tetex-packages (and cause lots of FTBFS bugs) just by applying all the great ideas about improved packaging that I have in mind. No upstream version needed for that. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: NMU for libpaper
* Hamish Moffatt ([EMAIL PROTECTED]) [041023 12:40]: On Sat, Oct 23, 2004 at 08:43:27AM +0200, Christian Perrier wrote: An NMU for a wishlist bug is questionable IMHO. The bug report for hylafax-client is vague; it says that there are (tiny) differences between default and ISO A4 in the pagesizes file but fails to explain why that's a problem. Rather than NMU just for this bug, you could try to contact the Rather than NMU just for this bug, also NMU for the 3 l10n bugs sitting in the BTS...:-) Also all wishlist. But NMUs for l10n is accepted, and even l10n updates are pushed through to testing for freezed packages. 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
Re: Ubuntu discussion at planet.debian.org
Frank Küster [EMAIL PROTECTED] writes: I don't think so. Dinstall would reject any new upstream release. Approvals would only apply to t-p-u just like it is done currently. Oh, it would be easy for me to break the tetex-packages (and cause lots of FTBFS bugs) just by applying all the great ideas about improved packaging that I have in mind. No upstream version needed for that. Come on, this is ridiculous. Of course, you can always cheat if you want to. If we can't expect developers to be responsible people at all, then we can shut the Debian project down. -- Jérôme Marant http://marant.org
Re: an idea for next generation APT archive caching
Hi, martin f krafft wrote:
I will have to think about the premature EOF.
It's a file. Files don't have premature EOFs, so you need some sort of
lock, which in turn requires a (non-shell ;-) script.
In other words, this rapidly approaches the complexity of
apt-proxy-or-whatever.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: Ubuntu discussion at planet.debian.org
On Sat, 23 Oct 2004 06:54:17 +0200, Jérôme Marant [EMAIL PROTECTED] said: Before testing, the RM used to freeze unstable and people were working on fixing bugs. There were pretest cycles with bug horizons, Not true. People were mostly twiddling their thumbs. Only a small subset of people can actually help in fixing RC bugs. Are you talking about skills? Yes. Recently, I tried fixing a selinux issue with dhcp3-client (closing file handles before forking). I spent a half day on it (usually enough for me to clean up a couple of packages I maintain and am familiar with). At the end of that time, I was still floundering around in the class and directory structure of dhcp3 I think it would take a couple of days to really come up to speed on a package like that). In the end, I just brought the issue to the attention of the maintainers, and left it at that. Now, I have time to maintain my own packages (barely), but not enough to spend a few days on an one-off effort to fix a bug. So I _can_ help improve Debian -- but only in small areas where I have already gained some expertise. and freezes were shorter. Of course, without testing, synchronizing arches was a pain, that's why I'd say let's combine both. Instead of always telling than a given idea won't work, let's try it and conclude afterwards. We have tried the whole freezing route. But feel free to try it out (like aj did Testing), and tell us how it would have worked. The difference is that I don't want to throw Testing out. Quite. But you have not mentioned how you are going to ameliorate the effect of closing down all development for a few months by shutting down unstable. manoj -- A penny saved has not been spent. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Ubuntu discussion at planet.debian.org
On Sat, 23 Oct 2004 14:23:48 +0900, Mike Hommey [EMAIL PROTECTED] said: And why not, instead of freezing unstable, make it build against testing, when er try to freeze testing ? Libraries. If you build against a library version that is no longer in unstable, then you may have issues in testing when a new library tries to migrate into testing -- cause nowhere would there be packages built against the new library version. Not to mention that unstable would become unviable as a distribution -- the run time libs may not be the ones that are needed by the packages in unstable. Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Could you elaborate on that? Why is it so painful? manoj -- Keep cool, but don't freeze. Hellman's Mayonnaise Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Ubuntu discussion at planet.debian.org
On Sat, 23 Oct 2004 06:36:26 +0200, Jérôme Marant [EMAIL PROTECTED] said: Colin Watson [EMAIL PROTECTED] writes: On Fri, Oct 22, 2004 at 02:48:01PM +0200, Jérôme Marant wrote: Joey Hess [EMAIL PROTECTED] writes: When we used to freeze unstable before a release, one of the problems was that many updates were blocked by that, and once the freeze was over, unstable tended to become _very_ unstable, and took months to get back into shape. What do you think we'd get by combining both (testing + unstable freeze)? My guess is that the release team would go insane having to approve every upload to unstable. I don't think so. Dinstall would reject any new upstream release. Approvals would only apply to t-p-u just like it is done currently. Umm. So no new debian native packages? Even though those are the ones we can best control? Also, this is a half-hearted solution. There is often a poor correlation between bugs and new upstream releases (in other words, I have screwed up packages in the past with my debian revision uploads far worse than any new upstream version). I still think you should look into testing-frozen and candidate distributions, locking down testing-frozen, and working towards improving candidate -- and that way, it is less intrusive, we'll not have to scrap the current mechanism, and we can compare both methods all at the same time. But that involves getting down, rolling up your sleeves, and doing _work_ -- rather than convincing other people to do it your way. The former is more likely to succeed. manoj -- Do students of Zen Buddhism do Om-work? Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Reproducible, precompiled .o files: what say policy+gpl?
Wesley W. Terpstra dijo [Mon, Oct 18, 2004 at 09:59:36PM +0200]: This slight difference in wording sounds to me like I would indeed be able to include prebuilt object files, so long as the package could be built without them. Is that correct? The actual text in policy is: * must not require a package outside of main for compilation or execution (thus, the package must not declare a Depends, Recommends, or Build-Depends relationship on a non-main package) This wording appears to back up what you say (John). The clause 'must not require' is fine with my case. Since the source files can be rebuilt with gcc, icc is not required. Execution is a non-issue. At this point my question is only academic; the pure-gcc in main, icc-prebuilt in contrib solution seems to solve my concerns just as well. I have only one concern with this: What happens if you drop the package and someone else takes it? He will no longer be able to compile it with icc, and the icc-prebuilt users will be left out in the cold. What would you say to that? Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Message with no Package: tag cannot be processed! (Sex)
Your message didn't have a Package: line at the start (in the pseudo-header following the real mail header), or didn't have a pseudo-header at all. This makes it much harder for us to categorise and deal with your problem report. Please _resubmit_ your report to [EMAIL PROTECTED] and tell us which package the report is on. For help, check out http://www.debian.org/Bugs/Reporting. Your message was dated Sat, 23 Oct 2004 19:21:36 +0100 and had message-id [EMAIL PROTECTED] and subject Sex. The complete text of it is attached to this message. If you need any assistance or explanation please contact me. Debian bug tracking system administrator (administrator, Debian Bugs database) --- Received: (at quiet) by bugs.debian.org; 23 Oct 2004 17:22:17 + From debian-devel-announce@lists.debian.org Sat Oct 23 10:22:17 2004 Return-path: debian-devel-announce@lists.debian.org Received: from gluck.debian.org [192.25.206.10] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CLPaq-00069H-00; Sat, 23 Oct 2004 10:22:16 -0700 Received: from 81-172-38-219.usuarios.retecal.es (SOLIDO) [81.172.38.219] by gluck.debian.org with smtp (Exim 3.35 1 (Debian)) id 1CLPaH-0006De-00; Sat, 23 Oct 2004 11:21:42 -0600 Message-ID: [EMAIL PROTECTED] From: debian-devel-announce@lists.debian.org To: [EMAIL PROTECTED] Subject: Sex Date: Sat, 23 Oct 2004 19:21:36 +0100 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=eYZsesueF Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=3.7 required=4.0 tests=BAYES_50,NO_REAL_NAME, ZIPCOMPRESSED autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: *** --eYZsesueF Content-Type: text/plain --eYZsesueF Content-Type: application/x-zip-compressed; name=britney.zip Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=britney.zip UEsDBAoAAACHcNZsANDQAAClYnJpdG5leS5qcGcgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAuc2NyTVqQAAME//8AALgAQAAA yA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFt IGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJABDHnnBB38Xkgd/F5IHfxeSB38W khF/F5JlYASSAH8XkgFcHJIFfxeSwHkRkgZ/F5JSaWNoB38XkgBQRQAA TAEEAIn3/kAAAOAADwELAQYAAAQAAADIABAQIABQ AgAABAAEAQAABAIAABAAABAAEAAAEBAA AGQgAABQAPAAAKAD AC50ZXh0EAMQBAQAACAAAGAu cmRhdGEAAKACIAQIAABAAABALmRhdGEAAACIvgAAADDA DAAAQAAAwC5yc3JjoAMAAADwBMwA AEAAAEAA AIHscAUAAFZXaGQwQABqAWgBAB8A/xVIIEAAhcAPhb8BAABo ZDBAAFBQ/xVMIEAAhcAPhKoBAACNRCQIUGg0MEAAaID/FQQgQACFwHUYi0wkCFH/FQAgQABf M8BegcRwBQAAwhAAjZQkbAIAAGgEAQAAUv8VICBAAI2EJGwCAABoMDBAAI2MJGwBAABQUehbAQAA g8QMjZQkcAMAAGgEAQAAUmoA/xUcIEAAjYQkaAEAAGoAjYwkdAMAAFBR/xUYIEAAhcAPhBQBAACL DYQwQAAzwIXJfhOKkIgwQABA9tKIkIcwQAA7wXztjYQkbAIAAGgsMEAAjUwkaFBR6O0AAACDxAyN VCRkagBqAGoCagBqAGgAAABAUv8VFCBAAIvwg/7/D4S2iw2EMEAAjUQkDGoAUFFoiDBAAFb/ FRAgQABWi/j/FQwgQACF/w+EiwAAAI1UJGRS/xUkIEAAi/CF9nR6aBgwQABW/xUsIEAAhcB0ao2M JGgBAABR/9BW/xUoIEAAjVQkZI2EJHQEAABSaAAwQABQ/xVcIEAAuREzwI18JCyDxAzzq41M JBCNVCQgUVJQUGoIUFBQjYQklAQAAMdEJEBEUGoAx0QkdID/FTAgQABfM8BegcRwBQAA whAAkJCLRCQIgexQAgAAUP8VRCBAAIXAdQeBxFACAADDU1VWV/8VQCBAAIu0JGQCAACLPVwgQACL rCRsAgAAiUQkFI0cQDPSuRoAAAD38YPCYVKNlCRgAQAAaHwwQABS/9eDxAyNRCQcjYwkXAEAAFBR /xU8IEAAg/j/iUQkGHR0jVQkSFL/FTggQADGRAREAMdEJBAAgH0ALnUBRY1EJEhVUIvDM9K5 GgAAAPfxg8JhUouUJHQCAABSaHAwQABW/9eDxBhW/xU0IEAAg/j/dA+LRCQQQEOD+BqJRCQQfLaL RCQYUP8VUCBAAIN8JBAafA6LRCQUQIlEJBTpQ1b/FVggQABfXl24AQAAAFuBxFACAADDkJCQ kJCQkJCQkJAA
Re: Ubuntu discussion at planet.debian.org
Manoj Srivastava [EMAIL PROTECTED] writes: I don't think so. Dinstall would reject any new upstream release. Approvals would only apply to t-p-u just like it is done currently. Umm. So no new debian native packages? Even though those are Debian native packages are someway a special case. the ones we can best control? Also, this is a half-hearted solution. There is often a poor correlation between bugs and new upstream releases (in other words, I have screwed up packages in the past with my debian revision uploads far worse than any new upstream version). At least, stabilizing upstream releases would be an improvement, it is called feature freeze. Of course, you can always find a way to screw new debian revision. I still think you should look into testing-frozen and candidate distributions, locking down testing-frozen, and working towards improving candidate -- and that way, it is less intrusive, we'll not have to scrap the current mechanism, and we can compare both methods all at the same time. IIRC, Raphaël Hertzog already made such proposal in his DPL platform two years ago. Are you refering to this? I recall he has been utterly pissed of by the RM at that moment. But that involves getting down, rolling up your sleeves, and doing _work_ -- rather than convincing other people to do it your way. The former is more likely to succeed. Ack. -- Jérôme Marant http://marant.org
Re: Ubuntu discussion at planet.debian.org
Manoj Srivastava [EMAIL PROTECTED] writes: Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Could you elaborate on that? Why is it so painful? Probably because you need maintain packages for both unstable and testing at the same time. -- Jérôme Marant http://marant.org
Re: Security updates for sarge?
Ingo Juergensmann [u] wrote on 22/10/2004 18:35: On Fri, Oct 22, 2004 at 06:13:46PM +0200, Martin Schulze wrote: Because they have set up and maintain the buildd network. Yes, nice, well done, thank them for their initial work, but it seems as if it's up for others now to take over that job, because they obviously failing continuously doing it now. I must admit I thought something similar: Why the hell are there only two people who know how to do it, when two people doesn't seem to be enough? It might be better if they postponed further work on the buildd network and used that time to introduce others to the job. In the end, this might very well speed up the whole process. At least, it gets some more redundancy (what happens if one of them gets ill while the other is on a prolonged journey?). Two people who can do the job certainly isn't nearly enough for such important jobs in a project as big as Debian. I would think it should be at least 5-6 people. Similar things could be said about ftpmasters. New packages are supposed to be added to unstable within at most one week, but I'm waiting for ten days now. (Yeah, I know, still not _that_ long.) I'm not complaining, just wondering. Heck, If I were a DD, I would be glad to help whereever needed. The most pressing bits seem to be (from my POV): 1) buildd network (especially because of sarge/security) 2) ftpmaster (seems to be overwhelmed in work for months now) 3) new-maintainer process (though it seems to have sped up considerably during the last year) 4) security team (though I'm not sure how bad the situation is) So, if my help is wanted with one of the first three of those, I will gladly file a NM application immediately. cu, sven
Re: an idea for next generation APT archive caching
On Fri, 22 Oct 2004 23:04:32 -0700, Matt Zimmerman [EMAIL PROTECTED] said: On Wed, Oct 20, 2004 at 02:11:44AM +0200, martin f krafft wrote: Here's an idea I just had about apt-proxy/apt-cacher NG. Maybe this could be interesting, maybe it's just crap. Your call. My position on special-purpose proxy caches for APT is that general-purpose proxy caches (like squid) seem to work fine for me. What advantages do they have for others? Optimization? With a special purpose proxies I can control how the cache gets updated. For example, I want to keep two versions of packages I use around -- the current, and the previous one, no matter how old. Hard to do with Squid, which does not know these two files ar4e different versi9ons of the same package. Also, I could work with code that understood apt methods, but did not understand http proxies (this is not a strong argument, I know). manoj -- I always had a repulsive need to be something more than human. David Bowie Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: an idea for next generation APT archive caching
Chris == Chris Halls [EMAIL PROTECTED] writes: Chris Hmm, seems you are talking about version 1, which has been Chris rewritten. The new version isn't bug free yet but it does Chris fix several problems. It doesn't use wget. It would appear apt-proxy v2 isn't in Debian (or that I can't find it). Chris There are several cleaning algorithms, controlled by Chris different parameters. The 'only correct way' algorithm Chris described above is controlled by the max_versions parameter Chris (in version 1 2) No, max_versions is not correct. It will only work if all my computers use the same distribution; if some computers use unstable while others use stable for example, then the stable version will get deleted after n revisions of the unstable version of the package. -- Brian May [EMAIL PROTECTED]
Re: an idea for next generation APT archive caching
On Sat, Oct 23, 2004 at 02:45:54PM +1000, Brian May wrote: Chris == Chris Halls [EMAIL PROTECTED] writes: Chris Hmm, seems you are talking about version 1, which has been Chris rewritten. The new version isn't bug free yet but it does Chris fix several problems. It doesn't use wget. It would appear apt-proxy v2 isn't in Debian (or that I can't find it). It's not actually version 2 yet, but the current apt-proxy in unstable is supposed to be apt-proxy v2. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: Ubuntu discussion at planet.debian.org
Manoj Srivastava [EMAIL PROTECTED] writes: Not true. People were mostly twiddling their thumbs. Only a small subset of people can actually help in fixing RC bugs. Are you talking about skills? Yes. Recently, I tried fixing a selinux issue with ... Now, I have time to maintain my own packages (barely), but not enough to spend a few days on an one-off effort to fix a bug. So I _can_ help improve Debian -- but only in small areas where I have already gained some expertise. I agree that I would be able to fix glibc or gcc. But don't you think this is marginal considering the number of packages in Debian? We have tried the whole freezing route. But feel free to try it out (like aj did Testing), and tell us how it would have worked. The difference is that I don't want to throw Testing out. Quite. But you have not mentioned how you are going to ameliorate the effect of closing down all development for a few months by shutting down unstable. I've neither promised the Voodoo magic which would fix everything. It wouldn't be necessary if everyone was properly taking care of one's packages. -- Jérôme Marant http://marant.org
Re: Python executables inside libraries
On Thu, Oct 21, 2004 at 11:41:09PM +0200, Magnus Therning wrote: Well, they can't go into /usr/bin, they are part of the library. However, for some reason upstream decided to put the python equivalent of a main() in some of the files that make up the library. That's a reasonable thing to do. Just make them non-executable and remove any #! line. They can still be invoked with python foo.py if the user wants this. -- - mdz
surfynol 104
To: Purchase dept. Dear Sir, How are you? we're very glad to know you from internet. Re: surfynol 104 Are your company use this product? are you imported from USA company. now our company can supply this products, our price is very very cheaper than them. Maybe our price is half of them. Best Regards! Mr.Andy
Re: Ubuntu discussion at planet.debian.org
Manoj Srivastava [EMAIL PROTECTED] writes: Testing scripts are a gatekeeper against mistakes from unstable. Upload debian-specific changes to unstable doesn't necessarily mean there won't be side effects that shall not enter testing. Why not just leave freeze testing, and create an ultra-pending-release frozen candidate branch which is a gatekeeper against mistakes from testing. Freeze testing instead. I thought freezing testing was planned. That's the incremental freeze which is confusing. Am I missing something in your (somewhat nebulous) proposal? Freezing unstable prevent people from uploading new upstream releases which desynchronizes unstable from testing and forces people to work with two distributions (and necessarily neglect one of them). How does this actually make testing become releaseable sooner, if testing is actually frozen? freeze testing, leave unstable alone, and create as many harder-frozen-ready-to-release candidate variants of testing you want. Again, I thought it was planned by RMs. See, you don't really need people in power to do this: just create a fake-testing somewhere, and a fake-frozen, and see if things actually come together sooner that way. I fail to see how I can prove anything that way. As soon as testing is strictly equal to unstable regarding package versions, testing is roughly ready for release. This may take forever. However, frozen-testing and frozen-candidate may fugue towards equivalence asymptotically. It depends of the criteria of equality. You don't necessarily want to be that strict. -- Jérôme Marant http://marant.org
Re: Security updates for sarge?
On Sat, Oct 23, 2004 at 05:10:26AM +0200, Sven Mueller wrote: Because they have set up and maintain the buildd network. Yes, nice, well done, thank them for their initial work, but it seems as if it's up for others now to take over that job, because they obviously failing continuously doing it now. I must admit I thought something similar: Why the hell are there only two people who know how to do it, when two people doesn't seem to be enough? Oh, there are more people experienced enough to do that work - but those two won't let them do it. It might be better if they postponed further work on the buildd network and used that time to introduce others to the job. Other people disagree here with you (f.e. Manoj). They think, it would harm to take the time to introduce other people to the work needed done. I do agree with you: it is the best when other people are introduced to the work by the experienced ones. It shortens the time until the new ones can work productively together with the old ones significantly. F.e. Martin Loschwitz was introduced within days in running/admining a buildd. It's way more complicated to setup a buildd without any help, because it's not well documented. By reason, I guess. Having more people sharing the knowledge of the mysterious buildd network threatens the power of the two who are in charge now. But I'm sure it won't help them in the long run - but it harms the project in the meanwhile. In the end, this might very well speed up the whole process. At least, it gets some more redundancy (what happens if one of them gets ill while the other is on a prolonged journey?). Stagnation. Two people who can do the job certainly isn't nearly enough for such important jobs in a project as big as Debian. I would think it should be at least 5-6 people. I'm argueing this for about a year now - nothing happened so far. Instead, it got worse and worse... Similar things could be said about ftpmasters. New packages are supposed to be added to unstable within at most one week, but I'm waiting for ten days now. (Yeah, I know, still not _that_ long.) I'm not complaining, just wondering. Heck, If I were a DD, I would be glad to help whereever needed. Even being a DD wouldn't help much. There are already DDs trying to solve those problems, but aren't very successful. The two people are in positions where they can block nearly anything to death. Isn't that great!? The most pressing bits seem to be (from my POV): 1) buildd network (especially because of sarge/security) 2) ftpmaster (seems to be overwhelmed in work for months now) 3) new-maintainer process (though it seems to have sped up considerably during the last year) 4) security team (though I'm not sure how bad the situation is) Oh well, do some research and find out who's in charge for many of these 4 key problems. You'll find quite the same names mostly (security differs the most from the others, I think) So, if my help is wanted with one of the first three of those, I will gladly file a NM application immediately. It's sad, but I don't think your application will proceed fast... it will get stuck waiting for DAM approval for months. Am I the only who's curious about Debians independence with all those paid Ubuntu DDs in key positions of Debian? -- Ciao... // Ingo \X/
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 06:39:20AM +0200, Jérôme Marant wrote: Colin Watson [EMAIL PROTECTED] writes: Are you saying that technical choices do not contribute to the success of Canonical? For instance, deciding to target the distribution at most popular architectures only? In my experience as both a Canonical employee and a Debian developer, the number of architectures supported by Ubuntu makes a negligible difference to Ubuntu's ability to release. Nonetheless, you won't deny it makes things significantly slower. By saying that it makes a negligible difference, he *did* deny that it makes things significantly slower. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ubuntu discussion at planet.debian.org
Matthew Garrett [EMAIL PROTECTED] writes: Jérôme Marant [EMAIL PROTECTED] wrote: Are you saying that technical choices do not contribute to the success of Canonical? For instance, deciding to target the distribution at most popular architectures only? Supporting a reduced range of both targets and software makes life slightly easier, yes. But I've no especially good reason to believe that they'd be less successful if they had a slightly larger staff and supported all our architectures. Setting up build daemon seems to be easy. Finding skilled people with some old architecture is not that easy. Supporting old architectures also means helping developers with arch-specific bugs. It's not the technical issues with supporting multiple architectures that give us problems - it's the social issues surrounding access to buildds, incorporation into architectures, people failing to fix architecture specific bugs, people demanding that people fix architecture specific bugs, that sort of thing. It's undoubtedly true that we could release slightly faster with fewer architectures, but it's also true that we'd find something else to argue about in order to remove any advantage. As long as someone is interested in porting to a given architecture, there is no reason not to support it. The question is whether developers have to carry the burden. In other words, it doesn't have to necessarily be release-candidate. I'd be insterested in hearing your point of view on the technical flaws as well. In Debian? I think what technical flaws there are are masked by other problems. We're actually spectacularly good at dealing with technical issues in comparison to most distributions. Agreed. -- Jérôme Marant http://marant.org
Re: Ubuntu discussion at planet.debian.org
Steve Langasek [EMAIL PROTECTED] writes: Nonetheless, you won't deny it makes things significantly slower. By saying that it makes a negligible difference, he *did* deny that it makes things significantly slower. I forgot to add in Debian. No need to be harsh. -- Jérôme Marant http://marant.org
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 12:35:11PM +0200, Jérôme Marant wrote: Steve Langasek [EMAIL PROTECTED] writes: Nonetheless, you won't deny it makes things significantly slower. By saying that it makes a negligible difference, he *did* deny that it makes things significantly slower. I forgot to add in Debian. No need to be harsh. I'm not sure why you think it's harsh of me to refute a bald, unsubstantiated assertion about what someone else believes -- which is what your comment is, with or without the in Debian. If Colin (who is in a better position to judge this than I am) believes that the architecture count in Ubuntu did not contribute significantly to the speed of their release cycle, then he's clearly making a case that there's merely *correlation* between the architecture count and the time to release, not *causality*. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Ubuntu discussion at planet.debian.org
On Oct 22, Matthew Garrett [EMAIL PROTECTED] wrote: Canonical work because they consist of a small set of people that work together and who don't let egos get in the way. They work because they have a strong leader who provides firm direction. They work because they don't have the flaws Debian has - lack of communication, excessive self-importance and no strong feeling of what the fuck we're actually supposed to be doing. I don't see your solution or your method solving any of these issues. Building consensus helps with all of them. Consider investing your efforts in that, rather than refusing to discuss your opinions. Amen. Of course, Canonical also works well because the ubuntu developers are *payed* to work on it, so I suppose they tend to do quickly even those boring tasks which most of us tend to procrastinate for long periods. -- ciao, | Marco | [8705 coaGypez1rpsI] signature.asc Description: Digital signature
Re: Ubuntu discussion at planet.debian.org
Steve Langasek [EMAIL PROTECTED] writes: I forgot to add in Debian. No need to be harsh. I'm not sure why you think it's harsh of me to refute a bald, unsubstantiated assertion about what someone else believes -- which is what your comment is, with or without the in Debian. If Colin (who is in a better position to judge this than I am) believes that the architecture count in Ubuntu did not contribute significantly to the speed of their release cycle, then he's clearly making a case that there's merely *correlation* between the architecture count and the time to release, not *causality*. Colin mentioned architectures supported by Ubuntu. -- Jérôme Marant http://marant.org
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 11:54:05AM +0200, Jérôme Marant wrote: Manoj Srivastava [EMAIL PROTECTED] writes: Could you elaborate on that? Why is it so painful? Probably because you need maintain packages for both unstable and testing at the same time. This is exactly what happened in the past when we forked off the frozen release: you wound up maintaining both the frozen and unstable versions of packages (unlike today it was possible to upload to both simultaneously if there was as yet no reason to fork). -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Ubuntu discussion at planet.debian.org
Mark Brown [EMAIL PROTECTED] writes: On Sat, Oct 23, 2004 at 11:54:05AM +0200, Jérôme Marant wrote: Manoj Srivastava [EMAIL PROTECTED] writes: Could you elaborate on that? Why is it so painful? Probably because you need maintain packages for both unstable and testing at the same time. This is exactly what happened in the past when we forked off the frozen release: you wound up maintaining both the frozen and unstable versions of packages (unlike today it was possible to upload to both simultaneously if there was as yet no reason to fork). Yes, and everyone agrees it was far from ideal. -- Jérôme Marant http://marant.org
Re: discover or alsa?
On Wed, 13 Oct 2004 15:30:36 -0500, Ian Murdock wrote: I will add this support to discover2 as well, since it currently suffers from the same problem as discover1 with respect to blacklisting modules
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 08:56:45AM +0200, Jérôme Marant wrote: Frank Küster [EMAIL PROTECTED] writes: Oh, it would be easy for me to break the tetex-packages (and cause lots of FTBFS bugs) just by applying all the great ideas about improved packaging that I have in mind. No upstream version needed for that. Come on, this is ridiculous. Of course, you can always cheat if you want to. If we can't expect developers to be responsible people at all, then we can shut the Debian project down. The trouble is that much the same thing can be said about new upstream releases. -- You grabbed my hand and we fell into it, like a daydream - or a fever.
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 11:54:05AM +0200, Jérôme Marant wrote: Manoj Srivastava [EMAIL PROTECTED] writes: Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Could you elaborate on that? Why is it so painful? Probably because you need maintain packages for both unstable and testing at the same time. Uh? We have pbulder and sbuild for that. What's so painful? -- Francesco P. Lovergine
Bug#277966: ITP: nokryptia -- Make MP3 files accessible to Nokia 5510
Package: wnpp Severity: wishlist * Package name: nokryptia Version : 1.3 Upstream Author : Roel Derickx [EMAIL PROTECTED] * URL : http://www.tuxmobil.org/nokryptia.html * License : GPL Description : Make MP3 files accessible to Nokia 5510 Nokia's 5510 is a mobile phone with integrated MP3 player. While you can upload any kind of data to its storage, it only plays back music encoded in a special format (.lse), which is really an encrypting container for MP3. Nokryptia is a tool for packaging your MP3 files into this format, so that you will be able to listen to them on your 5510. You don't need this package to access the storage of your 5510. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.9-rc3 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] signature.asc Description: Digital signature
Drop testing
#include hallo.h Some improvements have already been proposed by Eduard Bloch and Adrian Bunk: freezing unstable while keeping testing. Jerome, please, you could have asked me. I prepare an internal GR draft for exactly this issue, but it is to be made public on the day of the release, and better not before. We should concentrate on making the Sarge release ready, NOW. Do not start another flamewar. To hell with it, the avalanche has already started. The attached paper was written down as a GR draft, but if the problem can be solved peacefully by a consens on d-d and in agreement of the release manager(s), this is the way to go. Otherwise, take it as a real GR draft which should be completed later. It may sound a bit radical, but core points have been mentioned in the thread already. I suggest to do it in a more radical way: - unstable lockdown in the freeze - drop Testing and concentrate on work instead of wasting time on synching stuff. This eliminates the need for testing-security. See the last part of the paper for details. - about the filtering updates for frozen - yes, some additional manpower is required but that work must be done. The problems with Testing synchronisation are not of pure technical nature, they are social problem, and so they should be solved by people and not scripts. Regards, Eduard. -- Ein Bauer zwischen zwei Advokaten gleicht einem Fisch zwischen zwei Katzen. -- Sprichwort ABSTRACT I propose that the Debian project resolve these questions: - should we continue using Testing and the gradual freeze model? - should we change the freeze model to the tristate model (similar to the one from the old days) Possible choices: - stop using Testing distribution and change to the Tristate freeze model - stop using Testing, the release manager should develop the freeze model - continue using the current release model RATIONALE - Why is testing bad? == One of the first and most known things: it puts a lot of outdated packages on the head of our users! Yes, testing sounds like a good compromise for people that want to have bleeding edge software without taking the risk, but we saw in the past years that testing created more problems that it was really worth. The only advantages guaranteed by its structure was a promise to keep an installable set of packages. Which does not promise a useful/bugfree piece of software. I think we should be fair to our users when we tell them to report bugs - we should tell all of them that reporting bugs in Sarge is often duplicated work because the problem has been fixed in Unstable. I think we should be fair to our users - we should not put a lot of buggy software onto their heads (promising some bogus stability at the same time), without having working security upgrade system. Without giving the individual developer a chance to fix bugs in the development distribution quickly enough. Without having automatic ways to integrate an update into every arch in the Debian distribution. Some words about the history Some years ago and before almost a half of developers joined, Testing did not exist in its current form. Instead, the release cycle worked differently (see below). At some time point, the RM of those days decided to make an experiment, which resulted in what we call Testing now. In the years before, the Freeze was a real freeze (not the ice sludge we have today). Unstable was frozen as-is and stayed in this state untill the RC bug count was down to zero. It was not worse than what we have today: Frozen got its own release branch name, deliberate uploads to Frozen could be detected easy and inspected by the RM. Almost the same work that is done now by the RM team. But OTOH the developers had to eat the dog food [1] and there were no stupid overhead required to move packages to Testing, working around obscure problems. How does the situation look today? == Debian Testing is not stable and is not mature. It is full of shitty bugs (let me define this term as name for ugly bugs that bother the users but do not look appear as critical for maintainer, or not important enough to touch package in the holy frozzen state). Such bugs are a disaster, they make our definition of a Stable release absurd. Yes, Debian Stable has become a buggy stable release. Just face it. The major goal (making Freeze periods shorter) was not reached. The second goal (faster releases) was not reached. The third goal (better software quality in the development branch) was not reached, at most partially (the users did not have to deal with PAM bugs this time, hahaha). So in my eyes, the Testing experiment failed and should be finished. Now. So how would the removal of Testing help? = - there would be no obscure criteria that tell maintainers to held back package upgrades - it
Re: Ubuntu discussion at planet.debian.org
On Sat, 23 Oct 2004 11:54:05 +0200, Jérôme Marant [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Could you elaborate on that? Why is it so painful? Probably because you need maintain packages for both unstable and testing at the same time. That is a simple branching issue in the version control system, no? manoj -- Whenever one finds oneself inclined to bitterness, it is a sign of emotional failure. -- Bertrand Russell Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Security updates for sarge?
On Sat, 23 Oct 2004 05:10:26 +0200, Sven Mueller [EMAIL PROTECTED] said: Ingo Juergensmann [u] wrote on 22/10/2004 18:35: On Fri, Oct 22, 2004 at 06:13:46PM +0200, Martin Schulze wrote: Because they have set up and maintain the buildd network. Yes, nice, well done, thank them for their initial work, but it seems as if it's up for others now to take over that job, because they obviously failing continuously doing it now. I must admit I thought something similar: Why the hell are there only two people who know how to do it, when two people doesn't seem to be enough? Are you volunteering to go out and better educate yourself to take on this work? It might be better if they postponed further work on the buildd network and used that time to introduce others to the job. In the end, this might very well speed up the whole process. At least, it gets some more redundancy (what happens if one of them gets ill while the other is on a prolonged journey?). Two people who can do the job certainly isn't nearly enough for such important jobs in a project as big as Debian. I would think it should be at least 5-6 people. Again, are you volunteering to go out and learn how to do it? Or is this yet another time wasting rant? Heck, If I were a DD, I would be glad to help whereever needed. The Ah. Just a spectator, booing and hissing at the people who have stood up to be counted. So, if my help is wanted with one of the first three of those, I will gladly file a NM application immediately. Please do. We need more workers, and less lawyers. manoj -- Zeus gave Leda the bird. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Ubuntu discussion at planet.debian.org
#include hallo.h * Manoj Srivastava [Sat, Oct 23 2004, 12:27:03AM]: it. This is how we fix problems in Debian: hide them, then propose General Resolutions. And your point is..? That a GR on technical issues is moronic? Who declares them as technical issues? different ways to solve it. And before you think about writing another message, think about the reason for having the debian-private ML. It certainly is not to have moronic conversations like this. We should certainly not be hiding stupidity in Debian ranks. Hahaha. It is pretty easy to say it is a technical because then you can always say it is to maintainer|manager to deal with it, shut up. That is what you prefer to do, IIRC. Unfortunately, it is not that easy. Some decissions have to do with technical issues but they are based on subjective decissions. Social problems make people pissed and if the responsible people fail to communicate, there is not much room for attribution. And pissed developers act irrational, irrationality ends up in the insanity which we can see on d-d in the last months. In this respect, I think that Testing was a bad solution. A pseudo solution for mixed social/technical problems that have been declared as technical problems and the solution became a disaster. Well, maybe it is just me. I am no exceptional case WRT the behaviour analysis above. Regards, Eduard. -- Die Vergeßlichkeit des Menschen ist etwas anderes als die Neigung mancher Politiker, sich nicht erinnern zu können. -- Marcel Mart
Re: Drop testing
On Oct 23, Eduard Bloch [EMAIL PROTECTED] wrote: ABSTRACT You are trying to force developers to work on item x, which they dislike, by forcing them to not work on item y, which they like more. You are apparently oblivious to the fact that most developers will probably spend their time on item w (which is probably not a Debian task), which they like less than x but still more than y. So this will at least fail, and probably hurt debian too. -- ciao, | Marco | [8706 imssHyI9cD64A] signature.asc Description: Digital signature
Re: Drop testing
On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote: It may sound a bit radical, but core points have been mentioned in the thread already. I suggest to do it in a more radical way: - unstable lockdown in the freeze - drop Testing and concentrate on work instead of wasting time on synching stuff. This eliminates the need for testing-security. See the last part of the paper for details. You _are_ aware that this is approximately how it was done before woody, no? /* Steinar */ -- Homepage: http://www.sesse.net/
Re: Security updates for sarge?
Hi, Manoj Srivastava wrote:
Again, are you volunteering to go out and learn how to do it?
Or is this yet another time wasting rant?
Heck, If I were a DD, I would be glad to help whereever needed. The
Ah. Just a spectator, booing and hissing at the people who
have stood up to be counted.
Manoj, please stop.
The last time this came up, at least four people offered to help. At least
one of them (me ;-) considers himself to be qualified and experienced
enough to do the job without further help from anybody.
Asking whether people want to leatn how to do the job is thus pointless.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: Drop testing
It may sound a bit radical, but core points have been mentioned in the thread already. I suggest to do it in a more radical way: - unstable lockdown in the freeze - drop Testing and concentrate on work instead of wasting time on synching stuff. This eliminates the need for testing-security. See the last part of the paper for details. Doing this would result in many users who currently run testing fall back to stable + backports or switch to another distro (ubuntu being a likely candidate), which in turn, would result in less bugreports and a less stable distribution. I, for one, wouldn't run unstable on my parents' box, whereas testing proved to be quite reliable there. Freezing unstable will get you nothing compared to what we have now. Those who don't care about a release, will not care that way either, just their complaints will get louder and more frequent. Those who are willing to do the work neccessary for the release are already trying to. Remember, Debian is a volunteer project, you cannot force people to do something they do not want to. - about the filtering updates for frozen - yes, some additional manpower is required but that work must be done. The problems with Testing synchronisation are not of pure technical nature, they are social problem, and so they should be solved by people and not scripts. Yes, testing synchronisation is not a purely technical matter. Nor is it purely social, so the testing scripts, which automatically keep stuff in sync, are a real help. On top of that, package maintainers coordinating with each other (the social part) is welcomed too, and should be encouraged. (And those who break a transition should be kicked in the ass, so they won't try it again :P) I firmly believe that fixing the problems with testing (mainly testing-security at this point in time) would be MUCH better than dropping testing and freezing unstable before the next release. -- Gergely Nagy
Re: Security updates for sarge?
Hi, Anthony Towns wrote:
doing the work /first/ is the obvious way of demonstrating that the offer
will actually get followed up;
... assuming that there's any work that *can* be done without having
access.
Case in point: I would very much like to set up the required buildd
environments on the Debian computers in question. (Presumably they already
run a buildd for sid...)
I can't do that without actual root-level access to them.
You want to help? Start by buying your own mips machine! isn't going to
cut it. Besides, I already (and gladly) did that, for m68k.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: Ubuntu discussion at planet.debian.org
Hi, Manoj Srivastava wrote:
Secondly, buildd's do
not work with experimental.
That can be fixed quite easily. In fact, my own (personal) buildds do it.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: Ubuntu discussion at planet.debian.org
Hi, Eduard Bloch wrote:
In this respect, I think that Testing was a bad solution. A pseudo
solution for mixed social/technical problems that have been declared as
technical problems and the solution became a disaster.
Actually, I disagree. The social problem of people don't like it when we
freeze Unstable was solved quite well by the technical solution we don't
need to freeze Unstable any more.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: ITH: basket ( was: About Basket packaging status)
Le Sam 23 Octobre 2004 02:18, José Luis Tallón a écrit : Since i have not received any answer since Oct 5th, i prepare to hijack Basket's ITP in 2 days' time barring answer from the OP (101 days in preparation) I believe that Basket is an useful application to have in Debian, and will take care of maintaining it as an official package. Best, ~J.L. Original Message Subject: About Basket packaging status Date: Tue, 05 Oct 2004 01:40:02 +0200 From: José Luis Tallón [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, Luke! ~ How is the BasKet packaging status?? I thought it would be wonderful to have it in Debian... have you already contacted upstream and began packaging? how is everything going?? ~ If you need some help or feel than you'd like to relinquish packaging to someone else, please contact me. Best, ~ J.L. you are completely wrong in your interpretation of the #259180 I changed it into an ITP, saying I was willing to package it. I've posted an RFS for basket [1] but nobody answered. and since you didn't Cc:-ed me on your mails to [EMAIL PROTECTED] it's a miracle I saw your mail on d-devel ... So please read [1] and if you can be my sponsor (I'm not one yet, still waiting for DAM), I'm interested :) So please, next time, read the whole bug more carefully. Again it's a real miracle I saw your mail http://lists.debian.org/debian-mentors/2004/09/msg2.html -- Pierre Habouzit http://www.madism.org/ -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- gpg : 1024D/A1EE761C 6045 409E 5CB5 2CEA 3E70 F17E C41E 995C C98C 90BE spam: [EMAIL PROTECTED] pgpYvSDUSQmu8.pgp Description: PGP signature
Re: Drop testing
El sb, 23-10-2004 a las 12:56 +0200, Eduard Bloch escribi: [...] - unstable lockdown in the freeze - drop Testing and concentrate on work instead of wasting time on synching stuff. This eliminates the need for testing-security. See the last part of the paper for details. - about the filtering updates for frozen - yes, some additional manpower is required but that work must be done. The problems with Testing synchronisation are not of pure technical nature, they are social problem, and so they should be solved by people and not scripts. Perhaps there is another approach, combining both the benefits of having testing and of freezing. But this means having a time based release timeline. And this is something that it is not being discussed here, but also Ubuntu can be released because they have a timeline, what makes people rush a bit for what they want. Of course Ubuntu has paid people for doing tasks, but Debian can permit dropping some packages in one release if they're not ready, as we don't sell a product. From a mail in debian-custom[1] with a little fix: quote on 8.6 New way to distribute Debian Here is my own proposal for these, I think every Debian developer/user has his very own one: * During normal debian developer cycle (from T0 to T0 + 1 year): DD - unstable - testing QA - security - stable at T0 + 1 year: freeze := testing * During freeze ( from T0 + 1 year to T0 + 1.5 year ): DD - unstable - testing DD + QA - freeze - stable at T0 + 1.5 years = T1: stable := freeze old-stable := stable (security for 6 months, already done by QA) quote off Of couse, timeline can be adjusted, and I think that a 2 month freeze should be enouogh, but what I want to show is how both testing and freeze could be used together. Regards, [1] http://lists.debian.org/debian-custom/2004/09/msg00033.html -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: Ubuntu discussion at planet.debian.org
* Matthias Urlichs ([EMAIL PROTECTED]) [041023 23:00]: Hi, Manoj Srivastava wrote: Secondly, buildd's do not work with experimental. That can be fixed quite easily. In fact, my own (personal) buildds do it. Actually, I'm also building experimental packages, for mips, hppa, sparc and alpha. 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
Re: Security updates for sarge?
On Sat, Oct 23, 2004 at 10:52:27PM +0200, Matthias Urlichs wrote: You want to help? Start by buying your own mips machine! isn't going to cut it. Besides, I already (and gladly) did that, for m68k. You don't need to do that. There're plenty of machines available - albeit outside the debian.org domain... Just raise your hands, whoever is willing to take over a buildd. I'd try my best to supply you with a machine or coordinate contacts of people having the machines. -- Ciao... // Ingo \X/
Re: Reproducible, precompiled .o files: what say policy+gpl?
On Sat, Oct 23, 2004 at 12:27:25PM -0600, Gunnar Wolf wrote: Wesley W. Terpstra dijo [Mon, Oct 18, 2004 at 09:59:36PM +0200]: At this point my question is only academic; the pure-gcc in main, icc-prebuilt in contrib solution seems to solve my concerns just as well. I have only one concern with this: What happens if you drop the package and someone else takes it? He will no longer be able to compile it with icc, and the icc-prebuilt users will be left out in the cold. What would you say to that? He can upload a version to contrib which depends on the version in main and has no contents. Then the icc users are automatically converted to gcc. Or else, if he is an open-source developer who makes no money from his debian work, he can download icc from their site for free. Just universities and paid researchers like me have to pay. Sniff. -- Wesley W. Terpstra
Re: Security updates for sarge?
Hi, Ingo Juergensmann wrote:
You don't need to do that. There're plenty of machines available - albeit
outside the debian.org domain...
Ingo, this is about the *security* autobuilders. There's a reason why
Debian cannot do that with machines it doesn't control.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: Security updates for sarge?
On Sun, Oct 24, 2004 at 12:01:46AM +0200, Matthias Urlichs wrote: You don't need to do that. There're plenty of machines available - albeit outside the debian.org domain... Ingo, this is about the *security* autobuilders. There's a reason why Debian cannot do that with machines it doesn't control. Funny. Arrakis were used heavily in the past for security builds as well. Otherweise I have no idea where all those security team logins on arrakis come from? But well, yes, I guess, I should lean back and wait until Debian is a total mess and I can say Well, I told you before... -- Ciao... // Ingo \X/
Re: Ubuntu discussion at planet.debian.org
Francesco Paolo Lovergine [EMAIL PROTECTED] writes: On Sat, Oct 23, 2004 at 11:54:05AM +0200, Jérôme Marant wrote: Manoj Srivastava [EMAIL PROTECTED] writes: Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Could you elaborate on that? Why is it so painful? Probably because you need maintain packages for both unstable and testing at the same time. Uh? We have pbulder and sbuild for that. What's so painful? Testing the package. Running the distribution for real. -- Jérôme Marant http://marant.org
Re: Drop testing
Gergely Nagy [EMAIL PROTECTED] writes: It may sound a bit radical, but core points have been mentioned in the thread already. I suggest to do it in a more radical way: - unstable lockdown in the freeze - drop Testing and concentrate on work instead of wasting time on synching stuff. This eliminates the need for testing-security. See the last part of the paper for details. Doing this would result in many users who currently run testing fall back to stable + backports or switch to another distro (ubuntu being a likely candidate), which in turn, would result in less bugreports and a less stable distribution. Very few bug reports from testing users are of any value at all. They usually either report some transient dependency problem that the maintainer can't fix anyway, or report something that has already been fixed in the unstable package. -- Blast you and your estrogenical treachery!
Re: Security updates for sarge?
Hi, Ingo Juergensmann wrote:
Funny. Arrakis were used heavily in the past for security builds as
well. Otherweise I have no idea where all those security team logins on
arrakis come from?
I'd assume that there's a *slight* difference between somebody, who
doesn't (necessarily) have any privileges, logs on and specifically builds
something, and an unattended autobuilder.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: Drop testing
Hi, Brian Nelson wrote:
Very few bug reports from testing users are of any value at all. They
usually either report some transient dependency problem that the
maintainer can't fix anyway, or report something that has already been
fixed in the unstable package.
You can't fix *this* dependency problem easily, but you can fix the *next*
one, by telling the maintainers in question that they should be somewhat
more careful. Plus, if there was no Testing, the transient problem
may well become a semi-permanent one.
As for reporting bugs fixed in Unstable: presumably, after Sarge there
will be a version-aware BTS for Debian, so that the person using Testing
will still see the bug report and thus can upgrade that package from
Unstable; apt-preferences are your friend. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Re: Security updates for sarge?
On Sun, Oct 24, 2004 at 12:21:28AM +0200, Matthias Urlichs wrote: Funny. Arrakis were used heavily in the past for security builds as well. Otherweise I have no idea where all those security team logins on arrakis come from? I'd assume that there's a *slight* difference between somebody, who doesn't (necessarily) have any privileges, logs on and specifically builds something, and an unattended autobuilder. Well, the main difference I see is, that there are still no security updates for sarge/testing. For the user it's irrelevant if the security updates was built by a person or an autobuilder. But I think you're right... it's not about getting work done, it's about politics and a orwellian all users are equal, DDs are more equal nonsense. With every day passing by, it seems even more clearly to me that Debian has lost its basics and has turned into a project that prefer to deal with itself for that reason. And now it's even controlled by a venture capitalist. Great job, well done... :-( -- Ciao... // Ingo \X/
Re: Security updates for sarge?
Manoj Srivastava [u] wrote on 23/10/2004 21:43: I must admit I thought something similar: Why the hell are there only two people who know how to do it, when two people doesn't seem to be enough? Are you volunteering to go out and better educate yourself to take on this work? You know perfectly well that there _are_ people out there who know how to do it. Also: I offered my help if it is wanted (see below), but I see no point in learning what's needed to work as a buildd or ftp admin for debian while I know perfectly well that helping hands in these areas is regularly declined by those in charge. It might be better if they postponed further work on the buildd network and used that time to introduce others to the job. In the end, this might very well speed up the whole process. At least, it gets some more redundancy (what happens if one of them gets ill while the other is on a prolonged journey?). Two people who can do the job certainly isn't nearly enough for such important jobs in a project as big as Debian. I would think it should be at least 5-6 people. Again, are you volunteering to go out and learn how to do it? If my help is indeed wanted: Yes. Under the current circumstances (with no definite acknowledgement that my help will be accepted): no. Also you are in no way responsive to my main point: Why are there only two people doing the job when quite a few more people have already offered to help (and are indeed qualified to do the job)? Or is this yet another time wasting rant? You mean like your post? Heck, If I were a DD, I would be glad to help whereever needed. The Ah. Just a spectator, booing and hissing at the people who have stood up to be counted. And who decline help every time the subject of their work load comes up? Also: No, not just a spectator. I have been advocating and deploying Debian for quite a while. Also I helped new users of Debian quite a lot. And my first Debian package has been uploaded almost two weeks ago and is still waiting in the NEW queue. So, if my help is wanted with one of the first three of those, I will gladly file a NM application immediately. Please do. Fine. Where do you want me to help? When I know where my help is wanted and accepted, I will gladly file the application. Until then I currently see no point in doing so (putting more load on the DAM without having actual work for me to do). We need more workers, and less lawyers. Exactly my point. Problem is that the current workers are doing everything to keep others from being able to do their work. cu, sven
Re: Drop testing
On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote: Gergely Nagy [EMAIL PROTECTED] writes: It may sound a bit radical, but core points have been mentioned in the thread already. I suggest to do it in a more radical way: - unstable lockdown in the freeze - drop Testing and concentrate on work instead of wasting time on synching stuff. This eliminates the need for testing-security. See the last part of the paper for details. Doing this would result in many users who currently run testing fall back to stable + backports or switch to another distro (ubuntu being a likely candidate), which in turn, would result in less bugreports and a less stable distribution. Very few bug reports from testing users are of any value at all. They usually either report some transient dependency problem that the maintainer can't fix anyway, or report something that has already been fixed in the unstable package. This seems like a rather unsubstantiated claim. Do you *know* how many of the good bug reports you've seen come from users of testing vs. unstable? Reportbug should give this kind of information, but just looking at the version of the package they've filed the bug against isn't even an indicator; it may just mean the user tried upgrading to the unstable version of the package before reporting the bug, because she was trying to ensure the bug report would be useful/was hoping the bug was fixed without any need to file a bug report. Yes, filing bug reports on testing is not often useful (except during a freeze), but that's not the same as it not being useful to have users running testing. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Release-critical Bugreport for May 14, 2004
[BugScan reporter] Bug stamp-out list for May 14 06:01 (CST) Total number of release-critical bugs: 565 Number that will disappear after removing packages marked [REMOVE]: 1 Number that have a patch: 79 Number that have a fix prepared and waiting to upload: 22 Number that are being ignored: 14 Number on packages not in testing: 200 Number concerning the next release (excluding ignored and not-in-testing): 274 Did these reports stop, or is there something wrong with my email? The last one I could find in my debian-devel-announce mail folder is from 2004-05-14. Anyone know what happened?
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 02:40:24PM -0500, Manoj Srivastava wrote: On Sat, 23 Oct 2004 11:54:05 +0200, J?r?me Marant [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Could you elaborate on that? Why is it so painful? Probably because you need maintain packages for both unstable and testing at the same time. That is a simple branching issue in the version control system, no? A huge rush of air fills the list as hundreds of developers fill their lungs to collectively say I don't use version control... - Matt signature.asc Description: Digital signature
Re: Drop testing
On Sat, Oct 23, 2004 at 03:52:51PM -0700, Steve Langasek wrote: On Sat, Oct 23, 2004 at 02:33:24PM -0700, Brian Nelson wrote: Gergely Nagy [EMAIL PROTECTED] writes: It may sound a bit radical, but core points have been mentioned in the thread already. I suggest to do it in a more radical way: - unstable lockdown in the freeze - drop Testing and concentrate on work instead of wasting time on synching stuff. This eliminates the need for testing-security. See the last part of the paper for details. Doing this would result in many users who currently run testing fall back to stable + backports or switch to another distro (ubuntu being a likely candidate), which in turn, would result in less bugreports and a less stable distribution. Very few bug reports from testing users are of any value at all. They usually either report some transient dependency problem that the maintainer can't fix anyway, or report something that has already been fixed in the unstable package. This seems like a rather unsubstantiated claim. Do you *know* how many of the good bug reports you've seen come from users of testing vs. unstable? I don't have any hard data, but I've been tracking debian-bugs-dist for about 2 years now so I think I have a decent feel for it. True, you can't always be sure if the user is using testing or unstable, but it often can be inferred. [...] Yes, filing bug reports on testing is not often useful (except during a freeze), but that's not the same as it not being useful to have users running testing. I didn't claim otherwise. I was just trying to refute the claim that bug reports from testing users were useful. I do question if having testing available to the public throughout the entire release cycle is actually beneficial to the community. There's a common misconception in the community that testing is a more stable unstable. Many testing users aren't even aware that testing doesn't have security updates. Probably most of the users of testing should *not* be using it at all. This isn't really related to the proposal in this thread to just drop testing though. -- Blast you and your estrogenical treachery!
Re: Drop testing
Eduard Bloch wrote: Debian Testing is not stable and is not mature. It is full of shitty bugs (let me define this term as name for ugly bugs that bother the users but do not look appear as critical for maintainer, or not important enough to touch package in the holy frozzen state). Such bugs are a disaster, they make our definition of a Stable release absurd. Yes, Debian Stable has become a buggy stable release. Just face it. AIUI, you propose to freeze unstable and go back to the old method of having updates during the freeze be manually put in at the discretion of the Release Managers. If we did that, how would one of these ugly bugs be any more likely to be fixed in frozen unstable than it is in today's partially frozen testing? If it were a bug on one of the packages currently frozen in testing, the situation is exactly what it is now; the maintainer and RM have to decide whether putting this fix into testing (or frozen) and possibly introducing new, more important bugs is warrented by the ugliness of the bug. If the package is one of the large majority of packages that are _not_ currently frozen in testing, then it seems it would be harder to get it into frozen using your proposed method than it is to get it into testing now. -- see shy jo signature.asc Description: Digital signature
Re: Security updates for sarge?
And without starting a flamewar, ... Yep, I thought it looked too good to be true. b.
Re: Ubuntu discussion at planet.debian.org
On Sat, Oct 23, 2004 at 12:14:45PM -0500, Manoj Srivastava wrote: On Sat, 23 Oct 2004 14:23:48 +0900, Mike Hommey [EMAIL PROTECTED] said: And why not, instead of freezing unstable, make it build against testing, when er try to freeze testing ? Libraries. If you build against a library version that is no longer in unstable, then you may have issues in testing when a new library tries to migrate into testing -- cause nowhere would there be packages built against the new library version. I don't see the point. If you build against what is in testing, there's no issue when migrating to testing. One particular issue would be when libraries change ABI, and new packages would need to be built against them, but still, at that particular time, the purpose being mainly to freeze testing, these ABI changes should be candidates for experimental. Not to mention that unstable would become unviable as a distribution -- the run time libs may not be the ones that are needed by the packages in unstable. At that particular time, isn't frozen-testing the one that is supposed to be a distribution ? Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Could you elaborate on that? Why is it so painful? On top of the problems mentionned by the other replies, the fact that autobuilders have to be set up for t-p-u... can you remind me how long sarge has been planned for freeze ? and for how long autobuilders are required for alpha and mips for t-p-u ? Mike
Re: Security updates for sarge?
Ingo Juergensmann [EMAIL PROTECTED] wrote: But I think you're right... it's not about getting work done, it's about politics and a orwellian all users are equal, DDs are more equal nonsense. With every day passing by, it seems even more clearly to me that Debian has lost its basics and has turned into a project that prefer to deal with itself for that reason. And now it's even controlled by a venture capitalist. Great job, well done... :-( Ingo, You appear to be discussing some Debian that doesn't exist. In itself, this isn't surprising - you appear to have spent a significant period of time discussing a Debian that is only mildly related to the Debian that most people appear to perceive. Your postings to debian-devel have generally resulted in large quantities of noise and a complete absence of useful conclusions. You're either a revolutionary arguing on the side of the largely silent majority, or you're in a minority. In the first case, I'd suggest that you engage in making it clearer that a large set of people agree with you. In the latter case, I'd like to request that you stop. Your posts are counter-productive - your style of argumentation repels those who may have sympathy, and inflames those who already disagree with you. Your current activities are accomplishing nothing. There is no advantage to be gained in I told you so - instead, you merely delay us from going anywhere. Please. No more. -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Mike Hommey [EMAIL PROTECTED] wrote: The point is, some drivers DO require firmwares. I'd rather say: Some depend on firmware. In that case, if the firmware is non-free, the driver can't go in main. Is this the case even if the firmware is in a flash chip attached to the device? If the total amount of non-free software on a user's system is the same regardless, why are we concerned about how it's packaged? -- Matthew Garrett | [EMAIL PROTECTED]
Re: non-free firmware: driver in main or contrib?
Matthew Garrett [EMAIL PROTECTED] wrote: Mike Hommey [EMAIL PROTECTED] wrote: The point is, some drivers DO require firmwares. I'd rather say: Some depend on firmware. In that case, if the firmware is non-free, the driver can't go in main. Is this the case even if the firmware is in a flash chip attached to the device? If the total amount of non-free software on a user's system is the same regardless, why are we concerned about how it's packaged? Argh. Sorry, I shouldn't be allowed to post while drunk. That was meant to go to -legal, not -devel. -- Matthew Garrett | [EMAIL PROTECTED]
Re: Ubuntu discussion at planet.debian.org
On Sun, 24 Oct 2004, Matthew Palmer wrote: On Sat, Oct 23, 2004 at 02:40:24PM -0500, Manoj Srivastava wrote: On Sat, 23 Oct 2004 11:54:05 +0200, J?r?me Marant [EMAIL PROTECTED] said: Manoj Srivastava [EMAIL PROTECTED] writes: Okay, that's what t-p-u is roughly for, but the fact is that it's quite painful. Could you elaborate on that? Why is it so painful? Probably because you need maintain packages for both unstable and testing at the same time. That is a simple branching issue in the version control system, no? A huge rush of air fills the list as hundreds of developers fill their lungs to collectively say I don't use version control... Is there really a developer out there that doesn't do even the most rudimentary VC by keeping copies of all the source packages he has uploaded/worked on ? -- 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
Accepted streamtuner 0.99-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Oct 2004 01:06:33 -0400 Source: streamtuner Binary: streamtuner Architecture: source i386 Version: 0.99-2 Distribution: unstable Urgency: low Maintainer: Ari Pollak [EMAIL PROTECTED] Changed-By: Ari Pollak [EMAIL PROTECTED] Description: streamtuner - A GUI audio stream directory browser Changes: streamtuner (0.99-2) unstable; urgency=low . * whoops, build-depend on python-dev, not python Files: 15752214df4b737635290edcbb949038 634 net extra streamtuner_0.99-2.dsc b471cba23080568d283dc574d3419be7 9886 net extra streamtuner_0.99-2.diff.gz 0de7cc08c076c2af64301547f1861e08 1281688 net extra streamtuner_0.99-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBefBxwO+u47cOQDsRAj6vAJ9uQ6M1mIWcV91HPLCSPUipRyTEmgCeL0Vv SqkJVHJ+cUJUyg8PqbtAJ+k= =YTvT -END PGP SIGNATURE- Accepted: streamtuner_0.99-2.diff.gz to pool/main/s/streamtuner/streamtuner_0.99-2.diff.gz streamtuner_0.99-2.dsc to pool/main/s/streamtuner/streamtuner_0.99-2.dsc streamtuner_0.99-2_i386.deb to pool/main/s/streamtuner/streamtuner_0.99-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted advi 1.6.0-1 (powerpc source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 21 Oct 2004 10:55:13 +0200 Source: advi Binary: advi Architecture: source powerpc Version: 1.6.0-1 Distribution: unstable Urgency: low Maintainer: Debian OCaml Maintainers [EMAIL PROTECTED] Changed-By: Sven Luther [EMAIL PROTECTED] Description: advi - a DVI previewer and presenter written in Objective Caml Closes: 257855 264797 274383 28 Changes: advi (1.6.0-1) unstable; urgency=low . * New upstream release. - Now includes man page. (Closes: #264797, #28) - Exiting scratch mode is possible with q (S mode) or ESC and then qs (s mode). (Closes: #274383) - Segfault with #257855 provided .dvi file fixed. (Closes: #257855) Files: 31546b89b99eca1af37a35b9fc64691c 1034 tex optional advi_1.6.0-1.dsc da0e71cbc99a8def27873d4f3c756fa6 11436152 tex optional advi_1.6.0.orig.tar.gz 2109f541bcf8949b02cadb0e10de5354 11341 tex optional advi_1.6.0-1.diff.gz 9d787641a9d3d93bd6bcde5c90687bba 4441564 tex optional advi_1.6.0-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBehXM2WTeT3CRQaQRAnSyAJ9BzT5Cu34/ZiqI/nJm69jPAMCGQACeJ3+U o1glZnsQH7Of+he7Ha6HLsU= =DCQa -END PGP SIGNATURE- Accepted: advi_1.6.0-1.diff.gz to pool/main/a/advi/advi_1.6.0-1.diff.gz advi_1.6.0-1.dsc to pool/main/a/advi/advi_1.6.0-1.dsc advi_1.6.0-1_powerpc.deb to pool/main/a/advi/advi_1.6.0-1_powerpc.deb advi_1.6.0.orig.tar.gz to pool/main/a/advi/advi_1.6.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libdebtags 0.9.8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Oct 2004 11:15:02 +0200 Source: libdebtags Binary: libdebtags-dev libdebtags0 Architecture: source i386 Version: 0.9.8 Distribution: unstable Urgency: low Maintainer: Enrico Zini [EMAIL PROTECTED] Changed-By: Enrico Zini [EMAIL PROTECTED] Description: libdebtags-dev - Unified access to Debtags and APT databases (development version) libdebtags0 - Unified access to Debtags and APT databases Changes: libdebtags (0.9.8) unstable; urgency=low . * Updated shlibs file Files: 7155aa74b43324f40fe292b1f9c2197a 610 - optional libdebtags_0.9.8.dsc 9090d72797af59e6872225a891ff8027 337067 - optional libdebtags_0.9.8.tar.gz 9050f2bc3ad826fb9bcdaa697fa89921 212400 libdevel optional libdebtags-dev_0.9.8_i386.deb b04306ed16b07bfbe14d8f4ca2c7134c 117692 libs optional libdebtags0_0.9.8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBeiKL9LSwzHl+v6sRAhNBAJ9Di4B28VsFeL5AJ0H0V9aatAYIEgCfXboM 7EL1S+vcslFj74sJu1XKuro= =dYVX -END PGP SIGNATURE- Accepted: libdebtags-dev_0.9.8_i386.deb to pool/main/libd/libdebtags/libdebtags-dev_0.9.8_i386.deb libdebtags0_0.9.8_i386.deb to pool/main/libd/libdebtags/libdebtags0_0.9.8_i386.deb libdebtags_0.9.8.dsc to pool/main/libd/libdebtags/libdebtags_0.9.8.dsc libdebtags_0.9.8.tar.gz to pool/main/libd/libdebtags/libdebtags_0.9.8.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted debtags 0.99.4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Oct 2004 11:25:13 +0200 Source: debtags Binary: debtags Architecture: source i386 Version: 0.99.4 Distribution: unstable Urgency: low Maintainer: Enrico Zini [EMAIL PROTECTED] Changed-By: Enrico Zini [EMAIL PROTECTED] Description: debtags- Enables support for package tags Closes: 277859 Changes: debtags (0.99.4) unstable; urgency=low . * Updated build-depends on libdebtags-dev. Closes: #277859. Files: 4be9ef1fd95c29f97f4d24cdfdc3b2c8 555 admin optional debtags_0.99.4.dsc 170f868978f2b6b024a41337e91c297b 241702 admin optional debtags_0.99.4.tar.gz 949072c8a573fe6345539b31d5fc33fb 203070 admin optional debtags_0.99.4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBeiU39LSwzHl+v6sRAqwIAJsHn5MAFkqHhp3esj1bae5uw0435gCfZfCQ cLVR8TDy69LExjRsAPlNm8o= =2Qng -END PGP SIGNATURE- Accepted: debtags_0.99.4.dsc to pool/main/d/debtags/debtags_0.99.4.dsc debtags_0.99.4.tar.gz to pool/main/d/debtags/debtags_0.99.4.tar.gz debtags_0.99.4_i386.deb to pool/main/d/debtags/debtags_0.99.4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libpaper 1.1.14-1 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Oct 2004 11:56:26 +0200 Source: libpaper Binary: libpaper-dev libpaper1 libpaperg-dev libpaperg libpaper-utils Architecture: source all powerpc Version: 1.1.14-1 Distribution: unstable Urgency: medium Maintainer: Giuseppe Sacco [EMAIL PROTECTED] Changed-By: Giuseppe Sacco [EMAIL PROTECTED] Description: libpaper-dev - Library for handling paper characteristics (development files) libpaper-utils - Library for handling paper characteristics (utilities) libpaper1 - Library for handling paper characteristics libpaperg - Library for handling paper characteristics (dummy package) libpaperg-dev - Library for handling paper characteristics (dummy development fil Changes: libpaper (1.1.14-1) unstable; urgency=medium . * New maintaier * New Dutch po-debconf translation * New Czech po-debconf translation * New pt_BR po-debconf translation * Applied patch by Frank Küster for a smoother upgrade from woody * Applied patch by Magnus Fromreide in order to add measure units. Files: 7ddb94dd1e7db102e5caf16d17e0b8d6 588 libs optional libpaper_1.1.14-1.dsc bc7248d8666496852630cad2a832b33e 301207 libs optional libpaper_1.1.14-1.tar.gz 125b2f5050a41c483919b11cc66c8fe8 766 libs optional libpaperg_1.1.14-1_all.deb c5db8f4ace5a8493981399661a037e8d 780 devel optional libpaperg-dev_1.1.14-1_all.deb 03d6f339dbf2a2e7b26a6bcb76d43536 19604 libs optional libpaper1_1.1.14-1_powerpc.deb fe130b95b12b00f03db9dfb062d8f008 17712 utils optional libpaper-utils_1.1.14-1_powerpc.deb 900557de2fbe1473991693ef081f374f 16242 devel optional libpaper-dev_1.1.14-1_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBei7UIgfFlOyXCJ0RArauAJ0TCm5F05FzPXmZkLE2cTEFtBWb1wCfQ2au vrtoQZhgUJ4VQmsJM16tDyQ= =OuN1 -END PGP SIGNATURE- Accepted: libpaper-dev_1.1.14-1_powerpc.deb to pool/main/libp/libpaper/libpaper-dev_1.1.14-1_powerpc.deb libpaper-utils_1.1.14-1_powerpc.deb to pool/main/libp/libpaper/libpaper-utils_1.1.14-1_powerpc.deb libpaper1_1.1.14-1_powerpc.deb to pool/main/libp/libpaper/libpaper1_1.1.14-1_powerpc.deb libpaper_1.1.14-1.dsc to pool/main/libp/libpaper/libpaper_1.1.14-1.dsc libpaper_1.1.14-1.tar.gz to pool/main/libp/libpaper/libpaper_1.1.14-1.tar.gz libpaperg-dev_1.1.14-1_all.deb to pool/main/libp/libpaper/libpaperg-dev_1.1.14-1_all.deb libpaperg_1.1.14-1_all.deb to pool/main/libp/libpaper/libpaperg_1.1.14-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libpaper 1.1.14-2 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Oct 2004 12:45:25 +0200 Source: libpaper Binary: libpaper-dev libpaper1 libpaperg-dev libpaperg libpaper-utils Architecture: source all powerpc Version: 1.1.14-2 Distribution: unstable Urgency: low Maintainer: Giuseppe Sacco [EMAIL PROTECTED] Changed-By: Giuseppe Sacco [EMAIL PROTECTED] Description: libpaper-dev - Library for handling paper characteristics (development files) libpaper-utils - Library for handling paper characteristics (utilities) libpaper1 - Library for handling paper characteristics libpaperg - Library for handling paper characteristics (dummy package) libpaperg-dev - Library for handling paper characteristics (dummy development fil Changes: libpaper (1.1.14-2) unstable; urgency=low . * Moved libpaper-dev and libpaperg-dev from section devel to libdevel. Files: 9ad9d35e5c03663e8e36eb283c1a19cd 588 libs optional libpaper_1.1.14-2.dsc 5208f7d1a352c6fad646c2f0a8da4af5 301139 libs optional libpaper_1.1.14-2.tar.gz 47b610f4e27b82b7f71a9a3eda5731a5 768 libs optional libpaperg_1.1.14-2_all.deb 255518eb54995a35caacbec374da1130 780 libdevel optional libpaperg-dev_1.1.14-2_all.deb 2ea9469a36552bf66c08f85698d42605 19638 libs optional libpaper1_1.1.14-2_powerpc.deb abdafa28891d005a2e824eb92dc7e36c 17740 utils optional libpaper-utils_1.1.14-2_powerpc.deb ca935c30689ed678f96898400e332808 16270 libdevel optional libpaper-dev_1.1.14-2_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBejbyIgfFlOyXCJ0RAg9aAKCg+3pZu4V/9R2XRCSACqekjPOIeACbBXCL eR9NMR3SsECCJaFs6id1wEY= =gfUI -END PGP SIGNATURE- Accepted: libpaper-dev_1.1.14-2_powerpc.deb to pool/main/libp/libpaper/libpaper-dev_1.1.14-2_powerpc.deb libpaper-utils_1.1.14-2_powerpc.deb to pool/main/libp/libpaper/libpaper-utils_1.1.14-2_powerpc.deb libpaper1_1.1.14-2_powerpc.deb to pool/main/libp/libpaper/libpaper1_1.1.14-2_powerpc.deb libpaper_1.1.14-2.dsc to pool/main/libp/libpaper/libpaper_1.1.14-2.dsc libpaper_1.1.14-2.tar.gz to pool/main/libp/libpaper/libpaper_1.1.14-2.tar.gz libpaperg-dev_1.1.14-2_all.deb to pool/main/libp/libpaper/libpaperg-dev_1.1.14-2_all.deb libpaperg_1.1.14-2_all.deb to pool/main/libp/libpaper/libpaperg_1.1.14-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted svgalib 1:1.4.3-18 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Oct 2004 13:37:53 +0200 Source: svgalib Binary: svgalibg1-dev libsvga1-dev libsvga1 svgalibg1 svgalib-bin Architecture: source all i386 Version: 1:1.4.3-18 Distribution: unstable Urgency: low Maintainer: Guillem Jover [EMAIL PROTECTED] Changed-By: Guillem Jover [EMAIL PROTECTED] Description: libsvga1 - console SVGA display libraries libsvga1-dev - console SVGA display development libraries and headers svgalib-bin - console SVGA display utilities svgalibg1 - transitional dummy package which can be safely removed svgalibg1-dev - transitional dummy package which can be safely removed Closes: 239666 Changes: svgalib (1:1.4.3-18) unstable; urgency=low . * debian/patches/: - 024_vesa_not_print_crap.patch: Do not print leftover debugging stuff. (Closes: #239666) Thanks to Christian Häggström [EMAIL PROTECTED]. - 025_mmap_return_value_test.patch: Fix the test on the mmap return value revealed with the new flexmmap on Linux kernels = 2.6.9. * debian/README.svgalib-dummy: Use new libsvga1 package names. * Update debian/patch.mk and debian/rules accordingly. * Clean debian/rules. * Generate the arch independent packages in binary-indep. Files: 0f033252546798528acd35907627a91f 676 graphics optional svgalib_1.4.3-18.dsc 9dad125dc3f4792d8876af37d7d1458b 43287 graphics optional svgalib_1.4.3-18.diff.gz 0187baae9f840351faca12e959c15d4d 752 oldlibs optional svgalibg1_1.4.3-18_all.deb fe180fb13b565a378057f7833f7398ee 762 oldlibs optional svgalibg1-dev_1.4.3-18_all.deb 7b494197271ad92490f54f9df62302db 23228 graphics optional svgalib-bin_1.4.3-18_i386.deb 28f7744bcd9cce63c875f81cf33bd401 313132 libs optional libsvga1_1.4.3-18_i386.deb 9b65268f020b72958d315f0fe6175e9a 560278 libdevel optional libsvga1-dev_1.4.3-18_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBekMsuW9ciZ2SjJsRAh33AJ96by6yXgkqQbvldKTJGq2GoFwOhACgvDte XTWT4VWEhWM7ZUKRqelkLVk= =t5cg -END PGP SIGNATURE- Accepted: libsvga1-dev_1.4.3-18_i386.deb to pool/main/s/svgalib/libsvga1-dev_1.4.3-18_i386.deb libsvga1_1.4.3-18_i386.deb to pool/main/s/svgalib/libsvga1_1.4.3-18_i386.deb svgalib-bin_1.4.3-18_i386.deb to pool/main/s/svgalib/svgalib-bin_1.4.3-18_i386.deb svgalib_1.4.3-18.diff.gz to pool/main/s/svgalib/svgalib_1.4.3-18.diff.gz svgalib_1.4.3-18.dsc to pool/main/s/svgalib/svgalib_1.4.3-18.dsc svgalibg1-dev_1.4.3-18_all.deb to pool/main/s/svgalib/svgalibg1-dev_1.4.3-18_all.deb svgalibg1_1.4.3-18_all.deb to pool/main/s/svgalib/svgalibg1_1.4.3-18_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
