[12:19] <tbf> https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/102128
[12:19] <ubotu> Malone bug 102128 in notification-daemon "Notification daemon leaks X11 windows" [Undecided,Unconfirmed]  
[12:25] <pochu> mjg59: still there? can you test 1.2.10c-0ubuntu1?
[12:28] <pochu> mjg59: bug 102114, if you're interested :)
[12:28] <ubotu> Malone bug 102114 in liferea "[UVFe]  Liferea 1.2.10c" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102114
[12:48] <mjg59> pochu: Sure - in the archive, or elsewhere?
[12:50] <pochu> mjg59: do you have i386?
[12:50] <pochu> if you want a .deb, you have it here: http://emilio.pozuelo.org/deb/ (built in pbuilder)
[12:50] <pochu> mjg59: otherwise, bug 102114
[12:50] <ubotu> Malone bug 102114 in liferea "[UVFe]  Liferea 1.2.10c" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102114
[12:50] <pochu> :)
[12:53] <mjg59> pochu: Not much good without liferea-mozilla.deb as well :)
[12:53] <pochu> LoL
[12:53] <pochu> hehe
[12:53] <pochu> one sec :)
[12:54] <pochu> mjg59: refresh please :)
[01:43] <KnowledgEngineer> hello
[01:43] <KnowledgEngineer> is possible install ubuntu in a Macintosh
[01:43] <KnowledgEngineer> ??
[01:44] <mjg59> KnowledgEngineer: Please ask support questions in #ubuntu
[01:45] <mjg59> pochu: Works fine!
[01:46] <pochu> mjg59: cool! feel free to comment in bug 102114 :)
[01:46] <ubotu> Malone bug 102114 in liferea "[UVFe]  Liferea 1.2.10c" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102114
[06:09] <fabbione> morning guys
[06:13] <ajmitch> hi fabbione 
[06:13] <fabbione> yo
[07:12] <manchicken_> Anybody got any clue why libmjs-dev conflicts with firefox, libnss3, and evolution among others?
[07:12] <manchicken_> libmjs0 didn't...
[07:24] <bluefoxicy> huh
[07:24] <bluefoxicy> does nmap fall under debian notfree?
[07:24] <bluefoxicy> it is licensed under the GPL
[07:25] <crimsun> no, it's in main.
[07:25] <bluefoxicy> however, its license considers any program that executes nmap and parses (not displays raw) the results as a "derivative work"
[07:25] <Treenaks> bluefoxicy: which then should be GPL too
[07:25] <bluefoxicy> and if the program reads nmap-os-fingerprints or nmap-service-probe files, it's a "derivative work" as well
[07:26] <bluefoxicy> (i.e. if it looks for installed nmap and reads the contents of those files)
[07:26] <desrt> the GPL supports neither of those claims
[07:26] <bluefoxicy> Treenaks:  so if I run, say, 'ls' and run the result through 'cut' and display an aggregate of ownership of files (who owns how many), that program has to be GPL because it's a derivative work of ls and cut?
[07:27] <bluefoxicy> desrt:  man nmap and go down to line 1635
[07:27] <desrt> not installed :p
[07:27] <bluefoxicy> are you nuts?
[07:28] <Treenaks> bluefoxicy: Real Men use telnet + seq ;)
[07:28] <desrt> vrms complained so i removed it
[07:28] <bluefoxicy> vrms?
[07:28] <Treenaks> bluefoxicy: apt-cache show vrms
[07:28] <desrt> are you nuts?
[07:29] <bluefoxicy> wow, that's horriffic.
[07:30] <desrt> bluefoxicy; nmap's claims are almost definitely bogus
[07:30] <bluefoxicy> desrt:  it's part of the license
[07:31] <desrt> no.  it's not.
[07:31] <desrt> This program is free software; you may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2.
[07:31] <desrt> i am therefore licensed to do anything authorised by the GPL
[07:31] <bluefoxicy>   Nmap Copyright and Licensing
[07:31] <bluefoxicy>        The Nmap Security Scanner is (C) 1996-2005 Insecure.Com LLC. Nmap is also a registered trademark of Insecure.Com
[07:31] <bluefoxicy>        LLC. This program is free software; you may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2.
[07:32] <desrt> the person owning the copyright doesn't matter.  they grant certain rights by distributing under GPL.
[07:32] <bluefoxicy> Note that the GPL places important restrictions on derived works, yet it does not provide a detailed definition of that term. To avoid misunderstandings, we consider an application to constitute a derivative work for the purpose of this license if it does any of the following:
[07:32] <bluefoxicy> <insert random rules here>
[07:32] <bluefoxicy> desrt: amap is no longer available in Ubuntu because it's GPL + you're not allowed to use it to hack into peoples' machines illegally.
[07:32] <desrt> oh.  by the way:  i consider an application a derived work if it was written by a person who has ever talked to me on IRC.
[07:33] <desrt> ...
[07:33] <bluefoxicy> desrt:  oh plus you have to mention the name and version etc if you distribute commercially.
[07:33] <bluefoxicy> http://www.thc.org/thc-amap/ under disclaimer.
[07:34] <desrt> GPL is GPL.  these claims are meaningless.
[07:34] <desrt> under GPL, for example, you can choose to redistribute without this manpage.
[07:34] <bluefoxicy> heh
[07:34] <desrt> so what?  again -- makes no difference
[07:35] <desrt> the GPL does not have a plugin infrastructure :p
[07:35] <desrt> (yet...)
[07:36] <bluefoxicy> oddly enough there's a special exception for linking programs with openssl and .. what the fuck does this say
[07:36] <desrt> that's a grant of additional rights
[07:36] <desrt> and it's a modification of the actual license
[07:36] <bluefoxicy> http://rafb.net/p/HvjQsC57.html
[07:37] <bluefoxicy> thaaaaat makes no sense.
[07:37] <desrt> it makes a lot of sense
[07:38] <desrt> and it's a modification of the actual license
[07:38] <bluefoxicy> "If you received these files with a written license agreement or contract stating terms other than the terms above, then that alternative license agreement takes precedence over these comments."  Also nmap is apparently REALLY BSD licensed  :p
[07:38] <tbf> desrt: but even gpl3 only will allow you to widen permissions
[07:38] <desrt> if nmap wanted to do what they are trying to do then they should have modified the GPL
[07:38] <bluefoxicy> tbf:  as the copyright holder you can do whatever the hell you want
[07:39] <bluefoxicy> you can say something is LGPL but you have to only run it when entertaining a dancing monkey or else the license is invalid.
[07:39] <desrt> bluefoxicy; but then it's _not LGPL_
[07:39] <desrt> it's a new licensed based on LGPL
[07:39] <bluefoxicy> desrt:  hey you see the point!
[07:40] <desrt> nmap says quite clearly "This program is free software; you may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2.
[07:40] <desrt> i can therefore chose to ignore their additional claims and redistribute straight-up under GPL2
[07:40] <desrt> *choose
[07:40] <bluefoxicy> technically not
[07:41] <desrt> technically i may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation
[07:41] <desrt> and technically they can bite me if they try to stop me
[07:41] <bluefoxicy> the additional claims are described as their interpretation of the license; copyright holder's interpretation, if documented, is then open to interpretation by court as part of the license.
[07:41] <tbf> bluefoxicy: you'd need to receive the alternate license agreement from some legitime copyright holder
[07:41] <tbf> bluefoxicy: otherwise that clause is void
[07:41] <bluefoxicy> technically my interpretation of the GNU GPL is that the linking clause is invalid and I treat the GPL exactly as the LGPL
[07:42] <bluefoxicy> so by desrt's logic I can pretty much ignore that part of the GPL
[07:42] <tbf> bluefoxicy: guess you'll fail with that interpretation in court
[07:42] <bluefoxicy> tbf:  are you up to speed on what we're talking about?
[07:43] <desrt> bluefoxicy; In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
[07:43] <desrt> bluefoxicy; installsheild is definitely a distribution medium
[07:43] <tbf> bluefoxicy: you claimed the linking clause of the GPL invalid
[07:43] <desrt> bluefoxicy; so not only are their ideas bogus... but some of them are outright contradictory....
[07:43] <tbf> bluefoxicy: and my believe is you'll fail in court with that interpretation
[07:44] <tbf> bluefoxicy: when GPL was tested in german courts reasoning of the judges always was: "GPL enhances your rights. the restrictions to not reduce your rights below the default case. so every restriction of it is valid."
[07:44] <bluefoxicy> tbf:  http://rafb.net/p/PTpOZj96.html  desrt's claim is that once you reach line 4, lines 10-24 are invalid
[07:45] <tbf> *do
[07:45] <bluefoxicy> (particularly 16-19)
[07:45] <Mithrandir> bluefoxicy: a licence is not a program, it has to be interpreted as a whole.
[07:46] <bluefoxicy> Mithrandir:  that is my argument, yes.
 nmap says quite clearly "This program is free software; you may redistribute and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; Version 2. <desrt> i can therefore chose to ignore their additional claims and redistribute straight-up under GPL2
[07:46] <bluefoxicy> is what I'm arguing against
[07:46] <_ion> This discussion is pointless. Everyone knows that GPL is invalid and SCO owns the rights to your code.
[07:47] <popey> bluefoxicy: line 31 specifically states that they see it as an interpretation of the GPLv2, not a change to or addition to the GPL
[07:47] <desrt> bluefoxicy; do you not believe that i may redistributed and/or modify nmap under the terms of version 2 of the GNU General Public License as published by the Free Software Foundation?
[07:47] <popey> so I would agree with desrt, you can re-release under flash GPLv2
[07:47] <desrt> bluefoxicy; if you don't believe this then perhaps you need to learn to read....
[07:48] <bluefoxicy> popey:  i.e. you can ignore their interpretation and substitute your own?
[07:48] <popey> you can ignore their interpretation and continue to redistribute the code under the *same* license - GPLv2
[07:48] <popey> IMO
[07:49] <Mithrandir> popey: you have to distribute it with the interpretations from Insecure.com LLC
[07:49] <bluefoxicy> who here is actually a lawyer
[07:49] <bluefoxicy> because I sure as hell ain't
[07:49] <popey> thats fine, interpretation != license
[07:49] <tbf> bluefoxicy: those are restrictions not found in original GPL and line 4 allows usage of original GPL
[07:49] <Mithrandir> popey: those definitions are parts of the licence.
[07:50] <popey> "We dont consider these to be added restrictions on top of the GPL,"
[07:50] <tbf> bluefoxicy: so the nmap authors better should have contacted a laywer to get their restrictions right
[07:50] <Mithrandir> bluefoxicy: I review quite a bit of licences, so even though I'm not a lawyer, I have a bit of training in reading them.
[07:51] <bluefoxicy> Mithrandir:  close enough.  I try to figure out what something logically says (you are distributing under X license, you specifically clarify that you think X says Y, so you are distributing under Y); but nobody said courtroom battles involved logic.
[07:51] <bluefoxicy> then again
[07:51] <bluefoxicy> Xerol tutors contract law, I could go ask him.
[07:51] <Mithrandir> bluefoxicy: but then, what is the problem?
[07:52] <desrt> nmap's claims appear to self-contradict even themselves
[07:52] <bluefoxicy> Mithrandir:  I was curious if those interpretations fell under debian non-free; amap was squashed out of ubuntu entirely (not even in multiverse, although we have ADOBE FLASH) for its weird license
[07:52] <desrt> they say that they consider a program a derived work if it reads nmap's files
[07:53] <desrt> but only if nmap is shipped by the same company as the program reading the files
[07:53] <tbf> hmm..... stop: have to correct me.
[07:53] <desrt> if the company directs you to the nmap website to download nmap (instead of giving you a copy) then they're OK again
[07:53] <bluefoxicy> "reads or includes" "does any of the following"
[07:53] <Mithrandir> bluefoxicy: which one do you believe makes it non-free?
[07:53] <bluefoxicy> these are both inclusive or
[07:53] <desrt> insane.
[07:53] <tbf> they use the loophole of GPL-2 not properly describing the term "derived works"
[07:53] <desrt> "derived works" is a legal term
[07:53] <desrt> it doesn't need to be defined
[07:54] <desrt> it already has a meaning
[07:54] <bluefoxicy> Mithrandir:  I don't know.  The license defines what a "derivative work" is and I'm simply not sure if that pushes it for debian or not.
[07:54] <desrt> (people disagree on this meaning... but that's really for a judge to decide)
[07:54] <desrt> bluefoxicy; the license is the GPL2.  it says so VERY VERY clearly.
[07:54] <bluefoxicy> I'm not an expert on debian policy either, I'm just a curious neophyte
[07:55] <tbf> desrt: if that's true, the only questions is: is their definitition more restrictive or more permissive?
[07:55] <desrt> tbf; if someone decides exactly what "derived work" means in a given country then it will affect all GPL code
[07:56] <desrt> for example... many contend that the idea that a program that links to a library is a "derived work" of that library to be quite bogus...
[07:57] <Mithrandir> tbf: that's irrelevant, given that it doesn't link with any GPL-ed libs.
[07:57] <bluefoxicy> desrt:  that is mostly because you can link to a similar library you wrote (that doesn't even provide any functionality), then copy the resulting program to a new machine and (lo and behold) it happens to use the other library instead, not exactly your fault.
[07:57] <bluefoxicy> yes irrelevant for this discussion
[07:57] <tbf> rofl: "Links to a library or executes a program that does any of the above."
[07:58] <tbf> so you connect via pipe to a GPL program doing the parsing
[07:58] <tbf> .oO(programmers really should not try to mess with licenses)
[07:58] <bluefoxicy> and you are automagically gpl
[07:59] <desrt> this conversation is mental.  bye.
[07:59] <bluefoxicy> tbf:  in the same fashion as with the linking clause argument I give above, imagine you connect via a pipe to an MIT-licensed program that has its own (shitty) built-in scanner; and the new version uses nmap instead and parses the result to look the same.
[07:59] <bluefoxicy> now what happens, does your program become a derivative work immediately when that program is born?  When the first end user runs it in this way?  When you release a new version?
[08:00] <Mithrandir> bluefoxicy: it probably depends on intent.  If you created the program so that you could use nmap, it ends up being a derivative work, if you didn't intend it to, it doesn't.
[08:00] <bluefoxicy> Mithrandir:  it depends on intangible assets, awesome.
[08:01] <Mithrandir> bluefoxicy: yes, computer people doesn't like those kinds of things, but it's important in law.
[08:01] <bluefoxicy> Mithrandir:  if I wrote a pure nmap clone and the program could use nmap because of this I'm safe, but if I write it without doing this I'm not safe.
[08:01] <Mithrandir> bluefoxicy: http://ansuz.sooke.bc.ca/lawpoli/colour/2004061001.php talks a bit about it.
[08:01] <bluefoxicy> Let us propose instead that the pure nmap clone theoretically exists, and just ignore that whole chunk of the license based on the theory that I can rectify any legal claims you bring up to me in about 3 days.
[08:02] <Mithrandir> bluefoxicy: that doesn't really help you if you intended it to be used with nmap, even though it could be used with something else.
[08:02] <Mithrandir> but we are getting very, very off-topic for this channel now. :-)
[08:02] <LaserJock> :-)
[08:02] <bluefoxicy> the channel was idle anyway.  It WAS relevant when I started, it's not NOW :)
[08:03] <bluefoxicy> (unless someone added #ubuntu-legal behind my back...)
[08:03] <Mithrandir> hence "getting", not "has been for a while".
[08:05] <StevenK> Oh no, debian-legal is messy enough already, we don't need to fuel that fire by creating ubuntu-legal.
[08:06] <StevenK> Mithrandir: If there's no herd 6, surely this week won't be so hard...
[08:06] <StevenK> Mithrandir: Or does it merely save the pain until the week of the 19th? :-P
[08:07] <Mithrandir> StevenK: I'm already tired and it'll be worse over the next two weeks.
[08:08] <StevenK> Mithrandir: Anything I can do to help?
[08:08] <mneptok> Mithrandir: can we release Herd 6/Beta 2 in ~12 minutes
[08:08] <Lathiat> mneptok: 12 minutes?
[08:08] <Lathiat> mneptok: getting a bit slack...
[08:08] <mneptok> Lathiat: "getting?"
[08:09] <Mithrandir> mneptok: no, our publishing machine isn't that fast. :-P
[08:09] <Mithrandir> StevenK: look at the RC bug list and see if there's anything there that you know how to fix.
[08:10] <mneptok> Mithrandir: ooo! you got a new business card to match the change in title? ;)
[08:10] <StevenK> Mithrandir: I had a look at the bug list for the ubuntu-7.04 milestone which are all mostly assigned.
[08:11] <Mithrandir> StevenK: indeed, there are a few which aren't, some of which are Hard.
[08:11] <StevenK> Mithrandir: I had a look at elmo's nmap bug, which I can't reproduce.
[08:12] <Mithrandir> I can't either
[08:13] <StevenK> Shall we slam it into Needs Info, and bounce the ball into elmo's court?
[08:16] <Mithrandir> yes, I think that makes sense.
[08:17] <tbf> crap: how do i create 99_autoreconf.patch files?
[08:18] <StevenK> Bad elmo. He isn't even subscribed to it.
[08:19] <tbf> i want to rebbuild notification-deamon-0.3.7 after applying https://bugs.launchpad.net/ubuntu/+source/notification-daemon/+bug/102128
[08:19] <ubotu> Malone bug 102128 in notification-daemon "Notification daemon leaks X11 windows" [Undecided,Confirmed]  
[08:22] <TheMuso> Mithrandir: When you have a chance, could you please consider bug 91868 for casper?
[08:22] <ubotu> Malone bug 91868 in casper "Magnifier does not start from accessibility menu due to incorrectly referenced file." [Undecided,Unconfirmed]  https://launchpad.net/bugs/91868
[08:22] <orkid> ubotu shut up
[08:22] <ubotu> Sorry, I don't know anything about shut up - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[08:22] <Mithrandir> TheMuso: sure.
[08:23] <StevenK> tbf: Which patch, there are 3?
[08:23] <StevenK> Mithrandir: Shall I be evil, and subscribe elmo to the nmap bug?
[08:23] <TheMuso> Mithrandir: Thanks.
[08:23] <Mithrandir> StevenK: yes, please.
[08:24] <tbf> StevenK: bugfix is the first one
[08:24] <tbf> StevenK: the other two patches are needed as some folders were moved
[08:24] <tbf> StevenK: currently patching the remaining 5 patches of the package, but to test them i want to build the package
[08:25] <StevenK> Mithrandir: All done (nmap bug)
[08:25] <tbf> StevenK: problem: applying the autoreconf patch fails even after recreating it
[08:25] <tbf> (by running autoreconf -i --force and diffing)
[08:25] <StevenK> tbf: Okay, so you only want to add the first patch to notification-daemon and rebuild?
[08:26] <tbf> StevenK: in a ideal world it would be that simple.
[08:26] <tbf> StevenK: but as folders have moved, i have to adjust all patches
[08:29] <tbf> StevenK: duh stop.
[08:29] <StevenK> tbf: Stopping. :-)
[08:29] <tbf> StevenK: maybe i just was too lazy to create a changelog entry
[08:32] <pitti> Good morning
[08:33] <pitti> hey StevenK 
[08:35] <tbf> StevenK: that plus the incredibly trick to create a recursive version of the autoregen patch containing a patch against itself
[08:37] <imbrandon> moins all
[08:37] <StevenK> tbf: Hurray!
[09:03] <pitti> \sh_away: I'm packaging mysql 5.0.38 now, let me know how it goes
[09:16] <tbf> woah! new launchpad's avatar scaling blows
[09:16] <popey> indeed
[09:16] <popey> you have to use a fixed size image
[09:16] <popey> padd it out with whitespace yourself :(
[09:18] <popey> bug #?
[09:18] <Treenaks> 101858
[09:19] <popey> bug 101858
[09:19] <ubotu> Malone bug 101858 in launchpad "User image in user info page is stretched" [Undecided,Confirmed]  https://launchpad.net/bugs/101858
[09:19] <popey> ta
[09:20] <popey> you know it does say on the +branding page "An image of exactly 64x64 pixels that will be displayed in the heading of all pages related to you." and "A large image of exactly 192x192 pixels, that will be displayed on your home page in Launchpad. "
[09:22] <Fujitsu> popey: The new avatar stuff was added about 24 hours before it went public.
[09:22] <popey> and the public beta was 3 days before it was originally planned?
[09:23] <Fujitsu> I didn't know that it was planned for any specific point.
[09:23] <popey> thats what i was told
[09:24] <dholbach> good morning
[09:25] <tbf> popey: well, but some people already uploaded avatars to the old launchpad ;-)
[09:25] <popey> yes, like me
[09:25] <tbf> well, just added some padding now.
[09:26] <tbf> don't have a 192x192 version of that photo and also do not know if i want such a high-res foto of mine in the public
[09:27] <StevenK> tbf: Scale it to 192x192 and then blur it a lot? :-P
[09:27] <tbf> StevenK: too much effort :-)
[09:29] <tbf> .oO(somehow the new look of launchpad triggers this "want to have it" feeling)
[09:33] <pochu> Mithrandir: if you have a moment, could you please review bug 102114? Thanks :)
[09:33] <ubotu> Malone bug 102114 in liferea "[UVFe]  Liferea 1.2.10c" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102114
[09:39] <Mithrandir> pochu: approved
[09:39] <pochu> cool, thanks! :)
[09:49] <mdke> Mithrandir: is it ok if translations for *ubuntu-docs come in by the NonLanguagePackTranslation deadline? we've done that in previous releases, there shouldn't be any possibility of serious bugs being introduced by adding translations in those packages
[09:49] <Mithrandir> mdke: yes, that should be ok.
[09:49] <mdke> Mithrandir: sorry, misspoke
[09:49] <mdke> I mean the LanguagePackTranslation deadline
[09:50] <mdke> we'll struggle to get them in by the first deadline, and translators haven't had very long at them
[09:50] <Mithrandir> that should be ok, yes.
[09:50] <mdke> great
[09:51] <mdke> Mithrandir: just to warn you, although you will probably know already, brining in translations increases the size of the -docs packages quite a lot; might have an impact on iso size if things are tight
[09:53] <Mithrandir> mdke: yes, we would probably need to drop a language or two off the CD.
[09:53] <mdke> ok, I'll try and get them in ASAP so you can see
[09:59] <Hobbsee> Mithrandir: what's happening now with syncs, which have uvfe approval?  are we poking?  presumably you're not doing all syncs this close to release.
[10:03] <pitti> StevenK: new ia32-libs uploaded; this should unbreak vmware on amd64
[10:03] <Hobbsee> (or pitti)
[10:03] <pitti> Hobbsee: should be processed as part of normal archive days
[10:03] <StevenK> pitti: Great!
[10:03] <pitti> Hobbsee: subject to the usual freezes, of course
[10:04] <StevenK> Which means no more syncs at all after Thursday?
[10:04] <Hobbsee> pitti: right.  yes, it already has an exception.  https://bugs.launchpad.net/ubuntu/+source/basket/+bug/102252
[10:04] <ubotu> Malone bug 102252 in basket "UVFe - Sync Basket 1.0.1 from experimental" [Undecided,Confirmed]  
[10:04] <pitti> StevenK: I just had to install the edgy version a second time and got sick of it ;)
[10:05] <pitti> Mithrandir: oh, no 0403 CDs; is the daily image process on manual already?
[10:06] <Mithrandir> pitti: no, it shouldn't be.
[10:06] <Mithrandir> pitti: they might just not be ready yet.
[10:06] <Mithrandir> Hobbsee: archive days, or poke if it's urgent.
[10:06] <carlos> pitti: did you upload the new language packs for Feisty?
[10:07] <Hobbsee> Mithrandir: right.  it's only urgent in the fact that id' like to see it tested more widely.  it can wait.
[10:07] <pitti> carlos: yes, I did
[10:07] <carlos> pitti: ok, cool
[10:07] <seb128> carlos: Hi. Do you know if the french translations have been changed? I got your mail bug no reply
[10:08] <carlos> seb128: the language pack that pitti uploaded had that change done, and I asked Stuart about that a couple of minutes ago, to see whether is on production, once he answers I will tell you...
[10:08] <seb128> carlos: ok, thank you!
[10:10] <carlos> you are welcome
[10:35] <siretart> Nafallo: around?
[10:44] <mneptok> ogra: ping
[10:44] <ogra> mneptok, pong
[10:44] <tkamppeter> Mithrandir, ping
[10:44] <dholbach> Mithrandir: what do you think about bug 102274?
[10:44] <ubotu> Malone bug 102274 in libsexy "UVF: libsexy 0.1.10 -> 0.1.11" [Medium,Unconfirmed]  https://launchpad.net/bugs/102274
[10:45] <Mithrandir> dholbach: looks sane to me.
[10:46] <dholbach> Mithrandir: gracias
[10:46] <Mithrandir> tkamppeter: don't just ping, ask me the question you want to ask.
[10:47] <mneptok> Mithrandir: i have a complex issue i need help with when you have a chance.
[10:47] <Mithrandir> mneptok: shoot
[10:48] <tkamppeter> Mithrandir, for the update to HPLIP 1.7.3 I did a user survey now to exclude regressions. I got 12 users going through my testing program and no one found any regression, this eaven lead to additional bugs getting found and fixed by HP. See bug 98520.
[10:48] <ubotu> Malone bug 98520 in hplip "Feisty UVF ER: New HPLIP 1.7.3 release fixes lots of bugs" [Medium,Needs info]  https://launchpad.net/bugs/98520
[10:48] <Mithrandir> tkamppeter: cool, great.  Go ahead and get your sponsor to upload then.
[10:49] <tkamppeter> Thanks, Mithrandir.
[11:03] <pitti> Mithrandir: weird; current live CDs are now two hours late, and alternate (http://cdimage.ubuntu.com/daily/current/) is empty
[11:04] <Mithrandir> pitti: I'll take a look at what's broken.
[11:05] <fabbione> pitti: could you be so kind to eyeball the patch to #98518 before i prepare edgy/feisty? specially if you want more details and so on...
[11:06] <fabbione> pitti: it's just to save time before i install edgy and feisty and blablabla
[11:07] <Arby> pitti: is it the same build system that provides the kubuntu daily builds as well?
[11:08] <Arby> I do some kubuntu iso testing and todays builds are late there as well.
[11:08] <pitti> fabbione: Tore's last suggestions don't sound bad; does this need to be addressed as well?
[11:09] <fabbione> pitti: adding the docs? yes.. i will do that too... i don't think they are critical for the proposed patch
[11:09] <fabbione> pitti: i need to know first if the code changes are ok with the SRU team. they are more important a bit intrusive.. hence priority to them first
[11:10] <pitti> fabbione: I meant using sg_turs as a test and checking vendor ID, too
[11:10] <kwwii> seb128: can you look at bug #43398
[11:10] <ubotu> Malone bug 43398 in ubuntu-artwork "Blurry icons in applications menu" [Medium,Fix released]  https://launchpad.net/bugs/43398
[11:10] <kwwii> seb128: at first I thought it was the icons themselves, but that does not seem to be the case
[11:10] <fabbione> pitti: oh that comment was not there when i reloaded the page 5 minutes ago!.. just one minute :)
[11:10] <pitti> fabbione: the udev rule ensures that the changes are confined to a specific type of hardware; if the change is tested on such hardware, the current amount of information is good for moe
[11:10] <pitti> fabbione: s/moe/me/
[11:11] <fabbione> pitti: i have the HSG80 here at home :)))
[11:11] <pitti> splendid
[11:17] <fabbione> pitti: ok.. i will need to recheck with Tore suggestions.. 
[11:17] <fabbione> pitti: they were just not there when i asked you :)
[11:17] <pitti> fabbione: right, I understand :)
[11:18] <fabbione> pitti: thanks tho :)
[11:24] <carlos> Riddell: hi, around?
[11:29] <seb128> kwwii: do you really think they are blurry? ;)
[11:29] <seb128> kwwii: the panel uses the 24x24 icon, it might scale it to 22x22 though
[11:32] <HiddenWolf> Guys, is something up with the ML archives?
[11:33] <HiddenWolf> haven't been any logs this month so far
[11:33] <Mithrandir> HiddenWolf: they're lagging
[11:33] <HiddenWolf> ok
[11:34] <fabbione> pitti: updated debdiff.. and i am off for lunch
[11:36] <pitti> fabbione: I can't claim that I would understand it completely, but given the specific udev rule I'm ok with it
[11:37] <pitti> fabbione: certainly much better than the weird init script h4ck
[11:45] <mvo> cjwatson_: hello! will it be ok if I change the section for ubuntu-meta from "base" to "metapackages" ? this will ensure that the section is correct in /var/lib/dpkg/status 
[11:46] <seb128> kwwii: http://bugzilla.gnome.org/show_bug.cgi?id=343437
[11:46] <ubotu> Gnome bug 343437 in Panel "Use correct size for launcher icons (on the panel and in the menu)" [Minor,Resolved: fixed]  
[11:47] <seb128> mvo: are you working on the seed?
[11:47] <kwwii> seb128: if you check that screenshot I attached, it is definitely blurry
[11:47] <mvo> seb128: no, this is just about the "ubuntu-meta" package, not the seed
[11:48] <seb128> mvo: ok, I thoguh it was built from the seed
[11:49] <kwwii> seb128: the difference in icon sizes between kde and gnome is a real pain
[11:49] <kwwii> seb128: so, are we going to stick to using 22x22 icons?
[11:50] <seb128> kwwii: the panel logic should handle 24x24 correctly, I'm talking to upstream
[11:50] <kwwii> seb128: excellent, thanks :-)
[11:51] <seb128> np
[11:52] <Riddell> carlos: pong
[11:53] <carlos> Riddell: hi, I know it's quite late in the development process
[11:53] <carlos> Riddell: but when k3b was updated to 1.0
[11:53] <carlos> k3b-i18n was not updated
[11:53] <carlos> so we have old translations
[11:54] <Riddell> carlos: very good point
[11:54] <Riddell> carlos: I'll get onto it now and chastase the people who forgot it (including myself)
[11:54] <carlos> Riddell: thank you
[11:59] <seb128> kwwii: could you try to:
[11:59] <seb128> - add 'gtk-icon-sizes = "panel-menu=24,24"' to the Human gtkrc
[11:59] <seb128> then change theme
[11:59] <seb128> or restart the panel
[12:00] <seb128> and let me know if you think it's nicer
[12:00] <kwwii> seb128: will do
[12:04] <doko> Mithrandir: please could you consider bug 102268 ?
[12:04] <ubotu> Malone bug 102268 in neon26 "UVF exception and sync request (0.26.3)" [High,Confirmed]  https://launchpad.net/bugs/102268
[12:05] <kwwii> seb128: yes, that fixes the problem for all the gnome icons although the kde icons in the menu now are blurry instead (but I think that as one is running gnome by choice it is better to have the gnome icons look nice as you'll see many more of those)
[12:05] <cjwatson> mvo: ubuntu-meta Section: metapackages> no problem
[12:05] <fabbione> pitti: thanks
[12:06] <fabbione> pitti: but if you want a full more detailed explanation i can give it to the sru team. it's just complex..
[12:06] <Mithrandir> doko: looks good; approved
[12:07] <mvo> cjwatson: cool, thanks!
[12:07] <fabbione> seb128: i saw your last gamin upload.. so i was right this time it wasn't a kernel issue :P
[12:08] <seb128> kwwii: right, better to have the GNOME icon theme looking nice on GNOME
[12:08] <seb128> fabbione: yep ;)
[12:09] <kwwii> seb128: exactly :-)
[12:20] <Riddell> carlos: uploaded
[12:27] <dholbach> kwwii: tangerine+tango-stock-icons uploaded
[12:27] <tbf> seb128: may you have a look at bug 102128 and apply at least the first patch?
[12:27] <ubotu> Malone bug 102128 in notification-daemon "Notification daemon leaks X11 windows" [Undecided,Confirmed]  https://launchpad.net/bugs/102128
[12:27] <seb128> tbf: I've already showed it to mvo
[12:27] <tbf> seb128: ah, cool :-)
[12:56] <Seveas> elmo, mako: CC meeting in 4 minutes - sabdfl available?
[12:57] <cjwatson> I can probably sit in for a while
[12:59] <Keybuk> fabbione: could you mail me your /var/log/udev
[01:00] <carlos> Riddell: ok, thank you
[01:17] <mvo> Riddell: I will do a upload of kubuntu-meta to change the Section to metapackages (just FYI)
[01:17] <mvo> ogra:  I will do a upload of edubuntu-meta o change the Section to metapackages (just FYI)
[01:17] <ogra> oki
[01:17] <Riddell> mvo: oki
[01:18] <mvo> thanks :)
[01:23] <seb128> mvo: will you update an ubuntu-meta?
[01:24] <mvo> seb128: no, I haven't
[01:24] <seb128> mvo: "will" you ;)
[01:25] <seb128> mvo: I've commited changes to the desktop seed yesterday and I'm wondering if I can be lazy and wait on your upload :p
[01:25] <cjwatson> mvo: xubuntu-meta too?
[01:25] <stgraber> Hey, anyone willing to sponsor the upload for : bug 68818 ?
[01:25] <ubotu> Malone bug 68818 in squid "squid transparent proxy is broken" [High,In progress]  https://launchpad.net/bugs/68818
[01:25] <mvo> seb128: no, I uploaded already and changed only the section. if you need a seed change you will have to upload again, sorry 
[01:25] <mvo> cjwatson: all of them
[01:25] <seb128> mvo: ok
[01:25] <mvo> cjwatson: ubuntu,xubuntu,edubuntu,kubuntu
[01:25] <mvo> -meta
[01:25] <mvo> seb128: what change do you need?
[01:26] <ogra> does anyone know where /sbin/update-modules.modutils belongs to ?
[01:26] <seb128> mvo: I commited it yesterday, added dcraw to desktop
[01:26] <ogra> seems its broken so debootstrap doesnt work
[01:26] <Fujitsu> `diversion by module-init-tools to: /sbin/update-modules.modutils'
[01:26] <ogra> (linux-sound-base.postinst calls it)
[01:26] <cjwatson> ogra: full log please?
[01:26] <mvo> seb128: ok, sorry. I can do another upload for you if you want me to
[01:27] <cjwatson> no, linux-sound-base.postinst calls update-modules
[01:27] <seb128> mvo: no, that's fine, I'm just wondering how you did update the package without using the change on bzr
[01:27] <cjwatson> though that execs update-modules.modutils
[01:27] <ogra> cjwatson, which in turn calls update-modules.modultils here
[01:27] <ogra> right
[01:27] <ogra> which in turn calls itself
[01:28] <ogra> a very excessive while 1; do :P
[01:30] <fabbione> Keybuk: yes... but it's the one without lvm/mdadm & co running from init.d
[01:31] <Keybuk> that's ok
[01:31] <Keybuk> I'm initially interested in the whole | thing
[01:31] <Keybuk> which I suspect is why the second bunch of init scripts stop
[01:31] <Keybuk> (they'll probably carry on after an hour or so <g>)
[01:32] <NDAKOTA> hi
[01:32] <NDAKOTA> anyone familiar with the python scripting bounty posted on ubuntu website
[01:34] <NDAKOTA> hello
[01:35] <NDAKOTA> !
[01:35] <NDAKOTA> developers
[01:36] <NDAKOTA> echo
[01:36] <thom> NDAKOTA: look, please be polite and show some patience
[01:37] <thom> if someone knows, they'll answer you. either way, everyone is busy preparing for a new release
[01:37] <NDAKOTA> alright, I'm being impatient.
[01:38] <NDAKOTA> yea, sorry i did not know
[01:39] <asac> pitti: simple question: how are dbgsym packages generated for your archive? Just a plain buildpackage or with "noopt"?
[01:39] <seb128> asac: the dh_strip way after build
[01:39] <pitti> asac: they are not compiled at all; just what objcopy --only-keep-debug gives us
[01:40] <pitti> asac: it hooks into dh_strip
[01:40] <asac> yeah i know about the strip
[01:40] <asac> but where do you get the debug symbols from if you don't build the package?
[01:40] <pitti> asac: they are copied from the already built ELF file during the normal build process
[01:41] <pitti> asac: in debian/rules binary stage, after dh_install and everything
[01:41] <asac> ok ... so you hooked into the buildd ?
[01:41] <asac> didn't know that ... thought you generate them on your own ... ok, then i understand
[01:42] <mvo> seb128: new ubuntu-meta with refreshed dependencies uploaded 
[01:42] <seb128> mvo: cool!
[01:51] <jwendell> how to make reportbug tool report bugs in debian, instead of ubuntu?
[01:52] <Hobbsee> jwendell: reportbug -B debian, iirc.  man reportbug tells you
[01:52] <Hobbsee> along with lots of other options
[01:52] <jwendell> Hobbsee, thanks
[01:54] <ogra> fabbione, did you change anything in update-modules with your last module-init-tools upload ? i cant build chroots anymore, linux-sound-base hangs at /sbin/update-modules.modutils which seems to call itself in an endless loop
[01:55] <fabbione> ogra: no.
[01:55] <ogra> hmm
[01:56] <ogra> root@edubuntu:/# cat /sbin/update-modules.modutils
[01:56] <ogra> #!/bin/sh -e
[01:56] <ogra> if [ -x /sbin/update-modules.modutils ] ; then
[01:56] <ogra>   exec /sbin/update-modules.modutils "$*"
[01:56] <ogra> fi
[01:56] <ogra> exit 0
[01:56] <ogra> that doesnt look right to me ...
[01:57] <cjwatson> looks like it's been mistakenly diverted twice
[01:57] <ogra> yes
[03:38] <Saied> all,hi
[03:38] <Saied> we are working on conexant winmodem driver
[03:39] <Saied> currently at start stage
[03:40] <Saied> we heared that the ubuntu community are working on a free conexant modem driver, is it true?
[03:41] <mjg59> Saied: Not currently
[03:41] <mjg59> (As far as I know)
[03:42] <miladmovie> Saied, na inja ham khabry nist
[03:42] <gicmo> grml
[03:43] <gicmo> wlan still doesnt work
[03:43] <gicmo> ohh and sound stopped working too
[03:43] <gicmo> wtf
[03:43] <Saied> miladmovie: tablo baazi dar nayar
[03:43] <Saied> miladmovie: :D
[03:43] <miladmovie> Saied, ;)
[03:43] <gicmo> Feisty from 2 weeks before worked way better ;-)
[03:43] <Saied> mjg59: are there any plans in future?
[03:44] <mjg59> Saied: It's quite likely that you'd find someone interested in working on it
[03:44] <mjg59> Saied: Who's currently working on it, and what sort of skills do they have?
[03:44] <seb128> gicmo: you might want to be specific about your configuration if you want any constructive reply :p
[03:45] <Saied> mjg59: yaah, we want to work on it
[03:45] <gicmo> seb128: I am not sure if I already have given up
[03:46] <seb128> gicmo: if you have opened a bug maybe join #ubuntu-kernel and ask if you can give extra details or something
[03:47] <Saied> mjg59: we have another team and currently we are at planning stage
[03:49] <Saied> mjg59: do you have any links to this project of ubuntu community?
[03:50] <mjg59> Saied: I'm not aware of anything having been produced
[03:50] <mjg59> Saied: do you have any pointers to your planning?
[03:54] <Saied> mjg59: in our country we have lots of problems with this winmodems and we want to solve it at least locally. in #technotux we are speaking on it
[03:54] <mjg59> Saied: What sort of implementation are you currently planning?
[03:56] <Saied> mjg59: HCF and HSF implementation for linux kernel 2.6.20 or above. maybe user space , udev based , etc
[03:57] <mjg59> Saied: Have you determined any of the functionality of the codec?
[03:57] <mjg59> Saied: slmodemd already provides an (admittedly closed-source) modem stack
[03:58] <Saied> mjg59: codec? what do you mean?
[03:58] <siretart> Keybuk: re bug #102089 - I'm not sure how to interpret your last comment
[03:58] <ubotu> Malone bug 102089 in devmapper "latest devmapper upload breaks booting" [High,Needs info]  https://launchpad.net/bugs/102089
[03:59] <mjg59> Saied: Hm. I think you need to do a little more research.
[03:59] <siretart> Keybuk: I had to downgrade libdevmapper1.02 in order to boot my system correctly again
[04:00] <mjg59> Saied: Precisely which hardware are you looking at? A great deal of modern Connexant chips are connected to an AC97 or HDA bus
[04:00] <mjg59> There's already some infrastructure for dealing with them
[04:00] <mjg59> But no support for the chip itself
[04:01] <Saied> mjg59: i mean modems that can attach to PCI bus. (internal winmodems)
[04:01] <ilovelinux> Saied: it seems irc.ubuntu.com is here !!!
[04:02] <iwj> ogra: So re update-modules.modutils, does anyone know of a fix or know who's responsible or is anyone working on it or what ?
[04:02] <Keybuk> siretart: right, you need to upgrade it to break your system and follow the second stage of "Needs Info" in that bug
[04:02] <Keybuk> iwj: isn't that a dpkg bug
[04:02] <Keybuk> ?
[04:02] <Keybuk> where's the diverted update-modules coming from
[04:02] <mjg59> Saied: The base functionality of the chip is the same whether it's on a PCI bus, an AC97 bus or a USB bus
[04:02] <Mithrandir> you can also just debootstrap a chroor
[04:02] <iwj> Keybuk: I don't know.  I don't know anything yet; I've only just stumbled over this.
[04:02] <Mithrandir> chroot, even
[04:03] <iwj> ogra: If you have some information please let us know :-).
[04:03] <Keybuk> iwj: I've only seen one bug report from somebody about it
[04:03] <Keybuk> ogra: does it affect you?
[04:03] <siretart> Keybuk: ok., will do this evening
[04:03] <iwj> Keybuk: In my case it breaks debootstrap.
[04:03] <Keybuk> siretart: this evening is going to make it practically impossible for this to be fixed before release candidate :-/
[04:03] <ogra> Keybuk, yes for ltsp chroots
[04:03] <Keybuk> ok
[04:03] <siretart> Keybuk: that's sad :( - but I can't leave work right now
[04:03] <iwj> ogra: You make those with debootstrap ?
[04:04] <Keybuk> ogra: dpkg -S /usr/bin/update-modules and .modutils
[04:04] <ogra> yes
[04:04] <Keybuk> siretart: if you could investigate heavily into what it is about those scripts that breaks things for you -- that would be very useful
[04:04] <ogra> Keybuk, i need to build a new one ... i'm currently totally into something else, give me a minute
[04:04] <Keybuk> siretart: rather than just "downgrade"
[04:05] <Keybuk> siretart: since those packages do fix things for (afaict) the majority of people, and only cause new breakage for a few (important) people
[04:05] <Keybuk> siretart: afaik those two init scripts (mdadm-raid and lvm) are completely useless; so we need to understand what they do, and why -- and why it breaks things (because they should have no effect)
[04:05] <siretart> Keybuk: the thing is that I didn't find enough documentation which explained how things are supposed to work and how to do useful diagnostics
[04:06] <iwj> ogra: Do you want me to pick this up ?  It's blocking me and I'm not too deeply nested right now ...
[04:06] <bddebian> Heya
[04:06] <Keybuk> siretart: you're subscribed to a bug where it's quite heavily detailed
[04:06] <siretart> Keybuk: I could upgrade them from here, but I'd better don't reboot. perhaps this helps you as well?
[04:06] <Saied> mjg59: we want to reimplement linuxant hcf and hsf winmodem drivers 1-free 2-with full bandwidth
[04:06] <Keybuk> iwj: there's not much you can do unless you can be around this evening to help siretart debug
[04:06] <ogra> iwj, that'd be great, i'm totally swamped with ltsp tests
[04:06] <iwj> Keybuk: No, I meant the update-modules thing.
[04:06] <Keybuk> iwj: err, sorry, ignore that :)
[04:06] <ogra> but i'm building a chroot already again, so if you need info i'll keep it around
[04:06] <mjg59> Saied: Then you have to care about AC97 and USB as well as PCI
[04:06] <iwj> Keybuk: Although I can try to help if you like and might be able to be around this evening at least a bit.
[04:07] <iwj> Keybuk: If so then I'll need to look over what you did in your most recent packages ...
[04:07] <Saied> mjg59: you said infrustructure. which infrustructure do you mean?
[04:07] <mjg59> Saied: So it makes sense to work out what the fundamentals of the chip behvaiour are, independent of the bus
[04:07] <Keybuk> iwj: I may be also, but I haven't gone to the new hotel yet, so haven't found out what their "High Speed Internet Access In Every Room" really means
[04:07] <iwj> Keybuk: Also you should know I have a cold so am a bit stupid atm.
[04:07] <iwj> Keybuk: *snort*
[04:07] <mjg59> Saied: For the ac97 case, you'll want to interface with the existing snd-intel-modem, snd-atiixp-modem and so on drivers
[04:08] <Saied> mjg59: hmm, maybe at beggining only for PCI . it is great if possible to work bus independent
[04:09] <Keybuk> siretart: bottom of #75681
[04:09] <siretart> bug #75681
[04:09] <ubotu> Malone bug 75681 in mdadm "boot-time race condition initializing md" [High,Fix released]  https://launchpad.net/bugs/75681
[04:09] <Keybuk> well, second-to-bottom
[04:09] <Keybuk> since someone can't read the "file a new bug with your symptoms, to avoid a hijack-fest" :p
[04:11] <jandark> Saied, yup
[04:11] <siretart> Keybuk: are there any diagnostics I can do with you which do not involve rebooting the system?
[04:13] <Keybuk> siretart: I can't think of any that won't hose your system
[04:13] <mjg59> Saied: You'll also need a modem protocol stack. As I said, slmodemd provides one. Rather than write one from scratch, it would make sense to make your driver provide an interface that slmodemd can use
[04:13] <Keybuk> I'd certainly recommend a console for "muck around with root filesystem"
[04:13] <ogra> ogra@edubuntu:~/devel/feisty-ltsp$ sudo chroot /opt/ltsp/feisty/ dpkg -S /sbin/update-modules 
[04:13] <ogra> diversion by module-init-tools from: /sbin/update-modules
[04:13] <ogra> diversion by module-init-tools to: /sbin/update-modules.modutils
[04:13] <ogra> module-init-tools: /sbin/update-modules
[04:13] <ogra> ogra@edubuntu:~/devel/feisty-ltsp$ sudo chroot /opt/ltsp/feisty/ dpkg -S /sbin/update-modules.modutils
[04:13] <ogra> diversion by module-init-tools from: /sbin/update-modules
[04:13] <ogra> diversion by module-init-tools to: /sbin/update-modules.modutils
[04:13] <ogra> iwj, Keybuk ^^^^^^
[04:13] <mjg59> Saied: That way, if someone wants to write an entirely free modem stack, they can just replace slmodemd. Then it doesn't just benefit the Connexant hardware, it benefits all Linux modem users.
[04:14] <Keybuk> ogra: dpkg-divert --list /sbin/update-modules
[04:14] <iwj> ogra: Yes.
[04:14] <siretart> Keybuk: any idea which command could cause theses 'Rendevouz with udev timed out' error messages?
[04:14] <Keybuk> siretart: using dmsetup (or anything linking to libdevmapper) and expecting a name to appear that's different to what the kernel knows for that name
[04:14] <ogra> ogra@edubuntu:~/devel/feisty-ltsp$ LANG=C sudo chroot /opt/ltsp/feisty/ dpkg-divert --list /sbin/update-modules
[04:14] <ogra> diversion of /sbin/update-modules to /sbin/update-modules.modutils by module-init-tools
[04:15] <Keybuk> so where's that other /sbin/update-modules.modutils come from?
[04:15] <iwj> AFAICT the problem happens as follows: debootstrap extracts (dpkg -x) update-modules.  Then it installs (dpkg -i, effectively) module-init-tools, diverting module-init-tools's update-modules to update-modules.modutils.
[04:15] <ogra> chaos :D 
[04:15] <Keybuk> iwj: but that shouldn't happen, because the diversion is listed against module-init-tools
[04:15] <yacoob> can anyone explain me what's so nifty about https://wiki.ubuntu.com/NoMoreSourcePackages ?
[04:15] <Keybuk> yacoob: rationale is in the spec
[04:15] <iwj> Keybuk: Yes, but the first module-init-tools is _extracted_ ie nothing looks at diversions, just dump the files in the fs.
[04:15] <ogra> Keybuk, no clue, its there when deboostrap hangs itself
[04:16] <Keybuk> I think iwj is right
[04:16] <Keybuk> but why's it suddenly happening now?
[04:16] <yacoob> Keybuk, it doesn't convince me :) Or rather, I'm not sure about the consequences.
[04:16] <iwj> And what is the point of diverting update-modules and replacing it with a file which just runs the original update-modules ?!
[04:16] <ogra> there is none
[04:17] <ogra> especially since it conflicts with modutils
[04:17] <ogra> which is the only other package providing it
[04:17] <Keybuk> does it conflict?
[04:18] <Keybuk> the original purpose was that you could install module-init-tools and modutils at the same time
[04:18] <iwj> debootstrap installs don't normally have modutils, do they ?
[04:18] <ogra> well, it Conflicts: modutils (<= 2.4.21-1)
[04:18] <iwj> Keybuk: Yes, but why the crazy wrapper script ?  AFAICT the only effect would be to make attempts to run update-modules silently succeed if modutils's update-modules isn't installed (at least, that seems to be the intent).
[04:19] <ogra> right, there is no modutils in my chroot
[04:19] <Keybuk> right
[04:19] <yacoob> my first concern is, where would upstream sources end up in this scheme?
[04:19] <iwj> Maybe the bug is that debootstrap shouldn't be installing module-init-tools.
[04:19] <Keybuk> because there's no reason to *have* an update-modules if you're using module-init-tools
[04:19] <yacoob> second: it doesn't mean apt-get source is going away, does it?
[04:19] <Keybuk> yacoob: 1) in revision control
[04:19] <Keybuk> yacoob: 2) yes, for normal development
[04:19] <ogra> iwj, maintainer scripts call update-modules ....
[04:19] <ogra> so you need a dummy at least
[04:19] <iceman> mvo: Is it possible at this time to upgrade to the beta via update-manager? I'd like to offer my help to test it out now if it's already supposed to work.
[04:20] <yacoob> Keybuk, so we're throwing .tgz into rcs?
[04:20] <yacoob> and what about those folks that want to recompile the packages?
[04:20] <iwj> Hmm.  All a bit lame really.
[04:20] <mvo> iceman: yes, please run "update-manager -d" (e.g. via terminal or alt-f2)
[04:20] <yacoob> (not popular among 'standard users', but popular when you're taking care of server, not workstation, and you have specific needs)
[04:21] <iwj> Maybe module-init-tools's update-modules should test whether $0 is update-modules.modutils and if so it should exit 0 and perhaps delete itself :-).
[04:21] <StevenK> seb128: I have a ~2K debdiff for zenity to fix 2 of the outstanding bugs if you have a moment, and the last bug open against zenity can be closed.
[04:21] <iceman> mvo: I knew how to do it, I just didn't know if it was already working. Thanks, I'm doing it right-away. ;-)
[04:22] <mvo> iceman: let me know about any problem
[04:22] <iceman> mvo: of course, that was the point ;-)
[04:24] <Keybuk> yacoob: they'd have a similar tool to grab the "package" in one command, taking just the name
[04:24] <iwj> Maybe this has just started happening now because we've stopped including modutils ?
[04:25] <yacoob> Keybuk, hmm.
[04:25] <yacoob> if it won't be a matter of http/ftp transfer, I'm cooked.
[04:26] <yacoob> (I have a bunch of machines behind very restrictive proxy)
[04:27] <ogra> iwj, did we ?
[04:27] <ogra> that'd be silly ... we dont have 2.4 kernels why should it have been in a default bootstrap
[04:27] <iwj> I don't know - I'm just speculating.
[04:29] <yacoob> ah, I see.
[04:29] <yacoob> * Source package and binaries are built and published into the archive
[04:29] <yacoob> so, the source package is still there, but is rather output, instead of input
[04:32] <iwj> The change to update-modules is from Debian in 2004.
[04:33] <iwj> Although we seem to have adopted it only somewhat recently.
[04:37] <Keybuk> iwj: we never needed to adopt it
[04:37] <Keybuk> ?
[04:37] <Keybuk> we've always had it
[04:37] <Keybuk> since that predates Ubuntu
[04:37] <Keybuk> something else (debootstrap, maybe) must have changed recently
[04:40] <iwj> I don't think I'm going to go any further into the archaeology.  I think I'll just add a fixup to the debootstrap script.
[04:40] <Keybuk> ogra: when did it break?
[04:41] <Keybuk> or, to ask a better question
[04:41] <Keybuk> when did it last work?
[04:41] <ogra> Keybuk, i didnt do any chroots since a week ..
[04:41] <ogra> and it broke with the first one today
[04:42] <iwj> Keybuk: I'm not sure either.  It's been a while since I regenerated.
[04:42] <ogra> all i found were fabios uploads, but that didnt change any maintainer scripts 
[04:42] <Keybuk> yeah, I'm just going to look at those carefully
[04:44] <iwj> I looked at them already, they're not relevant I think.
[04:44] <BenC> anyone know how to add keymappings for special keys on laptops (like media keys)?
[04:45] <Keybuk> ogra: confirmed, no changes there
[04:45] <Keybuk> BenC: setkeycodes thingy
[04:45] <BenC> Keybuk: thanks
[04:45] <Keybuk> there's an mjg59-tastic init script
[04:45] <iwj> But some laptops have buttons that aren't keys.
[04:45] <Keybuk> iwj: those usually generate acpi events
[04:45] <Keybuk> BenC: hotkey-setup package
[04:45] <BenC> iwj: these produce key codes, but they just aren't mapped to do anything
[04:46] <iwj> BenC: Oh, right, setkeycodes IYF
[04:46] <BenC> Keybuk: I'll check that too
[04:46] <_ion> benc: Hi, have you received my messages? I might be able to help with the l-r-m changes re: the nvidia drivers  is there a VCS branch for l-r-m?
[04:46] <BenC> _ion: I've gotten them, and I'm working on it today
[04:46] <Keybuk> BenC: that has little bits of shell for known laptop models so we can map them for everyone
[04:47] <BenC> Keybuk: ah, that's probably what I want then, thanks
[04:47] <Keybuk> so you should add your laptop to it, and then upload so everyone can share the KEY_COFFEE
[04:49] <iwj> Yep that change to the feisty script worked and I think that's the right fix because it's really a "bug" in the way debootstrap works (that is, it's a result one of the assumptions invalidated by debootstrap).
[04:50] <iwj> ogra: Tell me your email address and I'll pipe the diff to mail -s something you so you can try it.
[04:50] <Keybuk> what I don't understand is why this is suddenly happening
[04:50] <ogra> iwj, ogra@ubuntu.com :)
[04:50] <ogra> yeah
[04:50] <Keybuk> that code has been in module-init-tools since hogley
[04:50] <wasabi> Sometimes I think if launchpad was foss (or even commercial), I'd buy it for use at work.
[04:51] <wasabi> Sure works nice when it works.
[04:51] <Keybuk> fabio's uploads don't go near it
[04:51] <iwj> Keybuk: Yes.  I don't know what the problem is.  I suspect that module-init-tools has only recently shown up in debootstrap installs.
[04:52] <iwj> ogra: Mail on the way.  Please don't reply to that email; the From: will be a bit crazy.  (root@mytestbox)
[04:52] <ogra> yeps :)
[04:52] <cjwatson> iwj: is module-init-tools by chance now Priority: required?
[04:52] <cjwatson> iwj: please hold off on debootstrap for a second
[04:53] <iwj> cjwatson: I don't know but perhaps
[04:53] <iwj> cjwatson: Sure, I won't upload anything just yet ...
[04:53] <ogra> could mvo's base-Ymetapackage section change have something to do with it ?
[04:53] <cjwatson> iwj: stuff that's Priority: required gets extracted then unpacked; stuff that's Priority: important only gets unpacked
[04:53] <cjwatson> ogra: no
[04:53] <ogra> s/Y/>/
[04:54] <iwj> cjwatson: ISTR a message from debootstrap about it being an additional required package (due to dependency chasing) but I don't have a relevant log to hand.
[04:54] <cjwatson> iwj: aha
[04:54] <iwj> cjwatson: Is it wrong for module-init-tools to turn up in debootstrap ?
[04:54] <cjwatson> so somebody added a dependency from a Priority: required package on module-init-tools, I guess
[04:55] <cjwatson> iwj: it should be in the important set but not in the required set (at least until it learns how to cope with being extracted first)
[04:55] <iwj> initramfs-tools ?
[04:56] <Mithrandir> i-t is just priority: important
[04:56] <cjwatson> Priority: important
[04:56] <iwj> cjwatson: udev
[04:56] <iwj> Also important.
[04:56] <iwj> Hmm.
[04:57] <iwj> Bear with me, I'll run it again and get real information.
[04:57] <iwj> I: Found additional required dependencies: busybox-initramfs cpio initramfs-tools klibc-utils libklibc libvolume-id0 module-init-tools udev volumeid 
[04:57] <Mithrandir> nothing I have installed at least is Priority: required and depends m-i-t
[04:57] <cjwatson> whoa, that's a lot
[05:00] <pitti> asac: tbird upload> ah, that would explain crappy retrace results
[05:00] <cjwatson> dmsetup Priority: required Depends: udev
[05:00] <Keybuk> why is dmsetup required?
[05:01] <Mithrandir> Keybuk: depended on by libdevmapp1.02
[05:01] <Mithrandir> libdevmapper1.02, even
[05:01] <cjwatson> I don't think it needs to be. libblkid1 -> libdevmapper1.02 -> dmsetup
[05:01] <Mithrandir> (which is priority: required)
[05:01] <Keybuk> why is that required?
[05:01] <cjwatson> but libblkid1 isn't depended on by anything else required
[05:01] <cjwatson> so I think we can demote that whole shebang
[05:01] <cjwatson> I'll try it out and see
[05:02] <Mithrandir> cjwatson: e2fsprogs depends on libblkid1
[05:02] <cjwatson> oh, Pre-Depends, that's why I missed it
[05:02] <Keybuk> ah, I added that dmsetup -> udev dependency
[05:02] <Keybuk> so that explains why it's suddenly appeared
[05:02] <Keybuk> but yes, that whole lot should not be Required
[05:03] <cjwatson> Keybuk: no, Mithrandir's right, it needs to be due to libdevmapper1.02 -> dmsetup
[05:04] <Keybuk> but devmapper doesn't need to be Required
[05:04] <Keybuk> tracking its rdepends back doesn't find anything critical
[05:04] <cjwatson> libblkid1 Depends: libdevmapper1.02. Yes it does
[05:04] <Keybuk> what uses blkid?
[05:04] <cjwatson> 16:02 <Mithrandir> cjwatson: e2fsprogs depends on libblkid1
[05:04] <Mithrandir> e2fsprogs
[05:04] <Keybuk> oh, hmm
[05:05] <Mithrandir> which is Essential and required.
[05:05] <Keybuk> bugger
[05:05] <cjwatson> it's a pre-depends so if you were using grep-dctrl -FDepends like me you'd have missed it
[05:05] <Keybuk> yeah I just forgot that
[05:05] <iwj> libblkid doesn't use any of the device-creation stuff on libdevmapper, surely ?
[05:05] <cjwatson> iwj: I think it's linked against it ...
[05:05] <iwj> Which is what the dependency on udev is for (to stop the udev rendezvous not working)
[05:05] <Mithrandir> can it be turned into a breaks instead?
[05:05] <iwj> So perhaps libdevmapper -Recommends-> udev instead ?
[05:06] <cjwatson> so it doesn't have a choice unless the dmsetup -> udev Depends arc can be dropped somehow
[05:06] <Keybuk> hmm
[05:06] <iwj> I assume it's libdevmapper -> udev not dmsetup -> udev directly, surely ?
[05:06] <cjwatson> iwj: nope, it's dmsetup
[05:06] <iwj> How bizarre.
[05:06] <Keybuk> that's probably wrong :)
[05:06] <iwj> Yes :-).
[05:07] <Keybuk> it should be a breaks on udev
[05:07] <Mithrandir> 17:05 < Mithrandir> can it be turned into a breaks instead?
[05:07] <Mithrandir> :-P
[05:07] <iwj> Although I thought I'd made the libdevmapper rendezvous stuff only happen if /dev was udev.
[05:07] <cjwatson> so, either fix this dependency graph or make module-init-tools tolerate being dpkg -x'ed - preferably both
[05:07] <Keybuk> [ Uploading job devmapper_1.02.08-1ubuntu7_source
[05:07] <Keybuk>  devmapper_1.02.08-1ubuntu7.dsc 0.7 kB, ok (1 s, 0.73 kB/s)
[05:07] <Keybuk>  devmapper_1.02.08-1ubuntu7.diff.gz 48.2 kB, ok (0 s, 48.24 kB/s)
[05:07] <Keybuk>  devmapper_1.02.08-1ubuntu7_source.changes 1.2 kB, ok (0 s, 1.24 kB/s) ] 
[05:07] <pitti> dholbach: http://daniel.holba.ch/bugs/ FTW! *hug*
[05:07] <iwj> Keybuk: Oh, you meant Breaks.
[05:07] <iwj> cjwatson: Right.
[05:07] <iwj> The latter I think is debootstrap's bug, or do you disagree ?
[05:08] <cjwatson> I disagree; module-init-tools should tolerate it itself if at all possible
[05:08] <cjwatson> if absolutely necessary it could be special-cased in debootstrap but I'd much rather not
[05:08] <iwj> OK.  I think I know how to do that although it's a bit freaky.
[05:08] <dholbach> pitti: i hope everybody starts contributing their clue files now :)
[05:09] <cjwatson> I realise debootstrap's arrangement is odd although I counter that getting a base system to exist at all fundamentally involves oddness :-)
[05:09] <iwj> cjwatson: Fair point.
[05:10] <cjwatson> freaky> something like diverting it only if we think the file belonged to modutils?
[05:10] <cjwatson> *oww*
[05:10] <iwj> cjwatson: Yes.  Otherwise we trash it.  Perhaps we look at the file to see if it looks like one of ours.
[05:10] <iwj> Put a magic comment in it for that purpose.
[05:10] <Keybuk> [ Uploading job udev_108-0ubuntu2_source
[05:10] <Keybuk>  udev_108-0ubuntu2.dsc 0.7 kB, ok (0 s, 0.66 kB/s)
[05:10] <Keybuk>  udev_108-0ubuntu2.diff.gz 53.8 kB, ok (0 s, 53.78 kB/s)
[05:10] <Keybuk>  udev_108-0ubuntu2_source.changes 1.3 kB, ok (0 s, 1.34 kB/s) ] 
[05:11] <cjwatson> why does it divert it anyway if it's just going to exec the old one?
[05:11] <Keybuk> those two should sort it out
[05:11] <cjwatson> oh, it's just making sure that update-modules exists even if modutils isn't installed
[05:11] <asac> pitti: yes ... should be fixed now. that's why I asked you about dbgsym generation process, so i could verify :)
[05:11] <iwj> cjwatson: So that if the old one doesn't exist you get `true' rather than ENOENT.
[05:11] <Keybuk> cjwatson: right, maintainer scripts call it
[05:11] <cjwatson> yeah
[05:11] <cjwatson> argh, evil ancient workarounds
[05:11] <iwj> Why do they call it with absolute path ?
[05:12] <cjwatson> if stuff had done 'if which blah >/dev/null; then ...' then we wouldn't have this problem
[05:12] <iwj> Move it to /usr/sbin :-).
[05:12] <Keybuk> we could strip all the evil diversion out, since we don't have modutils anyway
[05:12] <iwj> Keybuk: Oh, don't we ?  I see ...
[05:12] <cjwatson> maybe which was less reliable back then and we didn't want to do if [ -x /absolute/path ] 
[05:12] <cjwatson> modutils is in main
[05:12] <cjwatson> something must depend on it
[05:12] <asac> who maintains the latest and greatest greasemonkey scripts for lp beta?
[05:12] <cjwatson> it's not seeded
[05:13] <Keybuk> cjwatson: yeah, I keep eradicating those, and they keep coming back
[05:13] <cjwatson> so we can't break the diversions because people have modutils installed
[05:13] <iwj> Oh, FFS, how do you tell whether /boot/vmlinuz-2.6.19-4-generic is (a) a normal kernel (b) a Xen kernel (c) something else ?
[05:14] <iwj> (a) shows up in `file' as `Linux kernel x86' etc.
[05:14] <cjwatson> nvidia-kernel-common Depends: modutils | module-init-tools
[05:14] <iwj> (b) shows up as `gzip compressed data' which when you decompress it is `ELF 32-bit LSB executable, Intel 80386'
[05:14] <cjwatson> as does laptop-net
[05:14] <cjwatson> and modconf
[05:14] <cjwatson> nvidia-kernel-common is probably what's causing it to be in main though
[05:15] <Mithrandir> nothing depends on modutils without an alternative on module-init-tools
[05:15] <cjwatson> Mithrandir: indeed, but sometimes germinate gets a bit confused by inconsistent alternates
[05:15] <Mithrandir> and since it's 2.4-only, we can just remove it.
[05:15] <fabbione> Keybuk: i guess those 2 uploads will fix my problem? :)
[05:15] <Keybuk> fabbione: which?
[05:15] <fabbione> Keybuk: udev and devmapper
[05:15] <Keybuk> fabbione: nope, nothing to do with your problem
[05:16] <ogra> fabbione, that fixes debootstrap
[05:16] <fabbione> Keybuk: ok :(
[05:16] <cjwatson> anyway, I maintain that there's a decent chance that people will have it installed since it's in main, and even if we remove it that doesn't mean we get to delete maintainer script code which causes it not to break
[05:16] <Keybuk> fabbione: I'm waiting for the further information I asked for from you before I can debug your problem
[05:16] <fabbione> Keybuk: i did send you all the info you asked?!?
[05:16] <Keybuk> fabbione: you only send me your udev.log
[05:16] <fabbione> Keybuk: what's missing?
[05:17] <Keybuk> fabbione: still waiting for the output of running the mdadm-raid and lvm scripts by hand with sh -x, noting where things go wrong
[05:17] <fabbione> Keybuk: nope.. i did reply to the mail too
[05:17] <fabbione> Keybuk: ah ok.. sure.. i can add those but i know where it hangs
[05:17] <fabbione> and i did add the strace of it
[05:17] <Keybuk> I don't :)
[05:17] <Mithrandir> cjwatson: fwiw, I have it installed. :-P
[05:17] <Keybuk> err, where's the strace?
[05:17] <iwj> Aha!  A __xen_guest section in the ELF.
[05:18] <fabbione> Keybuk: in the first email
[05:19] <Keybuk> "VG fucking" :)
[05:19] <fabbione> Keybuk: yeah that one
[05:19] <fabbione> at least i am sure it's unique :)
[05:19] <Keybuk> the bit I can't understand is how you have LVM-on-devmapper
[05:20] <Keybuk> what are those /dev/mapper/hda2 and /dev/mapper/hdb1 things?
[05:20] <ogra> 
[05:20] <Keybuk> where are those created/what by?
[05:20] <fabbione> Keybuk: i have no idea... i just upgrade on this box.. how can i check?
[05:20] <Mithrandir> Keybuk: evms
[05:20] <Keybuk> you have evms installed?
[05:20] <fabbione> probably yes
[05:20] <Keybuk> what happens if you remove evms? :p
[05:20] <Mithrandir> (with a 87.3% certainity)
[05:21] <fabbione> Keybuk: it's installed...
[05:21] <Keybuk> (purge it, in fact)
[05:21] <Keybuk> it shouldn't be depended on by this stack, since I don't have it installed
[05:21] <fabbione> Keybuk: i can try to remove it but lvm runs before evms on this machine
[05:21] <fabbione> ok i can try... 
[05:21] <Keybuk> evms is part-installed in the initramfs
[05:22] <Keybuk> that might explain where your /dev/mapper/lvm2|vgname|lvname things are coming from
[05:22] <fabbione> just keep in mind that everybody upgrading from warty up to dapper will have it installed by default
[05:22] <Mithrandir> Keybuk: yes, it does.  (I have lvm2|xoog1|home in /dev/mapper)
[05:22] <Keybuk> iiinteresting
[05:24] <fabbione> Keybuk: ok.. rebooting now.. if you don't see me back in 20 minutes i suggest start sending patches this way :PPPP
[05:24] <Keybuk>     EVMS is able to manage block devices ordinarily managed by both LVM and MDADM, for this reason these two services will be disabled if EVMS is installed, ideally we'd like to prevent them from being installed at all, but this has consequences for upgrades from when we used to install evms by default.
[05:24] <Keybuk> "we didn't do this bit"
[05:25] <Keybuk> and I suspect I can already see the bug
[05:26] <Keybuk> (assuming this isn't a total evms vs. world fuckage)
[05:30] <Keybuk> add -> add|change
[05:30] <Keybuk> fabbione: it booted?
[05:30] <fabbione> Keybuk: yes it booted and no hangs on the scripts
[05:31] <fabbione> 2 bugs then
[05:31] <fabbione> 1) evms blocks
[05:31] <fabbione> 2) evms must update initramfs on purge
[05:31] <Keybuk> ok
[05:31] <Keybuk> I think I have a fix
[05:31] <Keybuk> could you install evms again for me
[05:31] <fabbione> does it require me to reboot again?
[05:32] <fabbione> (installing)
[05:32] <Keybuk> yes
[05:32] <Keybuk> once installed, edit /etc/udev/rules.d/70-evms.rules
[05:33] <Keybuk> change both instances of ACTION=="add" to ACTION=="add|change"
[05:33] <Keybuk> update-initramfs -u
[05:33] <Keybuk> then try rebooting
[05:33] <fabbione> both the ACTIONS ?
[05:33] <Keybuk> yes
[05:33] <Keybuk> basically run evms_activate whenever a devmapper (or other block) device gets updated
[05:33] <fabbione> SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_USAGE}=="raid", GOTO="evms_activate_do"
[05:33] <fabbione> SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="dm-*", GOTO="evms_activate_do"
[05:33] <fabbione> GOTO="evms_activate_end"
[05:33] <fabbione> LABEL="evms_activate_do"
[05:33] <fabbione> RUN+="watershed /sbin/evms_activate"
[05:33] <fabbione> LABEL="evms_activate_end"
[05:34] <Keybuk> yup
[05:34] <Keybuk> try with that
[05:34] <fabbione> is the call to watershed ok?
[05:34] <Keybuk> looks ok, iwj?
[05:34] <fabbione> or does it need fancy paramentes?
[05:34] <Keybuk> not that I know of
[05:34] <Keybuk> that's fine
[05:34] <fabbione> ok.. brb
[05:34] <Keybuk> iwj's manpage is helpful (pointed look) :p
[05:37] <iwj> Yes, should be fine.
[05:37] <iwj> The usage message ought to be sufficient.  Sorry for the lack of manpage ...
[05:37] <iwj> And yes, you're supposed to be able to just wrap things up with watershed.
[05:40] <Keybuk> if this doesn't work, then evms must be doing rude things to devmapper
[05:40] <Keybuk> and asking it to create/wait for devices that are named differently to what it tells devmapper
[05:40] <Keybuk> (actually, that may not work anyway, because udev will "sanify" the names, but it'll give us a good start)
[05:41] <vciaglia> hello
[05:46] <fabbione> Keybuk: better but not good enough.
[05:46] <Keybuk> fabbione: what happened this time?
[05:46] <fabbione> Keybuk: with that change to the rule initramfs gets to mount / and that's good
[05:46] <Keybuk> ok, still hangs during boot though?
[05:46] <fabbione> Keybuk: as soon as mdadm init script triggers udev events -> BAM
[05:47] <Keybuk> it apparently only hangs for 3-9 minutes per LV, so it's not eternal
[05:47] <Keybuk> anyway, I think I know why
[05:47] <Keybuk> did you manage to boot with evms installed?
[05:47] <Keybuk> or did you go back to LNG without it?
[05:47] <fabbione> i had to purge it to reboot
[05:47] <Keybuk> ok
[05:48] <Keybuk> so you're in a clean no-evms system now?
[05:48] <fabbione> it's just a matter of time.. 9 minutes for lv on my system it means about 1h:30m per boot :)
[05:48] <Keybuk> heh
[05:48] <fabbione> Keybuk: yes.. i am without now
[05:48] <Keybuk> can you install evms again, and make the add -> add|change modification to 70-evms.rules again
[05:48] <Keybuk> no need to reboot for this test though
[05:48] <Keybuk> root fs mounting = good
[05:48] <Keybuk> I think I know what is causing the hang
[05:48] <fabbione> Keybuk: not right now.. i need to feed my son and getting ready for a conf call in 1 h
[05:49] <fabbione> it will need to wait a little bit.. but later i can do it for sure
[05:49] <Keybuk> ok, when's good for you?
[05:49] <fabbione> after the conf call.. that means around 6:30pm your time
[05:49] <fabbione> or Mithrandir can probably help you there too. he even uses evms :)
[05:49] <bluefoxicy> Wow.  One of my bugs went from NeedsInfo => Rejected => Confirmed over the course of 2 days.
[05:49] <fabbione> i don't.. it was just installed there since.. hmmmm sid -> warty ?!?
[05:49] <Keybuk> bluefoxicy: which?
[05:50] <Keybuk> Mithrandir: do you use LVM as well?
[05:50] <bluefoxicy> Keybuk: https://bugs.launchpad.net/bugs/66820
[05:50] <ubotu> Malone bug 66820 in linux-source-2.6.15 "nobody cares about via interrupt" [Undecided,Needs info]  
[05:50] <Keybuk> heh
[05:50] <fabbione> gotta run now...
[05:50] <fabbione> bbl
[05:50] <bluefoxicy> oh, okay..  Change in linux (upstream) I see.
[05:50] <bluefoxicy> upstream rejected, then confirmed it.  (I'm getting e-mails about this somehow)
[05:51] <bluefoxicy> by the by, there should be a message center in Launchpad, so it stops spamming my e-mail.  Imagine having about 30 active bugs, and every day you have 12 messages coming down your pipe.
[05:51] <bluefoxicy> I can't imagine what the developers must face.  5000 messages per day?
[05:53] <pitti> bluefoxicy: I feel like that, yes ;)
[05:53] <pitti> bluefoxicy: message center is called 'bug views' ;)
[05:56] <bluefoxicy> pitti:  ah thx
[06:03] <TomaszD> has feisty-changes list gone off the record?
[06:04] <cjwatson> TomaszD: the list archiving machine is having trouble keeping up
[06:04] <TomaszD> ok
[06:12] <yacoob> is there a way to find out for a closed bug on launchpad which package version brought in the fix?
[06:12] <Keybuk> yacoob: sadly not yet, that is being worked on so we can close bugs with the upload and thus record that information
[06:13] <yacoob> mmm, good.
[06:13] <_ion> I thought that feature already works.
[06:13] <yacoob> (debian does that? by scaning package changelog, no?)
[06:13] <_ion> I probably thought wrong, then.
[06:13] <Keybuk> yacoob: exactly, we're going to be doing it a similar way
[06:13] <Keybuk> we've already made the necessary modifications to dpkg, and already set a policy for the changelog format
[06:13] <Keybuk> so many uploads actually already include the list of bug numbers to be closed
[06:14] <Keybuk> but the LP part isn't yet finished (the LP team have been hard at work preparing for the 1.0 Beta)
[06:14] <_ion> Alright.
[06:14] <yacoob> why it wasn't just taken from debian? :)
[06:14] <Keybuk> yacoob: because Debian use a different bug tracking system from us
[06:14] <Keybuk> and we upload Debian changes as well
[06:14] <yacoob> Righto.
[06:14] <Keybuk> so uploads using exactly the same format would've closed randomly unassociated bugs
[06:15] <Keybuk> (since they would be from Debian changelog entries, thus referring to Debian bug numbers)
[06:16] <_ion> "rituals", interesting way to put it. :-)
[06:17] <yacoob> _ion, things that are done the way they're done because... everyone did those that way :D
[06:17] <Keybuk> ours are mostly they're done that way because nobody came up with something better at the time
[06:18] <yacoob> Keybuk, any url you can point me to, for above?
[06:18] <Keybuk> wiki.ubuntu.com/UbuntuDevelopment
[06:20] <yacoob> thanks.
[06:21] <siretart> Keybuk: okay, just returned home, now following your instructions
[06:26] <Mithrandir> Keybuk: sorry, got distracted; no, I don't use LVM on this machine, just evms
[06:26] <Mithrandir> and lvm2 isn't installed either
[06:28] <siretart> Mithrandir: would you consider evms more mature than lvm2?
[06:28] <Keybuk> Mithrandir: ok
[06:28] <Mithrandir> siretart: I haven't used lvm2, so I can't comment on that.
[06:29] <siretart> i see
[06:31] <siretart> Keybuk: manually exec'ing /sbin/init shows the same symptopms (bug #102089)
[06:31] <ubotu> Malone bug 102089 in devmapper "latest devmapper upload breaks booting" [High,Needs info]  https://launchpad.net/bugs/102089
[06:31] <siretart> Keybuk: what whas the rune again to make upstart boot into single user mode? booting with option 'single'?
[06:34] <Keybuk> siretart: yes
[06:34] <Keybuk> (busy right now, will look into these problems in a bit)
[06:34] <siretart> Keybuk: no problem
[06:35] <siretart> I'm glad I've caught you  at all
[06:35] <Keybuk> siretart: do you have evms installed?
[06:36] <siretart> Keybuk: booting with 'single' shows the same symptoms
[06:36] <zyga> hello
[06:36] <siretart> Keybuk: evms: yes, it is installed
[06:36] <siretart> shall I remove it?
[06:36] <Keybuk> siretart: try removing it, yes
[06:37] <siretart> do I need to rebuild the initramfs?
[06:37] <Keybuk> yes
[06:38] <siretart> k
[06:39] <siretart> huch? "filesystem doesn't have /sbin/init?!
[06:40] <siretart> but it does have!
[06:40] <siretart> hmm
[06:40] <siretart> seems my initramfs is fucked up. I get a Usage error message from modprobe
[06:42] <keescook> are packages in main allowed to Recommend packages in universe?
[06:42] <seb128> yes
[06:43] <siretart> keescook: we already have some
[06:43] <keescook> seb128, siretart: okay, thanks.  Just wanted to be sure.  :)
[06:43] <seb128> keescook: that might change when we do the "install Recommends by default" though
[06:43] <siretart> seb128: I hope it doesn't
[06:44] <keescook> seb128: the specific issue is that an Inkscape python extension needs python-numpy.  I figured the best course was to add it to Recommends
[06:44] <seb128> siretart: why?
[06:44] <seb128> siretart: change it to Suggests if it's an universe package
[06:44] <seb128> siretart: or get the recommended package promoted
[06:44] <siretart> seb128: xine is nearly useless without libxine1-ffmpeg, but it must not depend on it
[06:44] <seb128> siretart: we have no real reason to recommand a package we don't support officially
[06:45] <seb128> well, you need easy codec installation ;)
[06:45] <siretart> seb128: we do: it must not go on the livecd, but having it on installed systems is really recommended
[06:45] <siretart> seb128: aaah, then I have you as volunteer to implement  it. Thanks! :)
[06:45] <seb128> siretart: no
[06:46] <seb128> siretart: well, if it's to main it can be recommended, if it's not then we don't support it and we should not recommend it anyway
[06:46] <seb128> yeah, patents suck :/
[06:46] <siretart> seb128: true, libxine1-ffmpeg is indeed in main, so that's a non-issue here. you're right
[06:47] <siretart> perhaps we need some switch in apt for that: install recommends only from main by default or something
[06:47] <siretart> and optionally recommended packages from universe as well
[06:51] <LaserJock> keescook: I'll probably be interested in promoting python-numpy and python-scipy for Feisty+1
[06:51] <siretart> Keybuk: update: removing evms seems to 'cure' it
[06:51] <kofler> Has anyone experienced issues with the i810 on ViewSonic monitors before? If my case ends up being compelling enough, a patch to the kernel modules package may be in store.
[06:51] <keescook> LaserJock: cool.
[06:52] <siretart> Keybuk: somehow I managed to produce a fucked initramfs, removing some backup files (*.~ and *.dpkg-old) and regenerating it fixed that for me
[06:53] <kofler> If I start GDM up, login with resolution at 1440x900, then logout, GDM produces an effective I can only label as "radioactive."
[06:54] <kofler> Er, no sorry, that's with the intel drive. With the i810, it doesn't scale the resolution out to the full width of the monitor.
[06:54] <kofler> driver even.
[06:56] <Keybuk> siretart: ok, can you reinstall initramfs
[06:56] <Keybuk> errr
[06:56] <Keybuk> EVMS
[06:56] <Keybuk> reinstall that
[06:57] <Keybuk> modify 70-evms.rules to change ACTION=="add" to add|change
[06:57] <Keybuk> exit 0 in the two problematic init scripts
[06:57] <Keybuk> and then reboot
[06:57] <Keybuk> and see how far that gets
[06:57] <siretart> you mean exit 0; in mdadm-raid?
[06:58] <Keybuk> yeah
[06:58] <Keybuk> just at the top so it doesn't get run
[06:59] <siretart> and you mean both lines with ACTION=="add", right?
[06:59] <Keybuk> yup
[07:00] <siretart> rebooting
[07:02] <siretart> oh nice, now it seem to hang at "Starting Enterprise Volume Management System"
[07:02] <Keybuk> heh, exit 0 that one too
[07:02] <siretart> ok, killing it with SysRq-i
[07:02] <Keybuk> (I think I know why they hang - I just need you to get to the end of the boot to confirm my hypothesis)
[07:03] <siretart> so I get a rootshell at least
[07:03] <siretart> rebooting
[07:04] <mvo> ogra: can you please check #94712 ? I assume you have a current edubuntu addon-cd?
[07:05] <siretart> Keybuk: ok, now it hangs somewhere after fsck.
[07:05] <siretart> Keybuk: but I've seen this before
[07:05] <siretart> any idea how to figure out what's actually blocking here?
[07:08] <siretart> hm. after some timeout, I get the well known message: "Rendevouz with udev timed out for '...'; stat failed: No such file or directory
[07:08] <siretart> killing it with SysRq-i
[07:09] <Keybuk> siretart: please get to the end of the boot and have a shell
[07:09] <Keybuk> anywhere in the boot with a shell
[07:09] <siretart> Keybuk: by pressing SysRq-i I kill rcS, but the boot procedure continues
[07:09] <siretart> Keybuk: not all filesystems have been mounted, but it is enough to get my gdm started
[07:10] <Keybuk> ok
[07:10] <siretart> Keybuk: read: I do have a rootshell now
[07:10] <Keybuk> ok
[07:10] <Keybuk> exxxxcellent
[07:10] <Keybuk> can you look for /dev/mapper/lvm2* for me
[07:10] <siretart> I suspect the cryptdisks init script are blocking here
[07:10] <Keybuk> do you have any of those?
[07:10] <siretart> has, there are several /dev/mapper/lvm2_* devices there
[07:10] <Keybuk> do you have lots of things that look like /dev/mapper/lvm2_vgname_lvname
[07:10] <Keybuk> (note _s)
[07:11] <siretart> yes, I see e.g. my root device as /dev/mapper/lvm2_hades_stripe_ubunturoot
[07:11] <Keybuk> ok
[07:11] <Keybuk> now, looking at those Rendezvous error messages
[07:11] <Keybuk> do those refer to the same devices BUT with | instead of _ ?
[07:12] <Keybuk> ie. /dev/mapper/lvm2|hades|stripe|ubunturoot
[07:12] <siretart> gnarf, it just scrolled away :/
[07:13] <siretart> and nothing to see in /var/log/boot :
[07:13] <siretart> :/
[07:13] <Keybuk> ok
[07:13] <siretart> need to reboot and retimeout
[07:13] <Keybuk> can you check that for me?
[07:13] <siretart> to be sure, I'm disabling the cryptsetup initscripts and reboot, okay?
[07:16] <Drakeson> I want a patched/enhanced dpkg, apt-utils to manage local stuff ($HOME/bin, $HOME/lib, $HOME/share). I don't like ruby gems, not evan cpan ...
[07:16] <Drakeson> (this was a wish actually)
[07:17] <Treenaks> Drakeson: there's cpanplus, that can create debs..
[07:17] <Drakeson> suggested in debian-devel, and found out there is lack of man-power
[07:17] <Drakeson> what about a dpkg based one?
[07:17] <Drakeson> dpkg is already very good
[07:17] <Keybuk> siretart: sure
[07:18] <Keybuk> siretart: just want to know whether the timeout errors are due to lvm2|...|...| where you have _ instead
[07:18] <siretart> Keybuk: timeouting now...
[07:18] <siretart> ok
[07:18] <siretart> is there some way to lower the timeout?
[07:18] <siretart> it seems rather high to me
[07:19] <Drakeson> imagine if that happens... I can build, install and test packages locally (dpkg --prefix=$HOME), and then install them in my system (dpkg --prefix=/usr)
[07:19] <LaserJock> Drakeson: if Debian has a lack of man-power I'm not sure you'll find more in Ubuntu
[07:20] <Drakeson> and then I can finally forget about all the lousy package managers (gems, ...)
[07:21] <Drakeson> LaserJock: maybe my imagination, but I thought ubuntu has some mechanisms to develop special stuff more quickly
[07:22] <Drakeson> e.g. polishing the desktop
[07:22] <Drakeson> maybe this is not important enough...
[07:22] <kofler> Anyone heard of such a phenomenon before where GDM goes "radioactive"?
[07:22] <LaserJock> Drakeson: right, but those resources are going into polishing the desktop, etc. not rewriting dpkg
[07:24] <Drakeson> actually not rewriting but just patching. if I could somehow fakeroot apt and feed it my custom sources, I could provide some repos for various locally installed packages
[07:24] <siretart> hm. now it hangs for too long without timeout :/
[07:25] <LaserJock> Drakeson: I don't think there's really a common usecase that can't be handled by existing tools
[07:27] <Drakeson> to me a local package manager is as important as cvs/svn/git/... , of course I am only a single user, but I can see many uses in many many applications for a locally managed repos. Starting from monthly repos for wallpapers, themes, ..., to speciall purpose software packages
[07:28] <LaserJock> Drakeson: well you can easily do locally managed repos
[07:28] <LaserJock> with existing tools
[07:29] <cjwatson> Drakeson: that's been discussed in Debian, but I'm afraid making that work would involve changes to a very large number of packages, and I just don't think there's enough impetus to make it happen
[07:29] <siretart> Keybuk: wow. on my 2nd boot with just disabling the cryptsetup scripts, now I have /dev/mapper/lvm2|hades_stripe|.. devices
[07:29] <siretart> Keybuk: and most of my LVs are missing
[07:29] <cjwatson> doing it in Ubuntu would involve us maintaining a pretty huge diff from Debian, which we try to do only when it's a very big win for us
[07:29] <siretart> rebooting again to see if that's reproducible
[07:29] <Drakeson> LaserJock: by locally I mean as a non-root user
[07:30] <cjwatson> Drakeson: packages are built with many expectations about paths, and in general are not relocatable
[07:30] <cjwatson> dpkg is not the real problem here
[07:31] <cjwatson> it's more 10000 packages each with their own different and exciting absolute path assumptions
[07:31] <Drakeson> cjwatson: but user-mode could discard many of the expectations for stuff like e.g. $HOME/shar/emacs/lisp stuff
[07:31] <siretart> Drakeson: many packages's maintainer scripts (postinst, prerm, etc) expect to be run as root and have assumptions about the exact location of shipped binaries
[07:31] <cjwatson> Drakeson: it cannot be done automatically, and would involve experts in each package going through it with a fine tooth-comb
[07:31] <cjwatson> that sort of thing is actually better tried in Debian than here
[07:32] <Drakeson> are we talking about relocating an existing package?
[07:32] <cjwatson> but as I say, it has come up before, and it's basically come down to too much effort for not enough gain
[07:32] <siretart> perhaps someone could invent *.rdeps, (relocatable debs), which have like normal debs, but can be relocated by a future dpkg
[07:33] <Drakeson> relocating already built packages is not my main point.
[07:33] <mvo> Drakeson: something like "klik" might actually be a better option to spend resources on
[07:33] <cjwatson> source packages also have extensive assumptions
[07:33] <cjwatson> siretart: rpm has a Relocatable: yes flag or similar, but that still leaves changing all the packages
[07:33] <LaserJock> I think zeroinstall is kinda close too
[07:33] <cyt> I am curious why my friends use Debian for a long time think Ubunut is bug-prone than Debian?
[07:33] <Drakeson> mvo: klik is just another example
[07:34] <cyt> Is that ture, or any misunderstanding?
[07:34] <siretart> cjwatson: yes. at least, this becomes an opt-in rather than an opt-out decision
[07:34] <Drakeson> I already know there are many other projects and package-managers out there in the wild.
[07:34] <cjwatson> personally, I honestly don't think it's worth the introduction of bugs that the facility would imply
[07:35] <Drakeson> but dpkg is very strong in my opinion.
[07:35] <Drakeson> well, let me focus on my first use-case:
[07:35] <Drakeson> I want to manage stuff like matlab toolboxes, octave pkgs, emacs lisp pkgs, gems, ...
[07:36] <Drakeson> they all have the same concepts
[07:36] <cjwatson> we understand your request, but explaining them further here will not cause (a) manpower to magically appear or (b) the potential for bugs due to introducing this facility and hacking up loads of packages to be able to use it to go away
[07:36] <cjwatson> s/them/it/
[07:36] <cjwatson> I'm afraid this is just an extremely long-term project and not a quick hack at all
[07:37] <cjwatson> and TBH I would just recommend using a test box and then installing them as root
[07:37] <cjwatson> given path assumptions strewn throughout many projects, test-installing in $HOME is not going to be very reliable anyway
[07:37] <Drakeson> well, the problem is that some packages are not even meant to be put in /usr
[07:37] <cjwatson> test hardware, or even a virtual machine, is pretty cheap these days
[07:37] <Drakeson> thanks for the clear answer ;)
[07:38] <keescook> siretart: none of my LVM starts up any more, even if I do break=mount
[07:39] <keescook> on the other hand, the md is okay.  :)
[07:39] <siretart> keescook: huch?
[07:39] <keescook> To boot these days, I'm doing   break=mount, waiting for it to settle, then "lvm vgchange -a y" followed by "exit" when it settles again
[07:39] <siretart> keescook: yes, this was the situation for me before yesterday
[07:41] <siretart> Keybuk: can I modify /etc/event.d/rcS somehow so I can see which scripts it is actually executing?
[07:41] <siretart> Keybuk: I was thinking about replacing the "exec /etc/init.d/rcS" line with "exec sh -x /etc/init.d/rcS"
[07:42] <Drakeson> cjwatson: just let me ask your opinion, what do you think of a (small) project to fork dpkg (and discard/remove many of its capabilities) or maybe patch it and build dpkg-local to manage fancy stuff like user wallpapers, small perl/ruby/... packages, ... ?
[07:43] <siretart> Drakeson: did you already have a look at zeroinstall and/or klik? - aren't they doing what you have in mind?
[07:44] <cjwatson> Drakeson: it's free software, you can do whatever you like
[07:45] <cjwatson> I'm just saying I think you will find it difficult, that's all
[07:47] <Drakeson> cjwatson: ok, thanks a lot.
[07:47] <Keybuk> siretart: yeah, /etc/init.d/rc has a startup() function
[07:47] <Keybuk> siretart: the | vs. _ thing is caused by udev
[07:47] <Keybuk> udev makes the devices but "sanifies" their names
[07:47] <Keybuk> http://people.ubuntu.com/~scott/packages
[07:47] <Keybuk> that has a udev you should build and install
[07:47] <siretart> k
[07:47] <Keybuk> and then modify 25-dmsetup.rules and add OPTIONS+="all_partitions" into it before the PROGRAM= bit
[07:48] <Keybuk> uh
[07:48] <Keybuk> no
[07:48] <Keybuk> OPTIONS+="no_replace"
[07:50] <siretart> Keybuk: ok. btw, editing /etc/event.d/rcS to say 'exec /bin/sh -x /etc/init.d/rcS' didn't show the bash traces :/
[07:52] <siretart> Keybuk: I added that OPTIONS+="no_replace", directly before the only line ACTION=="add|change", PROGRAM="..." bit, correct?
[07:53] <iwj> Drakeson: You might get some mileage out of a bizarre combination of fakeroot and --admindir etc. options, but please don't come running to me when you can't get it to work.
[07:53] <Keybuk> ACTION=="add|change", OPTIONS+="no_replace", PROGRAM="/sbin/devmap_name %M %m", \
[07:53] <Keybuk>                 NAME="mapper/$result", GOTO="dmsetup_end"
[07:53] <Keybuk> ^ should look like that
[07:53] <Treenaks> *growl* panel crashed _again_
[07:53] <siretart> ok. that's how it looks here
[07:53] <siretart> anything else?
[07:53] <Keybuk> nope
[07:53] <Keybuk> update initramfs and try again
[07:53] <siretart> rebooting
[07:54] <Drakeson> iwj: thanks
[07:55] <siretart> Keybuk: wow. now this is much better. it doesn't block anymore
[07:55] <siretart> hald takes ages, but that's another story (and I've noticed that before)
[07:56] <siretart> Keybuk: I'm reenabling the cryptsetup scripts and evms, okay?
[07:56] <Keybuk> ok
[07:56] <Keybuk> try it with that
[07:56] <tkamppeter_> pitti, doko, anyone there?
[07:58] <siretart> Keybuk: happy with enabled evms and cryptsetup scripts, now reenabling crypted swap
[07:59] <Adri2000> Keybuk: can you please take a look at http://librarian.launchpad.net/7130514/buildlog_ubuntu-feisty-i386.filezilla_3.0.0%7Ebeta7-0ubuntu1_CHROOTWAIT.txt.gz ?
[07:59] <tkamppeter_> who is responsible for dmsetup?
[08:00] <siretart> tkamppeter_: better don't ask ;)
[08:00] <tkamppeter_> sirestart, why?
[08:00] <siretart> tkamppeter_: I'm fighting with it together with Keybuk and iwj for some days if not weeks!
[08:01] <siretart> Keybuk: all happy now. seems that the test udev package with the new dmsetup udev rule does the trick
[08:01] <Keybuk> Adri2000: any particular reason?
[08:01] <Keybuk> missing depends
[08:02] <tkamppeter_> I have a problem with it. Someone (doko or Pitti) has uploaded HPLIP 1.7.3 for me and the build server cannot build it as it chokes on installing dmsetup for the chroot. See http://librarian.launchpad.net/7130499/buildlog_ubuntu-feisty-i386.hplip_1.7.3-0ubuntu1_CHROOTWAIT.txt.gz, In the end there is 
[08:02] <tkamppeter_> Setting up dmsetup (1.02.08-1ubuntu7) ...
[08:02] <tkamppeter_> /var/lib/dpkg/info/dmsetup.postinst: line 4: update-initramfs: command not found
[08:02] <Keybuk> siretart: everything works, mdadm-on-lvm crypted-swap-on-md ?
[08:02] <siretart> btw, does anyone now why at the end of feisty boot, I get a "HOME not defined in environment!" why?
[08:02] <siretart> Keybuk: yepp!
[08:02] <Keybuk> tkamppeter_: err, don't you have initramfs-tools installed?
[08:02] <Adri2000> Keybuk: missing depends in dmsetup, right? you are the last uploader
[08:03] <siretart> Keybuk: err, it's the other way round: lvm-on-mdadm rather than mdadm-on-lvm
[08:03] <Keybuk> siretart: right
[08:03] <Keybuk> what's your cryptroot on?
[08:03] <Keybuk> or cryptswap?
[08:03] <siretart> I don't have cryptroot, only cryptswap
[08:03] <tkamppeter_> keybuk, if dmsetup tries to use it it must depoend on it and then the build server should install it automatically into the chroot.
[08:04] <Keybuk> err
[08:04] <Keybuk> oh bugger
[08:04] <siretart> crpytroot is horribly broken in ubuntu, I'm sure it was already broken in edgy, not sure about dapper
[08:04] <Keybuk> we can't depend dmsetup -> initramfs-tools
[08:04] <Keybuk> because that'll reintroduce the module-init-tools problem again
[08:04] <Keybuk> cjwatson: HELP!
[08:04] <siretart> cryptswap is pretty easy to setup: just install cryptsetup, create a /etc/crypttab, and add swap on /dev/mapper/cswap in /etc/fstab. 
[08:05] <tkamppeter_> So the buold servers are broken now, shortly before main freeze?
[08:06] <tkamppeter_> Please fix that ASAP, there will be tons of uploads which do not come through.
[08:22] <iwj> Keybuk: The mistake is mine; the postinst should do that only if type update-initramfs succeeds.
[08:22] <iwj> (Sorry about the delay noticing this here.)
[08:24] <tkamppeter> iwj, can you fix this to revive the build servers, amd64 and i386 are broken, ia64 seems not to be affected.
[08:24] <tkamppeter> iwj, see https://launchpad.net/+builds/+build/316099 and https://launchpad.net/+builds/+build/316098.
[08:26] <tkamppeter> What happens with the failed builds of HPLIP, will they be retried automatically as soon as the build servers get fixed?
[08:30] <Keybuk> tkamppeter: no, a buildd admin has to retry them
[08:31] <Adri2000> Keybuk: then please retry filezilla builds as soon as it's fixed, please :)
[08:32] <Mithrandir> Keybuk: except that the chroots seem slightly busted ATM; I'll handle it.
[08:33] <Keybuk> Mithrandir: thanks
[08:34] <jbaloul> hi all
[08:34] <jbaloul> i am trying to save stream in kaffeine and it seems to be brocken since this last upgrade
[08:35] <jbaloul> used to work on dapper, but doesn't work neither on edgy nor feisty
[08:35] <Mithrandir> Keybuk: making dmsetup call update-initramfs isn't the best idea.
[08:36] <Mithrandir> at least not without making initramfs-tools priority: required and adding the necessary dependency.
[08:37] <Mithrandir> Keybuk: ^ ; do you want to look at that?
[08:38] <Keybuk> Mithrandir: iwj is already making it call update-initramfs only if that exists
[08:38] <Keybuk> Mithrandir: can't make initramfs-tools required, since it depends on module-init-tools, which debootstrap hates
[08:38] <Mithrandir> yup, makes sense.
[08:39] <Mithrandir> do you know when he's going to upload it?
[08:39] <keescook> jbaloul: sorry, this isn't a support channel.  Please use #ubuntu, #ubuntu-bugs, or file a bug report on launchpad.net.
[08:39] <Keybuk> nope
[08:40] <jbaloul> ok thanks
[08:44] <iwj> Keybuk: Oh, you want me to upload new dmsetup ?  Fine, give me a moment.
[08:45] <Keybuk> yes
[08:52] <iwj> Keybuk: devmapper_1.02.08-1ubuntu8_source.changes 1.3 kB, ok (0 s, 1.30 kB/s) ] 
[08:52] <iwj> It works here on a system with module-init-tools, at least.
[08:53] <iwj> Ohhhh.  edubuntu-desktop installs network-manager which _completely funts the testbed's networking_ of course.
[09:01] <vprints> Good evening!
[09:01] <vprints> who sets the default applications for firefox  ?
[09:07] <vprints> firefox in KDE opens pdf's with Kghostview, but in kghostview the page previews don't work
[09:07] <fabbione> Keybuk: did you solve the evms issue or do you still need me to test?
[09:07] <vprints> in the desktop environment pdf's are opened with KPDF, what works very well
[09:08] <vprints> so we could just change the default app for opening pdf's through firefox to KPDF
[09:10] <Riddell> vprints: asac would know
[09:12] <vprints> Ridell, thanks =)
[09:12] <vprints> *Riddell
[09:14] <vprints> asac, are you around?
[09:20] <Keybuk> fabbione: it looks like it's solved
[09:20] <Keybuk> in scrollback you'll find something if you're interested
[09:20] <Keybuk> I may have chance to put real packages together on thursday or next tuesday
[09:21] <Nafallo> Keybuk: how far up? :-)
[09:22] <asac> vprints: gnome mime handling afaik
[09:22] <asac> if that doesn't give a result it tries mailcap
 siretart: the | vs. _ thing is caused by udev
 udev makes the devices but "sanifies" their names
 http://people.ubuntu.com/~scott/packages
 that has a udev you should build and install
 and then modify 25-dmsetup.rules and add OPTIONS+="no_replace" into it before the PROGRAM= bit
 ACTION=="add|change", OPTIONS+="no_replace", PROGRAM="/sbin/devmap_name %M %m", \
                 NAME="mapper/$result", GOTO="dmsetup_end"
 ^ should look like that
[09:23] <Keybuk> -- 
[09:23] <Keybuk> Nafallo, fabbione ^
[09:23] <vprints> do you maintain it asak?
[09:23] <asac> y
[09:23] <Keybuk> (that assumes you have also edited 70-evms.rules and changed both occurances of ACTION=="add" to ACTION=="add|change")
[09:25] <manchicken> Does anybody know what package provides jsapi.h these days since libsmjs-dev is a migration package?
[09:25] <ajmitch> morning
[09:27] <vprints> asac, could you change it from kghostview to kpdf ?
[09:27] <asac> me? no ;) its not in firefox package .... e.g. mailcap
[09:31] <asac> you have to file a bug against either khostview to lower priority or kpdf to raise priority of their mailcap entries
[09:31] <asac> vprints: ^^
[09:32] <vprints> k
[09:32] <vprints> thankyou
[09:33] <asac> vprints: maybe ask in kubuntu channel as well
[09:34] <Majost> does anyone have the i386 daily iso for 20070327?
[09:34] <Majost> Trying to do a regression test
[09:37] <vprints> asac, i did that, but those who were active at that moment were quite, well, impolite
[09:41] <cyberix> Feisty has quake3-data package, but not the game itself. Is the final version going to have the game also? :-P
[09:50] <jdong> BenC: just a heads-up, the new fglrx 8.35.5 is pretty quirky for me; control center crashes on startup, random hangs when switching PowerStates.... I wouldn't recommend it for feisty :)
[09:50] <asac> vprints: yeah ... file a bug. if they still don't want it, there is not much you can really do
[09:50] <jdong> yay for the fglrx lottery.
[09:50] <BenC> jdong: thanks
[09:51] <jwendell> seb128, will feisty be shipped with gnome 2.18.1 ?
[09:51] <seb128> jwendell: yes
[09:51] <asac> vprints: feel free to subscribe to that bugs, so i see what happens
[09:51] <jdong> seb128: is that magical fglrx compiz thing still on your todo list?
[09:52] <jdong> (not meant in a pushy way; just curious)
[09:52] <seb128> jdong: no, it's not working as expected and it's too late now for such change on 7.04 anyway
[09:54] <jdong> seb128: ok, cool, sounds reasonable. Is that patch public anywhere, or any description of how it works?
[09:55] <tkamppeter> Wo are the buildd admins? Is Keybuk one of them?
[09:55] <tkamppeter> s/Wo/Who/
[09:56] <jdong> infinity I think is one of them.
[09:58] <seb128> jdong: I think it's the same hack as used on beryl, not sure if it works on aiglx, gandalfn was not really clear about it, he spoke about fglrx and then about old card with ati driver
[09:59] <seb128> jdong: I've not really looked at it
[09:59] <jdong> seb128: hmm... well, Beryl surely doesn't work natively on fglrx; without using Xgl _and_ a special beryl-xgl binary :(
[09:59] <jdong> so it probably doesn't work as magically as we expected :(
[09:59] <seb128> hum, k
[10:00] <seb128> clearly not a 7.04 thing then ;)
[10:00] <jdong> right, totally agreed on that point :)
[10:00] <jdong> at least compiz under Xgl works like a total dream.
[10:01] <seb128> nice
[10:06] <tkamppeter> jdong, thanks.
[10:15] <vprints> asac, bug 102544
[10:15] <ubotu> Malone bug 102544 in kdegraphics "Firefox uses not fully functional Kghostview to open PDF's in KDE instead of the system default KPDF" [Undecided,Unconfirmed]  https://launchpad.net/bugs/102544
[10:49] <ds> seb128: you around?
[10:49] <seb128> ds: yes
[10:49] <ds> http://www.schleef.org/~ds/xvideo_test
[10:50] <ds> I'm showing this causing problems on Edgy
[10:50] <ds> is it too late to get these kinds of things fixed in Edgy?
[10:50] <ds> er, *Feisty*
[10:50] <ds> yeah
[10:51] <ds> it would be nice to not have people complain about xvimagesink being broken, especially since it's a driver problem
[10:52] <seb128> ds: well, do you know of any driver broken atm and how much changes are required to fix it?
[10:52] <ds> radeon
[10:52] <seb128> ds: we are not frozen yet, so we can still apply patches that make sense
[10:53] <tepsipakki> I have 6.6.191 running, and will test this now
[10:53] <ds> probably "not much", and I'll track it down
[10:53] <seb128> ds: ok, just tried with my radeon card using the open source ati driver, colors are good
[10:54] <ds> seb128: what version?
[10:54] <seb128> feisty one
[10:55] <tepsipakki> thats 6.6.3
[10:55] <seb128> (II) ATI: ATI driver (version 6.6.3) for chipsets: ati, ativga
[10:55] <ds> ok, that's what I have
[10:55] <seb128> and it's buggy for you?
[10:55] <ds> yes
[10:55] <seb128> weird
[10:55] <ds> curiouser
[10:57] <ds> tepsipakki: what driver?
[10:57] <tepsipakki> ati-6.6.191
[10:58] <tepsipakki> it's not going in feisty, but just testing it
[11:00] <seb128> tepsipakki: does the Ubuntu 6.6.3 has some patch that could fix that?
[11:03] <tepsipakki> doesn't seem likely
[11:05] <seb128> ds: if you know about any driver shipped on feisty which is broken and have a patch we can probably get it applied this week
[11:05] <seb128> ds: do you want us to make a call for testing with your xvideo_test?
[11:06] <ds> seb128: that's probably a good idea
[11:06] <seb128> ok, I'll send a mail on ubuntu-devel then
[11:07] <tepsipakki> btw, here I get an error "ERROR: Pipeline doesn't want to pause." and it kinda fails :)
[11:07] <ds> seb128: it could be better, and print out some debug info
[11:07] <seb128> ds: I'll send the mail tomorrow, if you want to do some changes you can do them
[11:07] <ds> and, of course, there are other errors that it doesn't check for
[11:08] <seb128> and I'll point your URL so if you made any change users will get the new version
[11:08] <ds> tepsipakki: define "fails"
[11:08] <ds> seb128: ok
[11:08] <seb128> ERROR: Pipeline doesn't want to pause.
[11:08] <seb128> ERROR: from element /pipeline0/xvimagesink0: Could not initialise Xv output
[11:08] <seb128> Additional debug info:
[11:08] <seb128> xvimagesink.c(1243): gst_xvimagesink_get_xv_support (): /pipeline0/xvimagesink0:
[11:08] <seb128> No port available
[11:08] <seb128> 
[11:08] <seb128> it prints that
[11:08] <seb128> it does display the window though
[11:09] <tepsipakki> one window
[11:09] <tepsipakki> when it should wait for ctrl-c and then open another with new settings
[11:10] <tepsipakki> right?
[11:10] <manchicken> Is there a reason why libmozjs-dev wants to remove firefox when I try to install it?
[11:10] <ds> tepsipakki: correct
[11:11] <seb128> manchicken: the lib from firefox and xulrunner conflict apparently
[11:12] <manchicken> I'm trying to get spidermonkey libs installed so I can use Test::JavaScript Perl modules.
[11:13] <tepsipakki> ds: it needs #!/bin/bash :)
[11:13] <tepsipakki> since /bin/sh is normally dash
[11:13] <tepsipakki> on ubuntu
[11:13] <ds> tepsipakki: just figured that out :)
[11:15] <seb128> ahhhh
[11:15] <seb128> ds: now it's buggy :p
[11:15] <seb128> the UYVY screen has many small lines
[11:16] <seb128> ds: did you open a bug upstream for the ati driver?
[11:16] <tepsipakki> hah, 6.6.191 works fine :)
[11:17] <tepsipakki> although it does skip four of the tests for some reason
[11:17] <tepsipakki> but UYVY looks fine
[11:17] <ds> tepsipakki: yeah, it's supposed to skip tests
[11:17] <tepsipakki> ok
[11:18] <seb128> tepsipakki: ok, your next mission is to backport to fix then ;)
[11:18] <tepsipakki> seb128: ouch, the commitlog is loooong :)
[11:38] <Adri2000> nobody wants to fix MoM? :-(
[11:43] <LaserJock> Adri2000: MoM is not open source so there's only a limited number of people who can "fix" it
[11:44] <LaserJock> Adri2000: and I doubt it's a high enough priority to get it "fixed" before Feisty is released
[11:45] <Adri2000> LaserJock: how would you merge a package manually?
[11:45] <seb128> debdiff?
[11:45] <LaserJock> Adri2000: debdiff
[11:46] <LaserJock> if the Ubuntu changes are trivial you should be able to grab the new Debian package and make the changes
[11:47] <LaserJock> but you can alse debdiff <old debian package> <old Ubuntu package>
[11:47] <LaserJock> I put a little how to in the Ubuntu Packaging Guide
[11:47] <Adri2000> the debdiff between the current ubuntu package and the current debian one is 1175 lines
[11:47] <LaserJock> not current
[11:48] <tkamppeter> doko, are yiu there
[11:48] <LaserJock> debdiff the current Ubuntu source to the Debian package it was based on
[11:48] <tkamppeter> doko, are you there?
[11:48] <seb128> Adri2000: I usually read the Ubuntu changelog to know what changes are applied to it
[11:48] <LaserJock> yep
[11:48] <seb128> then debdiff | diffstat
[11:48] <seb128> and you know what you need to copy usually
[11:49] <seb128> Adri2000: now if not a moment to merde packages anyway
[11:49] <Adri2000> it's a bit more complicated here because we have a -0ubuntu1... and where can I find the "old" debian version? is it still available in their archive?
[11:49] <seb128> just grab a change from the Debian version if you need it
[11:49] <geser> Adri2000: snapshots.debian.net
[11:50] <LaserJock> Adri2000: and now a -1 package in Debian exists?
[11:51] <Adri2000> LaserJock: yes
[11:51] <Adri2000> -2 even
[11:51] <LaserJock> Adri2000: k, then first thing is to see if it's syncable
[11:51] <Adri2000> geser: snapshot without "s" :), thanks
[11:51] <geser> Adri2000: simply debdiff the Ubuntu package and the Debian package so get an impression what needs merging
[11:52] <Adri2000> http://changelogs.debian.net/mpd < our package is based on 0.12.1-1.1
[11:53] <Adri2000> we have a bug for PulseAudio support, which is fixed in debian
[11:53] <Adri2000> and there are some other interesting fixes...
[12:06] <Adri2000> I have the debdiff debian base version / current ubuntu version, but if I try to apply it to the new debian version, it doesn't work... even for the changelog... how does MoM handle that?