Re: two dpkg-instances / invoking module-assistant on kernel-upgrade
So, what is the best practice to recompile kernel-modules on kernel-upgrades? The current best practice is definitely to rely on users' memory :S See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=299727 for some discussion about this. A few hacky ideas were proposed. I don't expect to see a non-hacky solution anytime soon. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: pre-building NEW packages, when they only introduce new binary packages
Le February 12, 2008 03:19:47 am Joerg Jaspert, vous avez écrit : On 11293 March 1977, Philippe Cloutier wrote: Lets jump in here, even if not all points address your mail only. If by disfavour you imply that it's intentional that NEW packages aren't built before being accepted, I think you're wrong. I think it would require not completely trivial changes. It *is* intentional that NEW queue packages wont get build automagically. [...] Now, one might limit the packages to such ones that already got accepted in the past and just change binary package names. But thats IMO much more work than it will ever gain us, as you [...] - Have to sort them into the queue somehow. If you go and sort them below everything in unstable then you wont have *any* advantage from autobuilding NEW, as only faster architectures will ever built them, as the slower ones wont get down that far in the queue. You do get the advantage that builds for faster archs are ready right away. Also, slow archs don't necessarily always have a queue. They just need to have more buildds than fast archs. At the moment, only hppa and mips* have significant queues, so...at least arm would build sooner. [...] The whole thing is just way less benefit compared to the work one needs to do for it. Thanks. Of course, it *is* intentional not to throw NEW packages to the buildd network in its current form, since it's not designed to support that. I was talking about whether it was intentional to autobuild *none* of NEW. Your mail clarifies that this is not intentional, we just don't have the infrastructure for it, but we agree that even if it's possible to autobuild at least parts, this would be low priority work. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: pre-building NEW packages, when they only introduce new binary packages
On Sat, 09 Feb 2008 20:10:20 -0500 Philippe Cloutier wrote: That probably won't make much time difference on fast archs (i386, amd64 etc), but on slower ones like mips, mipsel etc (those sometimes hold up testing transition :(). A missing build will only slow testing migration if the package wasn't built when the unstable testing delay is over. Since almost all uploads to NEW are low urgency, the build would need to take over 10 days to affect the time to testing migration. pokerth 0.6-1-2 needed 13 days (uploaded on 28.01, built [but not yet uploaded] today), so it *can* make a difference (not a really big one though in this case) Ah, yes. I misinterpreted your message. I thought you meant that the package would spend more than the testing transition delay actually compiling, which is not reasonable. I see others reasons to mention slow arches: 1. Builds tend to take more time to be signed 2. Builds tend to fail more often 3. Slow arches are more often unable to keep up Your suggestion could help with 1 and 2, but not really with 3. If the NEW package gets earlier in the queue, it's built more quickly, but packages that come later are built more slowly. And 3 must be the main reason for the delay in this case, presumably more than 90% of the delay. To speed up testing migration due to missing builds, it would be much more efficient to work on buildd redundancy (or other improvements to the buildd network). More/faster buildds, nicer dependencies etc, sure. But why not this one too? ;) I didn't mean this one shouldn't be done. I just meant that if it should, it's a low priority one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: pre-building NEW packages, when they only introduce new binary packages
Dear Philippe, if the ressources are scarce, I think that it would be fair that the internal competition for the access to them would be organised in a productive way. The current system disfavours the works that changes the structure of the package. How does this fit in a strategy to optimise the usage of the buildd power in Debian? It avoids building packages that will be rejected. If by disfavour you imply that it's intentional that NEW packages aren't built before being accepted, I think you're wrong. I think it would require not completely trivial changes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pre-building NEW packages, when they only introduce new binary packages
That probably won't make much time difference on fast archs (i386, amd64 etc), but on slower ones like mips, mipsel etc (those sometimes hold up testing transition :(). A missing build will only slow testing migration if the package wasn't built when the unstable testing delay is over. Since almost all uploads to NEW are low urgency, the build would need to take over 10 days to affect the time to testing migration. To speed up testing migration due to missing builds, it would be much more efficient to work on buildd redundancy (or other improvements to the buildd network). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Changing priority of selinux back to optional
I agree. Regarding the installed size, on my not-so-barebone KDE lenny PC (1067 packages installed), installing standard selinux packages would require 40 MB more. Systems with old HDD-s and miniature systems could be bothered. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Shouldn't apt-listchanges be Priority: standard?
Could we consider increasign the priority of apt-listchanges so that it is installed by default? I'm against making it standard, because currently tasksel doesn't ask if a recommendation should be installed, so when we make tasksel install recommendations by default, apt-listchanges would bring in GTK+ and company (due to its recommendation of python-glade2). This is useless for X-less installs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
#BUG_INTERACTIVE (Re: Bug#422085: Better terminal emulator patch_
3. I'm definitely opposed to a feature which will pop up a *terminal* where a user has to do something before he can proceed reporting a bug. Sorry, but this won't happen in rng. I might consider such a thing if it could be scripted to use QT or even GTK but a terminal popping up in a GUI application is a no-go for me, sorry. For any script that is non-interactive the terminal will appear and then disappear once the script is done running. On my system it's barely noticeable. One thing that I'd be open to is modifying the standard so that scripts put something like #BUG_INTERACTIVE in the interactive scripts. We could trivially grep for this phrase, launch a terminal in this one case, or just run the script and get the output directly if this comment is absent. I don't know of any interactive bug scripts that currently exist, so this should be a fairly simple thing to require if people are willing (I've CC'ed -devel for opinions on this). I quickly checked scripts on one of my machines and about 1 out of 3 was interactive. In my opinion it's wrong for reporting tools to risk hanging if an interactive script doesn't [yet] have that line. It would be safer to use #NON_INTERACTIVE. But anyway, it would only solve part of a [very] small problem. And a proper resolution via something debconf-like would obsolete this solution. It's not worth it IMO to implement #*INTERACTIVE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Testing migration (Re: Re: Bits from the MIA team)
At least use important. I actually don't care, if there is a bug or not for the issue. But I do care about the testing migration. We do have DDs, who are doing work only during the weekend (which is perfectly acceptable). So if you write an RC bug on monday, this might hold up the testing migration for a couple of days. Imagine there is a security fix waiting for migration. Do you want to keep this from migrating? Please don't make the work of the testing-security team harder ;) Cheers Steffen The same problem exists for any RC bug. If one reports an RC bug in a package in testing against the (different) version in unstable, britney will play safe. If QA people miss this, all you'll need to do is mark the bug as found in testing's version. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Bug#454162: libxine1-plugins: should not depend on libxine1-gnome
This bug is now about that all plugins are installed by default, dragging in too many dependencies at install/upgrade time. I have the following compromise in mind, which I first want to be commented on before I do the follwing changes: a) Let's introduce 2 meta packages: libxine1-all-plugins, which depends on all binary packages including libxine1-gnome, and another one libxine1-common-plugins, which depends on all packages except libxine1-gnome. b) Additionally, the libxine1 package gets versioned conflicts against all gnome/gtk2 related frontends in etch. I'm not sure about a) ; how would these meta packages be used? b) looks great. Thanks for caring about this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
firmware-nonfree (Re: Bug#448980: ITP: rt73-firmware -- firmware for Ralink USB wireless cards)
What about adding it to the already existing firmware-nonfree source package? Cheers, Moritz What about it, indeed? Would it have any advantage over introducing a new source package? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Out-of-tree kernel module popularity
WiFi 4 ipw3945 897 Replaced by (free) iwlwifi which will be present in 2.6.24. iwlwifi is contrib, like ipw3945. 25 ieee80211 109 61 ieee80211softmac 14 31 ipw2100 71 18 ipw2200 169 36 hostap 51 Merged. Already removed. 132 rtl8180 1 130 rtl8180-sa24001 Merged. You must be thinking about rtl8187. These look like unofficial packages anyway. 53 pcmcia 17 30 kernel-pcmcia79 2.4 material, not needed on 2.6. Removed long ago. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Out-of-tree kernel module popularity
If anyone has some time, it would be valuable to work through the list and check, which of these have been merged into Linux mainline by now (e.g. several of the wifi drivers have) and report the missing ones to Greg Kroah-H's driver project: http://www.linuxdriverproject.org/twiki/bin/view According to that page We work with the manufacturers of the specific device to specify, develop, submit to the main kernel, and maintain the kernel drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Enabling and installing of risky (patented) codecs - madeeasy
I don't see why users in countries where software is not patentable should be forced to jump through hoops to get access to multimedia software. If this repository is not added to the user's sources.list file by default then there is no advantage in setting up yet another repository for such software. There would be the advantage that the software is distributed by Debian, and it should be easier to add/enable the repository. I think the Debian project needs to seek legal advice on the subject. We need to know who actually becomes liable for patent infringement if we set up a repository in a country where software cannot be patented. I would guess the answer would be anyone who distributes the software; therefore it would be up to each mirror to decide whether to mirror this archive. I suppose that both distributors and users are liable. Otherwise, it would be good to ask on debian-legal. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Wiki page (was Re: [RFC] Promoting the use of Homepage: field in debian/control)
I'd start with amending the Developers' Reference, then having a test added to lintian and linda, and after that announcing it on debian-devel-announce. Then next year, after everyone's had time to react and upload new packages, do a mass bug filing. Basically agreed. I created http://wiki.debian.org/HomepageFieldTransition adding a few things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Wiki page (was Re: [RFC] Promoting the use of Homepage: field in debian/control)
I'd start with amending the Developers' Reference, then having a test added to lintian and linda, and after that announcing it on debian-devel-announce. Then next year, after everyone's had time to react and upload new packages, do a mass bug filing. Basically agreed. I created http://wiki.debian.org/HomepageFieldTransition adding a few things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on the Desktop - plans for Lenny?
* Simplify installation of out-of-tree kernel modules, possibly by adapting Ubuntu's Restricted Manager to work with m-a. Non-free drivers would *only* be displayed if non-free is in the sources.list. No plans AFAIK. Working on this should not be difficult and should be appreciated, either by improving m-a or by writing something new. In particular, solving the problem described in #299727 and/or creating a GUI would help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Release team structure (was Release Team Meeting results (the Juelich Edition))
* Filipus Klutiero ([EMAIL PROTECTED]) [070616 20:46]: Le vendredi 15 juin 2007 19:19, Andreas Barth a écrit?: Release team structure ~~ Steve Langasek, who served as Release Manager for the past two cycles, doesn't want to be on the hot seat anymore. As he is still an active member of the release team, we decided to have him titled with Release Wizard now. Luk will become a Release Manager, so that we have again two Release Managers. Actually, it seems that Luk is already a Release Manager since a few days according to intro/organization in CVS. I would appreciate if the release team would start to announce changes in its membership. What do you think this mail is? If the mail was an announcement of Luk becoming RM, that was not clear...but in this case, best wishes to Luk with his new title (whatever it means, I guess). And thanks to Steve for his great service as RM. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: GCC 4.2 transition
BTW: anybody more versed in the bts system than I am, how can I get #359634 marked as not actually being fixed? Does a simple reopen not work? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: APT 0.7 for sid
I am definitely a GUI person (aptitude is the last non-GUI program with a GUI available that I still use), but I still prefer aptitude to any other. I was under the impression that most others did too, is it not the recommended Debian way?. Yes (but that's a reported bug, #418455) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
aptitude removals (was Re: APT 0.7 for sid)
Apparently there have been bugs in this for years and no-one reported them until they caused trouble for the d-i team several months ago. They should be fixed in stable's aptitude now, and I would appreciate bug reports on any transition problems that remain. FWIW, I thought that you acknowledged that this problem was reported in #299009 (over 25 months ago). I'm mentioning this because I believe this issue is/was the main reason for anti-aptitudism. Anyway, if it's resolved, I'll have to give aptitude a try. I second Michael in thanking you for bringing this feature at the right place. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[EMAIL PROTECTED] (was Re: Why not move Apt to a relational database)
Is this the correct mailing list to send this idea to? [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Reasons for recommends and suggests
The only time you wouldn't want a Recommends: installed is if you know that it wouldn't be useful. Not really. Policy is vague and only specifies that Recommends means that more than a proportion between 1/2 and 1 of systems consider that the recommended package's contribution to the recommending package makes the recommended package worth installing if it isn't already installed. Suppose that proportion would be 1/2. 1/3 of systems initially without package A install it when installing package B. Package A should therefore be suggested by B. 2/3 of systems initially without package C install it when installing package D. Package C should therefore be recommended by D. Both systems that have B but not A and those that have B and A have their reasons. You'll agree that system administrators installing B that do not know why B suggests A can still want A's contribution to B. In the same way, both systems that have D but not C and those that have D and C have their reasons. Administrators installing D that do not know why D suggests C can still want C's contribution to D. In practice, the proportion for Recommends is higher than 1/2, but the same reasoning applies. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Did the number of installations really increase by a half in one month?
Ah, dammit. Thanks anyway :-P -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: primary mirrors, debootstrap and d-i (was Modifying/etc/apt/sources.list in postinst)
Am I right in thinking that normal d-i installations ensure that at least one primary mirror is selected (or at least strongly advise that one primary should exist)? No -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Debian ISOs
Hendrik makes me think that ktorrent would be another good idea. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IPW3945
Daniel Baumann a écrit : Philippe Cloutier wrote: See #363967. I heard some doubts about panthera's ability to handle more stuff, so maybe you can offer help. thanks you for your trust in me, this makes me very happy. Hi Daniel, I see you didn't take that a compliment, which I understand. I don't want to try justifying the bastard formulation I used, but I don't want to make you unhappy, so I'll attempt to clarify what I meant. I did read some people doubt about a single person maintaining such a number of packages. I don't doubt that you're *able* to maintain more packages, but I guess you too have limits, which could mean that your responsiveness would get lower. Of course, you're the one who chooses how much you contribute. But in IPW3945's case, since it was slower than usual, and I know you're doing a lot, I thought it would be good if someone would *offer* help. (FWIW, I had heard about IPW3945's state at least 3 times in the 2 previous months.) Sorry and huge thanks for your huge work, Filipus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IPW3945
See #363967. I heard some doubts about panthera's ability to handle more stuff, so maybe you can offer help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux 2.6.18
Is there any chance 2.6.18 will make it into etch to solve bugs like #391448 and #389803? Yes, but this requires addressing #395110, investigating or fixing #395247 and #392818 and getting a s390 build first, as per linux-2.6's excuses. This would be best asked to debian-kernel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
