#ubuntu-devel 2005-09-19
<Surak> What's the way to enable dma in boot time or even modifying the breezy live iso? I would like to test with the hardware we sell.
<netstar> Does anyone have a copy of /etc/mkinitramfs/initramfs.conf used to generate the initrd for the latest kernels?
<netstar> and /etc/mkinitramfs/modules
<netstar> I am losing this battle here
<karlheg> jbailey, Have you looked at the patch I sent for initramfs-tools?  Will you apply it?  Will you push that to the bzr mirror?
<karlheg> I have some changes in progress for the man page also.
<Surak> Lathiat: I mean, with D-I commands, not changing /etc/hdparm.conf. Can this be done?
<jbailey> karlheg: I have looked at them.  I'm uncomfortable with the directory move and the variable name change at this point, although I think both probably make sense after breezy releases.
<jbailey> karlheg: I need to poke abentley for help getting bzr-push to work again.  I'll do that now.
<Nafallo> jbailey: will you guys put bzr-tools in the archive at some point? ;-)
<jbailey> Nafallo: Yes.  Although I'll put it up on my snapshot site first.
<Nafallo> jbailey: oki, I'll probably build it locally till then ;-)
<jbailey> Nafallo: Well, with any luck you'll have it in the snapshot section tonight. =)
<jbailey> Nafallo: Failing that, you could build it and uploaded it and become a motu ;)
<Nafallo> jbailey: I am a MOTU already ;-)
<jbailey> Excellent!!!
<jbailey> =)
<Nafallo> that's why I will have to be carefull with dput if I build it ;-)
* Nafallo pulls :_)
<Nafallo> :-)
<sabdfl> argh
<sabdfl> Kamion: ping
<karlheg> jbailey, Can you easily rework the patch, or do you need me to do that?
<ajmitch> pitti: ping
<Evaso> hi guys whois packaging prism54 driver for breezy?
<jbailey> karlheg: I can no prob.
<karlheg> For the variable name change, what about if, for now, both 'version' and 'VERSION' are defined, deprecating 'version'.
<jbailey> karlheg: I was hacking on klibc to convince it to do jfs for a bunch of today.
<jbailey> It's in prep for other initramfs pieces.
<pitti> Hi ajmitch 
<ajmitch> pitti: n/m - build was still trying with older libgphoto2-2 :)
<Evaso> there are some cards (for example netgear wg511v2) that are softmac cards 
<ajmitch> hi anyway :)
<Evaso> drivers are here: http://jbnote.free.fr/prism54usb/
<karlheg> For the directory move, what about if a postinst snippet can move the files to the new location?  It's much easier to copy the scripts to the initramfs image with them in their own subdirectory like that.  No package so far is shipping /etc/mkinitramfs/* conffiles, afaict.
<karlheg> The thing is that if a local admin created an entirely new set of directories, by cloning 'nfs' or somesuch, they will automatically get copied if /etc/mkinitramfs/scripts/* are all copied to ${DESTDIR}/scripts.
<karlheg> Before the patch, it does not copy anything at all from /etc/mkinitramfs/*.
<karlheg> ... but should.
<sabdfl> Evaso: could you ping BenC about that, please?
<sabdfl> BenC: ping
<sabdfl> ^^ re prism54 drivers
<karlheg> Nobody noticed because no packages use those locations.  I use them for local hacks.
<sabdfl> Evaso: perhaps mail him. ben.collins@canonical.com should work
<karlheg> I think it would be useful to have sort of a reverse-depends feature, for this, and for a dependancy-based 'init' script setup.  A local script may need to run before a packaged one, but the packaged one cannot depend on a script it doesn't know about.
<karlheg> Of course number prefixed file-names will probably suffice in most cases.
<lamont> dpkg-gencontrol: error: package mac-fdisk-cross not in control info
<lamont> dh_gencontrol: command returned error code 65280
<lamont> mac-fdisk_0.1-12 suckage
<thierry> could anyone check ubuntu bug 14744 to apply the patch?
<jbailey> Nafallo: My bzr nightly snapshot archive now contains bzrtools
<jbailey> Nafallo: A quick caveat is that the previous tools that were in my packages don't exist anymore, since they're now plugins to bzr.
<jbailey> Nafallo: If you'd been following Aaron's code anyway, then it won't matter to you.
<Nafallo> jbailey: where is that archive? :-)
<jbailey> deb http://people.ubuntu.com/~jbailey/snapshot/bzr ./
<jbailey> Updated nightly.
<Nafallo> kewl :-)
<\sh> wth is bzrtools? importing and exporting bzr archives from/to svn? 
<\sh> ,-)
<ajmitch> \sh: oh far more than that
<ajmitch> jbailey: so this means we can have bzr-buildpackage soon too? :)
<ajmitch> \sh: tailor is what you want for importing svn
<jbailey> ajmitch: Angie's away this weekend, perhaps I'll hack it then.
<jbailey> ajmitch: Anything bzrish I do is only in my spare time, which is running in short supply atm.
<Nafallo> \sh: http://bazaar.canonical.com/BzrTools
<Nafallo> :-)
<jbailey> \sh: Mostly I use bzr push to copy my archives up to people.ubuntu.com
<\sh> jbailey: nice :) we just had a discussion about security things...ssh accounts/rsync or webdav ,-)
<jbailey> \sh: context?
<jbailey> (which 'we'?)
<\sh> jbailey: having a bzr archive for some source...and to commit your local changes towards the public one (public means user auth secured)
<\sh> jbailey: Nafallo, slomo and I
<Nafallo> MOTUIM ;-)
<\sh> the three from the garage ,-)
<jbailey> \sh: Right, the problem is that there's isn't centralised commits yet, so you'll still need something like pqm to manage it for you.
<thierry> could anyone check ubuntu bug 14744 to apply the patch?
<\sh> well...actually u don't know this german movie with heinz ruehmann
<jbailey> It's coming, but it's not here yet,AFAIK.
<thierry> \sh : you asked to tell this here but nobody answered me yet
<\sh> thierry: because it's already in bugzilla...and someone will have a look...u can't force anyone :) actually it's feature freeze
<thierry> oh ok... thanks anyway
<jbailey> It's a silly typo fix. =)
<\sh> thierry: I just had a look...and will check it today 
<\sh> jbailey: it means it will break the pot file
<thierry> yeah
<\sh> jbailey: pqm? 
<jbailey> Fix it in the 'english' translation in rosetta maybe?
<jbailey> \sh: You're thinking StringFreeze rather than FeatureFreeze, I think.
<jbailey> And that was Sep 1, so this can't get applied.
<\sh> jbailey: right...
<bddebian> infinity or lamont: ping?
<lamont> bddebian: ack
<bddebian> lamont: Can you please clear the dep-wait for libffi2 on g-wrap?
<lamont> dine
<lamont> done, evn
<bddebian> lamont: Thank you sir
<pitti> jordi: cool, CAN arrived, and Steven even figured out my real email address :-)
<\sh> lamont: when u wanted to start a universe test build run, or is it already running?
<lamont> \sh: not sure - I know elmo dumped at least main back into a fresh breezy-autotest run... 
<\sh> lamont: ok...so we have some more time to polish ;)
<mdz> doko: ping?
<infinity> \sh : I only looked at one build log, so I may be wrong here, but you're note doing those phpapi changes by hand, are you?
<infinity> \sh : ie: Hardcoding the number in debian/rules?
<\sh> infinity: no...php-config --phpapi
<infinity> \sh : Cause what you really want there is `php-config4 --phpapi`
<infinity> \sh : Okay, good. :)
<\sh> infinity: but phpize is b0rked
<infinity> \sh : No, it's not.
<\sh> infinity: phpize is giving the wrong phpapi ver..
<\sh> infinity: or is it intentionally?
<infinity> \sh : No, it's not.  the "phpapi-###" virtual package is the highest number from PHP API, Zend Module API and Zend Extension API.
<infinity> I should probably have renamed the virtual package, but since it's invisible to most users, I really didn't care much.
<infinity> Maybe I'll break the world and rename it after breezy ships, just to piss everyone off again.
<bob2> man php makes me want to gouge my eyes out
<bob2> even hearing about that sort of thing
<infinity> bob2 : Me too.
<\sh> well...
<infinity> The problem is that the ABI can change (and has done so) when any of those APIs increments, so in the intrest of my own sanity (and since 'phpapi-###' is there for module<->ABI compatibility), I rev it on a bump of any of those.
<\sh> last php package for today from the unmet deps
<infinity> But yeah, I should rename it to phpabi, I suppose, to make that obvious.
<infinity> \sh : Anyhow, thanks for that.  I was going to do it this weekend during my "clean up universe in my spare time" Saturday, but I guess I'll now find something else to attack.
<\sh> infinity: hehe...well, just bored ;)
<\sh> infinity: but you can fix gnome-launch-box instead to honour the new gnome-menus api ;)
<\sh> infinity: so rewriting this piece of software ;)
<\sh> infinity: bah checking for imlib_load_image in -lImlib2... no
<\sh> configure: error: Imlib2 module requires CVS Imlib2
<infinity> ...?
<infinity> php-imlib?
<\sh> yes
<slomo> infinity: you can't remove packages from the archives?
<infinity>  /msg vorlon and smack him around.
<infinity> slomo : no.
<slomo> infinity: hrm... ok, then i have to wait for elmo or just break that package again until he deletes it ;)
<\sh> infinity: he is what for php-imlib?
<infinity> \sh : Upstream author and Debian maintainer.
<\sh> infinity: I see :)
<infinity> Oh, wait.
<infinity> You pulled a new version of it?
<infinity> In that case, it's your fault. :)
<infinity> 0.5-1 that was in the archive before should have built fine.
<\sh> infinity: no
<infinity> Oh, someone synced it.
<infinity> At some point.
<infinity> Feh.
<\sh> 0.5-1
<infinity> Oh, wait. I just can't read.
<infinity> Christ.
<\sh> who? I will give him a hiding ,-)
<infinity> I'll go get something to wake me up, then come back and be coherent.
* infinity wonders why you're getting that error, then..
<HrdwrBoB> is gnome-cups-manager supposed to be broken?
* \sh dccs infinity a pot of good java ,-)
<bob2> ETOOEARLY
<infinity> 0.5-1 built fine previously.
<jdub> NOOOOOOOoooooo......!
<infinity> Probably a broken autoconf test of some sort.
<\sh> or a new imlib2 version?
<infinity> Yes, but newer shouldn't be an issue.
* jdub needs to convince fabbione/BenC to accept a pci-id patch for our kernel ;)
<infinity> jdub : Which one?
<jdub> ooh, maybe it's worse
* jdub misread
<jdub> i have a pdc40719 card
<jdub> sata_promise
<jdub> 2.6.13-git4 has an entry for the 40718
<jdub> and an id patch for the 40519 (which i misread)
<\sh> infinity: I'll check if there is a new upstream;)
<infinity> \sh : Just the one with the added vi.po (ie: no code changes).
<\sh> infinity: in debian there is 0.5-2
<infinity> \sh : Yes, see above.
<\sh> infinity: lemme try it...and eventually ask elmo for a sync
<infinity> \sh : The only thing added in -2 is a vietnamese translation.
<\sh> ok
<infinity> \sh : On the other hand, our libimlib hasn't changed either, so I still assert that this is just a goofy/broken autoconf check.
<infinity> \sh : And if you can't figure it out, leave it to me and I'll fix it later.
<infinity> \sh : I can either fix it, or smack vorlon around, since we have years of violent history. :)
<\sh> infinity: I just queried him
<\sh> infinity: he doesn't know me ;)
<\sh> grmpf..i have to clean the hallway today
<infinity> slomo : What did you want removed?... haskell-cabal?
<slomo> infinity: yes
<infinity> slomo : Yeah, okay, me too. :)
<ogra> \sh, you still didnt do it ... ?
<\sh> ogra: no :(
<slomo> infinity: i have all the haskell stuff lying on my hdd... is just can't upload because of this crappy package ;)
<\sh> ogra: I'm a lazy bastard 
<ogra> \sh, nah
<\sh> ogra: but today after I'm leaving bed ,-)
<infinity> elmo : Can we get haskell-cabal dropped from the archive and blacklisted from syncs?  It breaks the world, and ghc6 >= 6.4 no longer needs/wants it anyway.
<slomo> infinity: but i removed the depend in haskell-devscripts on cabal... so most stuff should be fine for most stuff
<slomo> infinity: (correct grammar ;) )
<infinity> slomo : Kay, cool.  Thanks.  I'll have to run through all the buildds in a few minutes and see if any of the chroots are still broken from libghc6-cabal-dev sucking.
<infinity> slomo : Did you unbreak libghc6-hsql-dev while you were at it?  (It's uninstallable too, but not for the same reason)
<\sh> infinity: same issue with 0.5-2 so I think I will deal with config.m4 to get it straight
<slomo> infinity: it broke the chroots? wonderful ;)
<slomo> infinity: i have it on my hdd... need to try it again after cabal is gone
<slomo> infinity: does libghc6-hsql-dev also have a broken postinst?
<infinity> slomo : Does ghc6 6.4 completely replace the need for cabal-dev?
<slomo> infinity: yes
<\sh> ogra: and u r not sleeping ,-)
<bddebian> Hey, don't we need a cabal to be like Debian?? ;-PO
<bddebian> -0
<ogra> \sh, on my way to bed :)
<infinity> slomo : Cause, if so, you could do something icky like conflict against it to make sure it never gets pulled into a build using ghc 6.4
<infinity> slomo : yes, hsql-dev's postinst is broken too, but it looks like it's due to the pgsql migration/shuffle at first glance.  Didn't look into it.
<slomo_> infinity: haskell-devscripts had a depend on "libghc6-cabal-dev | ghc6"
<slomo_> infinity: and my cabal upload a few seconds ago was braindead... well, it will fail anyway...
<slomo_> infinity: ok, i'll try to fix it
<BenC> what's the correct option to disable framebuffer in the installer: debian-installer/framebuffer=false ?
<\sh> infinity: the function for checking imlib2 is broken somehow
<bddebian> slomo_: You ROCK as always too :-)
<infinity> \sh : No surprise there.
<\sh> ogra: good night :) when I fixed this imlib crappy thingy here I'll go to bed as well
<infinity> \sh : Just leave it to me.  I'll attack it today.
<infinity> BenC : Yes.
<BenC> infinity: thanks
<infinity> BenC : Also, given your rich debian/sparc heritage, you should know that by heart, given how many sparc machines blow up if the FB is on in the installer. :)
<\sh> infinity: ok...your choice :) 
<\sh> but actually the rest built fine
<infinity> \sh : Cool.
<BenC> infinity: given that sparc requires framebuffer for any sort of video (outside of prom console), and that I always do my sparc installs the hardway (serial console), I've never used it before :)
<bddebian> heh
<infinity> Benc : Some of the sparcs I've installed on just do very, very weird things unlkess I disable d-i/fb... But yes, most I've done via serial, which completely eliminates the problem. :)
<\sh> infinity: use 0.5-2 then ... 
<infinity> \sh : Yeah, if I'm going to be mucking with it anyway, I'll upgrade to -2 first to get that extra translation.
<slomo_> infinity: did you also want to fix the haskell stuff? or just hsql?
<infinity> slomo_ : No, I want YOU to fix hsql.. I can't be bothered. :)  But I can revisit your cabal/ghc/devscripts changes and make sure it all looks sane to me.
<slomo_> infinity: ignore my cabal changes... just pretend this package is already deleted ;)
<slomo_> infinity: i just asked because you wanted cabal deleted too
<infinity> slomo_ : You know, the problem would probably easily be masked by changing the order of that dependency from "cabal-dev | ghc6 (>> 6.4)" to "ghc (>> 6.4) | cabal-dev", so brain-dead parsers will be satisfied with the first, first.
<slomo_> infinity: i know... but it doesn't matter for us anyway... we don't have a ghc << 6.4 ;)
<infinity> Yes, true.
<\sh> infinity: I'm speaking to vorlon right now ;)
<slomo_> infinity: is it defined, that the first conditional dependency is tried first?
<infinity> slomo_ : Anyhow, anything you can do to make sure all the libghc* stuff is actually installable, buildable, and working would be great.  Because we waited so long to bootstrap ghc6, I suspect a lot of haskell stuff is a bit goofy.
<infinity> slomo_ : And I have a lot of main bug reports to work on right now.
<slomo_> infinity: ghc6 isn't bootstrapable currently? how did we get the working package? :)
<infinity> slomo_ : Well, not exactly, but if you have "foo | bar (>> 2), bar" (which is what we have in that package), bar is already pulled in by the "and" dependency, so we're free to pull in foo for the "or", (and probably will, because it's first in the list)
<infinity> slomo_ : It is bootstrappable NOW.
<\sh> infinity: I'd send vorlon a config.log...it's a mess
<Lathiat> fabbione: kernel good so far
<slomo_> are the ppc buildds dead?
<slomo_> infinity: how can i remove a broken hsql package after partially installing it? ;) dpkg --remove fails because of broken prerm
<infinity> The prerm isn't broken, but it fails because the postinst never finished.
<infinity> Just comment out the call to unresgister it in the prerm.
<infinity> (/var/lib/dpkg/info/libghc6-hsql-dev.prerm)
<\sh> ok..another dosis of iron maiden for today
<slomo_> \sh: good choice :)
<bddebian> pfft Metallica baby ;-)
<\sh> bddebian: baby music ;)
<\sh> but I could watch metallica - whisky in the jar video ,) with all those drunken b*tch*s 
<bddebian> Heh
<mjg59> Is there any easy way to get stats out of bugzilla?
<mjg59> I'd be interested in knowing how many people have more assigned bugs than me...
<infinity> Haha. :)
* desrt suspects, for that, you need mysql client and suitable privileges
<jdub> mjg59: luis is a good person to ask :)
<elmo> bugzilla _better_ have good stats since luis was pimping them to hard as bugzilla's winning feature
<infinity> elmo : Can I get php-imap synced?
<bddebian> Hey, stand in line ;-P
<mjg59> Nnngh.
<mjg59> I have 120 open bugs for which I'm owner
<bddebian> Nice
<mjg59> Plus some more where I'm on the Cc list and effectively dealing with it
<bddebian> Want some Malone bugs too? ;-)
<mjg59> Ah, yes, 200 in total.
<mjg59> Hurrah!
<mjg59> Sorry, only 156 open
<mjg59> Out of 3280 open bugs
<mjg59> I own 5% of open bugs? Seriously?
<bddebian> Feels good to be wanted doesn't it?
<mjg59> Nngh. Ang 728 of those are debzilla, which takes me to 156 out of 2500
<\sh> infinity: it can't find X libs stuff...
<bddebian> \sh: Which one?
<\sh> bddebian: php-imlib
<bddebian> I meant which X lib stuff :-)
<\sh> bddebian: yes..php-imlib needs some X libs ,-)
<bddebian> Grr
<mjg59> Daniel has 173, Colin has 312, Ben has 362 (but inherited all of the kernel bugs), mdz only has 73!
<\sh> actually imlib2 needs it and php-imlibs tries to link against imlib2 + -lX11
<bddebian> I guessed, that, what's it failing on? Ohh
<infinity> \sh : Ahh, easy enough to fix, then.
<\sh> infinity: but normally imlib2 should pull them in
<\sh> infinity: anyways trying to fix it
<infinity> \sh : Uhm, libimlib2-dev DOES pull in libx11-dev, so something else in that test is failing.
<slomo_> infinity: working hsql uploaded :)
<\sh> infinity: I'll see it right now...the configure test is not linking towards -lX11
* bddebian wonders if elmo has mail from him going to /dev/null yet
<infinity> slomo_ : Cheers.
<jbailey> mjg59: What %age of RC bugs do you have? =)
<\sh> infinity: no wonder checking for X... libraries /usr/X11R6/lib, headers in standard search path
<mjg59> jbailey: Good question. No idea...
<jbailey> I have 30/251 =(
<mjg59> Maybe I should ask for a big pile of money :)
<jbailey> Mostl either evolution-exchange or initramfs-tools, though.
<jbailey> The first is annoying, but the second I can actually do something about.
<mjg59> What does RC count as?
<jbailey> Maj and above.
<jbailey> Thinking of which, can you comment on 7463 so hat I can deal with it?
<jbailey> It's the recover-the-swap link that you sent to me.
<mjg59> I've got 14 of them
<jbailey> mdz said basically that it sounds reasonable and asks for your feedback.
<jbailey> I might not actually have 30.  My query also includes RC bugs that I'm cc:'d on.
<mjg59> Yeah, me too
<mjg59> I generally assume that if I'm on the cc, either someone wants it to be my fault or I'm taking the blame anyway...
<bddebian> heh
<mjg59> Nnngh.
* mjg59 just manages to resist the temptation to say "I need to stop drunkenly deleting bugzilla mails"
<mjg59> jbailey: Done
<infinity> Deleting bugzilla mails is one of my favourite passtimes.
<jbailey> mjg59: You could do my solution and just tell bugzilla not to send them.
<jbailey> infinity: Hey, ppc hasn't done klibc yet.  Is the buildd having issues?
<infinity> jbailey : One buildd is offline, cause it's acting up, the others are probably stuck building Big Things, but I'll check.
<jbailey> I'm not too fussed, it's just unusual that a small package wouldn't have showed up by now on only one arch.
<infinity> Yup, Openoffice on adare and gcc-4.0 on ross.
<jbailey> Cool, I'll check it again in the morning.
<jbailey> I wrote it on a ppc box, though, so there's no risk.
<infinity> It'll all clear itself up and be happy again soon enough.  There's only 20 package sin needs-build for powerpc, so it's not exactly "behind".
<mdz> mjg59: you're CCed on bugs because you don't answer on IRC ;-)
<elmo> infinity: err, acting up?
<infinity> elmo : Yes, I need to dig around the chroot and make sure it's not my fault, then bug you if it looks like hardware.
<mjg59> mdz: Dude, I'm too busy having a life
<mdz> mjg59: regarding #6108, any reason not to go ahead with the workaround of avoiding hdparm -B?
<mjg59> mdz: No, assuming it works
<infinity> elmo : royal's had an incredible number of segfaults that the other two haven't been seeing.
<infinity> elmo : Like, just about every libtool invocation on royal segvs.
<mjg59> The power saving probably isn't that great, but some time we should figure out what's actually going wrong
<elmo> infinity: royal's also the one with the ghc fux0red chroot?
<mjg59> Someone needs to bitch about it on LKML
<infinity> elmo : No, that's cleaned.
<mdz> mjg59: I was able to reproduce the bug on AC power in single-user mode with only hdparm -B
<mdz> mjg59: so I'm pretty confident that'd work around the issue
<mjg59> Ok
<infinity> elmo : But the segv issue stands.  Unless it fixed itself overnight.  I need to test some stuff later, then email you if it's out of my domain.
<Nafallo> elmo: could you sync sbackup from unstable and NEW it, please?
<bddebian> Nafallo: No, you have to wait in line too! :-)
<Nafallo> bddebian: :-P
<bddebian> Although elmo could probably spend days with all the crap I keep sending the poor guy
<\sh> infinity: fixed...now I make a patch
<bddebian> \sh: rockin'
<\sh> infinity: oh sh*t 2:27utc
<infinity> ?
<\sh> infinity: I should be in bed
<infinity> Yes, you should be. :)
<Nafallo> infinity: that means 4:27 local time ;-)
<infinity> php-imlib isn't more important than sleep.
<\sh> infinity: php-imlib works now .. after patching config.m4
<Nafallo> for both me and \sh :-P
<\sh> infinity: na..I don't like packages laying around unfixed ;)
<\sh> infinity: 0.5-2ubuntu1 is hitting the archives...;)
<bddebian> heh
<\sh> bddebian: if u see elmo...gtk-gnutella from debian unstable can be synced..it fixes all ftbfs issues with gcc4 ....thx :)
<bddebian> \sh: Sheesh do you guys WANT elmo to hate me? ;-)
<\sh> bddebian: haha ;)
<\sh> bddebian: do not worry...I tested it on amd64...so it's ok :) 
<bddebian> \sh: I'm not worried about your request, I have just been flooding the poor guy with sync requests :-)
<\sh> bddebian: prepare some 6packs of your best local beer and send it via UPS 
<\sh> anyways I'm ready to go to bed...anything else?
<bddebian> \sh: If Imake it to UBZ I'll have to buy himsome.. ;-)  Gnight man, good work as always! :-)
<\sh> g'night gentlemen
<khermans> I think I found a security vulnerability in mozilla-thunderbird on AMD64
<khermans> if anyone can verify, msg me
<wasabi> irc:// is never a registered protocol.
<wasabi> I wonder if we should add that.
<infinity> khermans : Only on amd64?
<khermans> infinity, seems so
<khermans> if someone can verify, let me know
<infinity> Feh.  Kay, can't readily test right now, then.  Only my i386 machine is up.
<khermans> it has to do with running the Import function
<khermans> if you open the import tool, and it doesnt crash immediatly, you are not vulnerable
<infinity> khermans : If you could mail martin.pitt@ubuntu.com and CC adam.conrad@ubuntu.com with details, that might be helpful.
<khermans> ehh...im busy right now -- ill do it if someone else verifies it first, otherwise it could be one of my libs
<khermans> gotta finish this scheme homework
<infinity> Although, aI'm not sure how "the import tool crashes" is necessarily a security bug..
<khermans> infinity, the data that the import tools read on startup may be causing it to crash -- i some weird things in the stack that should not be there
<khermans> it is only a local vuln
<infinity> Not even that.
<infinity> The import tool could be reading everything from your home dir (and may well do so), but if it can only do so on your command, that's not a security hole, just something you odn't like.
<khermans> it seems that another user on the system may be able to manipulate some things it does read on bootup, so if that is true, and they control them, and they are in the stack....
<khermans> it doesnt really matter, i just came to see if anyone else had the same setup
<infinity> Still a non-issue.  If the user can access those things with thunderbird, that means they can access them with, oh, say, 'cat'.
<khermans> this is not anything like the firefox HOST vuln
<infinity> khermans : I'd just file a bug about the crash, with a backtrace.
<infinity> khermans : Being able to read files you have access to isn't a security issue. ;)
<khermans> infinity, , did you know evolution mail client stores passwords very insecurely?
<infinity> Surely it stores them in files with mode 700
<khermans> haha
<khermans> nope
<Lathiat> where does it store them?
<khermans> .gnome2_private, which is 700, but the file with the passwords is 744
<khermans> and they are only base64
<infinity> Oh, same thing.
<Lathiat> ffs
<Lathiat> you know
<infinity> If the directory is 700, there's no problem.
<Lathiat> your right
<Lathiat> infinity: oh?
<Lathiat> i thought you could still get at files just not readlist them
<infinity> Yeah, directories have permissions for a readson, you know.
<infinity> No.
<Lathiat> ah
<Lathiat> is ee
<infinity> If you have read on a directory, you can list files, if you have execute, you can traverse, if you have neither, you can't go near it.
<infinity> But don't take my word for it, you have a shell, you have the power to create test users, give it a try. :)
<khermans> i know this is true, but still dumb to store passwords in base64
<Lathiat> it ried it :)
<Lathiat> khermans: what else are you going to store them in
<Lathiat> khermans: its not going to be any more or less secure
<khermans> do a hash, jeesh
<Lathiat> err
<Lathiat> khermans: and how do you propse to unhash the password to send to the server
<infinity> It has to be a 2-way hash, or you can't GET IT BACK.
<infinity> Storing it in base64 is snakeoil, though, it should probably just be sotred plaintext.
<khermans> lol
<infinity> But, whatever.  People base64 the thing to give a false sense of security, I'm sure.
<infinity> (Or to allows for easier import/export of weird characters)
<infinity> Either way, it's not a problem, cause only you can read the file.
<Lathiat> well
<Lathiat> if someone jumped  on my machine
<Lathiat> at least they couldnt remember my password
<infinity> Don't let them do that.
<Lathiat> if they only had 2 seconds
<Lathiat> :)
<infinity> If they jump on your machine, they can just run your mail client.
<Lathiat> sure but they cant do that later
<Lathiat> :)
<khermans> i hate computers, everything is insecure, code is horrible, always will be
<infinity> But in this case, nothing is actually insecure.
<infinity> Except if you let people shoulder-surf, or steal your hard drive.
<khermans> infinity, but what about client side exploits?  your are totally vulnerable
<daniels> khermans: so you propose that your client ... never knows your password?
<infinity> If you tell the client to "save your password", it'll probably have it in memeory all the time anyway.
<khermans> if i found a remote bug in thunderbird, knew you used it to acess your corporate mail, and your user/pass are stored in that evolution file in plain text, and i make it read and then send it back to me, well now you have a problem
<khermans> sorry evo
<infinity> Uhm, I can ull your mail password from tbird, too, not just evo.
<bob2> daniels: encrypt it on the client, duh
<infinity> And this has nothing to do with either.
<bob2> then no one can steal it
<infinity> If you don't want the client to know your password, don't click the box.
<infinity> If a completely DIFFERENT bug allows you to read the stack of any application that knows one of your passwords, you are vulnerable, yes.  So, don't let them know your passowrds, or watch out for other exploits.
<infinity> But having them know your passowrd isn't an exploit in and of itself.
<daniels> khermans: er, I could use a client-side exploit in Firefox to steal your password, provided I can read files on the disk.
<khermans> and thats the thing, encryption is never 100% either -- so there is always a vuln somewhere
<daniels> i think what you're trying to say is that if someone has access to your user account, you're stuffed.
<khermans> daniels, yea
<fabbione> morning guys
<daniels> and yeah, that's pretty true.  try not to let that happen.
<khermans> lol, you go on the net, anyone has access to your machine
<bddebian> Heya fabbione 
<fabbione> khermans: i remember i solved a problem like that with a user when i was working as sysadm
<fabbione> it was very simple.. i just unplugged his power cord and left the room :)
<khermans> hehe, 100% remote security
<bob2> if your account is compromised, you lose
<bob2> film at a11
<wasabi> This argument sucks.
<wasabi> Can we move onto discussing the best beer?
* bddebian agrees :-)
<khermans> guiness
<bob2> cooper's heritage
<wasabi> Guiness is like drinking pudding.
<bddebian> *lol*
<bddebian> Newcaslte
<infinity> wasabi : I propose we discuss why ant just failed to build in an autotest run.
<bddebian> Err Newcastle even
<wasabi> Awww. Do we have to?
* wasabi tries.
<bob2> I'd like to meet the persion who looked at make syntax and thought "...you know what this needs? some more xml."
<wasabi> It's not that it needed XML.
<wasabi> It was that reusing a XML parser was easier than writing a Makefile parser in Java.
<bob2> if only someone had already written a make parser
<bob2> they could call it "make"
<daniels> wasabi: buckley's dark bock, bellevue kriek
<bob2> and use it to build all sorts of things
<wasabi> And Make doesn't very well handle compiling multiple files with one command
<wasabi> Pssh.
<wasabi> Java devs use java.
<infinity> wasabi : http://people.ubuntu.com/~lamont/buildLogs/Test/a/ant/1.6.5-0ubuntu3/ant_1.6.5-0ubuntu3_20050914-0311-i386-failed.gz
<wasabi> Or they'd be using python instead or something.
<bob2> java devs only know java
<bob2> which is a problem in itself
<wasabi> Perhaps.
<infinity> wasabi : Mithrandir has been changing a bunch of other java packages that were FTBFS, I assume this needs something similar.
<wasabi> Cooper's heritage you say? Where can I find that?
<bob2> wasabi: probably not outside .au
<bob2> get daniels to bring some
<wasabi> Oh.
<wasabi> Looks like somebody changed the command line options on ecj.
<wasabi> Oh.
<wasabi> I bet it's because somebody upgraded ecj.
<whiprush> howdy bob2
<bob2> aloha
<bob2> fridge?
* whiprush points in the general direction of Mr. Dub.
<whiprush> bob2: although, I've been slammed at work for 2 weeks, so yeah, I suck also.
<daniels> cooper's heritage is indeed great stuff.  and I'm not flying through the US, so I might chuck a few in my bag.
<jammcq> whiprush: HEY
<whiprush> hi jam.
<whiprush> see /msg
<jammcq> hmm, nothing there
<jammcq> are you registered?
<jammcq> am I?, hmmmm
<whiprush> thought I was. freenode seems content in making things difficult.
<jammcq> yeah
<jammcq> and everytime theres a netsplit, it seems I have to re-identify myself
<whiprush> yeah, that's what happened to me.
<fabbione> hey jamesh 
<fabbione> ops
<fabbione> jammcq: hey
<jammcq> hey fabbione, how's it going?
<fabbione> jammcq: not extremely well... my ws is driving me nuts and i don't understand why
<fabbione> it keeps turning off by itself
<fabbione> (hw problem)
<jammcq> hmm
<jammcq> no fun
<fabbione> no
<jammcq> thermal issue?
<fabbione> at least i managed to get it to stay up for a while
<fabbione> i don't think so.. CPU is at 47C
<fabbione> i did remove each single gram of dusts from it to be sure all the fans are working properly
<fabbione> changed one of the power supply and so on...
<jammcq> hmm, my workstation doesn't have a fan :)
<fabbione> but it didn't help mych
<fabbione> much
<jammcq> in fact, my workstation doesn't have any moving parts at all :)
<fabbione> jammcq: ehhe
<fabbione> jammcq: well.. we still need to talk about that :) 
<jammcq> yep
<fabbione> but i think we will take 2 of the one you suggested..
<jammcq> we'll figure out some special pricing, to make the ubuntu guys happy 
<fabbione> jammcq: price isn't an issue.. really
<jammcq> oh, in that case.... :)
<fabbione> it's more important how we the deliver
<fabbione> jammcq: well at least it is not for me...
<fabbione> but i would love to be able to save in delivery and custom (if possible ;))
<fabbione> that would make me happy enough
<jammcq> yeah, that shouldn't e any problem
<fabbione> specially because i will take them to dk
<fabbione> and one them will travel to italy
<fabbione> jammcq: otherwise, if you make a special price, we will use the difference for beer ;)
<fabbione> and have extra fun at UBZ :P
<jammcq> the beer margin :)
<fabbione> eheh
<jammcq> and Canada is the place to get some damn fine beer
<fabbione> i tend to prefer belgium beer, but i guess whatever it's there will do
<fabbione> elmo: ping?
<fabbione> mdz: ?
<jdub> daniels: is there a good proggy to use for lcd display autoconfiguration? nvidia has a nice one for windows
<Lathiat> jdub: to configure what exactly?
<Lathiat> jdub: nvidia-settings lets you fiddle a few values
<jdub> not configuration
<jdub> displaying a test screen
<Lathiat> oh
<jdub> for display-side autoconfiguration
<Lathiat> to calibrate with
<Lathiat> yeh
<Lathiat> open X
<Lathiat> with that backgroudn it defaults to
<jdub> bong
<jdub> ok
<Lathiat> you know the checkered one
<Lathiat> :)
<jdub> better, but still has pretty bad shadowing
<jdub> unfortunately the screen autoconfigures during the nvidia logo bit
<Lathiat> ah
<Lathiat> cant you ask it to tho
<Lathiat> most things have an auto-adjust button
<fabbione> Lathiat: how is it going with the test kernel?
<jdub> yes, but it's autoadjusting against an inconsistent image
<Lathiat> fabbione: good so far
<fabbione> great
<Lathiat> still need longer to see tho
<fabbione_> grrrr
<fabbione_> it
<fabbione_> it's not a temperature problem...
<fabbione_> it is more like the video card freezes
<daniels> jdub: the X grey/black moire is the best for that
<daniels> jdub: but it also shows up the slightest flaw in your display; it makes my 21" Trinitron weep
<Lathiat> yeh its horrid on alot of crts
<fabbione> daniels: are you aware of any way to monitor an nvidia temperature?
<fabbione> (gfx.. not the chipset itself)
<Lathiat> fabbione: if you are using the binary driver
<fabbione> Lathiat: i do...
<Lathiat> fabbione: nvidia-settings has it, and i hacke dup a program to dump it to stdout
<Lathiat> i was graphing mine
<fabbione> s/do/must do/
<Lathiat> under 'thermal monitor' in nvidia-settings just to look at it
<fabbione> i have no such thing like "thermal monitor"
<Lathiat> kmm
<Lathiat> perhaps your card doesnt support it?
<Lathiat> its in the list between 'antialiasing settings' and 'display device' for me
<fabbione> probably it doesn't
<fabbione> there is no such thing
<Lathiat> oh well
<Lathiat> interestingly, i cant get that information from the nvidia stuff in windows
<Lathiat> at least i couldnt find it
<fabbione> hmmm
<fabbione> i don't trust nvidia-settings anyway.. it finds only one of the 2 cards and one of the 3 monitors
<Lathiat> heh
<fabbione> i guess i will need to fiddle with the BIOS a bit more.. i start to believe it's not hw the problem
<Lathiat> what happens?
<fabbione> well the machine freezes hard (both windows and linux)
<Lathiat> ah
<Lathiat> memtest?
<fabbione> in linux i can see that only the monitors connected to a specific card blank
<fabbione> i did run memtest. memory is fine
<fabbione> i suspect more an irq problem at this point in time
<Lathiat> interesting
<fabbione> at BIOS level
<fabbione> because i noticed yesterday a lot of ERR in /proc/interrupts
<fabbione> now i just enabled IO-APIC
<fabbione> and the cards got different IRQ
<fabbione> and no ERR
<jdub> daniels: so with the nvidia test image in windows, which includes blocks of colour, it calibrates really nicely. with the X 'checkers', it still isn't quite right.
<daniels> jdub: interesting
<daniels> jdub: i guess the nvidia test image looks not unlike the sbs test image?
<jdub> daniels: hrm, bit different
<jdub> wonder if i can sshot it
<jdub> haha, rad
<jdub> daniels: http://people.ubuntu.com/~jdub/2005/nvidia-display-test.png
<jdub> it's only 20K, but it's 1920x1200
<Lathiat> jdub: interesting
<ajmitch> shows how screwy my monitor is :)
<Lathiat> heh
<Lathiat> looks perfect here ;)
<Lathiat> not so great when scaled down
<jdub> yeah, when this thing isn't calibrated, that image is... ah... moving. :-)
<Lathiat> i hear 10% brightness level is good ;)
<daniels> jdub: oh, wow.  yeah, that's a really good image.
<jdub> pretty thorough
<jdub> oh man
<jdub> usb-storage sucks so hard on windows
<jdub> like, we are *way* ahead
<[Chameleon] > jdub: pretty much everything sucks so hard on windows.
<[Chameleon] > except for availability of games... but, actually, that fact sucks, too.
<jdub> fabbione: still here
<jdub> ?
<jdub> heh
<jdub> gar
<pitti> Good moooorning!
<torkel> pitti: thanks for taking care of heimdal, and I'm sorry for taking so long to do the debdiff
<pitti> torkel: no worries, thanks for doing it
<doko> good morning
<jdub> http://www.brendoman.com/dbc/2005/09/13/my_techtv_appearance
<jdub> ha ha ha ha
<Treenaks> "I haven't even bothered trying to compile a program since I switched to Ubuntu."
<pitti> Hi doko 
<jdub> check the comment ;)
<pitti> daniels: to make the nvidia driver work, I had to add a symlink from the new into the old driver directory; known issue?
<pef> hello
<pitti> Mithrandir: do you care for ia32-libs?
<Kamion> sabdfl: pong, re your ping last night
<Mithrandir> pitti: yes
<dholbach> good morning
<mvo> hey dholbach 
<dholbach> hey mvo
<pitti> Mithrandir: could you please upgrade the contained zlib to the latest version to fix CAN-2005-1849 and CAN-2005-2096?
<pitti> Hi dholbach 
<Burgundavia> Kamion, how does one test the oem installer?
<dholbach> hey pitti :-)
<Mithrandir> pitti: in all dists or just breezy?
<Mithrandir> mvo: didn't you do an upload to fix 8265 yesterday?
<mvo> Mithrandir: not yesterday, but it should timeout in at most ~120sec 
<Mithrandir> mvo: per request or in total?
<Kamion> Burgundavia: install oem-config
<mvo> Mithrandir: how long does it take for you to timeout?
<Kamion> Burgundavia: to test it properly, it's best to install oem-config along with the desktop system (by preseeding)
<Burgundavia> Kamion, ok
<Mithrandir> mvo: I haven't tested it, since I don't have such a setup here; I was just asking what the code is supposed to do?
<Burgundavia> Kamion, is there docs for that somewhere? If not, lets talk at UBZ about building an OEM doc pack and what it needs
<mvo> Mithrandir: the default timeout for http is 120sec, apt will have to timeout once for each active sources.list entry. so it's 240s. I think the installer could probably use a slightly lesser timeout
<mvo> Mithrandir: this only applies for setups that have working dns but non-working direct access to the archive
<Mithrandir> mvo: ok, is it tunable with a command line parameter or something?
<mvo> Mithrandir: yes, "-o Acquire::http::Timeout"
<Kamion> Burgundavia: not at the moment, no, it's too new
<Kamion> I suppose I could add an (undocumented) 'oem' boot option to the CDs, so that people can test this more easily
<Burgundavia> that would be nice
<pitti> Mithrandir: just breezy; stables were fixed a while ago
<pitti> Mithrandir: please also mention these two CAN numbers in the changelog
<Mithrandir> pitti: ok, will do once my apt-get upgrade finishes so I have > 0 free space
<pitti> thanks
<dholbach> good morning seb128! :)
<seb128> hey dholbach
<Kamion> Burgundavia: ok, as of next CD images it should be possible to boot with preseed/file=/cdrom/preseed/oem.seed to test oem-config
<Treenaks> Kamion: cool!
<Burgundavia> Kamion, thanks
<parshimers> is there anything buggy about sudo in breezy?
<robitaille> parshimers,  not that I know
<Burgundavia> parshimers, it is a little bit slower than in hoary
<[Chameleon] > parshimers is having problems with it
<[Chameleon] > on a clean install
<[Chameleon] > we've tried to figure it out in #ubuntu, but aren't getting far
<[Chameleon] > it's basically not doing anything for him. most of the time it seems to just exit.
<[Chameleon] > parshimers: I was going to ask you to type this:
<[Chameleon] > dmesg | tail
<[Chameleon] > and look for anything related to sudo
<[Chameleon] > you could actually do this:
<[Chameleon] > dmesg | grep -i sudo
<[Chameleon] > that'll be better
<pitti> ogra: will you upload a new moodle anytime soon?
<parshimers> parshimers@Parshimers:~$ dmesg | grep sudo
<parshimers> parshimers@Parshimers:~$
<parshimers> :\
<pitti> parshimers: what do you expect?
<pitti> parshimers: kernel messages don't have anything to do with sudo
<parshimers> i figured
<mdz> fabbione: ?
<fabbione> mdz: ?
<[Chameleon] > pitti: sorry, I figured it was worth checking on
<fabbione> mdz: it was about the tetex-* stuff..
<fabbione> mdz: i did add comments based on the stuff that's happening in Debian, but i would like a double review
<mdz> fabbione: saw your comment via mail
<mdz> fabbione: probably elmo would be the right person to review
<fabbione> mdz:  ok
* hunger has the /dev/input/mice issue agian after upgrading yesterday.
<torkel> [Chameleon] /parshimers: check /var/log/auth.log
<parshimers> lol thats great
<parshimers> i need to be root to read the file
<parshimers> :(
<Mithrandir> elmo: can you please sync sgml2x and blender?  Ok to override and the blender sync has been approved by Kamion.  (The sgml2x doesn't need approval)
<[Chameleon] > parshimers: bummer
<[Chameleon] > parshimers: you might try single-user mode. That should give you root access.
<[Chameleon] > parshimers: at the grub boot screen, type the letter 'a' and then add an 'S' to the end of the boot string, separated by a space.
<[Chameleon] > parshimers: disclaimer: I think that's right, that's how it worked on FC3's grub boot, should be the same here.
<parshimers> the problem was it didnt add my 2nd user to the sudoers list :P
<torkel> [Chameleon] : can we please move it back to #u?
<[Chameleon] > torkel: sure, but it seems he has found the problem.
<[Chameleon] > parshimers: back to #ubuntu we go.
<torkel> [Chameleon] : I know :-)
<[Chameleon] > :)
<[Chameleon] > torkel: thx for your help
<[Chameleon] > pitti: you too
<torkel> [Chameleon] : np
<seb128> mvo: around?
<mvo> seb128: yes
<mvo> seb128: 'sup?
<seb128> mvo: hi :)
<seb128> Trying patch debian/patches/05_use_C_locale.patch at level 0...1...success.
<seb128> Trying patch debian/patches/09_desktop.patch at level 0...1...2...failure.
<seb128> make: *** [debian/stamp-patched]  Error 1
<seb128> 
<seb128> mvo: build log for current gdm
<mvo> seb128: uh, bad
<mvo> seb128: thanks. I didn't touched 05_use_C_locale but had to adjust 09_desktop. but it applied for me. oh well
<seb128> np
<jkrogh> Hi.. the latest breezy kernel gives me a "busybox" after bootup.. 
<jkrogh> 2.6.12-8-amd64-smp
<jkrogh>  169.472773]  audit(1126687587.704:0): initialized
<jkrogh> [  170.303754]  scsi_proc_hostdir_add: proc_mkdir failed for <NULL>
<jkrogh> mount: Mounting /root/dev on /dev/.static/dev failed: No such file or directory
<chmj> anyone know if the archive is broken or something ? 
<jkrogh> mount: Mounting /dev on /root/dev failed: No such file or directory
<jkrogh> Target filesystem doesn't have /sbin/init
<sivang> Morning all!
<jkrogh> Anyone you knows what to do to submit a proper bugreport? 
<chmj> I keep getting MD5Sum missmatches and I'm not behind a proxy 
<chmj> elmo: ping 
<doko> chmj: too early :)
<jkrogh> 2.6.12-3-amd64-k8-smp works fine.. 
<mvo> chmj: maybe a transparent proxy? breezy seems to be fine here 
<sivang> morning mvo , seb128 , pitti 
<chmj> mvo: nope
<jkrogh> The archive works fine from here.. 
<jkrogh> dk.archive.ubuntu.com 
<chmj> mvo: no proxy
<pitti> Hi sivang 
<seb128> hi sivang
<seb128> hi pitti
<pitti> Moin seb
<chmj> hmmm, it means something wrong by my side then 
<mvo> chmj: you may try "apt-get update -o Debug::Acquire::http=true" and look at the http headers
<chmj> mvo: thanks 
<jkrogh> Should i ask on the ubuntu-devel list instead? 
<mvo> chmj: if you want, paste the debug output somewhere and I'll have a look
<chmj> mvo: I think the local telco is caching us or something 
<chmj> mvo: we've been having problems with adsl 
<seb128> does somebody have a ldap setup here?
<\sh> dholbach / seb128: can u have a look on libgda2...binary package gda2-freetds has unmet dep on libct1 (which should be libct3) but all versions of libgda2 (up to 1.3.91) are ftbfsing because of using the wrong interfaces of freedts lib
<Mithrandir> \sh: it's infty's bug, he asked other to let him handle it
<\sh> Mithrandir: ok then..
<seb128> Mithrandir: do you want amd64 bug? http://bugzilla.ubuntu.com/show_bug.cgi?id=14903
<Mithrandir> yay bugs! /me munches
<sivang> seb128: I  have some kind of ldap server on one of the machines, what do you need?
<seb128> Mithrandir: that's browsers crashing with totem video player, seems to be reproducible if you use "previous page" from a video
<Mithrandir> seb128: I'll take a look
<seb128> sivang: https://bugzilla.ubuntu.com/show_bug.cgi?id=14763
<seb128> Mithrandir: thanks
<Kamion> chmj: transparent proxy == local telco caching you
<Kamion> due to the "transparent", you often won't know about it
* lifeless rants about how transparent is really interception
<Kamion> well yes
<chmj> they should not be doing that anyway 
<\sh> chmj: normal behaviour of ISPs in modern times
<HrdwrBoB> my ISP doesn't transparent proxy me
<\sh> Mithrandir: btw...is {gcc,g++}-3.4 installable on amd64 again, since dokos upload yesterday? :) 
<\sh> HrdwrBoB: not all..but many
<HrdwrBoB> \sh: I cheat though.. I route traffic through work
<Mithrandir> \sh: yes, done.
<\sh> Mithrandir: u rock :) thx :)
<jdub> seb128: that totem plugin bug appears on !amd64 too
<seb128> jdub: ppc?
<jdub> x86
<jdub> at least last time i tried
<jdub> currently stuck in console tho
<jdub> will try again later
<seb128> jdub: I don't have it on my box, but on the same box with the amd64 liveCD it crashes the browser everytime I do "previous page" from a video page
<seb128> with the same versions
<seb128> jdub: get me a backtrace on x86 please, amd64 are screwed 
<jdub> ok
<seb128> thanks
<dholbach> Kamion: do i get approval  to sync workrave from debian? (new upstream, builds nicely, fixes #10667)
<jdub> hrm
<jdub> how do i get a backtrace? run firefox in gdb?
<Mithrandir> firefox -g, iirc
<jdub> ahr
<seb128> jdub: or gdb -p `pidof firefox-bin`
<seb128> when it's running
<jdub> yeah
<jdub> seb128: did you see alexl's blog?
<seb128> jdub: nop, /me opens planet
<seb128> jdub: waouh, that's cool
<jdub> yummy :-)
<\sh> hmmm.
<\sh> this is much more valuable: http://www.gizmoproject.com./
<\sh> this is much more valuable: http://www.gizmoproject.com/
<dholbach> elmo: could you pretty please sync tdiary (security issues)
<pitti> dholbach: I just write an email to elmo with a whole bunch of sync requests
<pitti> dholbach: I just do a major security review, also of universe
<\sh> pitti: put gtk-gnutella as well on it, thx :)
<pitti> dholbach: email requests generally work better anyway
<dholbach> pitti: cool, will you add tdiary please then?
<pitti> dholbach: it's already there :-)
<dholbach> pitti: super, thanks
<pitti> dholbach: I included all recent DSAs and CANs
<dholbach> ROCK :)
<pitti> \sh: changelog doesn't mention a security issue
<\sh> pitti: ok...then I write the email by myself...it's gcc4 issues...need to collect anyways for universe
<Kamion> dholbach: that's a fairly substantial upgrade; have you tested it?
<pitti> \sh: yes, thanks
<Kamion> dholbach: please check with the doc team to find out whether they've got workrave in screenshots or other documentation; if so, I'd rather stick with what we've got, since it's after UI freeze
<\sh> pitti: btw..when u do a security review also of universe...can u put somewhere the list of source packages which a vulnerable somewhere on the wiki? 
<pitti> \sh: putting that on a wiki would be error prone and redundant
<pitti> \sh: I just invent a mechanism in ubuntu-cve for that
<pitti> \sh: I added some vulnerable packages, if anybody spots something, I can easily add it
<dholbach> Kamion: ok... will talk to them - the release contains mostly bug fixes and translation updates - will give it some more testing, before i will request the sync
<mdke> i don't think we have such a package in our documentation
<\sh> pitti: can u give me a link to this list for ubuntu-cve?
<mdke> dholbach, ^
<dholbach> mdke: merci beaucoup :)
<pitti> \sh: http://people.ubuntu.com/~pitti/ubuntu-cve/unfixed.html
<pitti> \sh: look at the very end, there is breezy universe
<pitti> \sh: shortly the list will get bigger when I add the new stuff
<pitti> I'm still in the review process
<pitti> \sh: if something on that list is fixed, please tell me
<pitti> CAN-1005-1759 	
<pitti> php4 [Ubuntu: 4.4.0-2]  [Debian: 4:4.4.0-2, vulnerable] 
<Kamion> dholbach: merge rather than sync, I'd expect
<pitti> ouch - that is a *VERY* old one :-/
<dholbach> Kamion: are you still talking about  workrave ? we don't need to merge, it builts nicely as it is
<pitti> dholbach: about which package are you talking?
<pitti> ah, ok
<dholbach> :)
<mvo> seb128: do you have a idea for #15361?
<\sh> pitti: is the wine stuff fixed in 20050725?
<Kamion> dholbach: er, ok, I just assumed that since one of the Ubuntu changes was a modular X.org build fix ...
<Kamion> :qa
<Kamion> (d'oh)
<pitti> \sh: http://bugs.winehq.org/show_bug.cgi?id=2715, please check
<Kamion> elmo: please sync man-db and groff
<pitti> \sh: should indeed be fixed in the existing version already
<\sh> pitti: should be...regarding your link ------ Additional Comment #4 From Marcus Meissner  2005-03-17 11:29 -------
<\sh> The misc/registry.c code is gone in CVS right after 20050310 release. 
<\sh> pitti: but I could do a new upstream version to 20050725 as well ;)
<pitti> \sh: ok, marked as fixed in Breezy; hoary could still be vulnerable
<\sh> pitti: hoary had the old wine packages..we're using now scotts
<\sh> pitti: we could ask backport team to use breezy ones...
<Mithrandir> doko: mind if I steal 14938 from you?
<doko> if you have a solution, currently investigating ...
<Mithrandir> it's the same as 14609
<Mithrandir> and it appears to be that gcj doesn't handle many input files.
<Mithrandir> or doesn't reorder input files or something like that.
<doko> the file definitely is in the ecj.jar
<Mithrandir> if you try to compile a bit fewer files, it works.
<doko> ok, that looks like a good workaround
<Mithrandir> gcj should really be fixed
<Mithrandir> doko: it's a bloody ugly workaround, though.  I'm considering just closing infinity's bug as duplicate of yours and leaving it to you.
<Mithrandir> doko: as I said, I think it's a gcj bug, but I'd like not to go completely insane, so I'm not going there. :-)
<doko> yes, it looks better in 4.1
<Mithrandir> can you add the workaround and we'll just leave it as that for now?
<doko> yes
<Mithrandir> cheers
<ogra> pitti, yes, i'm on it, could you review the remaining dependency (mimetex) ? 
<pitti> ogra: can you please upgrade to 1.5.1 or port the security fix, and mention CAN-2005-2247 in the changelog?
<pitti> ogra: I'm doing the review ASAP
<ogra> pitti, will do
<sivang> elmo: ping, got my email?
<seb128> Mithrandir: Debian has new pwlib/gnomemeeting packages, you use it right? Do you want to try if they work and do the update/ask for the sync?
<Mithrandir> seb128: I could do that, sure.
<seb128> thanks
<jdub> elmo, seb128: did ross ping either of you about python-cairo?
<seb128> jdub: no, he should? The new version PENDINGUPLOAD on my list, what's the issue with it?
<jdub> ah, ok
<seb128> jdub: blocked by freeze some days ago ... should I not upload for a reason?
<jdub> he wanted the new version :)
<seb128> ah
<seb128> new version junky :)
<jdub> no, please go ahead
<seb128> sync don't work for python stuff BTW 
<jdub> he said he'd let 90% of my blood if it didn't go in
<seb128> since Debian still has 2.3 by default
<seb128> ah ah
<jdub> and he's a bit of a closet blade fanatic
<jdub> yeah
* seb128 is tempted to not update and blame jdub for the non update :)
<jdub> heh
<Robot101> the 2.3/2.4 thing makes my sid/breezy hybrid box cry :)
<jdub> pipka will be after you for the cleaning bill ;-)
<pitti> seb128: asa long as the package is sane and uses the python metapackage, syncs should be fine
<seb128> pitti: the non versionned package points on 2.3 usually
<pitti> seb128: but the package is rebuilt for Ubuntu, and then it should become 2.4 as default
<seb128> pitti: how so? The Debian has a "Depends: python2.3-cairo (= ${Source-Version})"
<pitti> ouch
<seb128> pitti: we sed the control to change 2.3 to 2.4? :)
<pitti> seb128: that explicit version is evil, right
<pitti> seb128: nevermind then
<seb128> pitti: lot of package do that ... python-cairo Depends on python2.N-cairo
<seb128> pitti: what Depends should be used?
<pitti> seb128: dunno, I just remember many packages that use ${python:Depends} and work fine
<Kamion> python:Depends only handles python itself, not modules.
<Kamion> there is no shlibdeps-like mechanism for python
<Kamion> same goes for perl modules
<mjg59> "Dapper drake"? Oh my.
<doko> Mithrandir: which files did you translate in a separate compiler run? compiling each file for itself doesn't work neither
<jdub> shoulda been dingo ;-)
<jdub> </ferventnationalism>
<ogra> jdub+++
<Mithrandir> doko: you need to compile each file once, then retry them all, iirc.
<Mithrandir> doko: ignore failures on the first run
<sivang> mjg59: that's the code name for breezy+1 ?
<mjg59> sivang: Yes
<Robot101> ha
<ogra> sivang, read te mailing list :)
* ogra shudders "...and freeze a little longer."
<sivang> ogra: I will I will, on weekend =) hard to managet to catch on all the mails while at work..
<sivang> ogra: u-d ml ?
<ogra> u.u
<sivang> ogra: at work I'm only trying to keep with u.d ;-)
<WaterSevenUb> in which package is the "disks-admin" tool?
<ogra> WaterSevenUb, gnome-system-tools
<WaterSevenUb> ogra, thx.
<daniels> pitti: hmm?
<mvo> elmo: can you please nuke "babytrans" from the archive? it's useless without babytrans-common (dictionary files) and that seems to have no license (both are from marillat)
<dholbach> can somebody tell me if  http://bugzilla.ubuntu.com/show_bug.cgi?id=12076  really is all about metacity?
<Evaso> Benc: ping
<sivang> hey mpt 
<Evaso> who is maintaining synaptic?
<pitti> Evaso: mvo
<Evaso> mvo: ping
<mvo> Evaso: pong
<mpt> hi sivang
<Evaso> hi mvo
<Evaso> what do u think about to propose removing packages installed by dependencies on package remove?
<Evaso> if this dependencies are not needed from others installed packages
<mvo> Evaso: I like the idea a lot, there is already a experimental apt branch that supports this feature called apt--auto-mark--0
<Evaso> mvo: this also works for suggested and reccomended packages?
<mvo> Evaso: hm, I don't think so. right now only for "real" depends. are you interessted in working on such a project?
<Evaso> mvo: i doesn't know apt internals, but i would to integrate upstream version in synpatc with Dehs
<mvo> Evaso: let's move to #synaptic and talk about details, ok?
<Evaso> ok
<infinity> pitti : <poke>
<pitti> infinity: eek
<infinity> pitti : Want me to go through this universe CVE list and tell you which ones are wrong? :)
<pitti> infinity: you mean on ubuntu-cve/unfixed.html? sure, that would be nice
<pitti> infinity: I did not add them manually, it's just the fallout of automatic changelog computation
<infinity> pitti : Well, I see a lot.  Ahh.
<pitti> daniels: I had to create a symlink /usr/lib/xorg/modules/drivers/nvidia_drv.o => /usr/X11R6/lib/modules/drivers/nvidia_drv.o
<infinity> piti : 1005-1759 is a CAN we accidentaly invented due to a typo in a changelog, BTW. :)
<pitti> infinity: just saw that, a thousand year old CAN is something rare :-)
<daniels> pitti: errr ... what?
<pitti> daniels: well, yesterday I installed the nvidia-glx driver again, which drops the driver into /usr/X11R6
<pitti> daniels: but xorg does not find the driver there, all others are in /usr/lib/xorg
<Mithrandir> 7win 26
<Mithrandir> bah
<pitti> infinity: I propose to leave the CAN there as a reminder to fix it at the next php update
<infinity> pitti : Anyhow, it looks like everything against php4/php4-universe is a false positive, and the apache vulns are also false (because apache in hoary and breezy uses apache2-utils, not apache-utils)
<daniels> pitti: oh, right
<pitti> infinity: they are solved upstream in 4.4, I suppose?
<daniels> pitti: modular server
<pitti> daniels: oh, right, it should still be installed
<sivang> \sh: added a comment for you on your blog :)
<hunger> fabbione: I sometimes get the /dev/input/mouse missing after bootup problem with your kernel. Never noticed that with my 2.6.13 kernel.
<pitti> infinity: ok, I mark them as fixed; can you also add the CANs to the changelog in your package RCS?
<infinity> pitti : Yeah, the php ones are all solved in 4.4.0 (except for the XML_RPC vulns, but php4-pear no longer contains files, it just depends on php-pear from php5, which is all fixed up)
<\sh> sivang: thx :) and yes...this is what I want ;)
<fabbione> hunger: it's a udev issue. not a kernel issue
<hunger> fabbione: Your/BenC's kernel did work fine so far (after the occasional udevstart).
<fabbione> hunger: there is a bug open already
<pitti> infinity: btw, AFAICS we should remove php4-universe from the archive, right?
<hunger> fabbione: That is what I was told. I just never noticed it with a 2.6.13 kernel.
<hunger> fabbione: Maybe I am just lucky;-)
<infinity> pitti : Same story for mod_ssl.. The vuln there was fixed in .18 or .19 or something (I backported it to warty, but hoary and breezy already had the fix)
<sivang> \sh: sounds very interesting, I'll look forward to UBZ to maybe discuss thiat
<\sh> sivang: me too :)
<pitti> infinity: and you are sure that php4-universe 4.3.10-15ubuntu2 fixes e. g. CAN-2005-1921?
<infinity> pitti : Yes, php4-universe and php4-imap should go, elmo was meant to do that. :)
<pitti> infinity: ok, then I don't mark these packages manually, just php4
<sivang> \sh: but still, I think there are more things to come before, like automatic mounting of existing file systems, unversal hardware support, but this can probably grow together
<infinity> elmo : We still need php4-unive and php4-imap (source) tossed from breezy.
<\sh> sivang: well...one side is distro..the other is community..and this idea is community environment :)
<infinity> pitti : Yeah, php4-universe no longer produces any binaries in breezy (except for php4-universe-common), so I intentionally ignored it.
<pitti> infinity: ok, marked php4 and apache; thanks for the review
<infinity> On a different note, some MOTU should bribe me to fix php3 in the older releases.  I completely forgot it was there.
<infinity> pitti : libapache-mod-ssl, too.
<pitti> infinity: shall I send you a list of all apache and php related CANs I manually marked in my db, so that you can add them to the changelogs? that would rock
<infinity> pitti : If you'd like to, sure.
<infinity> pitti : When you're scanning, keep in mind to check source<->binary mappings, I think a few of those got confused.  And stuff like "apache-utils doesn't actually ship anything, so it can't possibly be vulnerable to anything)
<seb128> \sh: do you have a slow or loaded box?
<seb128> <ross> seb128: i just got another weird deleted/created: /usr/share/control-center-2.0/capplets
<seb128> <ross> i didn't touch it, honest ;)
<seb128> <ross> inotify has load issues
<seb128> <ross> the moment i start a pdebuild a load of files "disappear" and "reappear"
<\sh> seb128: when I start pbuilding then i goes up to 1 or 2 sometimes (depends)
<seb128> does the menu breakage happen then?
<\sh> seb128: but it happens also when nothing runs
<seb128> k, so that's not it
<\sh> seb128: the log files I'd attach were when I did nothing at all
<seb128> <seb128> not sure if that's gamin or inotify
<seb128> <ross> seb128: i bet it's inotify
<seb128> bah
<seb128> this bug suck
<\sh> yes it sucks
<\sh> seb128: and after all, the menus were not coming back this time :(
<pitti> doko: poppler-utils is still in NEW, btw
<\sh> seb128: and if it's really inotify we only have time until the 29th ;)
<doko> pitti: -> elmo
<seb128> what is "knotify"?
<pitti> doko: I know, I just thought you were unsure about the status
<\sh> seb128: where is it?
<seb128> \sh: I installed amarok and when starting it I had a "starting knotify" windows list entry for like 15s
<seb128> seconds
<\sh> seb128: oh...i think it's one of the magical communiction utilities of kde ;) 
<seb128> maybe the breakage is due to it
<seb128> I didn't get any issue before using it
<seb128> let's note if that change something now
<\sh> I didn't use amarok or any kde stuff 
<seb128> k, so it just don't happen on my box
<seb128> s/don/doesn/
<\sh> I'm just using the ubuntu-desktop aka gnome
<pitti> sivang: I'm just fixing the cups bug, FYI
<Mithrandir> seb128: 14903 works for me; no crash.
<Mithrandir> seb128: I see the gstreamer bug, but that's just gstreamer not having an appropriate plugin?
<jdub> ogra: http://www.gnome-look.org/content/pre3/29050-3.png
<seb128> Mithrandir: start firefox, go to http://www.apple.com/trailers/, start a trailer, press the toolbar back button ... does i crash?
<seb128> s/i/it/
<ogra> jdub, see #ubuntu-meeting ;) thanks :)
<jdub> for...?
<ogra> jdub, we just have our weekly edubuntu meeting :)
<Mithrandir> seb128: hmm, now I got it crashing, yes.
<sivang> pitti: k, cool
<seb128> Mithrandir: cool
<mxpxpod> jdub: you have a ppc machine, right?
<pitti> jordi: did you already upload mailutils to Debian without the CAN? Or did you read yesterday's mail in time?
<pitti> jordi: also, do you want to fix this in Ubuntu?
<jdub> mxpxpod: i have what we may refer to as "an excuse" for a ppc machine
<mxpxpod> jdub: heh, could you check something for me?
<mxpxpod> jdub: I'm trying to figure out if this problem is ppc only or not
<mxpxpod> jdub: first, do you have a pretty recent breezy on your ppc machine?
<Mithrandir> seb128: now I made it just hang. :-/
<jdub> mxpxpod: not atm
<mxpxpod> jdub: ok, don't worry about it
<mxpxpod> jdub: I'm trying to figure out why beagle is crashing on me
<mvo> ping jamesh
<slomo> hi... is some kind of dpkg guru here? while creating the diff.gz i get the following error http://paste.ubuntulinux.nl/2182
<bddebian> Morning
<Diziet> Blimey.  This Firefox privacy situation is much worse than I thought.
<Diziet> There a variety of different kinds of stuff it remembers about what you've been doing, any one of which could get you nailed if that's what you're worried about.
<Diziet> These all have different UI controls for clearing them.
<Diziet> Some of those controls don't clear and flush the profile to disk, so a subsequent crash undoes the clear.
<Diziet> Some of them don't have a way to clear them at all (depending on version and configuration).
<Lathiat> firefox has a big fat screen of various informations tored and a clear all button?
<Lathiat> what other stuff does it store?
* Lathiat foudn this in contrast to epiphany, where deleting things is a marathon around the UI
<Diziet> I'm reading the bugzilla.
<Diziet> Apparently in some versions `clear all' doesn't clear all.
<sivang> hey bde
<sivang> err, bddebian even :)
<bddebian> Morning sivang
<Diziet> Luckily few of those bugs are in our version.
<Diziet> Ours just has the bug that the clear search history option on the search box context menu doesn't clear the browser history (so your searches are still recorded) and doesn't flush the profile.
<Mithrandir> Diziet: any thoughts on http://bugzilla.ubuntu.com/show_bug.cgi?id=14903 ?
<Diziet> I think I'll delete the option.  It's either that or invent a new popup saying `you mean to clear your whole history then?'
<Diziet> mith: I don't have any thoughts off the top of my head, no.  I'm not sure it's worth spending an afternoon chasing it down at this stage ?
<Diziet> Our mozilla package has been unmaintained for too long.
<Diziet> firefox, I mean.
<sivang> does anybody know if elmo is up already?
<bddebian> sivang: I think I killed him with requests ;-)
<ogra> fabbione, ping
<sivang> bddebian: I hope not ;-)
<fabbione> ogra: fast pong.. i am on the way off
<ogra> fabbione, who in the kernel team is our inotify specialist ? 
<ogra> fabbione, i'll need help with 14967
<JaneW> never miss (or step out of) a meeting...  http://www.comics.com/comics/dilbert/archive/images/dilbert2002713250914.gif
<seb128> \sh: I get the bug now
<seb128> \sh: it's load dependend here
<ogra> Riddell, any thought about 14967 ? it affects all KDE apps in the GNOME menu 
<fabbione> ogra: that's not a kernel bug. it's a gamin bug
<fabbione> ogra: probably related to the same memory leak
<fabbione> or stuff like that
<ogra> fabbione, hmm
<fabbione> the inotify in the kernel works fine
<\sh> seb128: hmmm
<ogra> fabbione, but its not gamin claiming that the dirs disappear afaik...
<\sh> seb128: this bug sucks really
<ogra> fabbione, it just recieves the event fom inotify
<fabbione> ogra: gamin had the exact same issue when we were using dnotify+polling
<fabbione> gamin is crap
<fabbione> we did workaround it
<fabbione> but not for inotify
<ogra> fabbione, do you remember how ? 
<fabbione> seb128, pitti and jdub will remember
<ogra> oki
<seb128> fabbione: no
<ogra> fabbione, thanks for now :)
<seb128> fabbione: it was dropping events 
<fabbione> ogra: basically gamin sucks at keeping track of what's under checking adn what's not
<fabbione> seb128: that was a consequence
<fabbione> hmm no
<seb128> fabbione: now we get "inotify: resource /....folder/ went away" messages
<fabbione> seb128: right..
<seb128> fabbione: no reason to create events
<fabbione> seb128: check the code.. i am sure it's a gamin problem
<fabbione> see where that message comes from
<seb128> server/gam_inotify.c for gamin
<fabbione> because the code and the messages are misleading
<seb128>         if (event->mask & IN_DELETE_SELF)
<seb128>         {
<seb128>                 GAM_DEBUG (DEBUG_INFO, "inotify: resource %s went away. Adding it to missing list\n", data->path);
<fabbione> seb128: when i did the debug last time, i had to re-read the entire code and add my debug statement
<seb128> fabbione: most of the code has been rewritten and not by DV this time :)
<seb128> maybe it's better now
<fabbione> seb128: well than i dunno.. but i am not going to pick up another talk with DV.. that's for sure
<seb128> fabbione: it's probably easy to monitor a folder with inotify to make a testcase
<fabbione> and i am 99.99% sure inotify is fine
<fabbione> seb128: sure.. reduce the test case to the minum that can be reproducible
<fabbione> seb128: adding debug statement to kernel inotify is very very easy
<fabbione> it's made of only 3 functions :)
<seb128> fabbione: is there any example of inotify code somewhere?
<fabbione> not that i am aware of.. probably there are some references in the kernel code itself
<fabbione> fs/inotify.c
<seb128> k
* fabbione goes offline
<seb128> mvo: you have not played with inotify by any luck?
<mvo> seb128: no, only fam/gamin
<seb128> k, thanks anyway
<\sh> seb128: http://www.developertutorials.com/tutorials/linux/monitor-linux-inotify-050531/page4.html if it helps
<seb128> \sh: thanks
<\sh> seb128: i think u can use the example as a test case with little modifications
<Lathiat> seb128, \sh: its changed since then tho
<Lathiat> its no longer a /dev device
<\sh> argl
<Lathiat> its a ioctl or whatever
<Mithrandir> I thought there was a libinotify or something, with glib bindings and all
<seb128> no, that's libnotify
<\sh> Mithrandir: http://www.kernel.org/pub/linux/kernel/people/rml/inotify/glib/ ?
<seb128> which makes the bubble you get for updates by example
<seb128> no?
<Mithrandir> seb128: no, libinotify; what sh posted looks approximately right.
<seb128> oh, k
<ogra> hmm, we dont ahve/use it apparently
<seb128> I don't want an another layer
<seb128> the goal is to know if inotify is to blame
<Mithrandir> well, it has code you can look at. :-)
<seb128> so better to use it directly
<seb128> ah, right
<Mithrandir> pitti: ia32-libs uploaded.
<Mithrandir> and it's trivial enough that it's meaningful to look at too
<pitti> Mithrandir: merci
<\sh> seb128: /usr/src/linux-source-`uname -r`/Documentation/filesystems/inotify.txt
<netstar> what's ubuntu's equivalent to /etc/rc.d/rc.local?
<Kamion> netstar: write a new init script
<Kamion> (in /etc/init.d/) and use update-rc.d to link it into the /etc/rc?.d/ directories
<netstar> ok
<netstar> thanks
<ogra> Diziet, after you took care of firefox now, would it be possible to add native forms support to it ? http://www.gnome-look.org/content/show.php?content=28984&vote=good&tan=33542613
<ogra> (i'm requesting that since warty btW)
<Kamion> didn't thom explicitly say no to that?
<Kamion> I'm sure I remember there being some problem with them
<seb128> \sh, ogra: thanks to mvo who pointed http://www.kernel.org/pub/linux/kernel/people/rml/inotify/utils/inotify-utils-0.25.tar.gz we figured your issue is an inotify bug
<\sh> seb128: u rock :) 
<ogra> Kamion, for warty, because it wasntmature enough back then
<seb128> \sh, ogra: can you try with it if you get a DELETE events when that happens?
<ogra> seb128, YAY !!
<seb128> just untar, run ./inotify_test /usr/share/applications/kde
<Kamion> ogra: I was *sure* it was later than warty.
<daniels> /w/win 31
<seb128> and not any event
<ogra> Kamion, then it was beginning of hoary.... i gave up on it later... its a simple css extension, nothing intrusive
<Kamion> ogra: you asked near the end of the hoary cycle
<\sh> seb128: running
<ogra> i'm pretty sure a asked at least 5 times... one might have been at the end of hoary...
<Kamion> http://people.ubuntu.com/~fabbione/irclogs/archived/2005-03/ubuntu-devel-2005-03-04.html, about two-thirds of the way down
<Kamion> there was a theming problem
<Kamion> and some display problem reported by tseng - should check if that's still a problem
<Kamion> although the one you just pointed to is clearlooks rather than industrial, so I guess it won't share the theming problem
<ogra> Kamion, 02:11	<thom>	i'll try and get it in for 1.0.1 if i can
<\sh> seb128: how long did u wait? or did u make some load on your machine?
<Kamion> ogra: with comments after that
<Kamion> context is everything ...
<seb128> \sh: I started a pbuilder
<seb128> \sh: it should get the signal when your menu are hidden ... you better know how long you wait usually
<\sh> hmm..pbuilder is running working on psi 
<ogra> Kamion, even with themeing probs, its still more beauty to have clearlooks forms than crappy gtk default ones :)
<seb128> but you said is not load depened for you
<\sh> seb128: so u had the menus before...because right now, I don't have them ;)
<Kamion> ogra: ok, well it's not my call
<ogra> Kamion, i just wanted to repeat the quetion for breezy since it seems we have a ff maintainer again :)
<ogra> and the theming has oimproved it seems
<seb128> \sh: doesn't matter, mv a /usr/share/applications/.desktop to force a refresh
<seb128> \sh: but the issue is not the panel, it's inotify sending the "resource folder went away" and that happens running the panel or not ...
<\sh> seb128: ok...I just copied a .desktop to kde/
<seb128> if panel has stopped to monitor kde/ changes, that's not going to work :p
<seb128> that's why I said /usr/share/applications/
<\sh> seb128: ah...ok...so I have to restart my session
<seb128> no
<seb128> gnome-session-remove gnome-panel && gnome-panel &
<seb128> by example
<ogra> \sh, jut touch a .desktop file in applications/
<ogra> just even
<seb128> or change a file to a monitored folder
<seb128> ie: /usr/share/applications/.desktop
<seb128> panel will get this notification
<seb128> and should redraw the menus
<\sh> ok..now ;) i have my kde stuff again
<ogra> yay
<\sh> got it
<doko> Kamion: please could you process poppler-utils from new?
<\sh> EVENT ON WD=1
<\sh> DELETE_SELF (file) 0x00000400
<\sh> EVENT ON WD=1
<\sh> IGNORED (file) 0x00008000
<mvo> seb128: it's interessting that it gets a IN_DELETE_SELF and not a IN_DELETE. do you have a idea?
<\sh> seb128: and now with load on my laptop
<Kamion> doko: is elmo not around?
<doko> Kamion: no, net yet
<Kamion> meh, ok
<Kamion> doko: is it targeted at main?
<doko> yes, but it is code, which was already in main (xpdf-utils)
<Kamion> I just want to know whether I need to do the straight-to-universe dance
<doko> pitti: did you already review poppler?
<doko> oops, no, I didn't write the report ...
<Kamion> doko: I'll process this for now, but you're missing a Replaces: xpdf-utils; please add that
<pitti> doko: it's not yet in the archive, or is it?
<seb128> \sh: and you menu broken when you got it?
<Kamion> (so that the packaging system knows that poppler-utils is a complete replacement for xpdf-utils)
<seb128> mvo: not really, I don't know how inotify events work
<Kamion>  Description: PDF utilitites (based on libpoppler)
<Kamion> also typo in the control file; that should be "utilities"
<\sh> seb128: yes
<Evaso> BenC: ping
<mvo> seb128: I figured the difference between IN_DELETE and IN_DELETE_SELF is that the former is emited when a file is removed from a directory and the later if the inode goes away. but I don't see the big picture yet
<doko> pitti: the source _is_ in the archive
<pitti> doko: oh, fine
<doko> Kamion: will do
<seb128> mvo: k, so we get an event saying the folder itself got away
<doko> seb128: any word on pdftohtml?
<Kamion> doko: thanks
<jdub> mdz: around?
<jdub> hmm, not quite yet
<\sh> seb128 / mvo: what fs are u using?
<seb128> doko: it's fine with me
<seb128> \sh: ext3
<\sh> xfs here
<\sh> so there is no string in between
<mvo> \sh: AFAICS (and I'm really no expert in no way) the event is emited from the dcache, so it may not be file system specific
<doko> seb128: ok, will upload the update
<\sh> mvo: ok for now, we know now it's a kernel bug...
<seb128> doko: thanks
<jdub> dides
<jdub> dudes rather
<jdub> http://people.ubuntu.com/~jdub/2005/mdz.png (and mdz-big.png)
<mvo> jdub: ROTFL
<jdub> that is mdz's "DON'T FUCK WITH THE FREEZE" face :-)
<pitti> jdub: yay, his new hackergotchi?
<jdub> pitti: for when he gets himself a blog ;)
<\sh> jdub: lol
<sivang> lool: omg, he looks rather intimedating :)
<ogra> jdub, wasnt that look caused by Burgundavia ? iirc
<ogra> (i think he took the pic :) )
<jdub> jonmasters
<ogra> ah
<fabbione> Dapper! Dapper! Dapper!
<lool> sivang: hmm?
<ogra> fabbione, yay
<fabbione> jdub: we need a new dance!
<ogra> fabbione, a duck dance ? 
<fabbione> ogra: possibly :)
<ogra> hehe
* Diziet reads scrollback about firefox form themes.
<Diziet> You know, I'm not all that keen on messing about with making it slightly prettier when the damn thing is unstable as hell.
<ogra> Diziet, is it ?
<Diziet> What, firefox ?  Yes, it's full of bugs and probably always will be.
<ogra> Diziet, your last mail looked encouraging that its much better now :)
<Diziet> You mean my activity report ?  I'm barely scratching the surface here.
<fabbione> http://www.bearcreekgifts.com/other-collectables.htm <- pic of Dapper Drake
<Diziet> And all of the really hard stuff that's not totally essential I'm not even bothering with - just hoping upstream fix it one day.
<ogra> Diziet, i mean Firefox and Mozilla Update from -devel
<dholbach> Diziet: you think we should all sign a petition to split up the source code into modules and libraries   R S N  ?
<ogra> Diziet, waiting for upstrem can last forever...
<seb128> fabbione: turned that the bog is inotify bog
<Diziet> ogra: Um, that mail of mine is just me throwing out one of the trickier problems that upstream definitely aren't going to solve.
<ogra> Diziet, thunderbird has no rply to list until today and its at version 1.0.6 :)
<Diziet> And, for the rest, if you don't like waiting for upstream I encourage you to go fix it there.  Fixing stuff downstream here is probably a poor use of effort unless it's a really painful bug.
<fabbione> seb128: i didn't read the scrollback..
<fabbione> seb128: how so?
<seb128> fabbione: read current comment on http://bugzilla.ubuntu.com/show_bug.cgi?id=14967
<Diziet> split up the source code> You must be joking.  It already is split up internally; you'd just be asking for a versionitis nightmare.
<daniels> not if you did it properly
<dholbach> daniels HAD to answer on that one :)
<Diziet> upstream vs here> The transaction costs of dealing with _two_ bugzillas are even worse than twice the (astonishing) costs of dealing with one.  And of course we're always lagging upstream's version so there's version skew in everything we do.
<daniels> got to defend my honour
<jordi> pitti: yes, and yes.
<jordi> pitti: merge from incoming
<pitti> jordi: do you want to fix stables?
<jordi> pitti: joey has a build going now
<pitti> jordi: I mean warty and hoary
<jordi> oh. it's universe, isn't it?
<pitti> jordi: yes, that's why I ask
<jordi> pitti: I don't know what your policy is wrt that. If it can be fixed, I don't see why not.
<jordi> the patches are pretty straight forward.
<pitti> jordi: it's generally a community-based thing; as long as there is somebody who prepares the upload, I happily process it
<jordi> pitti: great. If it can be done, that would be great.
<jordi> right now mailutils is problaby not used by many, because mailx gets installed by default
<jordi> but obviously some people do, as I get bug reports for Debian
<pitti> jordi: https://wiki.ubuntu.com/SecurityUpdateProcedures
<pitti> jordi: just send me a debdiff, I take a look at it, and happy upload :-)
<jordi> what does ubuntu have now?
<jordi> or do you want a debdiff of just this (I think ubuntu had -1, current is -3)
<pitti>  mailutils | 1:0.4+20040601-2 | http://archive.ubuntu.com warty/universe Sources
<pitti>  mailutils |    1:0.6-2 | http://archive.ubuntu.com hoary/universe Sources
<slomo> can someone kick xmule to build? seems to be on dep-wait
<Evaso> hi guys: what is this
<Evaso> on boot pnp: Evaluate _CRS failed
<Evaso>  pnp: Failed to activate device 00:0
<infinity> slomo : Neither me nor lamont nick hilight on "someone".
<slomo> infinity: sorry :/ and xmule is not on dep-wait but "Not-For-Us"... what does this mean? distribution is breezy
<infinity> slomo : It means I had it frozen for the C++ transition.  Does thta mean libcrypto++ is transitioned oand built on all arches?
<\sh> seb128: u changed #14967 to unconfirmed? 
<infinity> slomo : Ahh, looks like.  Freeing it up to build, then.
<slomo> infinity: at least on x86... libcrypto++5.2c2 depends on the gcc4 stuff
<slomo> infinity: ok, thanks :)
<infinity> slomo : Yeah, "at least on i386" isn't good enough, but I just checked the others.
<\sh> slomo: did it build on all arch? 
<slomo> \sh: yes
<\sh> grmpf...and where is the bug entry?
<\sh> ajmitch: *barkbark*
<\sh> infinity: btw...yehia will be morgued
<infinity> \sh : What's the status on libyehia0.5, libxdb1, and libace?
<infinity> Oh. :)
<\sh> infinity: ace has some really nasty -fPIC recompile stuff...I tried, and bmonty...but I think it's more upstream crap 
<bddebian> I thought yehia was to be morgued?
<HiddenWolf> \sh infinity: btw...yehia will be morgued
<\sh> lol
<ogra> \sh, infinity, bddebian, HiddenWolf, yehia will be morgued 
<ogra> if you didnt know yet
<\sh> uhm...yehia will be morgued? ,-)
<Evaso> i had goot with breezy preview: prism54: Your card/socket may be faulty, or IRQ line too busy
<HiddenWolf> ogra, now thats saying it 3 times in 10 minutes. :P
<infinity> \sh, ogra : And what happens to gql?... Will it be taught to not need/want yehia, or will it also go away>
<ogra> HiddenWolf, that will certainly make it disappear finally ;)
<HiddenWolf> Evaso, please file a detailed bug. :)
<seb128> \sh: I reassigned, it does that
<\sh> seb128: ok...
<Evaso> HiddenWolf: i had filed also this bug with Hoary with the hardware tools
<seb128> mvo: still waiting for mclasen ...
<HiddenWolf> Evaso, comment that it is still in breezy, and ask on the bug what info they need of you.
<mvo> seb128: that's ok
<\sh> infinity: it will...yehia has no upstream work since a couple of years
<Evaso> HiddenWolf: at prism54 chanell doesn't know what is the problem but with ndiswrapper this card works fine.
<mvo> seb128: I'll be away for ~1h, if you hear anything I would appreciate if you could /msg it to me
<Evaso> HiddenWolf: where i can find bugs reported with the hardware gtk gui?
<dholbach> mvo: bye michael
<\sh> infinity: and if xdb builds nicely I'll upload it in a few
<HiddenWolf> Evaso, bugzilla.ubuntu.org
<\sh> actually it was mvos work ;-)
<infinity> \sh : Cool.  Want me to poke at ace on the weekend?... If so, remind me.
<\sh> infinity: u can if you want
<infinity> \sh : Down to only one lib left to transition kinda excites me. :)
<sivang> yay IPP printer detection is working again
<\sh> infinity: libhid needs some love as well...
<ogra> infinity, MOTU will give you a medal if you take ace :)
<dholbach> just morgue ace too, it's too complicated to use anyway ;)
<infinity> \sh : ... That one's not in my list.
<\sh> infinity: the last time I tried, it was also a piece of crap
<\sh> infinity: good to know ;)
<\sh> infinity: na..it's one on my bug list
<infinity> \sh : Ahh, kay... My frozenapps is down to 3 apps waiting on 3 libs.
<infinity> dbbalancer dep-wait libace5.4c2
<infinity> gql dep-wait libyehia0.5-0c2
<infinity> oleo dep-wait libxdb1
<\sh> infinity: libxdb1 u will get in 3 2 1 now ,)
<infinity> So, if I can fix the first, and the second goes away, and you're doing the third right now..
<\sh> infinity: xdb uploaded -> creating bug entry
<sivang> yay almost time to go home and then much some bugs ....
* sivang can't wait
<jbailey> infinity: oleo?
<jbailey> Like the spreadsheet?
* jbailey can't beleive it'd still be in the archive.
<\sh> jbailey: there is more software in the archive, which shouldn't be there anymore ,-)
<bddebian> Heh, no kidding :-)
<Diziet> pool/main/o/openoffice.org-amd64/openoffice.org-amd64_1.1.2-2ubuntu6.1.orig.tar.gz WTF?!
<sivang> lol
<ogra> wow, thatsancient
* ogra looksforhisspacebar
<dholbach> ogra: oh no... the dog has it... he's carrying it outside ;)
<mdz> it's in warty-security and is current
<ogra> lol
<Kamion> openoffice.org is horribly un-64-bit-clean, and at the time we didn't have sufficient biarch compiler support to build an amd64 .deb with 32-bit binaries
* ogra runsafterthedog
<Kamion> we might do now; not sure
<Diziet> And it needs a different .orig.tar.gz with the ubuntu revision in the version ?  Someone's got too much upload bandwidth to spare.
<\sh> ogra: leave the dog alone ;)
<mdz> Kamion: it's not so much the compiler support as having to mess with all of the libraries
<Kamion> oh, yeah, that too
<mdz> Diziet: it needs to be updated each time openoffice.org is updated
<Diziet> I mean, what would be wrong with  cp openoffice.org_1.1.2.orig.tar.gz openoffice.org-amd64_1.1.2.orig.tar.gz ?
<mdz> that's the point
<mdz> Diziet: the fact that it has entirely different contents
<Diziet> The _.orig_ has entirely different contents ?
<mdz> Diziet: do you suggest we put the i386 binaries in the .diff.gz?
<Kamion> the .orig contains the i386 binaries ...
<infinity> The orig has the i386 binaries in it.
<Diziet> Obviously I'm foolishly imagining that it's the upstream source tarball.
<Kamion> (as .debs, no less)
<Diziet> Cripes.
<infinity> Similar to the evil that is ia32-libs.
<Kamion> I tend to run away from it in case I get infected
<Diziet> Very wise.
<infinity> Kamion : A fine plan.
* Diziet boggles some more.
* infinity takes that as his cue to go to bed, lest he get saddled with something OpenOffice-related.
<bddebian> heh
<mdz> Diziet: this turned out to be significantly more practical than chasing 64-bin cleanliness bugs through a few hundred megs of source code
<Diziet> mdz: Um, yers.
<sivang> anyone seen elmo ?
<bddebian> sivang: I told you man, I buried him in e-mail. ;-)
<sivang> bddebian: hehe, anyway see you 1.5 hours later
<bddebian> Later sivang
<mdz> doko: ping?
<doko> mdz: pong
<mdz> doko: sent mail
<doko> ok, looking at the mime-types
<mdz> doko: also, germinate still seems confused about xpdf
<doko> mdz: no, it shouldn't once poppler-utils is available
<mdz> doko: it is available and has been for some time
<tiefox> what is the best way to install the java firefox plugin in breezy?
<doko> Source: zope2.7-archetypes
<doko> Version: 1.3.3.93-2ubuntu1
<doko> Replaces: zope2.7-cmftransforms
<doko> Depends: lynx, pdftohtml, python2.3-docutils (>= 0.3.3), poppler-utils | xpdf-utils, zope-common (>= 0.5.7), zope2.8 | zope2.7
<Lathiat> tiefox: blackdown is in multiverse i think that includes a plugin no?
<ogra> tiefox, enable multiverse, install j2se
<doko> mdz: that should work. note that the binary did enter breezy only two hours ago
<tiefox> thx ogra and Lathiat
<mdz> doko: I ran germinate 10 minutes ago
<doko> so why does it prefer xpdf-utils?
<mdz> doko: that is the question
<Kamion> cjwatson@jackass:/srv/ftp.no-name-yet.com/sync/germinate/output$ grep -c '^xpdf-utils ' ALL
<Kamion> 2
<Kamion> it's just hppa and sparc
<Kamion> (at a guess, anyway)
<elmo> it's arch: all
<elmo> I was wondering if it's because they're all currently in universe
<Kamion> poppler-utils isn't
<Kamion> poppler-utils | 0.4.2-0ubuntu2 |        breezy | hppa
<Kamion> poppler-utils | 0.4.2-0ubuntu3 |        breezy | amd64, i386, ia64, powerpc
<elmo> right, but everything else is
<elmo> I dunno if that affects germinate's DTRT algorithm for or'ed deps
<Kamion> so certainly sparc will still pull in xpdf-utils, not sure about hppa
<elmo> or if it even has one
<elmo> we don't look at germinate for hppa
<elmo> but sparc would do it.  meh
<elmo> maybe I should just drop all the non-release arches from germinate and whitelist their needed packages for main
<Kamion> DTRT> not really, although ordering within the Packages file it's given can sort of affect things
<Kamion> but only if the situation is unstable anyway
<tiefox> opra: cant find packet j2se
<elmo> yeah, excluding sparc fixes it
<doko> or fabbione should build poppler-utils with a higher priority
<elmo> of course now it wants to drop efi, elilo, silo etc.
<Kamion> the way germinate deals with ORed deps is to check whether the whole thing is satisfied by something it has in the relevant seed; if not it tries to pull in something from a further-out seed; if not it tries to add the first of the ORed deps that's possible
<ogra> tiefox, rather j2sdk, sorry i muddled re and sdk to be se
<Kamion> but you're not looking at just one package here, so if multiple packages have some set of ORed deps in a different order, then which one ends up in main depends on which of those packages gets encountered first
<Kamion> elmo: ah, the two entries were probably Ubuntu and Kubuntu then, or something
<elmo> mdz/kamion: any objections to me dropping the arch list anastacia considers to release arches and using a hardcoded whitelist of stuff to keep in main to deal with the non-release-arch-specific packages like silo etc.?
<Kamion> it would be handy if you'd run germinate in a different subdirectory for each distro/arch combination to make this kind of thing easier to debug
<elmo> as a short term hack
<elmo> kamion: I already do, mostly
* Kamion doesn't object
<tiefox> ogra: i cant find j2sdk either...and i have multiverse enable
<elmo> kamion: anastacia can choose at run time which arches to pay attention to
<Kamion> you do? where?
<doko> tiefox: j2sdk1.4
<ogra> tiefox, what gives a search for java ? 
<Kamion> cron.sync doesn't cd
<doko> tiefox: or j2re1.4
<ogra> (and this belongs to #ubuntu btw)
<Kamion> elmo: I mean when you're building the ALL etc. files
<elmo> kamion: it redirects the output to different arch named files
<tiefox> ogra: breezy questions too /
<tiefox> ?
<elmo> Kamion: and anastacia uses them rather than ALL
<Kamion> oh, right, I see
<Kamion> $ grep '^xpdf-utils ' all_*
<Kamion> all_edubuntu_breezy_sparc:xpdf-utils                             | xpdf                            | zope2.7-portaltransforms                 | Hamish Moffatt <hamish@debian.org>                                                    |         1187368 |            3148
<Kamion> all_ubuntu_breezy_sparc:xpdf-utils                             | xpdf                            | zope2.7-portaltransforms                 | Hamish Moffatt <hamish@debian.org>                                                    |         1187368 |            3148
<Kamion> that makes much more sense
<elmo> sivang: around?
<mdz> doko: why is it using zope2.7-portaltransforms  anyway; shouldn't we use zope2.8?
<ogra> tiefox, support questions dont belong here, this channel is for development, all support suld be done in #ubuntu, also breezy support
<Diziet> What should I do if I discover what looks like a problem clause in a licence in non-free ?
<Diziet> Um, universe, I mean.
<tiefox> ok..sorry
<\sh> Diziet: which package?
<mdz> 2 zopes seems like enough for main
<bddebian> elmo: I think sivang said he'd be gone for 1.5 hours or so.  Should be back in about 1 hr
<Diziet> acroread.
<\sh> isn't it in multiverse?
<Diziet> multiverse I mean of course.  Excuse my wittering.
<Diziet> But still, the licence is not one that we ought to accept, I think.
<ogra> Diziet, acroread is fine in universe... its for the nonfree stuff
<ogra> Diziet, as long as it allow distribution its fine
<ogra> allows even
<mdz> Diziet: if it allows us to redistribute it, it's OK for multiverse
<mdz> _not_ universe
<Diziet> 12. Compliance with Licenses. If you are a business or organization, you agree that upon request from Adobe or Adobe's authorized representative, you will within thirty (30) days fully document and certify that use of any and all Software at the time of the request is in conformity with your valid licenses from Adobe.
<ogra> err s/uni/multi inseed
<doko> mdz: no, the package name was choosen, because the versions for 2.6 and >2.6 were needed together in the archive. zope2.7-portaltransforms does work with 2.8 as well.
<ogra> damned, cant type today
<Diziet> AFAIAA we (Canonical) have no mechanism for responding to such a request.
<\sh> Diziet: Ubuntu != canonical, or?
<Diziet> The file is on Canonical's servers.
<Diziet> But if that doesn't count (it's not clear whether Canonical had to agree to the licence for that) then fine.
<\sh> Diziet: then it's forbidden for all mirrors to distribute this file
<Diziet> Clearly, however, I can't agree to the licence when I'm doing paid work for Canonical.  So I ought to close the bug with `can't investigate' ?
<ogra> not only ubuntu...
<Diziet> ogra: Quite so.  But one thing at a time ...
<Diziet> \sh: Well, perhaps the mirrors have some other licence (an implied one perhaps).  The bit I'm quoting is in the clickwrap that turns up when you try to use the mozilla plugin.
<\sh> Diziet: no what I mean, is distributing...
<Diziet> Yes, I know what you mean.  We seem to be talking at cross purposes.
<ogra> anyway, i doubt adobe ever asked someone for the stuff above... as long as you dont try to make money with it
<Diziet> ogra: I'm not in the habit of agreeing to bad small print just because `it probably won't be enforced'.
<Diziet> And in any case, it's not my decision to make.
<ogra> nope, mine neither
<Diziet> My question is really, what's the correct forum for this discussion ?
<ogra> and i thin it already happened when it entered multiverse... i know how hard it is to get nonfree stuff past elmo :) he has eagle eyes
<Diziet> At this rate I'll end up crossposting to ubuntu-devel and debian-legal.
<elmo> what's it got to do with debian?
<Diziet> I don't know yet; I'm checking.
<Diziet> Looks like acroread isn't in Debian.  So it's just an Ubuntu problem.
<elmo> the package in multiverse was imported from Marillat
<elmo> Debian doesn't have it
<Diziet> Marillat is full of semidodgy stuff, isn't it ?
<HiddenWolf> it is
<elmo> Diziet: yes
<bddebian> Moreso than aptget.org? ;-)
<Diziet> So should I post to ubuntu-devel, do you want to talk about it here, or what ?
<Kamion> bddebian: yes
<Kamion> (generally)
<bddebian> elmo: Hey, what's the deal?  All those syncs I send you and you just to pkerns? :-)
<elmo> Diziet: is this from the acroread package itself?
<elmo> Diziet: because the copyright file in the package doesn't have that kind of onerous clause
<Diziet> It's either from acroread or mozilla-acroread.
<elmo> of course the copyright file bears no relation to reality
<elmo> "#!$%
<Diziet> There's a file in mozilla-acroread that contains the text it's displaying to me.
<Diziet> And another in acroread.
<Diziet> /usr/share/doc/acroread/LICREAD.TXT.gz
<elmo> yeah, I think I only checked debian/copyright in the source, which was clearly a mistake
<Diziet> It's clause 12 (see my quote above) that I think is the problem.  (I stopped there and haven't read the rest.)
<Diziet> Hrm.  It looks like Adobe changed the licence and the packager didn't update .../copyright
<neiras> Hello, I am experiencing the "no default font 'fixed'" X issue that a number of other Breezy testers are having. Can anyone here tell me how to get my X fonts working again?
<bddebian> Chirst, wtf is up with libextractor...
<Lathiat> what about it?
<Lathiat> i thought i fixed that
<ogra> neiras, thats an #ubuntu question, but i'd generate a clean xorg.conf if i were you
<bddebian> Lathiat: Fixed what?  I am trying to build 0.5.4 from Debian unstable and it's taking FOREVER
<Lathiat> bddebian: heh
<dholbach> have a nice evening everybody, see you tomorrow
<neiras> ogra, asking in #ubuntu. I've had several clean xorg.confs and stripped my system down to ubuntu-minimal, then reinstalled everything with no dice
<neiras> all I did was dist-upgrade! *sob*
<jdub> jbailey: did you see the thread on u-d about the dude with the fusion mpt card having initramfs probs?
<jbailey> jdub: I did, I'm going to reply in a few moments with a test initramfs-tools for him to try.
<jdub> rad!
* mpt often has memory problems
<jbailey> mpt: Careful, one of us will lay you on our bench and...
<ogra> mpt, eat more vitamins ;)
<jbailey> Wait, what were we talking about?
<jdub> mr fusion
<mpt> Mr Fusion? That's from Back to the Future, right?
<jdub> aye
<mirak> jbailey: hi
<mirak> jbailey: can I take a bit of your time ?
<jbailey> mirak: Sure.
<mirak> jbailey: I have you are in charge of ubuntu ppc
<mirak> heard
<jbailey> Eh?
<jbailey> Don't pin that on me. =)
<mirak> what ? :)
<jbailey> Ne me donne pas a. =)
<mirak> lol
<mirak> it means nothing
<mirak> :)
<mirak> hard communication
<mirak> jbailey: I have a problem with the kernel
<jbailey> I have two ppc boxes, so I tend to care about it more than some other do, but it's a supported arch for us.
<mirak> do you havge knowledge avout that ?
<mirak> what are you box ?
<jbailey> I am unlikely to be able to help you much with the kernel.  I can help with bootup/hotplug and such.
<mirak> bootup ?
<mirak> the problem I have is at boot time
<jbailey> mirak: I try to avoid giving lists of my equipment to help random googlers decide what to steal from me.
<jdub> that's jbailey's speciality :-)
<mirak> I own a G3 and a G4
<mirak> a G3 b&w
<mirak> the G3 b&w have a problem with breezy
<jbailey> What sort of problem?
<mirak> you there is two ide controlers on this box
<jbailey> Hmm.  Are all G3's oldworld?
<mirak> the cmd646 and something else
<mirak> no it's a newworld
<jbailey> 'k
<mirak> well, seems the module doesn't load
<mirak> in the kernel it's built as a module, so it should be in the intird 
<jbailey> 'kay.  Reboot and add the word 'break' to the kernel command line.
<jbailey> We need to check to see if it's loading at all.
<mirak> I can't do that right now
<jbailey> We can tell by doign an 'lsmod'
<mirak> I can control the computer remotely
<jbailey> "I can't do that right now, Dave"
<mirak> but it's 300km away from me
<mirak> at my mums place :)
<jbailey> Ah.
<jbailey> Will you be near it sometime soonish?  It's quite difficult to test boottime stuff remotely unless you have remote power and serial console setup.
<mirak> I don't have that
<mirak> what kind of box do you have ?
<mirak> jbailey: you know on the G3 b&w there is some troubles with the two ide controlers.
<mirak> it can happen that they switch letters
<mirak> depending of wich ide module is loaded first
<jbailey> letters?
<jbailey> Right.
<mirak> /dev/hda
<jbailey> We load them in pci bus order as shown in /sys
<mirak> so my system is always on /dev/hdc
<jbailey> mirak: If they initialise in different order randomly, I suggest you use LVM for your root volume and swap.
<mirak> well that's not random
<jbailey> Dapper will support volume names for plain volumes, but udev grew that feature after UVF
<mirak> ah
<mirak> what I can do is build a kernel with the module included in it
<mirak> built in
<mirak> but I exept it will switch drives
<mirak> i might try another binary, maybe it's fixed
<mirak> my mom can reboot the computer ^^
<jbailey> Well, if you'll be near the box soonish, it would be nice to know why the ide module isn't detected right.
<bddebian> jbailey: Maybe because it's SCSI? ;-)
<jbailey> bddebian: On a cmd646 chip?
<bddebian> Oh, hehe, missed that part :-)
<bddebian> elmo: Thanks for those.  Did you get my responses about vipec and oregano?  I'm wondering if my mail client at work is getting through?
<bddebian> We don't have guile-1.6??
<bddebian> Anyone, anyone, Beuhler?
<bddebian> Never mind
<ploum> Hello
<ploum> I've seen that OOo 1.1.5 is released. Will it makes to Breezy ?
<ogra> ploum, breezy uses ooo2
<ploum> ogra, yes, but I'm talking about universe
<ploum> For example, I've an old laptop here where there's no room left to install OOo2 ! (and I'm not sure it will even start, it's so heavy)
<ploum> But I think that I must be able to read odt file...
<ploum> So I'm asking if this will be a "freeze exception" or not
* ploum hates OOo2 as much as he hates OOo1.. very disappointed
<tseng> oo2 replaces oo1 on a clean breezy install
<ploum> this is not the question..
<ploum> my hardware cannot run OO2
<mdz> mvo: ping
<tseng> i seem to read that you didnt even try to start it
<tseng> but you have your answer.
<mvo> mdz: pong
<mdz> mvo: never mind, assumed you were gone and sent mail
<ploum> tseng, I've only 2Go on this computer..
<mvo> mdz: about #15361? sorry, my comment was badly worded
<mvo> mdz: oh, usplash, just got the mail, reading now
<ploum> and it takes 2 minutes to start OOo1.  I know it's not very mathematic, but OO2 si 1.5x slower on my main computer..
<ploum> so I guess it would be 3 minutes ;-)
<ploum> anyway : usplash is not working on this computer. It's a very old config. Must I file a bug about this or not ?
<mdz> mvo: also, your changes to console-screen.sh seem to kill usplash
<mvo> mdz: how so?
<mvo> mdz: I tested it here localy
<mdz> mvo: 15344
<mvo> mdz: thanks, I'll have a look now
<mdz> ploum: depends on whether you enabled it, and what the failure mode is
<mdke> what is up with this: http://davyd.ucc.asn.au/images/af/af-shot2.png Is that for real?
<mdz> seb128: the gdm slowness issue is something to do with how the background is drawn; I see it here too
<Burgundavia> mdke, that looks like a great prank
<Burgundavia> mdke, here is another one http://jrb.webwynk.net/files/evince-sponsor.png
<mdz> seb128: did something change from bitmap to svg or something like that?
<mdke> Burgundavia, ok just a prank then
<ogra> mdz, nothing changed in the artwork
<seb128> mdz: not that I known of
<Burgundavia> mdke, notice the doc creation date (april 1st)
<mdke> Burgundavia, ah, now I see what af means
<seb128> s/known/know/
<seb128> mdz: maybe gtk/cairo ...
<ogra> seb128, what does gdm use to draw the fullscreen background ? cairo, canvas ?
<seb128> mdz: cairo has created slowdown for some stuff
<mdke> by the way I installed poedit on Breezy today, and I noticed that it is not using gtk2, but gtk1, is that intentional? it's real ugly
<mdz> isn't cairo a vector graphics package?
<seb128> right
<mdz> seb128: I see this everywhere, on completely different hardware,  so I don't think it's X related
<mdz> it's completely cosmetic of course, but it gives the impression of slowness :-/
<ogra> its very likely that its cairo...
<mdz> people will say that the entire system is slower because it makes them feel this way
<seb128> it's the kind of issue not easy to track since it's subjective
<ogra> probably svg artwork would help
<mdz> it's  basically scaling a bitmap and drawing it on the screen
<mdz> should
<mdz> be very quick
<mdz> seb128: are there any simpler programs which use cairo to do this, so that we can more easily compare and profile them?
<seb128> one stuff to try for somebody noticing the difference with hoary would be to run gdm with GTK 2.6 and 2.8
<mdz> seb128: do you have the bug# for this?
<seb128> #
<seb128> Ubuntu | gdm
<seb128> ------- Additional Comments From carey@internode.on.net  2005-09-14 09:25 UTC -------
<seb128> The thing is, I have a very fast system and gdm loaded as such in Hoary. I would
<seb128> have thought this problem would be worse for slower machines. Not sure however.
<seb128> IMHO, it's not so much the time, it's the uglyness :).
<seb128> But yes, definitely not a high priority problem.
<seb128> -- 
<seb128> Configure bugmail: http://bugzilla.ubuntu.com/userprefs.cgi?tab=email
<seb128> ------- You are receiving this mail because: -------
<seb128> You are the assignee for the bug, or are watching the assignee.
<seb128> grrraaa
<seb128> ups
<mdz> hehe
<seb128> http://bugzilla.ubuntu.com/show_bug.cgi?id=15373
<mdz> thanks
<seb128> np
<bddebian> Any of you main folks have a problem syncing libdv 0.104 from Debian?  It closes a Malone bug but it would be a UVF exception I think
<seb128> gdm doesn't use cairo directly, it uses GTK which uses cairo
<bddebian> elmo: ping?
<mvo> seb128: speaking of gtk+, did you had any luck pinging mclasen?
<mdz> seb128: so someone could install hoary, change sources.list to breezy, update, install gdm
<seb128> mvo: not yet, I'll let you know
<ogra> bddebian, "mdz ping" would be the right term rather if you want to request a UVF breakage ;)
<seb128> mdz: it will take gtk with it since the shlibs has been updated
<bddebian> ogra: No, this is different.  But I guess I should be used to being ignored ;-P
<bddebian> lirc isn't a main package is it?
<seb128> mdz: somebody could build GTK 2.6 and try with it or somebody could install an hoary and build the current gdm on it, it doesn't require any new GNOMish stuff
<mdz> bddebian: apt-cache madison
<ogra> bddebian, you talked about libdv (libdv4 i guess)
<Kamion>       lirc | 0.7.0.1-1ubuntu2 |        breezy | source
<Kamion> yes, it is in main
<bddebian> Oh, it's in both
<Kamion> (due to liblircclient0 and liblircclient-dev)
<bddebian> Fuxxor
<mdz> the lirc binary package is in universe, the source and libs are in main
<mdz> no, that's quite intentional
<bddebian> Well both lirc and libdv have bugs on Malone asking for newer versions.
<mdz> bddebian: which packages could potentially be affected by changing libdv?
<ogra> kino
<mdz> bddebian: is there any rationale besides "it's newer"?
<mdz> ogra: nothing else?
<ogra> kino from the top of my head
<ogra> hmm, maplayer and friends it seems in the rdepends
<ogra> mplayer even
<ogra> gstreamer0.8-dv
<ogra> thats a lot
<seb128> mdz: first thing to try would be to build current gdm on hoary, it's fast and easy
<bddebian> mdz: "libdv 0.103 is not optimized for x86-64, and so is dog slow (i.e. cannot decode in real-time). libdv 0.104 has been out for many moons now, and there is a package in debian unstable. If it is at all possible, having libdv 0.104 in breezy would be great."
<mdz> seb128: ok, please add simple instructions to the bug if you could
<ogra> looks like that pulls a small multimedia apps transition on its tail bddebian 
<seb128> mdz: k, doing this
<bddebian> ogra: OK, NP.
<ogra> bddebian, apt-cache rdepends libdv4
<bddebian> Here is lirc "I would like to see lirc upgraded to the latest version. This adds support for the Hauppage PVR-250 and PVR-350 infrared capabilities, which are very popular among MythTV users."
<phlaegel> that new lirc version would be very useful to me as well, if another vote makes a difference :-)
<seb128> mdz: what setting would you use for #14763? 3 people have reported the issue, seems that GDM simply doesn't work with ldap atm which is annoying
<bddebian> rdepends for lirc:   vdr
<bddebian> , lirc-x, lirc-x, lirc-modules-source, irmp3, liblircclient0
<ogra> YAY
<ogra> Some good news with Edubuntu 'Preview' release: installation now works
<ogra> with my Serial-ATA disk on the AMD64 machine. :-)
<ogra> :-D
<bddebian> ogra: Nice
<ogra> from a mail i just got :)
<mdz> bddebian: it has new features, and it doesn't seem to contain any bugfixes.  it's hard to think of a clearer example of a new version that we don't want ;-)
<bddebian> mdz: OK, fine with me, just saw those when digging through Malone bugs.  Thx.
<mdz> bddebian: (referring to libdv)
<mdz> I haven't looked at licr
<bddebian> Ohh
<mdz> bddebian: take a look at the changelog and see what's there
<bddebian> mdz: For lirc?
<torkel> bddebian: what? I'm pretty sure the version in breezy already supports -250 and -350
<bddebian> torkel: Possible
<mdz> bddebian: yes
<bddebian> mdz: Here are the two Ubuntu changelog entries: lirc (0.7.0.1-1ubuntu2) breezy; urgency=low
<bddebian>   * md5sum from coreutils doesn't have -v, so drop that for now.
<bddebian>  -- LaMont Jones <lamont@ubuntu.com>  Sat, 23 Jul 2005 13:33:16 -0600
<bddebian> lirc (0.7.0.1-1ubuntu1) hoary; urgency=low
<bddebian>   * remove svgalib1 Dependency completely.
<bddebian> Has there been anymore discussion/decision about dropping yehia?
<ogra> bddebian, look if oyu find something about -{2,3}50
<bddebian> Ohh
<mdz> bddebian: what I meant was that you should read the upstream changelog and debian changelog
<mdz> bddebian: the purpose is to learn which changes you are proposing that we include in breezy
<bddebian> mdz: Honestly I'm not proposing anything.  I was just trying to close some bugs and initially hadn't realized this was a main package.
<ogra> bddebian, re yehia, yes... we'd like to morguify it
<ogra> upstream is dead since years
<bddebian> ogra: elmo was questioning it because of several rdepends.  Of course man of them are gql which also sucks. ;-)
<ogra> bddebian, did anyone try to build it with gcc3.4 as last resort ? 
<bddebian> ogra: You mean yehia/etc?
<ogra> yup
<bddebian> I haven't no but if they are dead, why keep them?
<ogra> because someone might want them ? 
<bddebian> Fair enough
<ogra> if its only a compiler issue, we could still keep it for breezy
* bddebian wonders how he is getting drug into this.. :-)
<ogra> s/for breezy/as long as we have a gcc3.4
<bddebian> Well someone just let me know if I should do something/anything about any of this.
<Surak> Hello, could someone help me on problems with latest totem in today's breezy?
<Surak> It outputs this when I run it under gdb and I try to open a dvd:
<Surak> Program received signal SIGFPE, Arithmetic exception.
<Surak> [Switching to Thread -1231230032 (LWP 20650)] 
<Surak> 0xb665cd07 in gst_ffmpegdeinterlace_register () from /usr/lib/gstreamer-0.8/libgstffmpeg.so
<Surak> This is happening with the only two DVDs I have here...
<seb128> Surak: gstreamer0.8-ffmpeg bug
<Surak> is this known? should I open it?
<seb128> it's not known, no
<seb128> you can open a bug with the backtrace
<seb128> debug backtrace is better
<Surak> ok
<seb128> bugzilla.gnome.org is better too :)
<seb128> that's an upstream issue probably
<seb128> if you open a bug on ubuntu use malone, gst-ffmpeg is an universe package
<Surak> allright. The strange thing is, it is happening with some recent daily builds, after the freeze. That's why I'm asking here before posting right into gnome.org
<seb128> is that new?
<Surak> yes.
<seb128> gst-ffmpeg has been update from 0.8.4 to 0.8.6 a few days ago
<seb128> you can try downgrading the gsreamer0.8-ffmpeg package
<seb128> and note on the bug if that fixes the issue
<Surak> ok
<Surak> seb128: the downgrade made it work
<Surak> will it worth something to add it into ubuntu's malone also?
<Surak> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=316341
<seb128> Surak: thanks
<HiddenWolf> seb128, is there an option to unmount volumes from within nautilus?
<seb128> Surak: could you just put a comment saying it doesn't happen with 0.8.4 ?
<Surak> sure
<seb128> HiddenWolf: computer:///, right click, umount
<HiddenWolf> seb128, ah, thanks. ( I was expecting an unmount button/rightclick action on the places sidebar, or a menu option)
<Surak> talking on unmount, the places menu should have the right-button ability for mounted units . You can only eject a mounted cd with its desktop icon or by opening the "computer" window.
<shawarma> I have a patch for the gstreamer packages that enables the mms plugin. It requires libmms, which I've also packaged (and uploaded to REVU (the MOTU review site))... But since gstreamer is in main, libmms also has to be in main if gstreamer depends on it... How should I handle this?
<shawarma> Should I just start out by wating ~1 month? 
<seb128> there is a wiki procedure for that
<seb128> https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<seb128> do what is written here
<shawarma> Right. So get libmms into main first, submit my patch for gstreamer afterwards. right?
<seb128> no need of the patch, it's quite trivial and there is a bug open about it
<seb128> just package the lib and get it moved
<seb128> then I'll upload a package using it
<seb128> thanks :)
<shawarma> Ok.. But not until after the Breezy release, I suppose?
<shawarma> And yes, the gstreamer patch was definitely the easiest part. :-)
<shawarma> seb128: Thanks for your help! Gotta go!
<Evaso> BenC: ping
<ctw> Hi! I installed the Breezy preview on a HP Pavilion dv1000 notebook and have some issues with suspend to ram/disk (apprently both worked fine in Hoary). Would anybody here be interested in more details or be willing & able to help out?
#ubuntu-devel 2005-09-20
<mdz> doko: the hplip /etc/default change seems to trigger a conffile prompt
<mdz> ctw: apparently?
<mdz> ctw: if you can confirm that it worked in hoary, then it's almost surely a bug, and you should file it in Bugzilla
<mvo> mjg59: is it a bug or a features that usplash exits if the vt is switched? 
<ctw> mdz: I haven't tried it myself, but several users have posed in the forums that it worked out of the box and the following site has a wiki entry that suggests that it did work: https://wiki.ubuntu.com/HoaryPMResults
<mdz> ctw: it's difficult to confirm that you have exactly the same components; it would help if you could test it
<mjg59> mvo: Feature
<ctw> mdz: it wouldn't work with a live-cd, would it?
<mdz> ctw: suspend-to-ram ought to, but certainly not hibernate
<ctw> it seems that the components in the dv1000 are very similar
<ctw> not much room to customize ...
<ctw> I'll give the live cd & suspend to ram a shot
<ctw> mdz: I've never filed a bug-report before, but found what looks like a very similar bug: http://bugzilla.ubuntu.com/show_bug.cgi?id=15141
<mdz> thanks
<ctw> albeit for a different computer
<ctw> computer - model
<elmo> FINALLY
<elmo> empty breezy_probs.html
<mvo> mjg59: thanks
<mjg59> elmo: Want to take my bugs?
<elmo> mjg59: dude, distro isn't even my job, I'm just ADD
<mjg59> Damnit.
<mjg59> You're quite happy to take part in prank calls, but will you accept the consequences? Nooooooooooooooo.
<elmo> for versions of "take part in" meaning "be in the same room as"? :P
<emile> i filed my first 2 bugs tonight, one of them has a comment added. I'm not exactly sure if i should respond or give any more info (http://bugzilla.ubuntu.com/show_bug.cgi?id=15427)
<mdz> emile: that comment was not directed at you
<emile> ok thanks
<mjg59> elmo: Bah. You're entirely in on it.
<mdz> elmo: there is blood on your hands
<elmo> lamont/infinity: around ?
<mdz> mjg59: do you already have the fix for #6108 queued?
<mdz> s/fix/workaround/
<mjg59> mdz: Nope - sorry, when you suggest a fix that's not in a package I've ever touched, I tend to assume that means you'll upload it :)
<mdz> mjg59: I suggested  a workaround in acpi-support, actually
<mjg59> Oh, argh, is it in there? I thought it was in the laptop-mode script.
<mdz> anyway I've done it and will mail you a diff
<mjg59> The bug is against linux. Hm.
<mjg59> Ok, thanks
<mdz> mjg59: our best guess at present is that there is a bug in linux, but meanwhile we can do something about it in acpi-support
<elmo> mdz: is it okay to use "touched it last" in assigning FTBFS or shall I leave bugzilla's defaults alone?
<mdz> elmo: trust your judgement
<mjg59> mdz: Yeah, ok
<mjg59> Sorry, I'm dealing with an absolutely huge number of bugs at the moment
<elmo> mdz: you realise if you say "use the force" or call me "luke" I'll never talk to you again, right?
<mdz> mjg59: is there anyone in the laptop team community who we might be able to recruit to help with those?
<mdz> elmo: ok, young jedi
<mdz> reach out with your feelings
<mjg59> mdz: Not that I could pick out now, not really I'm afraid
<elmo> configure: error: Your system is not supporting pthreads
<elmo> autoconf owns
<mdz> supporting pthreads your system is not
<elmo> grr, I wish people would check their uploads freakin build
<mbreit> elmo: if i want you to sync something, can i tell you here or should i write you an email?
<elmo> mbreit: tell me here - mail me if I don't acknowledge it here
<elmo> do we still need tla in main? :)
<ogra> mjg59, does usplash react on log_failure_msg ? or what do i need to do in the init script to make sure it switches back to console ? 
<mbreit> okay... so could you sync ardour from debian unstable? should be version 0.9beta29-5... thanks!
<slomo> elmo: did you already read my mails? ffmpeg and removal requests? ;)
<mjg59> ogra: usplash_write "QUITQ
<ogra> mjg59, thanks
<ogra> i assume thats "QUIT" ?
<mjg59> Yup
<ogra> :)
<elmo> mjg59: should hotkey-setup work on amd64?
<elmo> slomo: not yet
<Evaso> mbreit: i think that ardour-0.0beta30 is quite more usable
<mbreit> Evaso: i would prefer not breaking UVF if there is no good reason ;)
<mbreit> Evaso: and upgrading, testing and so on would take much time... so i would like to concentrate on fixing bugs first... and we have so much bugs to fix in universe....
<mjg59> elmo: Uhm. Ought to.
<Evaso> mbreit: ok but i doesn't know if beta29 is quite usable
<Evaso> mbreit: there a quite impressive upstream changelog fix
<mbreit> Evaso: but we have so many packages that are not even installable... and i would like to deal with them first...
<Evaso> seems also that gstreamer-ffmpeg doesn't work on amd64 it crash totem when it require this  backend to play files
<mbreit> Evaso: and beta30 is not in unstable yet
<Evaso> mbreit: i know..
<mbreit> Evaso: is it okay for you if i let elmo sync beta29 for now so it gets installable again? i will have a look at beta 30 when we have our unmet deps list empty?
<Evaso> mbreit: ok, if it could be help you later this is the quite impressive list of fix of beta 30 http://ardour.org/news.php
<mbreit> elmo: so could you sync it?
<mbreit> thanks elmo!!
<lamont> elmo: sup?
<jdub> GOOD MORNING FREEDOM LOVERS!
<tseng> jdub: you keep leaving me out.
<Robot101> jdub: moin
<tseng> hey robot
* Robot101 has ired his housemate intensely by erecting a desk and plugging in his computer at about midnight
<whiprush> yay freedom!
<tseng> whiprush: jdub doesnt include us, dude
<tseng> whiprush: we own ipods
<Robot101> and he's been bitching about me on other IRC channels for "breaking the network for the 2nd night in a row". sigh.
<daniels> my iaudio has non-free firmware on it.
<daniels> Robot101: so you're bitching on IRC about him bitching about you on IRC.
<tseng> daniels: you are a terrible person
<jdub> tseng: GOOD MORNING DELUDED RIGHT WING CONSERVATIVES!
<whiprush> heh
<Robot101> daniels: yes, but none of you know him, so it's fine :)
<jdub> oh.
<tseng> jdub: thanks.
<jdub> the ipod thing!
<whiprush> CONFIRMED: Breezy64 on Ultra 20 = works.
<tseng> whiprush: elite
<tseng> whiprush: now get the 1u x64 box
<whiprush> I got the hp 1u instead, with dual dual cores. It's metal.
<tseng> whiprush: im using breezy64 on the dell pe2850 (the box they claim be totally blow away)
<tseng> they just hate my freedom
<whiprush> heh.
<HrdwrBoB> the DL145
<whiprush> yep, gen2.
<tseng> i dont think i have any of those
<tseng> i have some older 1u compaqs
<tseng> (proliant)
<HrdwrBoB> we're going with the DL345s
<HrdwrBoB> do the 145s have ilo?
<whiprush> yeah
<whiprush> the entire line comes with ilo. If you call your hp guy they'll even put debian on it for you.
<HrdwrBoB> yeah
<HrdwrBoB> thought so
<elmo> no they don't
<elmo> DL140's don't have management hardware by default
<HrdwrBoB> elmo: that was the impression I got from the website
<HrdwrBoB> the 345's have ilo
<HrdwrBoB> the 145's don't
<elmo> and the management stuff on the 145 isn't anything like the stuff on the real HP hardware
<elmo> (140 and 145 are basically not real proliant hardware)
<elmo> HrdwrBoB: what's a 345?
<tseng> \sh_away: your jabber server kicks me off constantly
<HrdwrBoB> eer 385
<daniels> elmo: i think he meant 385
<daniels> yeah
<whiprush> hmm, well, my stuff came with ilo and I didn't ask for anything.
<whiprush> the webstore says the dl140 comes with ilo.
<whiprush> or is lights out 100i remote management something else?
<elmo> 100i remote management is nothing like a proper ilo, no
<whiprush> ah.
<elmo> but yeah, apparently DL140 G2's now have the 100i RM
<elmo> G1 didn't
<jdub> mjg59: ha ha ha ha
<jdub> whiprush: are one or both of us not registered?
<whiprush> probably me
<whiprush> I registered before
<jdub> elmo: did you get my /msg too?
<jdub> gawd feenode is offensive
<tseng> jdub: i noticed you didnt set umode +E yet
<tseng> jdub: have 6 global messages about it.
<jdub> what's +E?
<tseng> jdub: AND THANKS FOR USING FREENODE
<whiprush> +Ediocy
<tseng> that was the no-msgs-from-unauth-users tag
<tseng> until in his infinite wisdom
<tseng> it became server enforced default
<jdub> whiprush, elmo: so neither of you got my /msg in the last few minutes?
<whiprush> I just got yours
<jdub> oh
<whiprush> I see you're not getting mine.
* tseng smells something coming from The Fridge
<jdub> nup
<whiprush> tseng: lilo's frozen corpse.
<jdub> tseng: ;)
<tseng> whiprush: r0x0rz!!!1eleventy
<tseng> whiprush: oh dude
<tseng> whiprush: are you rocking out to slomo 's banshee package?
<whiprush> yessir
<tseng> rad
<tseng> mdz: that hdparm -B thing doesnt fix my dell very hard
<tseng> mdz: let me find that bug again.
<mdz> 6061 I think
<mdz> no 6108
<tseng> hm oh @ comment #55
<mdz> tseng: are you absolutely sure your drive isn't operating in APM mode?
<tseng> mdz: i absolutely have no idea
<tseng> mdz: could it get this way on a week old install with no intervention?
<mdz> tseng: try leaving laptop-mode enabled and doing an explicit hdparm -B 255 after switching to battery
<tseng> mdz: sure
<jdahlin> I'm not sure if this is the right place to ask, but is there a way to upload custom acpi DSDT images on recent breezy kernels?
<mdz> jdahlin: no, it isn't, but yes, there is ;-)
<tseng> mdz: done, we'll see
<mdz> jdahlin: /etc/mkinitramfs/DSDT.aml
<jdahlin> mdz: does that involve creating a custom initrd image?
<jdahlin> or is just dropping the file there enough?
<mdz> jdahlin: just drop the file there
<jdahlin> ok, thanks!
<mdz> jdahlin: then sudo dpkg-reconfigure linux-image-`uname -r`
<tseng> mdz: locking after hdparm -B 255
<mdz> tseng: stumped
<tseng> mdz: i still point an angry finger at laptop-mode
<tseng> mdz: i can look more another day if you post ideas via the bug
<fabbione> morning guys
<jdub> Fetched 158MB in 22s (7041kB/s)
<jdub> Xlib: connection to ":0.0" refused by server
<jdub> Xlib: No protocol specified
<jdub> 
<jdub> ^ after an apt-get upgrade, just before templates/apt-listchanges
<jdub> http://www.gizmodo.com/gadgets/laptops/index.php#lenibmovo-widescreens-launched-125477
<jdub> ^ interesting new ibm lappies
<Lathiat> jdub: Z series thinkpad?
* fabbione is totally demoralized
<Lathiat> fabbione: ?
<fabbione> Lathiat: i can't get my ws to work
<fabbione> and i don't understand what is wrong
<Lathiat> ws?
<fabbione> workstation
<fabbione> keeps powering off by itself of do random crashes
<Lathiat> ah
<fabbione> ram has been tested
<fabbione> all possible hw other than mobo/cpu swapped
<fabbione> if i leave only CPU/MOBO and ram it works
<fabbione> each single card works
<fabbione> i really don't get it
<Lathiat> could be a MB issue
<Lathiat> interacting badly with more than 1 card etc
<Lathiat> or perhaps it just hates you!
<Lathiat> i hate problems like that
<fabbione> so do i
<fabbione> but the mobo had the same hw mounted on for 4 years
<fabbione> more or less...
<Lathiat> things do just die
<fabbione> no shit
<Lathiat> sound slike your situation is sucky tho
<Lathiat> fabbione: can you get a certain combination of cards to work?
<fabbione> no
<Lathiat> so any 1 card works, any 2 doesn't?
<Lathiat> or all cards work in another machine?
<fabbione> somtimes it does, sometimes it doesnt...
<Lathiat> heh
<fabbione> i can't plug all the same cards in other machines
<fabbione> not all together at least
<fabbione> but it's the poweroff that's scary
<fabbione> why should it power off?
<Lathiat> if you get a chance try swapping the m/b i guess, i've had similar problems as a result of the m/b sucking
<Lathiat> fabbione: what it powers itself off if its not working?
<daniels> i'd be looking at the power supply, myself
<Lathiat> mmm yeh thats likely too
<fabbione> daniels: changed that too
* Lathiat hates everytime hes ended up in situations like this
<fabbione> Lathiat: well but it's not powering off always at the same point
<fabbione> yesterday it lasted 11 hours
<fabbione> this morning 10 minutes
<Lathiat> was fixing this old computer for someone once.. was freezing.. then i *moved* it.. stopped workign all together, swapped all manner of cpu/mobo configurations etc nothing woudl work.. after messing around for a few days i managed to find a combination that worked and left it, hope i never touch that again :)
<Lathiat> fabbione: mmm
<schweeb> good work guys... I can suspend-to-disk on my ibm x41, and that rules
<doko> mdz: the hplip prompt is only triggered, when upgrading from the preview/colony cd. how to avoid it?
<mdz> doko: what caused it?
<doko> mdz: when derootifying, I introduced a RUN_AS_ROOT variable, which I dropped again, when syncing with unstable, with the new upload I was introducing an "empty" conf file again, with a comment section, how to disable hplip on boot
<mdz> doko: you dropped the conffile entirely?
<poningru> can someone help with bugzilla queries?
<poningru> I wanna see what bugs are blocking 5.10
<doko> mdz: it's introduced again with the current version
<mdz> doko: argh
<mdz> doko: you can fix it in the maintainer scripts, but probably not worth it if it was only breezy
<doko> mdz: I'll recheck with a next upgrade from hoary, but I'm pretty sure, that I'm not asked any question
<poningru> so no one?
<mdz> poningru: anything severity blocker, critical or major is a good target
<fabbione> mdz: you broke hplip on sparc with your last upload...
<fabbione> http://bld-3.mmjgroup.com/buildLogs/h/hplip/0.9.4-3ubuntu3/hplip_0.9.4-3ubuntu3_20050915-0626-sparc-failed.gz <- pretty interesting error
<mdz> fabbione: how did I do that with a one-line change to a status message in the init script?
<Lathiat> with great ease apparently
<fabbione> mdz: no idea :) but you did touch it last rule owns :)
<mdz> that rule doesn't apply when sparc loses its mind
<mdz> then the "fabbione loves sparc" rule applies
<mdz> mizar:[/tmp]  debdiff hplip_0.9.4-3ubuntu2.dsc hplip_0.9.4-3ubuntu3.dsc |diffstat
<mdz>  changelog       |    6 ++++++
<mdz>  hplip-base.init |    2 +-
<fabbione> -checking for icon directory... using /usr/lib/menu/hplip
<fabbione> +checking for icon directory... none
<fabbione>  updating cache config.cache
<fabbione> interesting
<mdz> sparc = insane
<fabbione> mdz: that's not the only intersting difference...
<bob2> Processing was halted because there were too many errors.
<bob2> go breezy!
<mdz> breezy 0wns j00
* bob2 watches 5 trillion xserver-xorg modules install themselves
<rob^> bob2, the story of every breezy users life over the last couple of weeks :)
<schweeb> rob^: or months, depending on how much you've been tracking breezy
<rob^> schweeb, true, but there have been a lot since the last freeze 
<schweeb> I'm just happy that I can finally suspend my IBM X41 to disk <3
<tepsipakki> how come openssh is not built with kerberos-support?
<bob2> it's a seperate package
<bob2> schweeb: it didn't work in hoary?
<tepsipakki> yeah, and the version is 3.8.1
<bob2> 'sudo dpkg-reconfigure linux-image-2.6.12-8-686 -plow' should ask me about usplash, right?
<schweeb> bob2: no, I have a SATA hard drive... didn't work at all
<bob2> ah
<rob^> there is a usplash package
<schweeb> the ubuntu splash on boot is frigging sweet.
<tepsipakki> bob2: let me rephrase; why there is no openssh-krb5?-)
<schweeb> way better than the initial one
<rob^> schweeb, it is, but the font keeps fcking up for me
<schweeb> that sucks
<schweeb> I always get "failed" when setting console font... but it still works for me
<rob^> same, are your fonts during boot bold and ugly though?
<bob2> haha
<bob2> that splash screen is surreal
<tepsipakki> bob2: nevermind, #12725
<schweeb> yea... not sure that's an issue... framebuffer can only do so much
<bob2> and stops well before gdm starts
<schweeb> at least they're the right color
<rob^> heh yeah
<bob2> and X is broken
* schweeb goes to sleep
<schweeb> X works perfectly for me
<bob2> oh, the gdm login is the same
<bob2> and all my nautilus icons are gone
<doko> do we have minimun hardware requirements documented for breezy?
<fabbione> elmo, Znarl: ping?
<bob2> oh, heh, network-manager is uninstallable
<Burgundavia> bob2, j^'s might make universe RSN
<bob2> ?
<Burgundavia> bob2, the current version in universe is borked, a new version is sitting in REVU
<bob2> is that the same as queue/NEW?
<Burgundavia> bob2, no REVU is the tool for MOTU's to look at packages from non-MOTU's for upload
<torkel> bob2: http://bootlab.org/~j/NetworkManager-breezy/
<pef> hello
<doko> fabbione: please could you build poppler on sparc? anastacia is currently fooled, that poppler-utils is not available on all archs
<fabbione> doko: it's 4th in the queue already
<pitti> Hi folks
<fabbione> and afaik anastacia doesn't care about SSC
<doko> fabbione: thanks, but apparently it did, see the backlog from yesterday
<fabbione> doko: i have no irc backlogs
<sivang> morning all
<fabbione> i am having a lot of problems with my workstation.. and i am on and off.. randomically
<sivang> ah man, elmo looked for me and I wasn't here...
<dholbach> good morning
<mvo> good morning dholbach 
<dholbach> mvo: morning michael :)
<pitti> Hey dholbach 
<dholbach> pitti: morning martin :)
<dholbach> how are you all?
<sivang> pitti: good to see that cups bug is fixed, not I can again see all the printer on my network
<sivang> pitti: morning, btw
<pitti> Hi sivang 
<dholbach> sabdfl: morning mark
<sabdfl> moin moin
<dholbach> hehe :)
<doko> mdz, Kamion: I'm going to seed libdb4.2++-dev, db4.3-util and libdb4.3-java. we shouldn't make any difference in db4.2 and db4.3 support at the moment
<dholbach> morning doko
<doko> dholbach: morning. did you finish your presentation for berlinux? ;-P
<dholbach> doko: not finished yet, working on it
<jdub> mdz: reping
<mvo> mdz: are you still awake?
<fabbione> mdz: ping?
<dholbach> i HATE different orig.tar.gz in ubuntu and debian *GRR*
<bob2> spank people for that
<dholbach> i feel that spanking just is not enough
<dholbach> seb128: good morning sbastien :)
<seb128> hello daniel!
<doko> pitti: did you look at belocs, if it's ok to support it in main?
<sivang> mornig dholbach 
<sivang> Bo Jour seb128 
<dholbach> sivang: good morning :)
<sivang> err, Bon , even
<pitti> doko: belocs? no, not yet - I did not even see that; my work plans yesterday got disturbed (see my activity report), will catch up today
<doko> pitti: no, it's not mentioned in any report, just looking at it, because it adds support for km rw tn ss nso ts ve
<pitti> doko: it's not yet fully compatible with our language packs; I'm just typing a mail about it, I CC you
<pitti> doko: doko@u.c?
<seb128> hi sivang
<seb128> hi pitti
<pitti> Hey seb128
<doko> pitti: yes
<sivang> anybody know the method/module to get files from HTTP like wget does?
<sivang> (in python , that is)
<pitti> sivang: urllib
<sivang> pitti: k, thanks
<sivang> pitti: hmm, I wonder how it doesn't have a class like FetchFiles(filenames_list) or something, although it's easy to implement
<pitti> yep, simple for loop
<sivang> s/class/method/
<Keybuk> seb128: got an evo bug for you
<Keybuk> the "Sent Folder" button is disabled unless you set up an incoming mail server type
<Keybuk> which is ironic, given it's for _outgoing_ mail
<seb128> Keybuk: right, I've that here too
<sivang> Keybuk: nice =) 
<Kamion> Keybuk: is anyone working on getting grepmap into Debian? the d-i team are cautiously interested in switching to hotplug, but without grepmap the performance difference will probably be such that they'll give up
<Keybuk> Kamion: a few people have asked me about it over the last year, but I've not seen anyone actually upload it
<Kamion> mind if I take a look at it then?
<Keybuk> sure
<seb128> Keybuk: http://bugzilla.gnome.org/show_bug.cgi?id=315506
<Kamion> Keybuk: how do you want versioning handled? it's currently just 0.1.0-3 in Ubuntu - shall I just bump to 0.1.0-4 and make sure the packaging is such that we can sync it next time round?
<Keybuk> I think people have been put off because it's theoretically obsolete in the face of going-away-hotplug
<Keybuk> yup, seems sane to me
<Mithrandir> hmm, today's daily blows up spectacularly on this compaq nc8230
<Mithrandir> as in, the initrd seems busted.
<lifeless> where is the daily installer ?
* lifeless is going to brave breezy
<Mithrandir> http://cdimage.ubuntu.com/daily/current/ has isos
<lifeless> danke
<Kamion> Mithrandir: hmm, haven't changed anything dramatic lately
<Mithrandir> Kamion: it complains about partial reads and stuff, before it gets to d-i itself.
<Mithrandir> (sorry for vague error message, I rebooted with preview instead)
<Kamion> well *that* sounds like a bad burn
<Treenaks> or a bad drive
<Mithrandir> it's repeated across burns
<jdub> Mark in South Africa recently... 'With his crew, Ubuntu, he's won the national "Battle of the Year" for the last five years. "This is my dream. I only want to dance," he said.'
<Treenaks> jdub: ...
<jdub> url on sounder ;)
<sivang> jdub: nice, 'sup btw? what about us and ibm? (I am downloaindg db2 validations scripts as we speak)
<jdub> nothing to report
<jdub> Kamion: ping
<Burgundavia> jdub, what is planned for Ubuntu Love Day at UBZ?
<jdub> Burgundavia: cool presentations, marketing/loco bofs, stuff like that - should have schedule up next week
<pitti> infinity: can you please give-back affix?
<Burgundavia> jdub, ok, just chatting with Mark about involving the Canadian loco team and contacting the local LUG
<jdub> Burgundavia: and ubuntutoronto.org!
<Burgundavia> jdub, bah, TO can eat their donuts
<jdub> they're nearby
<Burgundavia> yes, they are
<Treenaks> isn't Ottawa closer?
<Burgundavia> Treenaks, yes
<Burgundavia> QC is only about 2 hours drive as well, if I remember correctly
<Treenaks> Burgundavia: hmm.. good thing I planned an extra day off for myself then :)
<Burgundavia> jdub, how are you travelling on the BBB tour?
<Kamion> jdub: pong
<jdub> Burgundavia: parachute.
<Burgundavia> jdub, I was hoping for steam-powered dirigible, but parachute is still pretty cool
<jdub> Kamion: was just thinking, perhaps we should see how the usplash logo works for the ISOLINUX image?
<Kamion> jdub: sure, could d
<Kamion> do
* Kamion adds it to his todo
<jdub> thanks 8)
<Mithrandir> Kamion: I see the boot problem with current daily, md5sum matches and I've tried with multiple different media.
<Kamion> meh, ok, I'll rsync and have a look
<Mithrandir> it complains about trying to access beyond end of device, then dies because it can't open initial console and init dies.
<Mithrandir> it also says RAMDISK: incomplete write (-28 != 32768) 12582912
<Kamion> hmm, that sounds like initrd bigger than boot args say
<Kamion> i386?
<Mithrandir> yeah
<Mithrandir> does the boot args say anything about initrd size there?
<Kamion> oh, huh, we have the initrd size hardcoded in debian-cd
<Mithrandir> uhm
<Mithrandir> that sounds bad
<Kamion> 'zcat /cdrom/install/initrd.gz | wc -c' please?
<Mithrandir> $ zcat /cdrom/install/initrd.gz | wc --bytes
<Mithrandir> 13791232
<Mithrandir> (I think you want --bytes, not -c; this is an utf8 locale)
<Kamion> true
<Kamion> now why did it grow so much?
<Mithrandir> they happen to give the same answer this time, though.
<Mithrandir> 13 megs sounds a bit excessive
<Kamion> debian-cd's current value for i386 is 12288 (*1024)
<Kamion> so that's like a megabyte growth all of a sudden. what happened?
<Kamion> one good thing about having it hardcoded is that you get to find out about this sort of thing :)
<Kamion> hmm, perhaps I have the numbers wrong; it's grown by a few tens of KB lately, but not hugely
<Kamion> I'll bump it to 16384 for now
<Mithrandir> thanks
<Kamion> rebuilding CDs now
* Mithrandir grumbles and kicks parted
<seb128> elmo: libglib-perl and libgtk2-perl syncs please. These are new stable versions base on the current unstable we have and will fix #15447 
<sladen> jdub: rocking idea
<sladen> jdub: I was also trying to work out whether it could be stuck in the middle of the black X display, as soon as X is started and for the 5-10 seconds before gdm starts doing-its-thing
<sivang> guys, since about 2 days ago when I updated my laptop, the USPlash appears but dropps on the "Setting up console font" msg, any idea?
<sivang> it goes back to the old console messages screen
<mjg59> sivang: Bug in console-tools
<mvo> sivang: yes, a bad console-tools upload
<mvo> sivang: fixed in todays upload
<mvo> btw, would anyone hate me if console-fonts can't be changed if usplash is used?
<sivang> mvo: cool ;)
<sivang> mvo: what do you mean?
<sivang> mvo: (re your last statmnt)
<mvo> sivang: while usplash is running the text-console fonts can't be set to something other than the default 
<Lathiat> is it possible to change it between usplash ending and gdm starting
<mvo> Lathiat: that may work, runing it right before gdm /me tests
<Lathiat> who cares anyway? ;)
<Kamion> Lathiat: I've got bugs from Polish console users
<Lathiat> oh
<Lathiat> blah
<Lathiat> non english people
<mvo> Kamion: so polish console users that use usplash would hate me ?
* jdub points out that Lathiat is non-english.
<jdub> or are you changing sides after the ashes?
<jdub> soft.
<Lathiat> non english language people
* Lathiat smirks
<Lathiat> english alphabet, really. :)
<jdub> mvo: is usplash explicitely killed pre-gdm?
<Mithrandir> Kamion: do you know the real reason for parted to be strict about msdos partitions being aligned on cylinder boundaries and such?
<sivang> mvo: fix working , now testing it on poweroff
<mvo> jdub: no, apparently it kills itself if the vt is switched. fortunately gdm switches the vt and usplash goes away 
<mvo> sivang: thanks
<Kamion> mvo: probably :-/
<Kamion> Mithrandir: no
<Kamion> Mithrandir: although I suspect it's because Windows barfs if the partition table isn't just how it likes it
<sivang> mvo: seems I didn't get the USPlash on poweroff, and I used to get it before the crucial update - known?
<Mithrandir> Kamion: well, fdisk and windows is happy on this laptop, but parted refuses to touch the drive because "Unable to satisfy all constraints on the partition."
<ogra> doko_, looking at 15330 i think we can just remove the 2.3 dependency safely... all apps call #!/usr/bin/env python, nothing is in 2.3's site-packages
<seb128> mvo: do you have this issue with german too: https://bugzilla.ubuntu.com/show_bug.cgi?id=14094 ?
<ogra> seb128, does it go away if you run unicode_start ?
<seb128> it doesn't bug the same way
<mvo> sivang: no, but it shouldn't change that behaviour
<seb128> without it  does an A@ by example
<seb128> with ie,  does a 
<ogra> hmm
<seb128> which seems to be a font issue
<ogra> wrong console font  ?
<mvo> seb128: I can type all german umlauts with the default font, but a  does not work
<seb128> mvo: I can type a 
<seb128> but not q 
<seb128> s/q/a/
<seb128> neither a 
<mvo> I can type 0
<ogra> does runnung /etc/init.d/console-screen.sh help ? its the one that fails due to usplash
<ogra> running even
<Mithrandir> can ubuntu-meta have versioned depends?
<Kamion> no infrastructure for that
<Mithrandir> hmm
<Kamion> theoretically yes, but I think it's a bad idea - better put the versioned depends elsewhere
<Mithrandir> the readahead -> readahead-list -> readahead transition didn't really work.
<Mithrandir> since both provides each other.
<Kamion> since the stricter ubuntu-meta gets, the more likely it is that people will deinstall it, and the more diminished its already diminished utility gets
<Mithrandir> mhm
<seb128> ogra: I don't have usplash on my box
<Kamion> but there's no readahead-list.deb anywhere any more, so that problem should go away?
<Mithrandir> Kamion: nope, since readahead-list provides readahead.
<seb128> no, no change with the console init
<Kamion> Mithrandir: but readahead-list isn't in Packages any more
<Kamion> so surely it should be counted as unavailable
<Mithrandir> Kamion: that doesn't matter if people have it installed already.
<Kamion> I hate apt
<Mithrandir> Kamion: I'll have readahead-list (which now produces readahead) produce an empty readahead-list package which just has a versioned depends on readahead.
<Kamion> it should see that readahead conflicts/replaces readahead-list and install readahead-list instead
<Kamion> er, "install readahead instead"
<Mithrandir> yes, the original meaning of replaces.
<Kamion> the original meaning of conflicts+replaces
<Kamion> I guess that readahead-list transitional solution is the best you're going to get
<Kamion> it can go away in dapper since readahead-list only existed during breezy development
<Mithrandir> yup
<doko> ogra: yes, I'm still hoping to update to the final release ... waiting for jinti
<sladen> seb128: dpkg-reconfigure linux-image-$(uname -r)
<ogra> doko, err, thats the freshest release they have, released about 4 weeks ago, i dont think we'll se any update before releas
<ogra> e
<seb128> what will that change?
<ogra> sladen, tht fixes the console font ? 
<sladen> nope.  I suspect the console font isn't loading because the VT has been shoved into framebuffer mode
<seb128> I don't use any framebuffer or splash
<doko> Kamion: did you see my question about db4.2/db4.3 ?
<terrex> hi. Anybody knows why wine Replaces: winesetuptk if actually it doesn't?
<terrex> I've renamed that second package to avoid conflict in dpkg database but both wine and winesetuptk works well at the same time.
<doko> was: mdz, Kamion: I'm going to seed libdb4.2++-dev, db4.3-util and libdb4.3-java. we shouldn't make any difference in db4.2 and db4.3 support at the moment
<Mithrandir> Kamion: should we put readahead-list into the supported seed or something, then?
<Kamion> doko: I didn't realise that was a question; it seemed to be a statement of intent, and I had no objections
<Kamion> terrex: that's not what Replaces means
<Kamion> terrex: it means that wine ships some files that used to be shipped by winesetuptk
<Kamion> Mithrandir: yes
<seb128> ogra: do you change gnome-system-tools for edubuntu: https://bugzilla.ubuntu.com/show_bug.cgi?id=15428 ?
<Kamion> seb128: how could he? same archive
<seb128> Kamion: dunno how Edubuntu works and if they can divert some packages
<doko> Kamion: ok
<seb128> Kamion: thanks
<terrex> Kamion, and why am I not be able to install both?
<terrex> when i select one, synaptic deselect the another.
<ogra> seb128, nope, i didnt touch it...
<bob2> terrex: it Conflicts with winesetuptk
<terrex> e$ apt-cache show wine | grep winesetuptk
<terrex> Replaces: winesetuptk, wine-doc, wine-utils, libwine-alsa, libwine-arts, libwine-capi, libwine-jack, libwine-nas, libwine-print, libwine-twain, libwine, libwine-dev
<terrex> Conflicts: binfmt-support (<< 1.1.2), winesetuptk, wine-doc, wine-utils, libwine-alsa, libwine-arts, libwine-capi, libwine-jack, libwine-nas, libwine-print, libwine-twain
<terrex> sorry for the paste.
<bob2> yes, it Conflicts
<terrex> but i think that it should conflict with
<bob2> (as well as Replacing)
<terrex> but i think that it should'nt conflict with
<ogra> terrex, winesetuptk is unmaintained and breaks the config, its not compatible with the packages from winehq, thats why it is replaced by the new wine packages (they are from winehq, not debian)
<terrex> or well, wine provides winesetuptk
<Kamion> terrex: Replaces is irrelevant, in any case
<Kamion> well, er, not really, Conflicts+Replaces has a special meaning of "this package totally replaces the other"
<ogra> terrex, there must be a new tool thats shipped with the winehq packages (dunno its name though)
<terrex> aha okey, i'll try to look for it.
<terrex> th
<terrex> thx.
<Mithrandir> maswan: would you mind making sure that the ubuntu-releases module exists on all of releases.ubuntu.com?
<Mithrandir> maswan: (rsync)
<jordi> pitti: did ubuntu get mailutils from incoming?
<pitti> jordi: mailutils | 1:0.6.90-1 | http://archive.ubuntu.com breezy/universe Packages
<pitti> jordi: so I guess not?
<jordi> pitti: is it frozen for that kind of updates'
<jordi> both -2 and -3 have important stuff
<pitti> jordi: please mail elmo about a sync request
<pitti> jordi: for hoary and warty we need proper uploads, though
<Mithrandir> Riddell: I'll chuck 14690 in your direction so you can follow up on it.
<fabbione> meh
<fabbione>  /usr/bin/ldd: line 171: /lib/ld-linux.so.2: No such file or directory
<fabbione> ldd: /lib/ld-linux.so.2 exited with unknown exit code (127)
<fabbione> who is that?
<fabbione> how even
<Riddell> Mithrandir: sure (although currently it's in elmo's direction to sync ttf-dejavu)
<fabbione> Mithrandir: isn't ia32-libs supposed to be installed everywhere on amd64?
<fabbione> Mithrandir: or do i need to B-D on it?
<fabbione> http://people.ubuntu.com/~lamont/buildLogs/l/linux-restricted-modules-2.6.12/2.6.12.3-2/ <- see amd64 FTBFS
<Mithrandir> fabbione: it's priority: optional and not build-essential, no.
<fabbione> so what could cause that error?
<Mithrandir> probably a missing build-dep on ia32-libs, as you noted.
<fabbione> fabbione Mithrandir: or do i need to B-D on it?
<fabbione> .. not build-essential, no.
<fabbione> i got the last "no" as referred to my B-D question
<fabbione> Mithrandir: so is it ok to add it as B-D?
<Mithrandir> yeah, except running dpkg-shlibdeps on 32 bit binaries doesn't really give you anything meaningful on amd64.
<fabbione> Mithrandir: except that nothing meaningfull will come out anyway, because it's nvidia
<Mithrandir> I thought it was fglrx?
<fabbione> Mithrandir: they both suffer of the same lameness
<Mithrandir> ;-)
<daniels> they both install lib32 stuff on amd64
<fabbione> ok..
<fabbione> let's prepare yet another upload..
<Mithrandir> daniels: that doesn't mean the dependencies will be in any way meaningful
<daniels> they don't really have to be
<HiddenWolf> daniels, is the nvidia-glx version bumped as well with the new l-r-m?
<maswan> Mithrandir: just checked, yes, it's there.
<Mithrandir> : tfheen@xoog ~ > rsync releases.ubuntu.com::ubuntu-releases
<Mithrandir> @ERROR: Unknown module 'ubuntu-releases'
<Mithrandir> rsync error: error starting client-server protocol (code 5) at main.c(1171)
<Mithrandir> maswan: hmm, it might be one of the DC servers.
<maswan> Mithrandir: ah, fun, they are only called "releases" on the DC servers
<maswan> Mithrandir: ftp.acc.umu.se have more releases than just ubuntu though..
* ogra growls at sladen
<Mithrandir> maswan: can you talk to elmo or Znarl about it and work something out?
<ogra> sladen, stop filing this weird bugs !!
<ogra> :)
<maswan> Mithrandir: I guess. Just putting up the same tree under the module ubuntu-releases on the DC servers seems the easiest way to go. I'll try and talk to them. I'm a bit backlogged right now though, so I might not be too active in hunting them down
<Mithrandir> maswan: sure
<fabbione> HiddenWolf: ????
* maswan prods elmo and Znarl, just in case they are somewhat around :)
<fabbione> HiddenWolf: i did the last l-r-m uploads...
<fabbione> HiddenWolf: what do you mean by bumping nvidia versions?
<HiddenWolf> fabbione, is the nvidia driver version newer now? The old one breaks quite horribly for me.
<Znarl> maswan : Hello!
<fabbione> HiddenWolf: 7667
<fabbione> and 7114 (legacy)
<HiddenWolf> legacy? they broke it up?
<fabbione> no daniels did it
<fabbione> anyway it
<fabbione> anyway it's not the latest one
<HiddenWolf> bah. :( I need to buy a serial cable then.
<HiddenWolf> nvidia guy wants me to debug my problem, but I'll need to pull the data off it.
<fabbione> HiddenWolf: you can still install the latest one from their site and see if it works
<HiddenWolf> Yup, i'll have to try that too.
<infinity> nvidia has stopped supporting the older cards in newer drivers, it has nothing to do with daniels.
<HiddenWolf> My system hardlocks whenever I try to start x with the nvidia drivers for some reason.
<poningru> so why the gay duck?
<poningru> err sorry wrong window
<HiddenWolf> poningru, dapper drake != gay duck!
<fabbione> infinity: daniels did the job.. do you want to take away credits from him? ;)
<infinity> He did the job of fixing LRM, but it's nvidia that forced it on him.
<infinity> Hence "they broke it up" was an accurate representation.
<Lathiat> ++ on the new lrm
<fabbione> well i read it as Nvidia did break it in 2
<fabbione> Lathiat: ??
<Lathiat> i thought legacy was 6629 tho
<Lathiat> did they update it?
<infinity> The "legacy" driver is for everything from the TNT to the GeForce2, and the other driver is for GeForce3 and up.
<Lathiat> ya
<herzi> elmo: can you sync alleyoop to fix 2039, please?
<poningru> HiddenWolf: it is so dapper drake == gay duck
<fabbione> infinity: can you please push your lazy buildd's to munge lrm again? ;)
<infinity> fabbione : Read your email.
<Lathiat> poningru: Do you have a problem with the concept of homosexuality
<poningru> Lathiat: rofl no
<poningru> I meant gay as in happy
<Lathiat> scapegoat
<poningru> hahahaha
<poningru> no but what I am worried about is mandrake
<poningru> mandrake used drake back in the day
<poningru> did our dev team know about this?
<fabbione> infinity: i miss something...
<maswan> Znarl: Greetings. Did you see the issue about rsync module name for releases.ubuntu.com?
<fabbione> 6.8.0-8.14.13-0ubuntu9 and 6.8.0-8.16.20
<fabbione> infinity: how can the first one be >= of the second one?
<Kamion> poningru: The Hearst trademark that caused Mandrake to change its name was on the whole word "Mandrake" (as in "Mandrake the Magician"), not on the "drake" bit.
<Kamion> so that's not a problem
<infinity> if dpkg --compare-versions 6.8.0-8.14.13-0ubuntu9 gt 6.8.0-8.16.20; then echo "Ugh"; fi
<fabbione> infinity: yes i can see that.. 
<infinity> fabbione : I assume because one has two "debian revisions", and the other has one, and dpkg is confused beyond believe about that.
<Kamion> fabbione: because the upstream_version and debian_revision parts are compared separately
<infinity> s/believe/belief/
<Znarl> maswan : Yes, I'll get back to you about it?
<fabbione> Kamion: bah
<Kamion> fabbione: dpkg compares 6.8.0-8.14.13 with 6.8.0
<fabbione> it's a dpkg bug
<Kamion> no
<infinity> No it's not.
<maswan> Znarl: Sure
<Kamion> policy specifies it to work that way
<infinity> Policy specifies how versoins work.
<fabbione> Kamion: shhh! let me push this crap to Keybuk :P
<Kamion> and it makes sense, because the first of your two versions has foo_6.8.0-8.14.13.orig.tar.gz and the second has foo_6.8.0.orig.tar.gz
<Kamion> the first is clearly newer
<Kamion> either add a -0ubuntu1, or add an epoch
<fabbione> daniels: how did you manage to break it in this way?
<fabbione> Kamion: all the vars are there
<fabbione> just not used
* Keybuk beats fabbione up
<terrex> aha, the wine package from winehq.com brings wincfg command instead of obsolete winsetuptk;
<fabbione> infinity: did you block the build of -3 ?
<infinity> No.
* infinity punts it for now.
<seb128> brb
<mbreit> infinity: could you please remove dep-wait on ardour?
<infinity> mbreit : Already done.
<infinity> mbreit : No need to repeat yourself.
<mbreit> infinity: thanks... i thought you did not read the query because i got no feedback... so sorry for repeating..
<fabbione> dpkg-deb: building package `xorg-driver-fglrx' in `../xorg-driver-fglrx_6.8.0-8.16.20-0ubuntu4_i386.deb'.
<fabbione> this should do
<infinity> Certainly sounds less broken.
<fabbione> it was lost in on of daniels changes
<fabbione> anyway i am off for a whilw
<fabbione> while
<fabbione> bbl
<\sh> mvo: ping
<Frafra> exist a version of ubuntu for sparc processor?
<ogra> Frafra, ports.ubuntu.com
<Frafra> ogra: thanks
<lifeless> ah, I know whhg
<Frafra> exist an iso image of ubuntu for sparc?
<Kamion> not yet no
<jdub> Kamion: what do you think about putting version number symlinks (5.04->breezy) in the archive?
<Kamion> presumably correct symlinks would be a start? ;-)
<infinity> <snicker>
<Kamion> it's fine by me; I already do that on releases.ubuntu.com
<jdub> yeah, that'd help!
<jdub> ahya
<jdub> ok
<Kamion> jdub: dude, you made the same 5.04 mistake on sounder as well :-P
<lifeless> where can I check the status of sfs  ? still lamonts home dir ?
<jdub> seriously?
<jdub> wtf
* jdub blames his horrible cold. or something.
<doko> Mithrandir: what did happen to the proposal to update valgrind to 3.0?
<Mithrandir> doko: I think it's sane, but somebody needs to check that it doesn't break kcachegrind or whatever is depending on it
<doko> maybe Riddell could do that?
<Mithrandir> Riddell: ^^^ ?
<doko> Mithrandir: do you have binary packages availabe at some place?
<Mithrandir> doko: no, but just rebuilding the ones from Debian works fine.
<doko> ok
<Mithrandir> doko: that is, I've got amd64 packages, but that doesn't help you when you want to test i386.
<Kamion> I thought Riddell already checked that out some time back
<\sh> can sombody tell me where to find GLwMDrawA.h? 
<doko> \sh: -> packages.ubuntu.com
<Kamion> ubuntu-devel-2005-09-01.html:<tr bgcolor="#eeeeee"><td>07:52</td><td><font color="#6e6ed1"><tt>Riddell</tt></font></td><td><tt>jdub: new valgrind looks fine, kcachegrind uses callgrind which doesn't like valgrind 3 but debian doesn't pacakge callgrind so it's no loss.&nbsp;&nbsp;and the kdesdk-scripts rdepend is fine</tt></td></tr>
<ogra> \sh, apt-file ?
<\sh> ogra: gave me the wrong answer..but it should be somewhere in the libgl* area...but I don't see it
<infinity> mbreit : ardour is FTBFS.
<mbreit> infinity: i see it... but it really worked in pbuilder yesterday
<Mithrandir> Kamion: ok; i'll ask for a sync from elmo then, since I'm writing him a mail already
<\sh> apt-file after update: nothing ;)
<Kamion> Mithrandir: yep, go ahead
<Kamion> somebody will need to keep a careful eye on it, though, since it's a late big version increase
<lifeless> hmm, several things wnt camel1.2-3, others wnat 1.2-6.
<lifeless> why is libcamel versioned by named and not version number ?
<\sh> gnarf...old location was xlibmesa-gl-dev...
<Mithrandir> lifeless: because some people think that the version number of the package should be in the soname, rather than having a soname which is a single integer.
<Kamion> lifeless: presumably because that's when the ABI changes?
<lifeless> Kamion: I have this sinking feeling that they bump ABI without bumping soname. 
<lifeless> Mithrandir: sounds dubious
<lifeless> where should I go to check on the status of sfs-client ?
<Mithrandir> lifeless: hmm, they're actually doing that too.
<Frafra> exist a package for libgplflash2 for amd64
<lifeless> Mithrandir: well that explains why they conflict with each other. eek.
<Frafra> ?
<ogra> Frafra, libflash0c2
<Frafra> ogra: thanks!
<Frafra> can i use this lib for play flash animation on firefox?
<ogra> Frafra, rather libflash-mozplugin
<ogra> Frafra, but you dont want that ... it crashes every now and ten
<Frafra> ok
<Kamion> ogra: re #15244, what bit of ltsp-server actually starts sshd? I can't find it
<Kamion> ltsp-server only Recommends: openssh-server
<ogra> Kamion, the ligon manager ldm
<ogra> heh, login indeed
<Kamion> that starts ssh, not sshd
<ogra> err, yes...
<Frafra> yes, it crash :D i've try macromedia test flash and it crash :)
<ogra> wait a sec
<Frafra> but libflash-mozplugin use libflash0c2 or the old gplflash (that support flash 4)?
<ogra> Kamion, none atm... sshd is just a dependency, looks like mdz just relies on the fact that it gets started if installed
<ogra> Kamion, so i guess some postinst magic in ltsp-server.postinst or ltsp-server-standalone.postionst is needed
<Kamion> ugh, I'd rather it shut down ssh properly really
<Kamion> surely kill -HUP'ing the client would suffice
<ogra> Kamion, thats done in ldm... 
<dholbach> pitti: did you ask for a centericq sync already?
<Kamion> hmm, oh yeah, there's that ghastly kill -1 $PPID hack on the other end
<pitti> dholbach: no
<Kamion> it obviously does not work properly
<dholbach> pitti: i will do so
<herzi> dholbach: can you ask for alleyoop too?
<Kamion> ogra: what way are you closing the ltsp session?
<Kamion> it must not be by exiting the session manager
<Kamion> because it doesn't matter that the ssh session stays open - it's the session manager you want to kill really
<ogra> Kamion, i guess it is by closing the session manager...
<ogra> Kamion, ldm starts a normal gnome-session... you log out there and X restarts on the client...
<Kamion> but then there would be no problem, because the session would not be running any more
<Kamion> surely?
<Kamion> in what way does the relogin attempt fail?
<ogra> i cant get any login... i'll have to try it to give you exact data... but looking on the server the ssh session persists even without any trace of gnome-session
<Kamion> that doesn't matter
<ogra> after ~30 sec it disappears
<Kamion> the ssh session is innocuous by itself; it must be something else
<\sh> default tcp timeout
<Kamion> \sh: yes we know
<Kamion> that was where the bug started ;)
<\sh> Kamion: I discussed the bug with ogra ;)
<ogra> \sh, if you force the quitting it shouldnt hang the 30 sec... thats the prob
<Kamion> \sh: it's still irrelevant; it doesn't matter when sshd exits, unless there's something else it's taking down with it
<Kamion> perhaps a forwarded X session
<ogra> we only forward the desktop session, X runs on the client...
<Mithrandir> Kamion: 7694 seems to be invalid/fixed already?
<ogra> so it can only be gnome-session or something related to it
<Kamion> ogra: yes, that's how X forwarding normally works ;-)
<Kamion> Mithrandir: not fixed because nothing has changed
<ogra> Kamion, but i think mdz assume that 'kill -1 $PPID' cleans that up... probably the right replacement would do it already...
<Kamion> Mithrandir: maybe invalid, but I can sort of see the submitter's point
<Mithrandir> Kamion: well it's intended behaviour.
<Kamion> well, not necessarily
<Mithrandir> it should bump the priority back up again, though
<Kamion> if you encounter an error during partitioning and subsequently fix up your partitioning to be right, maybe the debconf priority shouldn't remain as low as it currently does
<Kamion> ogra: there's some other fundamental issue though I think
<Kamion> perhaps an sshd bug
<ogra> Kamion, i guess $PPID might be wrong... and the wrong process is killed...
<Kamion> or maybe the greeter does not exit properly
<Kamion> ogra: $PPID looks OK when I try it out here
<ogra> hmm, it restarts the whole X server...
<Kamion> but in any case you really should not have to kill the sshd child to make logout work right
<ogra> so there shoudlnt be reaminings
<Kamion> X server runs on the client, has nothing direct to do with what's running on the LTSP server
<Kamion> only via ssh
<mjg59> Hmm.
<Kamion> this is why I need to know what's running on the server and what the error is
<mjg59> jbailey: Are network card drivers loaded before swsusp resume?
<ogra> Kamion, i'll do some tests and follow up on the bug
<jbailey> mjg59: Yes.  Any driver present in the initramfs is currently loaded.
<jbailey> mjg59: That would need to be the case for *puke* suspend over *puke* nbd anyway.
<Kamion> ogra: thanks
<jbailey> (Not that it's a supported case right now)
<mjg59> jbailey: We can absolutely and entirely ignore that case
<jbailey> mjg59: Promise? =)
<mjg59> jbailey: I worry that 14790 may be an issue
<jbailey> mjg59: feh.
<jbailey> mjg59: So what keeps HDD drivers from sucking on resume, since everything else clearly does?
<mjg59> No idea
<Mithrandir> jdub: what's the status of 7514?
<mjg59> Hm. Well, not strictly true. The PCI controller is in the same state either side of the suspend/resume
<jdub> Mithrandir: was just talking to Kamion about that before - he's going to try the usplash image to see if it rocks on ISOLINUX
<jbailey> mjg59: I'm more wondering if there's some sort of a reset that ought to happen *anyway* to make sure that the HDD controller is actually in a good state.
<jbailey> Like, are we just hiding the problem in this case?
<jdub> Sep 15 07:38:59 ubuntu kernel: [4923491.447000]  init_special_inode: bogus i_mode (177777)
<jdub> ^ what does that mean?
<Mithrandir> jdub: ook
<jdub> Sep 12 11:37:49 ubuntu kernel: [4678575.291000]  hda: dma_timer_expiry: dma statu
<jdub> s == 0x21
<jdub> Sep 12 11:37:55 ubuntu kernel: [4678585.291000]  hda: DMA timeout error
<jdub> Sep 12 11:37:55 ubuntu kernel: [4678585.291000]  hda: dma timeout error: status=0
<jdub> xd0 { Busy }
<jdub> Sep 12 11:37:55 ubuntu kernel: [4678585.291000] 
<jdub> Sep 12 11:37:55 ubuntu kernel: [4678585.291000]  ide: failed opcode was: unknown
<jdub> Sep 12 11:37:55 ubuntu kernel: [4678585.291000]  hda: DMA disabled
<jdub> Sep 12 11:37:55 ubuntu kernel: [4678585.341000]  ide0: reset: success
<jdub> 
<jdub> and that?
<jdub> is it megabackup time? :)
<zul> i would say yes
<jdub> ber.
<jdub> i should probably replace the drive before my trip, then, too
<mbreit> infinity: ping
* Kamion throws rocks at convert(1)
<Kamion> what part of '-background black' do you not understand?
<Treenaks> Kamion: the imagick manpages are notoriously bad
<Kamion> I know, I'm using its HTML documentation
<Kamion> the man pages used to be much better before they were (for some reason) eviscerated
<HiddenWolf> lol, malone bug #1 is _the best bug ever_
<jbailey> Kamion: Just use mogrify instead.
<jbailey> Kamion: Convert I think is just one format to another.
<sivang> HiddenWolf: that the MS market share one?
<HiddenWolf> sivang, yup
<sivang> hehe
<bddebian> Hello
<Whistler> hi
<elmo> meh, nvidia-legacy?!
<bddebian> Hi elmo :-)
<bob2> haha
<WaterSevenUb> mvo, thanks for correcting the problem in g-s-t with the POTFILE. But now... how to make the regenerated POT reach Rosetta?
<mvo> WaterSevenUb: it looks like the rosetta people are all on vacation, g-s-t is not yet imported :/
<Kamion> jbailey: mogrify is convert but in-place.
<Kamion> (and seems to have the same overwrites-the-background-colour problem)
<Kamion> HiddenWolf: that used to be bug #1 in our old disused Canonical-internal Bugzilla, too. :-)
<sivang> Kamion: lol
<sivang> Kamion: back on the no-name-yet.com days?
<HiddenWolf> Kamion, great attitude. :)
<\sh> mvo: what's up with g-a-i and psi?
<bob2> sivang: yes
<bob2> before no-name-yet, even
<mvo> \sh: it is installable again it seems?
<\sh> mvo: sure since yesterday 
<Kamion> sivang: as bob2 says, before that - bugzilla.warthogs.hbd.com
<mvo> \sh: then there is nothing up with g-a-i and psi (except you tell me about a new problem :)
<Kamion> we still have some services that live in /srv/<blah>.no-name-yet.com/
<\sh> mvo: not that I know of :) I resynced with debian and adjusted the desktop file to use no-gpg-agent
<mvo> \sh: great, the motus did a wonderfull job in cleaning up the unmetDepends list. psi can be removed from the wiki page
<\sh> mvo: we're fighting against the time and broken sources
<WaterSevenUb> mvo, the synaptic updated pt_PT.po I sent you was not good for inclusion? It isn't in your last upload of synaptic.
<mvo> \sh: yeah, I know. I really mean it, you are all doing a great job 
<WaterSevenUb> mvo, hhmm... wait a minute... apt-get source synaptic downloaded ....5 not. .... 6
<mvo> WaterSevenUb: I think I included it?
<mvo> WaterSevenUb: please beat me if I haven't (but not too hard)
<WaterSevenUb> mvo, I think my mirror or something is not updated yet ;) 
<\sh> hmm...looks like I have to prepare some text for the BOFs
<mvo> WaterSevenUb: my changelog says pt_PT is included, but if you double check it when it hits your mirror that would be nice
<\sh> seb128: ping libmms should hit universe and then main? 
<\sh> seb128: _before_ breezy release?
<fabbione> elmo: yes
<fabbione> elmo: can you please new it?
<pablof> how can i set default values for question boot ? 
<Kamion> pablof: please expand; that question doesn't make sense to me
<pablof> i want set default language and keyboard on boot
<Kamion> and ideally don't ask the same question in #debian-boot and #ubuntu-devel near-simultaneously without clarifying which distribution you're actually using :-)
<Kamion> 'd-i debian-installer/locale string en_US', 'd-i kbd-chooser/method select us' in a preseed file
<Kamion> (for instance)
<HWolf> Guys, I just dist-upgraded, then rebooted, and my system is now almost unworkably slow/jitterish.
<pablof> ok, i am using ubuntu.
<HWolf> *reboot*
<pablof> where i find out this docs ?
<Kamion> http://archive.ubuntu.com/ubuntu/dists/breezy/main/installer-i386/current/doc/manual/en/apcs01.html except that it's a bit out of date, unfortunately in particular for the two things you're asking about :)
<Kamion> er :( not :)
* Kamion goes to update that
<HWolf> seb128, ping
<HWolf> daniels, ping
* sladen wonders if there's actually any ExpressCard hardware out there to test with...
<mjg59> No
<HiddenWolf> Is any of you aware of an update today that could result in mouse events being treated as doubleclicks / turn gnome into something skitterish?
<slomo_> seb128: ping
<sladen> HiddenWolf: what laptop---I have that onthe R31 without i8042.nomux
<HiddenWolf> sladen, desktop
<sladen> HiddenWolf: originally there was also a problem with events appearing twice;  once via dev/input and once directly
<HiddenWolf> sladen, how do I check if this is the case for me?
<sladen> HiddenWolf: try commenting out one of the pointer entries in your xorg.conf and file a bug if that fixes it
<HiddenWolf> sladen, pionter entries?
<pablof> Kamion: I added those parameters in the archive server.seed, but they had not effect
<Kamion> pablof: oh, sorry, you can't put those two in a preseed file because the preseed file is only read later
<Kamion> pablof: just boot with 'debian-installer/locale=en_US kbd-chooser/method=us' or whatever on the kernel command line
<sladen> HiddenWolf: in /etc/X11/xorg.conf  comment out          InputDevice     "Synaptics Touchpad"
<HiddenWolf> sladen, I'm using a _desktop_ system. ImPS/2 mouse
<sladen> HiddenWolf: I know.  You did say that before.
<zyga> hello :)
<slomo_> elmo: ping? my ubuntu.com email address was a loopback before... now i corrected this but it seems the cronjob doesn't update it to the correct email address now
<sladen> HiddenWolf: then try commenting out the 'Generic' entry on the line above and see if either of those help
<Kamion> BenC: is the nls_utf8 addition to fs-common-modules on powerpc queued for the next kernel upload? I'd like to revert the temporary installer hack I applied to work around that.
<sladen> HiddenWolf: is the pointer you're using  USB or PS/2 or ADB?
<HiddenWolf> There are 2 imput devices in my xorg.conf. "Generic Keyboard" and "Configured Mouse"
<HiddenWolf> sladen, USB
<pablof> ok
<sladen> HiddenWolf: is your BIOS doing USB->PS/2 emulation
<HiddenWolf> sladen: not aware of that; xorg.conf -> http://paste.ubuntulinux.nl/2204
<elmo> slomo_: slomo@ubuntu.com should work AFAICS?
<sladen> HiddenWolf: intersting, we can discount those then
<HiddenWolf> sladen, single clicking on gaim icon in tray results in it popping open/closed 3 times, that kind of behavior.
<slomo_> elmo: i had this as my LP address until yesterday... someone told me that this is bad ;) and i want it to forward to another address now so i set another address as my default LP address and nothing happened yet
<bddebian> slomo_: Don't feel bad, I can't get any @ubuntu.com e-mail addresses to work. ;'-(
<Kamion> BenC: hmm, actually if you could just put it into hfs-modules then that should work
<Kamion> BenC: echo nls_utf8 >> debian/d-i/powerpc/modules/powerpc/hfs-modules
<sladen> HiddenWolf: 6 clicks?
<elmo> slomo@ubuntu.com mail@slomosnail.de
<bddebian> elmo: Would you mind looking at mine if you get a second?
<HiddenWolf> sladen, can't really be sure, ot
<HiddenWolf> sladen, it's erratic
<slomo_> elmo: yes... then it's correct now, thanks :)
<sladen> HiddenWolf: do you have any other USB mice you could try (from another computer perhaps)
<sladen> HiddenWolf: what happens if you unplug + replug the mouse?
<daniels> HiddenWolf: no, it isn't
<HiddenWolf> sladen, no other mice, no effect
<\sh> ah daniels 
<\sh> good to see u...
<\sh> daniels: got my mail? :)
<daniels> yeah
<daniels> i don't think we build libglw at all anymore
<\sh> daniels: but we need it...for grass e.g.
<daniels> you're the first person to notice
<HiddenWolf> daniels, all I know is that my desktop just turned to randomly twitching on mouse clicks
<\sh> daniels: i know..;) 
<daniels> HiddenWolf: 'randomly twitching'?
<zyga> daniels: I've got a question about libdps1 in breezy (it's gone)
<HiddenWolf> daniels, sometimes a click is just a click, sometimes it is 2/3 clicks.
<bddebian> zyga: Yes
<\sh> daniels: any solution for it? 
<zyga> bddebian: why is it gone?
<sladen> HiddenWolf: always a left click---or allows the key you clicked?
<HiddenWolf> sladen, happens only on left clicks.
<daniels> HiddenWolf: uhm.  what sort of mouse?
<daniels> zyga: because it never, ever worked
<HiddenWolf> daniels, MS explorer. imPS/2
<daniels> HiddenWolf: *shrug*, either kernel bug or hardware bug; nothing in xorg has changed like that recently.
<daniels> zyga: there has never been any freely-licensed server implementation of DPS
<daniels> zyga: so if you app uses DPS, it either would've refused to start (in the case of texteroids, e.g.), or not enabled DPS support.  so it's no loss.
<HiddenWolf> sladen, any idea?
<mvo> Diziet: could you please have a look at #13750?
<HiddenWolf> daniels, what info would be needed to debug?
<sladen> HiddenWolf: if you can't find another mouse.  take apart the one you have a blow any crap away from the left microswitch
<daniels> HiddenWolf: uhm, I guess the output from cat /dev/input/mice when licking
<daniels> clicking, whatever
<sladen> HiddenWolf: and/or stick that mouse in another machine and is if it happens on tha tmachine?
<HiddenWolf> daniels, I can't see any intelligable data coming out of /dev/input/mice.
<daniels> HiddenWolf: right.  it's more volume of data, I suppose.
<sladen> HiddenWolf: sudo hexdump -C /dev/input/muce
<sladen> HiddenWolf: sudo hexdump -C /dev/input/mice
<HiddenWolf> sladen, daniels, should I pastebin that?
<bddebian> zyga: I think it was dropped in Debian iirc. But don't quote me
<sladen> HiddenWolf: sudo head -c 18 /dev/input/mice  | hexdump -C
<sladen> HiddenWolf: and then press the mouse *once*.  0x09 == left down;  0x08 == left up  how many do you see?
<HiddenWolf> sladen, 3 down, 3 up, some 00
<sladen> HiddenWolf: so by that time there's already 3 clicks.  I suspect your mouse isn't debouncing...
<bob2> firefox 1.5 seems snappier
<HiddenWolf> sladen, now I only see 1 and one. :(
* HiddenWolf puzzled.
<HiddenWolf> If I monitor /dev/input/mice I get perfect behavior. when i'm not, it messes up.
<sladen> HiddenWolf: do   -c 6  if you only want to see the first two events (down + up).  -c 18  is the first 6 events
<HiddenWolf> sladen, that's ok, down, up
<HiddenWolf> sladen, it behaves a few clicks, then goes random again.
<seb128> HiddenWolf, slomo_: pong
<HiddenWolf> seb128, nm
<sladen> HiddenWolf: IMHO, I alledge that your mouse is fubared.  Can you visit/borrow another one to tell whether this is the case
<seb128> \sh: ? I've said that it needs to be moved to build gst-plugins0.8 with it, who said before 5.10?
<HiddenWolf> sladen, I'll reboot to the other OS, check it out.
<HiddenWolf> that should prove it.
<slomo_> seb128: shawarma told me you probably want libmms in main for breezy because of gst-plugins? if it's too much hassle i could add it the gst-plugins-multiverse and we can leave it in universe for breezy
<mjg59> pitti: Around?
<pitti> mjg59: yes
<mjg59> pitti: alsa-utils query
<mjg59> pitti: the sanify routine in the init script mutes "Headphone jack sense"
<\sh> seb128: I quote in query
<seb128> slomo_: I thought to that, but I would avoid to have to fork for Debian to put some Replaces on gst-plugins-multiverse
<pitti> mjg59: no idea what that is
<mjg59> pitti: Looking at 2.6.12, that'll be off by default except for whitelisted hardware
<seb128> \sh: maybe you are not registred?
<seb128> \sh: no query 
<mjg59> pitti: Some hardware can tell when you've plugged in headphones
<mjg59> pitti: We want it enabled on HP laptops. I'm doing the kernel changes that are necessary for that, but we'd have to lose the unconditional muting of it
<pitti> mjg59: that sounds sane
<slomo_> seb128: would we need replaces when debian has it? debian's version would always be higher than the multiverse one (-0ubuntuX vs -1 or something)
<mjg59> pitti: Any objections to just removing that? Should be safe on 2.6.11 and higher
<pitti> mjg59: no, that's fine
<seb128> slomo_: if a file move from one package to an another you have to replaces the previous container
<mjg59> (I've just spent ages wondering why it didn't work by default after my kernel changes, and then found that alsa-utils is run by udev...)
<mjg59> pitti: Ok. Do you want to do that, or shall I?
<seb128> slomo_: gstreamer0.8-misc would have to replaces the multiverse package
<pitti> mjg59: if you have time for it, go ahead
<pitti> mjg59: if not, I put it on my list (bit busy right now)
<slomo_> seb128: ah sure... sorry, didn't really thought about it :/ hmm... so no support for it currently? or what do you suggest?
<Diziet> mvo: Reading 13750 now.
<mjg59> pitti: I can do that now
<\sh> daniels: any solution for GLw stuff?
<seb128> slomo_: I suggest to package it, make a wiki page, get it moved to main and then make gst-plugins0.8 using it
<HWolf> sladen, right, mouse is messed up
<slomo_> seb128: ok... but that won't happen for breezy probably :( libmms will probably be voted for universe this evening
<seb128> slomo_: why not? 
<seb128> slomo_: moving a package to main is not that many work
<Diziet> mvo: When they say the Debian package includes this embedding support, does that mean that one of our (Debian or Ubuntu) patches to 1.0.6 is to do that ?  That seems unlikely.
<sladen> HWolf: dude.  now take it apart with a screw-driver and give it a good blow.
<slomo_> seb128: it's only a half month until release and i thought main is frozen for everything except bugfixes ;) but well, when you say it could be done... let's try it :)
<HWolf> sladen, I would, but there are no screws.
<niemeyer> hi, lifeless here.
<daniels> \sh: not really at the moment sorry, aside from 'don't
<daniels> '
<niemeyer> I need a hand, after upgrade, X hates me, at the ont-start level of hate
<niemeyer> daniels: good timing, you being up and all
<daniels> also me going to sleep about now and all ...
<seb128> slomo_: that not a change to any current feature or a new apps ... that just an extra file to support mms, could be considered imho
<sladen> HWolf: I'm out of ideas.  Try a sledgehammer.
<mvo> Diziet: I'm not really familar with the ff package, but we definitly include the  gtkmozembed stuff 
<zyga> daniels: Maya 7.0 uses that library and works correctly
<niemeyer> daniels: erk. can I bribe you ?
<zyga> mvo: hey :)
* mvo waves to zyga 
<daniels> niemeyer: not at the moment, sorry.  you could bribe me to not go to bed, but the only difference there is that I'll be passed out on the couch instead, with my laptop open.
<zyga> mvo: I'll talk to you later - lot's of work ATM
<niemeyer> daniels: can you at least point me at likely issues ?
<slomo_> seb128: ok... i'll tell him to write a main inclusion report later ;)
<daniels> zyga: okay, then it's not actually using DPS, it's just linking against the library.  trust me when I say that it's utterly useless.
<niemeyer> daniels: I am completely fucked right now
<mvo> zyga: sure
<Diziet> mvo: heh, I'm not that familiar with it either :-).
<daniels> niemeyer: um, Xorg.0.log should tell you what's up.  i fixed this a while ago, but if your keyboard driver is "keyboard", try changing it to "kbd"; shouldn't still be an issue but whatever.
<mvo> Diziet: aren't you the new maintainer ;) ?
* mvo ducks
<zyga> daniels: that's good to know, I'll try to build a dummy library and see if maya works in breezy, thanks
<daniels> niemeyer: other than that, I don't know of any upgrade issues offhand, sorry
<Diziet> What's that got to do with it ? :-)
<bob2> niemeyer: a 'sudo dpkg-reconfigure xserver-xorg' magically unfucked my X this afternoon after upgrade
* mvo chuckles
<Diziet> Do we have any users (including Ubuntu-using developers) who want this embeddable mozilla ?
<niemeyer> daniels: thanks, if I can get at the console to try stuff, Ill check that
<niemeyer> bob2: thanks
<Diziet> I mean, if it's just a question of shipping some config file that doesn't sound too hard.  But we ought to be able to check to see whether we've done it right.
<niemeyer> right now, Ive just got a corrupt-looking gdm failure screen that will not react, with ctrl-alt-f1 etc broken too
<slomo_> seb128: btw... gst-plugins-multiverse currently ships two plugins which could probably be in debian in the future... dirac and wavpack. i'm just waiting for the stuff to stabilize and then wanted to search some DD
<zyga> x.org just got upgraded in hoary, wow :)
<daniels> zyga: not so great.  security update.
<mvo> Diziet: yeah, checking now 
<seb128> slomo_: they could be built from gst-plugins0.8?
<Diziet> Ta.
<Diziet> If you have more info, add it to the bug report.  Or we could chat to the submitter by email or something.  (Bugzilla is such a sucky messaging system.)
<slomo_> seb128: when i get someone to upload the dirac and wavpack libraries to debian... yes. there seems to be nothing suspect with the libraries, no ugly patents, good licenses etc
<mjg59> elmo: Hm. I don't seem to be able to reach upload.ubuntu.com
<mjg59> Oh, no, sorry - this is because I'm suffering massive packet loss
<mjg59> Oh, FFS.
<mjg59> I've been slashdotted.
<HiddenWolf> mjg59, enjoy. ;)
<pitti> mdz: I fixed some pmount bugs and did a new upstream microrelease for that; any objections to just uploading it?
<jdub> mjg59: you hosted it locally?
<mjg59> jdub: Yes
<jdub> *d'oh*
<jdub> buh bye! :-)
<pitti> Kamion: see pmount question above - can you approve this as well?
<mjg59> jdub: If this is your fault, I'm going to beat you to death with your shoes
* mjg59 can't actually get enough packets through to open new connections
<Diziet> mjg: Can I help ?  I mean, I could cycle over, collect the data, upload it to chiark, and you could switch the DNS somehow.
<HiddenWolf> mjg59, what are you hosting?
<mjg59> Diziet: Not a bad idea - there's only 304K, though
<mjg59> Hang on, I'll see if I can scp it to chiark
<HiddenWolf> sladen, ping
<mjg59> I've disabled apache for now, that seems to have made things better
<Kamion> pitti: if they fit within feature freeze criteria, that's fine
<pitti> Kamion: it fixes a major bug, a normal one, and has updated translations
<Diziet> mjg: Let me know what you want me to do to chiark's setup, at the appropriate point.
<pitti> Kamion: no new features
<mjg59> Diziet: dcc.tar.bz2 in ~mgarrett
<mjg59> Which ought to be www.dccalliance.biz
<pitti> Kamion: erm, two normal ones actually
<Diziet> mjg: Right.  Mind if I become you with su to set it up in your filespace ?
<Diziet> And, you can change the DNS right away.  This'll only take a minute or two.
<mjg59> Diziet: No problem
<Diziet> ls: /u2/mgarrett/dcc.tar.bz2: No such file or directory
<jsgotangco> oh yeah you've been slashdotted alright
<mjg59> Oops - /tmp (force of habit)
<Diziet> /tmp ?!
* Diziet hacks mjg59's account with a symlink attack.
<mjg59> Ok, DNS is good
<Diziet> /u2/mgarrett/dcc.tar.bz2: gzip compressed data, deflated, last modified: Thu Sep 15 16:39:36 2005, os: Unix
<dilinger> pitti: hey, do you know anything about CAN-2005-1761?
<mjg59> Yup
<pitti> dilinger: yes
<dilinger> pitti: has its details been made public yet?
<Diziet> mjg: Is there a webmaster@ ?
<dilinger> pitti: i can't message you because i'm not registered
<pitti> dilinger: did you get my /msg?
<Kamion> pitti: sounds reasonable; go ahead
<mjg59> Diziet: @dccalliance.biz? Yup.
<dilinger> pitti: yep
<pitti> dilinger: I did not find the corresponding 2.6 patch yet
<dilinger> pitti: alright, thanks
* dilinger pokes around a bit
<Diziet> mjg: Now seems to be serving that.
<Diziet> Do you need it on http://dccalliance.biz too ?
<mjg59> Nope, that's fine
<mjg59> Thanks!
<Diziet> NP
* mjg59 decides to wait a while before reenabling apache
<dilinger> pitti: http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=0a65800243742480b4b594b619b759749a3cfef4
<dilinger> i suspect the fix is in there
<jsgotangco> hrmm you actually got linked from zdnet too
<Diziet> What's the TTL on the old RRs ?
<Diziet> Looks like 86400 on the new ones.
<Diziet> You could get your apache to redirect; that might help.
<pitti> dilinger: omg, compared to the 2.4 fix, this is huuuge...
<dilinger> pitti: i think "rewrite" in the description accurately describes it :)
<Diziet> Although it would mean spoiling the URLs.
<Diziet> Why oh why oh why do we have _two_ gnomeish vim packages, which _conflict_ with each other (unlike every other kind of bizarre vi variant) ?
<highvoltage> hi guys. i asked other channels, but couldn't find an answer. where can I find a copy of the ubuntu manifesto?
<Diziet> And they conflict with vim too.  Bizarre.
<netstar> Anyone working on breezy ppc32/64?
<mdz> pitti: no objection
<pitti> mdz: ok, thanks
<dilinger> pitti: how about CAN-2005-0757?
<pitti> mdz: Good morning! :-)
<jdub> highvoltage: look at ubuntu.com front page (which itself is the first hit in google)
<netstar> I'm having serious issues with X, and I'm not sure if it's a problem with the xorg packages, my kernel or x nv drivers...CPU load for simple window movements is unbelievable...
<mdz> Kamion: the PPID hack works for me; what happens for you?
<Kamion> mdz: -> ogra
<mdz> jdub,mvo,fabbione: pong
<Kamion> mdz: (I don't have an LTSP setup yet; it's ogra who's having problems)
<mdz> oh
<Kamion> namely #15244
<mvo> mdz: already send you a mail
<Kamion> netstar: what's the problem?
<mvo> good morning btw
<jbailey> netstar: I'm using the stock ati drivers with my two ppc systems and I'm not seeing a problem.
<lifeless> wow, that was a tough upgrade
<lifeless> jdub: up ?
<mdz> Kamion: it should work fine on a normal logout; I guess he's talking about killing the X server?
<pitti> dilinger: hm, it's on my ignore list
<jdub> lifeless: stupidly, yes.
<jbailey> netstar: It's probably worth filing a bug.
<jdub> lifeless: have a really horrible cold.
<Kamion> mdz: I don't know; I couldn't get exact details from him
<netstar> Extremely high cpu load for simple window movements.  For example when gdm loads I can literally watch it paint the background image onto the screen.
<lifeless> jdub: ouch
<Kamion> cairo, perhaps?
<lifeless> jdub: why does the stiky note applet not let me hide its notes anymore ?
<netstar> This is not an issue I have had when using earlier yellowdog releases.
<Kamion> does non-gtk stuff exhibit the same problem?
<jdub> lifeless: no idea
<Amaranth> gtg
<lifeless> mdz: do you want upgrade reports to ubuntu-devel, or is there some other place ?
<lamont__> pitti: it says I don't have permission to view the CVE report (launchpad).  fix that.  kthxbye
<dilinger> pitti: ok.  downloading the RHEL kernel sources now, i'll see whether it's 2.4-only
<netstar> Kamion, I havene't tried.  Are newer gtk+2's really much more CPU intensive than say gnome 2.6 and the gtk at that time?
<Kamion> netstar: gtk 2.8 uses cairo as a backend, which is a vector graphics library
<mdz> lifeless: ubuntu-devel is fine
<Kamion> some people have reported slowdowns with that, although I think not as dramatic as yours
<lifeless> mdz: ok. I have a few things that are likely me-being newbish. documetning now
<pitti> lamont__: hmm?
<netstar> perhaps I should try a non-gtk window manager and environment
<sladen> cairo is slightly slower that treacle on a cold morning
<netstar> lol
<lamont__> pitti: I was assuming that the CVE report is security-team stuff...
* lamont__ digs up a url
<lamont__> https://launchpad.net/distros/ubuntu/+cve
<jdub> Kamion: unlikely this stuff (which is coming up a fair bit) is cairo
<netstar> jdub, you been hearing the same regarding X on ppc32/64?
<jdub> it has been coming up generally
<sladen> It takes about a second for GDM to draw the background on these laptops---very noticeable top-to-bottom blitting
<netstar> sladen, that's the same I am getting
<pitti> lamont__: I don't have permission to change members
<sladen> netstar: I think that's just the alpha-blending+scaling gdm is using being slow
<sladen> netstar: pretend it's a feature.
<netstar> It shouldn't be THAT slow though.  What is the spec of your machines?
<pitti> dilinger: nothing in my email archives either
<lamont__> pitti: sigh
<netstar> I'm running imac G5 1.8ghz with 768MB ram.
<seb128> slomo_: but they are uploaded to ubuntu? universe or main? did you do a wiki package to move them from universe?
<slomo_> seb128: universe... and no, i want them to be more stable and mature first
<bddebian> elmo: ping?
<jdub> sladen: that's not a particularly useful comment - this is a regression from previous releases. make it clear.
<seb128> slomo_: k
<dilinger> pitti: heh, have you ever looked at a RHEL srpm package?  they do awful things..
<pitti> dilinger: no, I didn't
<dilinger> they've backported xattr stuff.  instead of including the fix in a separate patch, they've simply rediffed the entire backport patch
<pitti> dilinger: maybe they just did an error when backporting
<dilinger> that's what i'm guessing
<seb128> lifeless: you need to click out of the notes somewhere
<lifeless> seb128: oh, so its magic now ?
<pitti> dilinger: hey, I found something: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=311164
<pitti> dilinger: patch is in a Debian kernel package, that should make it much easier
<sladen> jdub: good point, I had it in my mind it was happening before, but thinking about it now---it's only showed up since since breezy.. mmm
<seb128> lifeless: yeah
<lifeless> seb128: any idea how I get my terminal windows (uxterm) to be black again ?
<netstar> Any idea when fluxbox will enter breezy universe?
* Treenaks is reading the changelogs incorrectly, or sees a problem
<seb128> lifeless: how did you do to have it black?
<lifeless> seb128: before upgrade, it looked lilke a normal xterm
<lifeless> seb128: after upgrade its got blue background
<seb128> netstar: pool/universe/f/fluxbox/fluxbox_0.9.12-1build1_i386.deb ?
<seb128> lifeless: it has a grey background here
<dilinger> pitti: nice, thanks
<Treenaks> daniels: xorg: Revert to DRI 4.x!     l-r-m: Switch to DRI
<Treenaks> daniels: or am I stupid?
<lifeless> ghmm scp is bust too
<\sh> Mithrandir: please apt-get build-dep grass, thx
<lifeless> seb128: what else on your desktop is grey ?
<lifeless> seb128: and are you looking at uxterm, or at gnome-terminal ?
<Mithrandir> \sh: done
<seb128> lifeless: nothing else is grey, I use GNOME stuff on my destkop ... I just entered "uxterm" from a g-t command line
<lifeless> seb128: thanks
<seb128> np
<lifeless> http://people.ubuntu.com/~robertc/blue-help-Screenshot.png
<seb128> right
<seb128> that's the same grey than my GTK widgets :)
<lifeless> so, uxterm is using gtk now ?!
* lifeless cries
<\sh> lifeless: no
<seb128> lifeless: maybe that's due to xrdb
<\sh> lifeless: can u check your /etc/X11/app-defaults/XTerm ?
<lifeless> sure
<dholbach> mdz, Kamion: can i have permission to upload new librsvg? according to upstream, it makes nautilus more stable, while the API stayed 100% the same
<dholbach> elmo: thanks for the syncs
<lifeless> \sh: what should I look for ?
<bddebian> dholbach: You can't thank him. ;-P
<\sh> lifeless: background 
<seb128> lifeless: echo 'XTerm*background: black' > color && xrdb -merge color
<lifeless> \sh: not present
<\sh> hmpf
<\sh> it should default to white, at least the old ones..
<\sh> I can change it 
<\sh> but should I ?
<lifeless> seb128: echo 'XTerm*background: black' > xterm-colour
<lifeless> robertc@lifelesslap:~/t$ xrdb -merge xterm-colour 
<lifeless> seb128: no change on existing or new terminals
<seb128> lifeless: try with UXTerm rather
<\sh> argl
<Evaso> BenC: ping
<\sh> moment
<lifeless> seb128: fantastric. halfway there
<seb128> cool
<lifeless> I'm guessing white and foreground ?
<\sh> yes
<Evaso> whois actually managing wifi card in ubuntu?
<\sh> seb128: do u think it's worth to default it to the old defaults? white background, black foreground?
<lifeless> seb128: I owe you a beer. collect in montreal
<seb128> lifeless: gnome use xrdb on /etc/gnome/config/ files at startup, you maybe want to hack or comment stuff here
<seb128> lifeless: cool :)
<bddebian> Speaking of UBZ.  I assume week1 is the better of the two if I have to choose?
<lifeless> bddebian: week 1 is distro, week 2 lp
<lifeless> bddebian: neither better nor worse, just what is interesting to you
<bddebian> FuXX0r. Week 1 is over Halloween and my children will disown me :'-(
<seb128> \sh: yeah, but I'm not sure of what changed ... GNOME xrdb stuff didn't, that's probably xorg
<Evaso> whois managing hotplug?
<doko> jdub, mdz: ok to demote mozilla-openoffice.org to universe? it doesn't work
<\sh> seb128: nothing... I think it's from new upstream I *censored* introduced 
<\sh> seb128: I'll have a look
<seb128> k
<\sh> lifeless: btw...can u check if double-clicking on emails and/or ip address highlights them in a correct way?
<bddebian> Are we gonna morgue Yehia?  Didn't sound like elmo thought we should?
<\sh> lifeless: (in xterm/uxterm that is ;))
<lifeless> \sh: what is 'correct way' ?
<lifeless> \sh: they've always acted like words for me
<\sh> lifeless: without any holes in it, i think ;)
<lifeless> seems fine.
<\sh> lifeless: ok..thx
<lifeless> hmm
<lifeless> my high colour stuff is hard to read
<lifeless> whats the xrdb thing to set fonts to 'default' ?
<\sh> bddebian: I don't want this lib anymore...because there is no upstream work anymore
<lifeless> or better yet, how do I turn the xrdb stuff off?
<highvoltage> jdub: sorry, is that on the frontpage the manifesto? from how i understand it, it sounds like it's refering to a bigger document.
<highvoltage> perhaps i just misunderstood.
<\sh> bddebian: what elmo said about yehia?
<bddebian> \sh: I don't disagree but it seems elmo might.  It also affects gql?
<mdz> dholbach: it's a GNOME package and a strict bugfix-only release?
<mdz> doko: it doesn't work or it has no chance of working?
<\sh> bddebian: yes..but I don't care...morgue both ;)
<jsgotangco> good night =)
<bddebian> \sh: I agree but I can't make that decision :-)  Looks like he was worried about the qgl rdepends
<bddebian> Gnight jsgotangco
<doko> mdz: I remember it did work for some snapshot, but at least since 121 it doesn't work anymore (same in unstable), and I see no chance to get it working in breezy.
<mdz> doko: ok
<mdz> doko: what are we doing about a python IDE for main?
<\sh> elmo: we can morgue as well gql...An app which depends on a lib, where upstream doesn't work anymore since a couple of years, it's not worth it to have it in the archives...
<\sh> and now I'm going into lag mode...
<\sh> seb128: btw...what is the purpose to put Emacs.ad into /etc/gnome/config and not into /etc/X11/app-defaults ?
<dholbach> mdz: according to the changelog it fixes loads of bugs and there were no new big features going in since the last release; apart from gnome, pike uses it
<mdz> dholbach: please send the changelog excerpt
<dholbach> mdz: will do
<doko> mdz: we have no good one, see UbuntuMainInclusionQueueIdle. I'd like to see idle in main independent of a decision, because that's the one which comes with the core package. We can add spe or boa-constructor, but both are based on wxwidgets, which looks a bit unstable. I'm still trying to get eclipse-pydev built from source, but eclipse is universe ...
<mdz> doko: jelkner mentioned idle and drpython
<seb128> \sh: this file is installed here by gnome-control-center
<\sh> seb128: *grmpf*
<seb128> \sh: and xrdb is called by gnome-settings-daemon
<\sh> seb128: and emacs21 itself doesn't install app-defaults/Emacs
<dholbach> mdz: http://ubuntu.gplan.info/librsvg2-ChangeLog.excerpt.txt
<mdz> \sh: gql or qgl?
<doko> mdz: drpython is wxwidgets as well. I'll try to contact jelkner about his reasons for drpython
<seb128> \sh: that's a "let's convert X apps to a GTK look"
<\sh> qgl ;)
<\sh> mdz: qgl sry
<mdz> dholbach: oh, this is a late 2.12.0 release?
<\sh> mdz: damnit...now u confused me
<\sh> mdz: gql dep-wait libyehia0.5-0c2
<\sh> this is correct ;)
<seb128> mdz: they are not really in sync with the GNOME desktop, but according to upstream that's their best version ever
* \sh needs some caffeine
* bddebian cracks open a Mt. Dew ;-)
<mdz> seb128: but everything uses it, right?
<mdz> our version is older than 2005-05-15?
<dholbach> mdz: that's when the "new upstream release" appeared in the debian package
<Keybuk> Kamion: Coooooollllllin, how do I delete a bad key out of .ssh/known_hosts now? :p
<dilinger> Keybuk: guess! ;p
<seb128> mdz: we have the same version as hoary had atm
<dholbach> mdz: nautilus uses it, an image-viewer, a game and pike, (ok and the ruby bindings) 
<seb128> mdz: abiword-plugins-gnome gdm libgnome-cil nautilus use it
<seb128> mdz: that's all from main
<mdz> doko: let's get idle in; go ahead and seed it to supported. it's built from python2.4 and so already the source is in main, no
<mdz> doko: ?
<mdz> seb128: oh, that's not so much
<mdz> dholbach,seb128: let's do it
<seb128> mdz: new version fixes quite a bunch of nautilus/svg crashers
<\sh> grmpf
<seb128> mdz: thanks
<dholbach> mdz: the biggest impact will be on nautilus, which will work better - YAY! :)
<doko> mdz: the source is in main, yes. will seed it
<\sh> can someone remove a *censored* mistake of mine? grass-6.0.1-0ubunu1?
<Kamion> Keybuk: ssh-keygen -R
<elmo> \sh: no,it's already been accepted
<\sh> elmo: sry about that...uploading ubuntu1 overrides it?
* \sh needs new glasses...asap
<elmo> \sh: dunno off hand, check with dpkg --compare-versions
<\sh> elmo: k
<slomo_> \sh: ubuntu1 should be lower than ubunu1... t comes before u
<lifeless> seb128: so any suggestion to remove xrdb stuff during startup ?
<lifeless> seb128: i.e. stop it happening at all
<seb128> lifeless: rm /etc/gnome/config/*
<lifeless> thanks
<seb128> lifeless: these are conffiles, if you remove them they will not be reinstalled on upgrades
<Kamion> \sh: just leave it and sort it out at next sync from Debian
<\sh> Kamion: k..I hope they're removing --with-glw as I did
<ogra> Kamion, looks like 15244 is a problem with the DISPLAY variable not being unset fast enough ...
<lifeless> is thomboy known broken
<slomo_> lifeless: tomboy? it works for me and there are no bugreports afaik
<ogra> Kamion, i get a clean ssh connection but x-session-manager threows a "cannot open display" in .xsession-errors ...
<Diziet> Dammitttt, I have a bouncy tttt key.
<lifeless> slomo_: hmm. the panel encountered a problem while loading "OAFIID:TomboyApplet"
<lifeless> click dont delete
<lifeless> comes back :[
<slomo_> lifeless: it is no panel applet anymore... it is in the notification area now
<slomo_> lifeless: so just delete it ;)
<lifeless> ok.
<slomo_> lifeless: and then start tomboy or better add it to your session
<Kamion> ogra: hmm
<lifeless> slomo_: would be nie to migrate it for users
<ogra> Kamion, it happens even if i ran a slay for the user directly after logout to make sure there are no leftovers from the session
<slomo_> lifeless: i don't know how this could be done :(
<pitti> elmo: can you please sync pmount from Debian incoming? Matt and Colin approved
<lifeless> slomo_: so, any hints on sfs-client ?
<ogra> s/ran/run/
<lifeless> I'm not sure where to look for failure results about it
<slomo_> lifeless: sfs-client?
<jdub> doko: please. it really shouldn't ship by defauilt anyway. :)
<bddebian> sfs is broken afaik
<mdke> what does /part mean in the installer when it says "resize /part and use free space"?
<mdke> i choose that and it crashed
<Kamion> mdke: it means there's a bug
<doko> jdub: already done
<mdke> Kamion, known?
<Kamion> send me /var/log/partman
<Kamion> mdke: seen it mentioned but haven't diagnosed it; log files good
<jdub> doko: rawk.
<Kamion> there's meant to be a device name for a partition there
<mdke> Kamion, how can I capture the log?
<Kamion> mdke: switch to tty2, 'anna-install openssh-client-udeb', scp it somewher
<Kamion> e
<lifeless> bddebian: ah, is anyone caring about it ?
<mdke> Kamion, ok i have to go out now but I think I should be able to do that, will file a bug report
<mdke> Kamion, it's preview release btw, not daily
<bddebian> lifeless: It's on the MOTU UniverseUnmetDeps wiki page I think
<lifeless> dbthanks, I'll have a look
<lifeless> bddebian: ^^
<bddebian> :-)
<Kamion> mdke: right, should be no difference
<Kamion> thanks
<mdke> np, got the log
<mdke> later
<mdke> Kamion, which package?
<Kamion> mdke: 'partman' to start with
<\sh> elmo: please sync hk-classes-0.7.3-1 from unstable, thx (universe, new package, needed for knoda)
<elmo> \sh: nothing to sync
<elmo> hk-classes |    0.7.3-1 | breezy/universe | source
<\sh> argl...
<\sh> elmo: thx
<Mithrandir> elmo: can you sync earth3d 1.0.3-1 from unstable?  It's a new package.
<elmo> done
<Mithrandir> thanks
<lifeless> mdke: my disks got faster in breezy
<lifeless> bah
<lifeless> mdz: ^^^
<mdz> doko: no inclusion report for zope-plonelanguagetool (seeded to supported)
<Mithrandir> mdz: can you verify that the new readahead fixes the upgrade problem for you?
<doko> mdz: hmpf, will add one, yes, that was the one package, which is only recommended by plone
<mdz> doko: linguaplone also
<mdz> doko: everything else is promoted to main now
<doko> mdz: cool
<mdz> Mithrandir: ia32-libs-kde is going to universe unless you say something; it's not used by anything in main
<doko> mdz: ia32-libs-kde needs to be added as a dependency to openoffice.org2-kde
<doko> (on amd64)
<mdz> Mithrandir: The following NEW packages will be installed:
<mdz>   readahead
<mdz> Mithrandir: readahead looks good, thanks
<doko> mdz: but you did prompte poppler-utils, not xpdf-utils?
<mdz> doko: yes
<Mithrandir> mdz: yay, good.
<mdz> doko: the builds or whatever are sorted now; germinate is no longer confused
<mdz> Mithrandir: and regarding ia32-libs-kde?
<Mithrandir> doko: are you handling the addition of ia32-libs-kde to ooo2-amd64?
<Mithrandir> doko: or should I?
<doko> Mithrandir: I would appreciate, if you could do. (and adding lib32gcj6 addtionally to all places where you find java-gcj-compat)
<Mithrandir> doko: adding lib32gcj6 should have been done already, iirc.
<Mithrandir> doko: I'll do an upload tomorrow, since it'll take forever from here.
<doko> Mithrandir: any chance to get openoffice.org-amd64 (1.1.4) for amd64? I'd like to see it in universe, it much more lean than OOo2 and does support languages not yet found in OOo2
<doko> hmm, lib32gcj6 is still in universe
<Mithrandir> doko: if ooo 1.1.4 is in universe, sure, I can do that tomorrow.
<doko> Mithrandir: that would be nice. I'm trying to get 1.1.5 to universe later (having the ability to import docs saved with OOo2), but that's not sure, if I can make it for breezy
<lifeless> slomo_: tomboy is still a panel app
<lifeless> slomo_: this is the real cause:
<lifeless> robertc@lifelesslap:~$ tomboy 
<lifeless> ** (/usr/lib/tomboy/Tomboy.exe:9717): WARNING **: The following assembly referenced from /usr/lib/tomboy/Tomboy.exe could not be loaded:
<lifeless>      Assembly:   Mono.Posix    (assemblyref_index=1)
<lifeless>      Version:    1.0.5000.0
<lifeless>      Public Key: 0738eb9f132ed756
<lifeless> The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly (/usr/lib/tomboy).
<slomo_> lifeless: apt-get --reinstall mono-classlib-1.0
<lifeless> mm, well sudo aptitude reinstall :)
<mdz> doko: no report for aspell-de-alt
<mdz> doko: otoh, myspell-de-de-oldspell has a report but is not germinated
* mvo is away now to play hockey
<emile> i'm following a bug i commited, it now had the status upstream. Is there somewhere i can find information on bug status and their meaning?
<Kamion> mdz: can I merge newt to 0.51.6-31? fixes missing bidi support in installer
<doko> mdz: hmm, yes. these packages are built from the same source as aspell-de and myspell-de-de, which already are in main. really need a report?
<jdub> lifeless: so your bonnie++ results are breezy-positive?
<Diziet> I wonder what happened to that dpkg upload.
<mdz> Kamion: sure; what's our ubuntu-specific delta in newt anyway?
<Kamion> and apparently improves BIDI support otherwise
<mdz> doko: no, aspell-de-alt is a separate source package: http://people.ubuntu.com/~mdz/anastacia.txt
<Kamion> Diziet: it reached breezy-changes, but you uploaded with iwj@debian.org in changed-by: which isn't on the whitelist so you didn't get notified
<Kamion> mdz: Xhosa translation (merged in Debian now); python2.4
<Diziet> I've just found that by rereading the source.changes.  How did that get there ?
<mdz> oh, forgot it had a python module
<lifeless> jdub: yes
<lifeless> jdub: breezy love++
<Mithrandir> doko: if you'd care to file a bug for ooo and ooo2 just asking for an update and assigning them to me, that'd be good.
<mdz> Diziet: are you not tracking breezy?  you should have seen the binaries appear and be upgraded by now
<Kamion> good cjwatson@rookery:~/ubuntu/pool/main/d/dpkg$ tar xzOf dpkg_1.13.10ubuntu3.tar.gz dpkg-1.13.10ubuntu2/debian/changelog | head -n6 | tail -n1
<Kamion>  -- Ian Jackson <iwj@debian.org>  Tue, 13 Sep 2005 19:32:44 +0100
<jdub> lifeless: ha ha, you wrote 'thomboy' in your email :)
<mdz> Diziet: iwj@debian.org got there because you used that in changelog
<Kamion> s/^good //
<mdz> lifeless: if you could follow up to the disk performance thread on ubuntu-devel with your results, that'd be grand
<Diziet> Yes, I know it came from the changelog.  I meant which neurons it came from.  I never use that address and who knows where mail to it goes.
<Kamion> oh
<mdz> better than all the hdparm -T posts
<Kamion> confused emacs changelog mode?
<Diziet> Possibly.  I'll have to check.  I should fix my uploading scripts to check for obvious brainos like that.
<Kamion> some DEB_* variable
<Diziet> I keep uploading things to `unstable' too.
<Mithrandir> DEBEMAIL, iirc
<doko> Mithrandir: ok
<Diziet> Maybe I could have it figure it out by looking up the parent directories to find out which hat I was wearing.
<lamont__> export DEBEMAIL="lamont@ubuntu.com"
<lamont__> export DEBFULLNAME="LaMont Jones"
<lamont__> Mithrandir++
<Diziet> (setq 'user-mail-address ...)  but of course that affects everything.
<lamont__> Diziet: I finally just cobbled together a script (uch) which I use for dealing with changelogs - it handles adding the ubuntu version number as needed, etc.
<Diziet> I think for now I'll just put a check in my dpkg-buildpackage wrapper which barfs.
<Mithrandir> Diziet: debian-changelog-mailing-address is what you're looking for.
<Diziet> mith: No, because when I mean `everything' I don't mean `every major mode in Emacs' (which would be fine) I mean `every time I edit a changelog in this Emacs' which is too broad.  I edit changelogs with a Debian hat on too.  I suppose I could have different emacsen but that just makes life harder.
<Diziet> (Debian hat has ian@davenant as the address.)
<mdz> Mithrandir: I think readahead should not invoke its init script in postinst
<Mithrandir> mdz: heh, it does?  I'll fix that.
<mdz> Setting up readahead (0.20050328.0142-0ubuntu2) ...
<mdz>  * Reading desktop files...                                              [ ok ] 
<mdz> Mithrandir: thanks
<Kamion> mdz: did you see the other stuff Edward Trager posted about i18n? various questions of font legality there that we certainly ought to check
<mdz> Kamion: posted where? I'm only just starting in on ubuntu-*
<emile> i'm following a bug i commited, it now had the status upstream. Is there somewhere i can find information on bug status and their meaning?
<emile> please ;-)
<Kamion> mdz: -devel
<Kamion> emile: upstream typically means either that it's upstream's responsibility to fix (i.e. "somebody else's problem") or that it's been explicitly forwarded to upstream
<jdub> and when seb marks a bug upstream, you know that there'll be blood to clean up
<emile> Kamion: ok thnx for explaining.
<doko> mdz: inclusion reports for aspell-de-old and the two missing zope products done
<pitti> mdz: thanks for catching up with the main inclusion queue
<mdz> doko: thanks. Please use the name of the source package to avoid confusion
* Kamion runs off to karate
<dholbach> Kamion: have fun :)
<ogra> doko, spe in main ??
<mdz> doko: MainInclusionReportOldGermanOrthography is supposed to be for hkgerman, right?
<doko> mdz: yes, will change it
<mdz> doko: I don't see an aspell-de-old package anywhere, neither binary nor source
<mdz> doko: and myspell-de-de-oldspell isn't seeded yet
<doko> mdz: aspell-de-alt ... ohh crap, that's a germish name
<Diziet> mdz: re 15336: No, the 16bpp bug was gs.
<Diziet> I haven't tried our firefox on 16bpp but I can easily do so.
<dholbach> have a nice evening
<pitti> bye dholbach 
<doko> hmm, who did drop aspell-de ?
<doko> sorry, s/de/es/
<doko> mdz: aspell-de-alt report done
<pitti>  aspell-es |      1.8-4 |        breezy | all
<pitti> doko: ?
<pitti>  aspell-es | 0.50-2-4ubuntu1 |        breezy | source
<pitti> hmm, odd
<doko> pitti: anastacia output
<pitti> doko: l-s-es still depends on it
<pitti> doko: but the version looks like as if aspell-es was built from another source now
<doko> mdz: severe bug, you have to shrink the browser window to have the anastacia output scrollable again ;-p
<pitti> doko: ah, aspell-es is built from espa-nol
<doko> pitti: ok, then adding it to the seeds should be enough
<pitti> doko: still odd, why is aspell-es built from two different sources? 
<doko> maybe old source, which elmo just removed?
<pitti> doko: in any case, espa-nol has a higher version, so I guess that source package wins for building aspell-es
<pitti> hmm - I can't baz update the breezy seeds. It complains about a missing gpg key C62AC3F4, but that is not on the key servers
<pitti> ah, Ian
<ogra> pitti, yup
<pitti> Diziet: can you please upload your gpg key to somewhere so that we can import it?
<pitti> Diziet: otherwise we can't update the seeds baz archive
<ogra> mdz, is idle worth to be included in edubuntu ? 
<mdz> ogra: you mean in the default install? I don't think so, no
<mdz> ogra: I think there is too much in the default install already
<ogra> ok
<ogra> yup, it is
<mdz> we cannot try to provide for everything that someone might teach somewhere
<ogra> 699MB on powerpc... i'm pondering to drop edubuntu-server there...
<ogra> mdz, 15244 starts looking ery odd...
<ogra> very even
<Diziet> pitti: I sent it to pgp-public-keys@the.earth.li a day or two ago.
<Diziet> Has it not propagated yet ?
<Diziet> Hmm.  No answer from the.
<ogra> Diziet, doesnt look like http://the.earth.li:11371/pks/lookup?op=vindex&search=C62AC3F4
<netstar> X11 is configured with prefix /usr right?
<Diziet> As in, no ack from the keyserver.  Indeed.
<Diziet> Should I add it there through the web ui or would you like me to email it somewhere convenient for you ?
<Diziet> I'll have to chase it up with Noodles too.
<ogra> Diziet, web ui will surely work ...
<ogra> and its up immediately
<Diziet> `Storing 1 keys' it says.
<ogra> :)
<ogra> http://the.earth.li:11371/pks/lookup?op=vindex&search=C62AC3F4
<ogra> there it is ;)
<Diziet> Good-oh.
<mdz> ogra: I cannot reproduce 15244
<mdz> ogra: logout works perfectly for me
<ogra> mdz, relogin within 10 seconds doesnt
<mdz> ogra: oh, I see
<ogra> it takes between 30 and 50 sec if the connection can be established again after logout
<Evaso> hi guys any hotplug maintainer here?
<mdz> ogra: can we fix it in ldm so that pressing enter logs you in, without having to use the mouse?
<ogra> also the switch to Xsession pulled a session dbus startup in that doesnt get killed on logout
<ogra> mdz, yes, i just didnt do any work on the old ui... i'll add it, its trivial...
<mdz> ogra: that will happen in a local login, too, then
<ogra> mdz, hmm, i'll go trying
<mdz> ogra: what causes the second login to fail?
<mdz> ogra: ssh X forwarding fails?
<mdz> ogra: change the ldm ssh command line to include "env;" or something to dump the environment
<jbailey> Anyone here have an evms root and/or jfs root system that's failing to work?  I have an initramfs-tools that ought to solve your problems.
<ogra> mdz, i'll do
<ogra> mdz, local login works perfectly
<doko> mdz: did you make a decision about the rrdtool stuff?
<pvanhoof> My fresh install (on another machine) of Breezy from a testing cd installed a graphical boot thing
<pvanhoof> how can I enable this feature on my from-hoary upgraded breezy?
<pvanhoof> also note that the update-notifier package has serious dependency problems
<mdz> doko: yes, did I not reply?  it's OK with me
<pvanhoof> like .. it doesn't depend on HAL, but without HAL .. it crashes
<pvanhoof> and it doesn't depend on the notification-daemon
<pvanhoof> but without it .. it won't start (d-bus errors)
<pvanhoof> and a hoary to breezy upgrade didn't activate it for my user .. perhaps it should have asked for this
<doko> mdz: cannot find an answer, will request syncs from elmo
<pvanhoof> http://bugzilla.ubuntu.com/show_bug.cgi?id=15526
<pvanhoof> hf
<pablof> debian-installer/locale=pt_BR not works
<jordi> jbailey?
<Lathiat> pvanhoof: dpkg-reconfigure linux-image-`uname -r`
<jbailey> jordi?
<Lathiat> pvanhoof: make sure you have ubuntu-desktop installed, else you wont have installed the package
<pvanhoof> why reconfigure my kernel Lathiat ?
<Lathiat> pvanhoof: it regenerates the initramfs to include usplash (graphical boot)
<pvanhoof> aha
<pvanhoof> I just installed ubuntu-desktop
<pvanhoof> and usplash
<pvanhoof> did it do the reconfigure for me? or do I need to enforce it?
<jbailey> usplash doesn't at the moment.
<pvanhoof> oh and .. the upgrades installed a new kernel for me
<pvanhoof> so the `uname -r` trick wont work right?
<jbailey> Depends if the ABI changed.
<jbailey> So if uname -r gives you the same as the new kernel name.
<pvanhoof> 2.6.12-8-386
<jbailey> Then you'll be fine.
<jbailey> in fact, it may have alreayd happened for you, then.
<jordi> jbailey: we need a new locale in breezy's glibc
<jbailey> jordi: The khurdish one?
<jordi> jbailey: if you could grab ku_TR from belocs and stick it in, that would be more than enough
<jordi> yup
<pvanhoof> always funny :). I just installed a new system with breezy .. and it looked way cooler than this laptop on which I upgraded from hoary
<jordi> pvanhoof: that's what new GNOME defaults do :)
<jbailey> jordi: I still want to convince you to just feed me all of these from Rosetta.. =)
<pvanhoof> I guess, yes
<jordi> jbailey: of course that's a medium term goa.
<jordi> jbailey: and we need to talk to denis about this stuff :)
<jbailey> jordi: 'kay.  I'm going to put in for a UBZ BoF around "Generating locales from Rosetta".  I wonder if we could get him on an irc chat during a session for that?
<jordi> jbailey: should be doable, if he sets date & time
<jordi> that's a good idea
<jbailey> Do you know what timezone he's in?
<jordi> jbailey: make sure you lead, I'm second or whatever
<jordi> CET/CEST
<jbailey> Yup, And I suspect Martin Pitt interested.
<jordi> heh, surely :)
<mae> Why the rabid componentization of xorg?
<jbailey> I'd just love to see us not import Belochs but strip locales out of glibc completely and have it updated by the langpacks mechanism.
<jbailey> Have belochs seed and update rosetta where it can.
<pitti> jbailey: yes, I'd like to join the locales BoF of course; Colin should, too
* jbailey delights in the thought of not trying to piece out whether albanian locale updates are accurate..
<lamont__> Rejected: gtk2-engines-xfce_2.2.7-1_amd64.deb: old version (2.3.0cvs20050306-2) in breezy-autotest >= new version (2.2.7-1) targeted at breezy-autotest.
* lamont__ grumbles at seb128 or elmo or someone.
* luis_ pokes mako
<pitti> Diziet: got your key now, thanks
<fabbione> mdz: unping.. don't worry thanks
<mdz> fabbione: ok, going for lunch now, sms if needed
<pitti> mdz: about ocaml-native-compilers: we had the discussion recently, and there is not really a compelling reason to not support it; can I just seed it?
<fabbione> mdz: enjoy :) i will be around a bit more 
<mdz> pitti: yes
<ogra> fabbione, have you seen how 14967 evolved ? 
<fabbione> ogra: no
<ogra> fabbione, its definately inotify sending wrong events... it seems
<fabbione> ogra: it seems or it does?
<ogra> according to seb128's tests it does
<\sh> fabbione: it does...
<ogra> for all directorys except /usr/share/applications
<ogra> and according to the last comment also for singel files
<ogra> single even
<fabbione> ogra: you mean that it sends wrong notifications for all dirs except /usr/share/applications ?
<fabbione> than you should try to see what makes /usr/share/applications special.. is perhaps the first in the list or the last in the list?
<fabbione> if so, is the test case reproducible using another dir as first/last?
<ogra> fabbione, i think /usr/share/applications is hardcoded as default anywhere... everything monitored dynamically seems to break
<\sh> fabbione: u can use the test suite and set something else..put your machine under load and wait
<fabbione> ogra: the kernel doesn't have any hardcoded path
<\sh> ogra: it has nothing to do with /usr/share/applications
<ogra> fabbione, gnome-menus probably...
<ogra> \sh, butits contents dont disappear
<fabbione> \sh: i don't have a machine. i have been without workstation for 3 days by now. so no i can't test.. if i could, i would have done it days ago
<fabbione> ogra: what happen if you use the test tool outside X/gnome?
<fabbione> ogra: like in init 1 ?
<fabbione> or just don't run anything X related or that uses gamin
<\sh> fabbione: the same...the dir which is watched as default stays...but all other subdirs disappear
<fabbione> \sh: in console?
<\sh> fabbione: yes
<fabbione> without X running?
<\sh> yes
<\sh> and only when load is bashing the machine
<\sh> so load raising to 1 and it starts
<fabbione> \sh: what comment is that in the bug report?
<\sh> fabbione: I have to fill that it...
<\sh> fabbione: I checked it yesterday and forgot to make a copy'n'paste..
<\sh> give me 2 hours more :)
<\sh> well...I can do it now...let me shutdown everything...brb
<\sh> re from console
<\sh> fabbione: disabled now all X stuff...
<jordi> pitti: what about different langpacks for universe, not in the same one?
<pitti> jordi: that's of course an option
<seb128> no language packs for universe
<pitti> jordi: but it would bloat the archive even further
<seb128> pitti: are you kidding me?
<ogra> jordi, found a MOTUi18n team ;)
<seb128> pitti: that would mean to install the .mo from the whole universe to get 1 translation?
<pitti> seb128: mark asked for universe translation _updates_
<pitti> seb128: we won't strip universe packages
<\sh> grmpf
<pitti> seb128: but mark wanted rosetta updates to actually appear somewhere
<\sh> my / ran out of space *gnarf*
<sto> seb128: what about a hook for apt to get individual package translations?
<seb128> pitti: k, I guess nobody will them :)
<seb128> sto: an evol hack? no thanks
<seb128> evol/evil/
<sto> it does not need to be evil
<seb128> you are welcome to send a non-evil hack
<seb128> I doubt you will get one
<pitti> sto: we discussed that to death at the last conference
<pitti> sto: (and at the one before that)
<sto> pitti: maybe I'm wrong, but something like putting the translations on a new language can do it
<pitti> sto: in the end we found that inventing a second archive structure is evil
<sto> pitti: no need of second archive
<sto> LANGUAGES="es_ES@updated:es_ES"
<sto> You put updates on the non standard local
<sto> e
<seb128> that is evil
<sto> seb128: why?
<seb128> because creating new language creates issues and is ugly
<sto> ugly, yes
<sto> sure
<zyga> hello :)
<zyga> translations on the table as I see :)
<sto> but if the programs use gettext it should work
<sto> you are not creating a new language
<sto> only an updated catalog
<sto> LANG should be left as usual
<pitti> sto: what should be the benefit of that?
<sto> pitti: updated translations without touching 10.000 packages
<sto> And the user can easily turn it on/off
<pitti> sto: hm? we don't touch 10.000 packages when we update translations - just the langpacks
<seb128> sto and you would have no translation for non-updated packages
<sto> seb128: wrong
<zyga> what is the issue with simply generating a new langpack for each language every week or so?
<seb128> sto: you use 1 locale, es_ES@updated or es_ES
<sto> if the messages are not in es_ES@updated, the ones on es_ES are used
<seb128> sto: you are reinventing what language-packs are
<seb128> 2 differents dirs
<seb128> one with updates
<sto> seb128: yes
<sto> but the apt hook should only get the translations I want, not everything
<jordi> ah, I opened a can of worms when I have to leave the house
<seb128> that doesn't work
<jordi> sorry. :)
<ogra> *giggle*
<seb128> apt manages packages
<sto> sure
<seb128> so you need a zillion of packages
<sto> and the hook gets only .mo files
<jordi> ogra: this archive bloat might be worth to not bloat the main package langpacks
<sto> Not packages
<sto> And it i s *optional*
<sto> No need to use it if you don't want
<seb128> apt installing something different of .deb packages is what I call an evil hack
<pitti> sto: hm, so exactly what are you trying to solve?
<seb128> pitti: getting the .mo just for the apps installed
<ogra> jordi, yup
<seb128> pitti: and not installing a language pack with a ton of translations you'll not use
<sto> seb128: right, just that
<pitti> sto: ah, I see. Please let me assure to you that we discussed that at least 5 times
<seb128> sto: we have discussed that for months
<pitti> sto: every other way is much more broken than our current one
<sto> pitti: I'm sure I'm not original
<pitti> sto: we can't produce a language pack for every application and every language - that would make the archive explode
<pitti> sto: and the Packages.gz file alone would use half of your hd
<sto> pitti: no need for packages
<pitti> sto: without packages you create even more problems
<mjg59> mdz: You missed the -B 1 in the init script
<mjg59> I'll remove that now
<pitti> sto: you can't put them on CDs, you lose the mirror network, you are reinventing apt
<sto> pitti: you can put them on CD, using a tarfile and a mapping package->.mo files
<seb128> pitti: you need to know if there is an update, etc ... as pitti said you are reinventing a packaging system
<sto> pitti: it's almost the same as the langpacks on that case
<sto> seb128: sure, but a specialized one
<pitti> sto: yes, but apt and the deb structure already solve that for us, we would only duplicate it
<sto> pitti: well, the solution can be implemented with apt
<seb128> sto: you can make a zillions of deb, right .. that would make the package index and the mirror and the users unhappy
<pitti> sto: we even discussed crazy ideas like generating debs on the fly
<sto> seb128: no, you can get langpacks and only install the files needed, not all
<seb128> sto: to install them you have to list all the files, to handle version, to get them by a way, etc
<sto> seb128: well, maybe a langpack can be an index of the files and to get them you can use a different method
<mjg59> elmo: The conversation with Ian started almost identically to the one with "Bruce"
<sto> seb128: how big are your langpacks?
<seb128> sto: now think about the different method, how it would work, etc ... you will probably conclude that apt is already here and does this job and use an existant structure with mirrors, etc instead of redoing that from scratch
<seb128> sto:would be for the whole archive ? 15000 packages ,50 locales ? 750 000 mo files 
<sto> seb128: yes, for the whole archive
<sto> seb128: only one language, of course
<seb128> sto: why only one? the structure has to host all the languages
<seb128> sto: and I use several locales here
<sto> seb128: then you install one langpack per language
<sto> seb128: I'm only trying to know how big is a langpack update
<sto> for one language
<seb128> pitti: question for you
<sto> If I want 10, I know I need 10*size_of_langpack
<sto> Each time it gets updated
<seb128> depending of the update
<seb128> how many translations changed, etc
<pitti> sto: for a well translated language like french or german, a langpack deb is about 4 MB
<Nafallo> jbailey: ping
<sto> pitti: for all the archive?
<jbailey> Nafallo: Pong
<pitti> sto: that is the sum of base and update and gnome and main
<Nafallo> jbailey: hi! are anything soundisch loaded already in the initramfs? :-)
<pitti> sto: for main
<jbailey> Nafallo: *sound*
<jbailey> Is this so that the Ubuntu logo can sing at you, too? =)
<sto> pitti: how many packages?
* jbailey phears the April fools day hampsterdance usplash.
<pitti> sto: in the magnitude of 400
<Nafallo> hehe, no. trying to figure out why my module argument doesn't do what upstream says it should do ;-).
<Nafallo> nice idea though :-P
<sto> pitti: so for everithing it can be 10 times that?
<seb128> sto: no, 400 to 15000
<jbailey> Nafallo: There generally ought not to be.  If you do a modules=dep in /etc/mkinitramfs/initramfs.conf, I suppose it might but it in, though.
<pitti> sto: what is "everything"?
<seb128> sto: everything doesn't ship an mo though ...
<sto> pitti: all the components of the archive, including universe
<sto> seb128: sure
<seb128> sto: what are you trying to argue?
<seb128> sto: let's do the implementation and come with a patch, then we will discuss about it
<pitti> sto: if we would create language-pack-universe update packages, you would get another 200
<Nafallo> jbailey: haven't touched the file :-). I touched /etc/hotplug/pci/snd-via82xx though :-P
<pitti> sto: if we put the universe updates into the existing update packages, we would not get any new package at all
<jbailey> Nafallo: Eh?  What are you trying to do?
<Nafallo> jbailey: tell whatever load the module to load it with ac97_quirk=hp_only
<sto> seb128: ok, I was simply trying to know if it made sense in the first place
<sto> seb128: if the update is small it makes no sense, langpacks are ok
<jbailey> Nafallo: The simplest thing to do is either just put your file and the options in /etc/modules
<seb128> sto: we discussed that for several meeting with everybody from the distro team, we have mails about that for weeks, we had real discussions about that
<Nafallo> jbailey: ah. wasn't sure that file was deprecated or not ;-).
<Nafallo> jbailey: thanx :-)
<seb128> sto: we didn't take the first random b0rked idea to use it
<sto> seb128: ok, forget about it, I don't want to convince any of you of anything
<Nafallo> jbailey: personally I suggest upstream is wrong though :-P
<seb128> sto: no, you just want to say we are all stupid and you will come with a better system with 10 min of discussion :)
<jbailey> Nafallo: Sorry, what are they wrong about? =)
<sto> seb128: no, I'm not saying you are stupid
<seb128> sto: was a joke, don't worry
<Nafallo> jbailey: my Headphones volumething does _not_ merge with Master and disappear :-P
<sto> seb128: I simply would like to have a good solution to the problem
<Nafallo> anyway, reboot :-)
<sto> seb128: but I have not seen a really good one (I don't belive what I say is a good idea, I'm sure it would have a lot of problems)
<seb128> sto: everybody wants that, languagepack is the best we found after weeks of discussions
<sto> seb128: yes, we are doing something similar, but they also seem a hack to me
<pitti> sto: feel free to add some ideas to https://wiki.ubuntu.com/LanguagePacks
<sto> I'll take a look, thanks
<sto> Have to go, bye
<karlheg> jbailey, You there?
<jbailey> karlheg: Yup, /msg'd you as soon as you logged in. =)
<karlheg> I see it.
<karlheg> I've got the patch in front of me.  What do you want to know?
<jbailey> Your patch redoes the move-/dev code without any explanation as to why.
<karlheg> It follows the same steps that the /etc/init.d/udev does; I thought that would be better.
<ajmitch> morning
<bddebian> Heya ajmitch
<karlheg> Also, it's moving things to ${rootmnt}; it looks like the other one does not.
<karlheg> Ah... /root/dev  ... but shouldn't it use the variable ${rootmnt}?
<Nafallo> hmm, didn't help
<jbailey> Yes, that's probably true. =)
<karlheg> I have not solved the problem with file names that have '-' in them.  The manual should probably simply document that, and a loud README ought to go in /etc/mkinitramfs telling of it... or perhaps mkinitramfs should check the file name syntax as a fail-safe.
<jbailey> I had avoided the move to /etc/udev since it didn't make any sense, I could just move it directly onto the already existing /dev directory.
<bmonty> elmo: ping
<jbailey> The mount -n usage, and the ${rootdev} are certainly right, though.
<jbailey> Yeah, I need to document that "-" is a sucky character for hooks.
<jbailey> I couldn't think of any sane way around it.
<karlheg> nomeata, it's moving ${rootmnt}/dev to ${rootmnt}/etc/udev.
<\sh> hmm....
<karlheg> That's to preserve a static /dev, right?
<jbailey> It's to make sure you can still access it if you need.  I think MAKEDEV is hacked somehow to drop device files there still or something.
<\sh> fabbione: I can't reproduce it *grmpf* what did do yesterday to get it
<karlheg> Then in the tmpfs dev that we move to ${rootmnt}, a mount point is created and it's move there.
<karlheg> Sure, so it needs to be put where it will be expected.
<\sh> seb128 / ogra: on the console with nothing then 2 pbuilder and mp3blaster running no inotify bug..load is actually at 3
<seb128> is it fixed?
<\sh> seb128: no
<ogra> seb128, fabbione asked to test without X
<\sh> seb128: yesterday I reproduced it also on the console...but I think I missed X stuff
<karlheg> Anyone else have trash applet leave up a progress window after dumping trash?
<jbailey> karlheg: I'm still too squirmy about changing the version variable for now.  I'd really rather look at that post-breezy.
<jbailey> karlheg: It's not an interesting enough change to be worth risking that some crazy part of LTSP that's not in the usual archive needs it.
<karlheg> No package that requires 'mkinitramfs' uses it.
<karlheg> Can we email the ltsp people and clear it with them?
<jbailey> ogra might now.
<karlheg> OR: export both 'version' and 'VERSION' for now, deprecating 'version'.
<jbailey> ogra: ^^/
<jbailey> ?
<ogra> jbailey, rather mdz
<\sh> seb128 / ogra: so something else is playing a really nasty game...if inotify is running cleanly on the console (without X running), then how can we find a better test case?
<karlheg> It would be better to just have everyone use VERSION.
<karlheg> That's the name that 'mkinitrd' uses, IIRC.
<jbailey> ogra: Yeah, but he's insanely busy, I try to ask anyone else first. =)
<jbailey> ogra: Thanks, though. =)
<karlheg> IIRC, that's what prompted me to change it.
<seb128> how can xorg have an influence on the linux code?
<jbailey> karlheg: Fair 'nuff.
<\sh> seb128: xorg? or gnome
<ogra> jbailey, i just cant give an immediate answer
<seb128> how can this impact on linux?
<karlheg> I should have been working on this more earlier on..
<seb128> I mean it's not supposed to have any userland stuff breaking it
<\sh> seb128: I don't know...we need a kernel hacker ,-)
<karlheg> mdz is insanely busy.  He replies to EVERY email in the list... ;-)
<\sh> I'm not able to debug the kernel side of the game
<seb128> that's like an app crahshing xorg, that's xorg's fault usually
<seb128> whatever an app do xorg should not crash
<ogra> jbailey, but i have enough worrying bugs to care for with ltsp, i wouldnt like to risk anything here
<seb128> whatever xorg do inotify should be robust
<\sh> seb128: this is not so easy...
<seb128> it is
<karlheg> ogra, do you maintain the initramfs support for LTSP?
<seb128> if inotify got broken that's inotify bog
<ogra> karlheg, nope
<ogra> karlheg, but i work on the code from time to time...
<jbailey> karlheg: When you're doing patches, can you do them with diff -up, btw?  It'll include the name of the shell function in the header.
<karlheg> ogra, The specific question is whether it, or any part of LTSP that runs from the hooks that are called by 'mkinitramfs', uses the ${version} variable exported by mkinitramfs?
<\sh> seb128: or it's playing a bad game with us...and the bug is somewhere else
<karlheg> jbailey, Ok; I'll try and remember that.  I just used 'bzr diff'.
<jbailey> karlheg: Ah, thanks.  I'll ask them to consider using that as a default.
<seb128> \sh: between inotify-utils and inotify ? I doubt so
<\sh> seb128: what was the bug number again?
<\sh> seb128: I'm trying to reproduce this with kde
<karlheg> ogra, I've dl the ltsp package source, and could not find any use of that variable.  The thing is that we want to change it from ${version} to ${VERSION}.
<seb128> 14967
<Riddell> \sh: KDE doesn't have any such problems
<\sh> Riddell: it has nothing to do with the menu
<ogra> Riddell, all KDE apps have ...
<seb128> Riddell: sure, KDE fixes inotify linux code ...
<\sh> Riddell: it's a common gamin/inotify bug
<\sh> even if seb128 doesn't want to hear gamin ;)
<seb128> \sh: it happens with inotify-utils
<\sh>  but if something is there in relation between kernel-inotify and X/gnome/kde/bla 
<Riddell> by which I mean KDE does not display the same menu problem as gnome is displaying.  you're a protectionist bunch
<Nafallo> gamin, gajim, gaim: stupid packages! :-P
<\sh> seb128: yes...but in X environment, in the moment speaking of gnome
<\sh> Riddell: forget the menu
<\sh> Riddell: this is only the user display of the bug
<\sh> Riddell: try the inotify-utils
<seb128> Riddell: does KDE use inotify to update its menus?
<ogra> karlheg, i dont see such reference either, but i build edubuntu on top of the ltsp package and i'm late with the ditro, i cant risk any additional breakage at this time of the development cycle
<Riddell> seb128: yes but I suspect not so tightly coupled
<\sh> ok...I'll enter the kde horizon..brb
<seb128> weird that it doesn't react to inotify events so
<Riddell> is there a way to see what inotify watches are active?
<ogra> Riddell, 14967
<ogra> there is a tgz with tools
<karlheg> ogra, I'm 99.9% certain that it won't break anything since there is no reference to a variable named ${VERSION} from anything called from the initramfs/*/hooks/* script.
<jbailey> karlheg: It really sounds like a depreceate-and-remove-after breezy.
<karlheg> jbailey, Nobody's using that variable at all yet.
<jbailey> The problem is that your 99.9% keeps us up all night hunting bugs if you're wrong. =)
<ogra> karlheg, whats the benefit of changing it now ? 
<karlheg> ogra, Not having anything using it by the old name.
<karlheg> 'usplash' will use ${VERSION} if they take my patch.
<karlheg> ... so we need both if anything at all uses ${version} unless 'usplash' is set up with the lower-case name.
<HiddenWolf> crimsun, can you please learn alsa to respect my mixer settings while upgrading...
<karlheg> I wanted it upper case for consistency with other variable names exported by 'mkinitramfs' for use by the hooks.
<crimsun> HiddenWolf: upgrading or dist-upgrading?
<karlheg> ${DESTDIR}, etc.
<\sh> back 
<HiddenWolf> crimsun, dist-upgrading
<karlheg> Also: Is there any other information that mkinitramfs knows that a hook script might need?
<karlheg> (for next cycle)
<crimsun> HiddenWolf: audigy 1, correct?
<LaschW> Anyone noticed system hangs due to xorg-driver-fglrx and linux-restricted-modules-2.6.12_6.8.0-8.16.20-0ubuntu4?
<karlheg> So far, nothing uses 'initramfs-tools' except for 'usplash', 'ltsp-client', and 'linux-image-*'.
<spayne> the Human icon theme seems to be broken
<spayne> known issue?
<ogra> karlheg, i think you should write a mail to -devel to have a bit broader discussion
<karlheg> That's such a small set, it seems managable.  I've looked at all of their mkinitramfs hook scripts... 'usplash' and 'ltsp-client' as source, and the 'linux-image-2.6.12-8-686' as installed.
<\sh> ok...load is 3
<karlheg> ogra, Ok.
<\sh> inotify test is running on /usr/share/applications/
<karlheg> jbailey, Before I write, are there any other issues with the patch?
<karlheg> What about the move from /etc/mkinitramfs/*-top ... to /etc/mkinitramfs/scripts?
<karlheg> That cannot affect any known package either, since none of them install conffiles there; none could have, since there was not previously any code in mkinitramfs that actually copied scripts from there.  That code is added by this patch.
<jbailey> karlheg: As you said, nothing could've been using them so far.  I just have to lookup how to move scripts that people might have put in there.
<jbailey> Right, I'm not worried about packages, those should all use /usr/sharea.
<jbailey> But I need to make sure anything a user thinkgs (s)he put in there gets moved.
<karlheg> jbailey, If they did, they must have had to write a hook for /etc/mkinitramfs/hooks.  That's what I did at first.
<jbailey> Nothing big, just work to do.
<karlheg> How about a NEWS entry, and call it good, since this is devel cycle?
<\sh> hmmm....
<karlheg> It's a minor change, given that the old scripts did not get copied anyhow.
* jbailey squirms
<jbailey> No, I think where it's possible to do the right thing, it's still a good idea.
<karlheg> How about a test in preinst that looks for any files in the old location, and warns?  But that's bad on non-interactive install... though it will be the rare case that message is ever printed.
<karlheg> My bet is that less than 50 people have any kind of custom script so far...  (start a pool?  5 point spread.)
<jbailey> karlheg: Looks like bzr uses internal difflib.  It's not worth the hassle of customising it just for this,
<\sh> seb128: there is nothing happening...not so much as in gnome environment 
<karlheg> Is that the difflib from python2.1-difflib that is part of python now?
<karlheg> Perhaps it has a conffile?
<jbailey> Yup
<jbailey> It just doesn't support that option.
<jbailey> No worries.  bzr can use an external diff if you need, but it's not worth it.
<jbailey> I was hoping to ask them to change it to use -up as a sane default if they were using an external diff anyway.
<jbailey> I'll poke bob2 to see what he thinks of this as a default for the .deb, but I'm not fussed.
<ogra> Riddell, does KDE use gamin ?
<\sh> ogra: yes shermann 30365     1  0 22:57 ?        00:00:00 /usr/lib/gamin/gam_server
<ogra> hmm
<\sh> ogra: but the output from inotify stuff is different then in gnome
<karlheg> jbailey, Ok, so two issues:  version --> VERSION, and /etc/mkinitramfs/*-top ... --> /etc/mkinitramfs/scripts/
<karlheg> Anything else?
<\sh> ogra: with gnome I have more events happening, now with kde only sometimes...not every minute at least one app pulling something
<jbailey> Just not being sure how much of the rework you did for moving /dev is necessary.  I'll make it use ${rootmnt} and mount -n, though.
<jbailey> You don't need to resend for that, I'll do it myself easily enough.
<\sh> ogra: and I have the same load as yesterday...and on the console with nothing running then 2 pbuilder and mp3 player + irssi and inotify stuff == nothing
<karlheg> jbailey, Please show that portion of the diff to the 'udev' maintainer for a second opinion.  I think that it's necessary to do it the way I have it written.  Let's mull it over, step by step:
<\sh> no delete event, no "going away"
<karlheg> Ah, wait...
<jbailey> karlheg: It can't be completely necessary, it's working in production now. =)
<karlheg> Ok, you may be right; I see now.
<\sh> ogra: I'm going nuts with this
<karlheg> You make the directory inside the tmpfs first, then bind mount the static ${rootmnt}/dev onto it before move mounting the tmpfs onto the ${rootmnt}/dev.
<karlheg> That's the same thing with fewer steps.
<ogra> \sh, me too
<karlheg> So unless that bind mount breaks when you move the parent directory, it ought to work fine.
<karlheg> I bet it does not break since the entire tree is moved.
<karlheg> I'll take your version when I 'bzr pull' next time around.
<karlheg> Anything from the 'usplash' people wrt log_*_msg etc?
<HiddenWolf> crimsun, sorry, internet connection is flaky. did you respond?
<jbailey> karlheg: Right.  The kernel rearranges all that internally.
<crimsun> 14:00 < crimsun> HiddenWolf: audigy 1, correct?
<jbailey> Lemme look at your usplash stuff again.  I've only reviewed the insmod bits so far.
<HiddenWolf> crimsun, audigy 2, since I've gotten it to work.
<Riddell> mdz: https://wiki.ubuntu.com/MainInclusionReportAdept
<karlheg> jbailey, Do you think that all the 'local _varname' stuff is overkill?
<HiddenWolf> seb128, my gtkfilechooser dialog is showing me 2 non-existant files....
<\sh> ogra: updated 14967
<jbailey> karlheg: "local" isn't posix, I don't even know if busybox supports it.
<karlheg> jbailey, I'm just trying to keep namespaces clean;
<crimsun> HiddenWolf: bug? I remember reading it, but I'm trying to fix a more critical one atm (kernel oops)
<sladen> ogra: where do Edubuntu bugs go?
<karlheg> It's overkill anyhow, I guess.
<jbailey> Right.  I've been trying to move to where local variables are prepended with their functionname.
<HiddenWolf> crimsun, I'll check for a bug number, or post one.
<jbailey> or an abbreviation of it.
<jbailey> Especially since I like using 'x' for loops. =)
<sladen> ogra: malone or bugzilla/product=Ubuntu ?
<seb128> HiddenWolf: what files?
<HiddenWolf> crimsun, I just spent half an hour searching for the problem when an alsa upgrade closed my line-in
<karlheg> I always use the first letter of the name of the thing I'm looping over, like f for file, or m for module.
<HiddenWolf> seb128, a folder and a .torrent file that I deleted. Nautilus doesn't show them, they're in trash.
<ogra> sladen, everything in edubuntu is in main ;)
<ogra> so bugzilla
<jbailey> For the initramfs modules, the modules.d/usplash can't contain fbconf and vga16b.  IIRC, there was some case where they shouldn't be auto-loaderd.
<karlheg> I like the edubuntu art work.  I installed it to see and it looks very nice.
<jbailey> Anything in modules is forcably loaded, it's just a shortcut that behaves the same as /etc/mkinitrd/modules
<\sh> hmmm..
<karlheg> jbailey, Right.  The patch I sent to them removes that file.
<jbailey> ogra: Thinking of which, Will you have edubuntu usplash artwork? =)
<sladen> ogra: as is everything in Kubuntu ...but that as a separate product
<\sh> seb128 / ogra: I'm running now a debug session on the gam_server
<karlheg> They cannot be force loaded in case the user boots with vesafb.
<jbailey> karlheg: Whups, I was looking at the first patch in 15129
<jbailey> karlheg: Might be better to upload patches to bugzilla rather than posting them inline.  Bugzilla includes the ability to say that a newer patch obsoletes the old one.
<karlheg> jbailey, Ah.  Ok.
<karlheg> I'll remember that.  Should I repost it?
<karlheg> If you have writes, perhaps you can remove the patches from the comment text?
<ogra> jbailey, i'll try to donate some hours on the weekend to that
<karlheg> Is anyone else having trouble with the trashapplet?
<jbailey> ogra: I can supply you the one I did, but I used a paintbrush to draw an "E D" over the Ubuntu logo for my testing. =)
<karlheg> When you empty trash, does it leave the progress meter on screen?
<ogra> heh
<HiddenWolf> seb128, illustrating: http://www.geocities.com/hiddenwolfsof/screenshot.png
<jbailey> karlheg: Nope, not important.  It's just convenient if you're posting patches in the future.  BZ's support for patches as attachments is surprisingly good.
<ogra> jbailey, mail it, probably some cleaning is enough ;)
<jbailey> karlheg: I tend to apply patches by hand, but in-body, this would lose all of the tabs, etc.  and attached patch file preserves it.
<seb128> HiddenWolf: which one is wrong?
<jbailey> ogra: dude, no, not at all.  I didn't even use my tablet for it, I used my mouse. =)
<karlheg> jbailey, I will repost it there the right way.
<seb128> HiddenWolf: hum, I've deleted them before opening the fileselector?
<jbailey> karlheg: Totally no worries.  This is small enough to not bother.
<ogra> jbailey, i do all my artwork with my touchpad... nobody complained yet ;)
<jbailey> Ahaha, serious?
<ogra> yup
<jbailey> I bought a Wacom tablet for my wife ages ago.
<HiddenWolf> seb128, filechooser is wrong
<\sh> jbailey: he's serious ;)
<jbailey> Mostly we use it for better freecell games now.
<HiddenWolf> seb128, those files have been deleted for days.
<seb128> HiddenWolf: how weird
<ogra> jbailey, i have a stac of wacoms, but i didnt use them since ages
<jbailey> I cut about 10% off my score with a pen. =)
<ogra> stack even
<jbailey> s/score/time/
<\sh> ogra: and u didn't tell me ;)
<Lathiat> fabbione: did the new kernel benc uploaded include that fix
<jbailey> ogra: http://people.ubuntu.com/~jbailey/edubuntu.png
<HiddenWolf> seb128, trash cleaned out, doesn't change it. :P
<ogra> \sh, 2 are in hannover, 2 are in some moving box and not even unpacked
<jbailey> I have a Kubuntu one in a similar style. =)
<ogra> jbailey, hmm, that needs *some* cleanup *g*
* ogra thinks of Mr. Ed
<jbailey> Yeah, not enough colour depths to put a horse on there. =)
<ogra> lol
<seb128> HiddenWolf: weird
<jbailey> Hmm, I should decruft my homedir sometime after breezy releases.
<karlheg> jbailey, the usplash patch is uploaded to https://bugzilla.ubuntu.com/show_bug.cgi?id=15129
<HiddenWolf> seb128, ls actually shows that nautilus is wrong...
<seb128> ah ah
<seb128> less weird now :)
<seb128> \sh: EVENT ON WD=1
<seb128> DELETE_SELF (file) 0x00000400
<jbailey> karlheg: Nice, thanks.
<seb128> \sh: that's from GNOME without using gnome-panel
<karlheg> I used 'smeg' a while ago, when I was running Hoary, to edit the menus.  I want to revert to default Breezy menus, but smeg does not seem to have an option for that.
<\sh> seb128: check my last logfiles...I updated just now running KDE
<\sh> seb128: inotify and gamin debug
<HiddenWolf> seb128, does it make any sense?
<\sh> seb128: nothing..no no no DELETE_SELF stuff
<seb128> \sh: I don't have KDE to try from it
<\sh> seb128: but I have :) and just now a load of 3 
<seb128> HiddenWolf: not really ... do you have a .hidden ?
<\sh> since 45 mins actually
<seb128> \sh: you said the other day it's not load dependend for you
<HiddenWolf> seb128, no
<\sh> seb128: yes....but I didn't realize that my load was 1 when I was running rhythmbox :(
<\sh> seb128: since I started with debugging I had quite a closer look on my system...
<seb128> \sh: I've it without nautilus or gnome-panel running
<\sh> seb128: what is it...
<seb128> let me try from wmaker :)
<\sh> and now...
<\sh> let me start evolution
<\sh> hmmm
<seb128> happens from wmaker with no GNOMish stuff used
<Burgundavia> jbailey, that is quite the well polished edubuntu boot splash there
<jbailey> Burgundavia: It's a new artstyle.  I'm trying to bring the joy of fingerpainting to the digital world.
<jbailey> It *is* supposed to be a distro for schools, after all. =)
<Lathiat> jbailey: haha
<\sh> seb128: nothing at my place...
<Lathiat> nice image
<\sh> seb128: even with evolution gnome-panel started on kde;)
<seb128> \sh: you are under KDE? nothing happens even with some load?
<HiddenWolf> seb128, Attachment #3830  to Bug #15545 Created
<seb128> \sh: do you use esd?
<\sh> seb128: nothing as i said
<\sh> seb128: no
<seb128> could you try with it ?
<\sh> seb128: on gnome yes
<\sh> seb128: sure
<seb128> HiddenWolf: thanks but this bug is useless as it and I don't get the issue
<HiddenWolf> seb128, hm, issue is that the files seem to exist but nautilus thinks they are deleted.
<HiddenWolf> seb128, or the files are deleted but ls and gtkfilechooser are wrong, that's an option too.
<seb128> ls beeing wrong is not an option
<\sh> seb128: ok...esd started...rhythmbox started ....
<karlheg> HiddenWolf, 'ls' cannot be wrong.
<HiddenWolf> Then it's nautilus.
<seb128> ctrl-R changes something?
<karlheg> HiddenWolf, Of course.
<karlheg> HiddenWolf, Do they go away when you click its refresh button?
<HiddenWolf> seb128, no. files have been 'deleted' in nautilus a few days ago.
<seb128> and nautilus is running for a few days ?
<seb128> or have you restarted it ?
<HiddenWolf> seb128, rebooted 4 times today alone.
<seb128> xfiles
<HiddenWolf> seb128, ?
<seb128> that makes no sense
<seb128> files are here
<seb128> you have rebooted
<HiddenWolf> seb128, I'm not messing with you, nautilus does not show them.
<seb128> and nautilus doesn't list them
<\sh> seb128: have itt
<seb128> \sh: since you use esd? :)
<Lathiat> can you get build logs for packages from debian?
<\sh> seb128: yes...but not in the inotify
<seb128> \sh: how "not in the inotify"?
<karlheg> HiddenWolf, What are the permissions of the directories on the path and of the files you cannot see?
<\sh> seb128: not in the inotify output of the test suite...only in the gamin server
<\sh> seb128: inotify: resource /home/shermann/.kde/share/apps/kicker/psi.desktop went away. Adding it to missing list
<\sh> inotify: Emitting Deleted on /home/shermann/.kde/share/apps/kicker/psi.desktop
<seb128> karlheg: good question, if there is an issue that's probably something like that :)
<\sh> inotify: got an event for unknown wd 857
<\sh> inotify: resource /home/shermann/.kde/share/apps/kicker/konqbrowser.desktop went away. Adding it to missing list
<\sh> inotify: Emitting Deleted on /home/shermann/.kde/share/apps/kicker/konqbrowser.desktop
<\sh> seb128: and no sign of kde involvement
<seb128> KDE doesn't react to events
<HiddenWolf> karlheg, just plain permissions, how do I check it from the command line?
<seb128> it's KDE bog :p
<seb128> HiddenWolf: ls -l <folder>
<\sh> seb128: *lol* 
<karlheg> Hmmm... Gimmee a minute.
<\sh> seb128: but I got them first when I started esd and rhythmbox
<HiddenWolf> seb128, karlheg drwxr-xr-x  2 hidde hidde  4096 2005-09-13 07:31 for one
<\sh> seb128: before that, not "went away"
<HiddenWolf> -rw-r--r--  1 hidde hidde     0 2005-09-12 18:29 - for the other
<\sh> seb128: and nothing in /usr/share/applications/*
<karlheg> for d in home myname subdir; do ls -lh $d; done; ls -lh /home/myname/subdir/filename
<marcin_ant> hi sorry to bother but could someone tell me how can I get what are default gcc flags in ubuntu breezy?
<seb128> \sh: I got some of then when starting epiphany which blocked on esound, and another one when stopping esd ... I would blame esd
<karlheg> HiddenWolf, is the file a .file?
<HiddenWolf> karlheg, check the screenshot, no.
<HiddenWolf> karlheg, no .hidden file either.
<\sh> seb128: ok..now we have more patients then before...from gnome-panel to gamin to inotify back to something else ;)
<seb128> \sh: I still blame inotify, should be robust
<seb128> \sh: and I never blamed gnome-panel :)
<\sh> seb128: inotify: resource /usr/share/applications/defaults.list went away. Adding it to missing list
<\sh> inotify: resource /usr/share/applications/mimeinfo.cache went away. Adding it to missing list
<seb128> \sh: I guess now you can try to move esound away and run GNOME again
<\sh> seb128: I'll stop the debug session now and provide the logfiles
<ogra> seb128, esd sounds like a good candidate, but how should it influence inotify ? 
<seb128> \sh: but that makes no sense
* ogra cant imagine
<seb128> maybe it uses some signal that confuse inotify
<ogra> hmm
<ogra> i dont even need it with ltsp ...
<seb128> we are not sure it's that
<\sh> gnome-vfs?
<seb128> try to get it without esound
<seb128> \sh: I had no gnome-vfs-daemon running and got the issue, I doubt a lib does that
<\sh> seb128: I have a headache now
<seb128> HiddenWolf: is this issue new? is that specific to your user?
<seb128> HiddenWolf: maybe that's could be due to your "hidde" username
<HiddenWolf> seb128, I've never seen it before.
<HiddenWolf> seb128, I've used this name for more than a year on ubuntu now.
<HiddenWolf> It's my first name.
<seb128> HiddenWolf: what does gnomevfs-ls /folder says
<HiddenWolf> seb128, a lot, but it shows the files.
<seb128> can you paste the lines about the files not listed by nautilus
<\sh> seb128: but which lib can it be
<seb128> to a query if you want
<seb128> \sh: not a lib, esd 
<seb128> HiddenWolf: NOTABUG
<seb128> the filename is useful here
<seb128> file~ is a backup file
<\sh> seb128: ok...I'll disable esd now when I'm back in gnome
<seb128> it's due to the ~
<HiddenWolf> seb128, weird.
<\sh> brb
<seb128> HiddenWolf: go to the nautilus preference and click on the option to list hidden and backup files
#ubuntu-devel 2005-09-21
<HiddenWolf> hm, there is an option to show backup files?
* HiddenWolf searches
<HiddenWolf> seb128, sorry to bug you.
<seb128> first tab of the prefs
<seb128> np
<HiddenWolf> Good night. 
<HiddenWolf> I've got class 9am tomorrow. ;)
<doko> elmo: please could you dist-upgrade concordia/breezy-i386 and davis/breezy and install openoffice.org2 b-d's
<seb128> HiddenWolf: later
<\sh> ok back in gnome without esd
<\sh> producing load ;)
<\sh> 00:07:18 up 10:49,  7 users,  load average: 2,50, 2,13, 2,53
<\sh> should be enouh
<Kamion> ogra: oh, since I see people were talking about artwork above, let me know when you've got plausible usplash artwork and I'll make it be the isolinux splash for Edubuntu CDs as well
<ogra> Kamion, ok
<ogra> Kamion, thanks :)
<Kamion> ogra: I need to be able to crop it to 639x320 without losing anything important (any usplash artwork should be fine for that), black background preferably, 16 colours, ideally one of the colours in the image should be fairly close to white so that isolinux can use that palette entry for drawing text too
<Kamion> I'll take care of the rest
<ogra> Kamion, i'll do an artwork session on the weekend :)
<\sh> seb128: kde menus gone
<\sh> seb128: read = 32
<\sh> sizeof inotify_event = 16
<\sh> pevent->len = 0
<\sh> pevent->len = 0
<\sh> EVENT ON WD=1
<\sh> DELETE_SELF (file) 0x00000400
<sabdfl> mdz: please could you put the screensaver dialog into Cliff's list for improvement? i've asked mpt to help ogra with it
<\sh> seb128: esd isn't to blame ;)
<mdz> sabdfl: sure
<ogra> sabdfl, thanks
<mdz> mjg59: I did? argh, thanks for fixing
<mdz> ogra: please send me the source file for the screensaver dialog, and I'll pass it on
<sabdfl> mdz: are you convinced about the "login as someone else" thing?
<sabdfl> i'm not
<mdz> sabdfl: nope
<sabdfl> ok, can we can that then?
<seb128> \sh: so it's plain inotify bog :)
<sabdfl> i think it's a recipe for trouble
<mdz> useful feature, sure, it's the UI I'm unconvinced about
<mdz> sabdfl: no argument here if we can't find a more pleasant way to present it
<\sh> seb128: but why is it not happening on console with high load or in kde? 
<\sh> seb128: and no console doesn't fix the kernel ,-)
<\sh> seb128: and kde neither ;)
<sabdfl> let's spec that out at UBZ
* \sh has really a headache and now aspirin in da house 
<ogra> sabdfl, it was mpt's suggestion... i've no prob to change it to "change user" or something along that line
<crimsun> mdz: "Choose another user" (with a menu, possibly)?
<sabdfl> ogra: we'll spec it properly in UBZ for Dapper
<\sh> s/now/no/
<ogra> sabdfl, we planned to go with gnome-screensaver for dapper
<mpt> No matter what it's labelled, it's in the wrong place if it's the only button.
<ogra> sabdfl, it wasnt just ready in time
<mpt> because that's where you'd expect an OK button.
<seb128> \sh: you didn't get it, doesn't mean it doesn't happen
<crimsun> mpt: agreed
<sabdfl> please let's drop it. let's go with a nice classy auth dialog, that's all
<seb128> \sh: it happens with wmaker here by example
<\sh> seb128: but something is different in the handling of those things
<ogra> sabdfl, drop it completely ?
<sabdfl> ogra: yes
<\sh> seb128: can't we work around this?
<ogra> ok
<karlheg> Is latest Breezy XMMS working for yous?
<seb128> \sh: work around what?
<karlheg> It fails to run here.
<Kamion> erk, my wife and I use the 'new login'-style thing all the time
<sabdfl> i ust don't think we can get it slick by breezy, given the state it is in currently
<Kamion> in xscreensaver
<tseng> Kamion: i think you want #ubuntu.
<\sh> seb128: when the event appears just re-add those missing things?
<karlheg> Message: device: default
<karlheg> Message: fmt 5, channels: 2
<karlheg> *** glibc detected *** double free or corruption (out): 0xb6ccc738 ***
<Kamion> I think it's very commonly used on shared computers
<Kamion> tseng: no I don't
<sabdfl> Kamion: if you are already logged in, does it reuse that login?
<crimsun> karlheg: < tseng> ...i think you want #ubuntu
<tseng> Kamion: er, karlheg.
<tseng> who also wants bugzilla
<Kamion> sabdfl: IIRC it says "you're already logged in <here>" but it's been a while, we're in the habit of ctrl-alt-f7/ctrl-alt-f8 if already logged in
<seb128> \sh: you mean "why not starting to workaround all the apps using notificiation instead of fixing inotify"?
<Kamion> removing it's pretty horrible, it means you just can't use the machine graphically unless you know how to fire up a new X server
<sabdfl> what's the <here> ?
<sabdfl> can we provide a simple "logout" option?
<Kamion> sabdfl: like I say it's been a while and I think the last few times have been on Debian; I'll try it and let you know
<Kamion> not logout!
<Kamion> I don't want my state canned because somebody else wanted to log in
<Kamion> anyway, bedtime
<\sh> seb128: well, temporarily yes, to have a clean desktop for ubuntu release 510
<mjg59> Yeah, "logout" would be a bit mad
<ogra> Kamion++, no logout
<sabdfl> ok, no logout
<\sh> seb128: i don't really have a clue how difficult this will be...
<sabdfl> right now the dialog looks terrible, and i don't see a resource that we can put on making it really slick
<ogra> sabdfl, the new login button is an upstream thing...
<mpt> upstream looks terrible too, ogra :-)
<Burgundavia> what about reverting the hoary style dialog?
<sabdfl> it's not just the layout
<ogra> sabdfl, i can revert it to the hoary one
<seb128> \sh: we can use the same effort to fix it
<sabdfl> to do it properly requires that it deal with a number of situations
<mpt> Ideally it would be resume by default, with a checkbox for new session
<ogra> mpt, yes, i know thats why i started the patch once
<sabdfl>  - it needs to tell you who is already logged in, so you can switch to one of them
<sabdfl>  - it needs to let you log in as a brand new user
<sabdfl>  - it needs to do all of that while looking classy
<sabdfl> that's going to take a little while
<\sh> seb128: so poking fabbione or benC to fix the kernel bog? ,-)
<sabdfl> and apparently the code and resources are a bit crappy to work with
<mpt> and realistically depends on gnome-screensaver
<\sh> seb128: without knowing what triggers the bug
<ogra> sabdfl, probably we should consider gnome-screensaver for breezy already, it offers much of the above
<Nafallo> ogra++
<Burgundavia> sabdfl, g-s is quite stable already, and does everything we need (except for the millions of screensavers that xscreensaver offers)
<HrdwrBoB> Burgundavia: which tbh are mostly not that good
<ogra> sabdfl, my only concern with it is, that its quite slow in bringing up the dialog and you have no options for the single screensavers yet
<ogra> Burgundavia, wrong
<Nafallo> well, "Pop art squares" should be enough for anyone :-P
<Burgundavia> ogra, ok, it offers some
<ogra> it can use all screensavers from xscreensaver
<seb128> \sh: right, patching all the client is not an option
<sabdfl> ok, i just played with it a little
<mjg59> The fact that it takes *so long* to pop up a dialog is an issue
<sabdfl> it worked fine, when i tried to log in as me again it told me what was going on
<sabdfl> i reused the session
<Nafallo> Burgundavia: ehm, get up-to-date and look at it. it has the xscreensaver hacks to :-)
<seb128> \sh: we the same efforts we can probably tackle the bug instead of workarounding it
<sabdfl> then it gave me an odd error message abut other virtual terminals :20 being open?
<mjg59> But that can probably be fixed by instantiating the dialog at startup, and just displaying it when it should appear
<Burgundavia> Nafallo, I have the latest, but I don't have xscreensaver installed as well
<mjg59> But if this decision is going to be made, it needs to be made quickly
<mjg59> It impacts on power management
<\sh> seb128: agreed...so we have to convince the two to do some extra nightshifts until kernel freeze ;-)
<Nafallo> Burgundavia: ah, that's the problem then :-)
<ogra> mjg59, it impacts positively, doesnt it ? 
<mjg59> ogra: Does it? How so?
<sabdfl> do we have a package of gnome-screensaver?
<mjg59> sabdfl: Yes
<sabdfl> has anybody here played with it extensively?
<mjg59> ogra: We need to send it lock signals on suspend
<Burgundavia> yes
<ogra> sabdfl, only a bit...
<mjg59> seb128: Hmm. has something happened to the sleep button patch in control-center?
<ogra> mjg59, it knows the xscreensaver options afaik
* mpt comes back from the Etherdeath
<Burgundavia> some minor visual glitches on resume, but it does show up
<HrdwrBoB> mjg59: yes, the current system is broken 
<mjg59> ogra: But signals via dbus
<mjg59> HrdwrBoB: ?
<Burgundavia> resume from disk that is
<sabdfl> ok, i'll install it and test it
<HrdwrBoB> mjg59: it resumes gives me up to a second of response
<HrdwrBoB> and then locks.
<mjg59> HrdwrBoB: What's that in response to?
<HrdwrBoB> resuming and locking
<ogra> sabdfl, as i said, we loose the option to change options for single screensavers, there is no ui for that
<mjg59> HrdwrBoB: Locking the screen? On Breezy?
<HrdwrBoB> yes
<Burgundavia> mjg59, I see the same thing
<mjg59> HrdwrBoB: We signal xscreensaver on suspend. It just takes far too long to actually do it.
<ogra> sabdfl, thatd need to be solved imho
<mjg59> ogra: Why?
<mpt> I'd rather have a sensible account-switching interface than be able to change the number of fireworks in the sky at once
<HrdwrBoB> mjg59: ugh, I'm disabling it anyway, I think it shouldn't be on laptop mode but that's just the way I use the laptop
<Nafallo> mpt++
<HrdwrBoB> yes, mpt is right
<mjg59> HrdwrBoB: "Shouldn't be on laptop mode"?
<HrdwrBoB> sorry shouldn't lock the screen when it goes into suspend
<mjg59> Why not?
<ogra> mpt, mjg59 , you probably want sound/no sound... or adjust the rss feed for all the rss reading screensavers etc
<mpt> There are screensavers with sound???
<mjg59> ogra: They're massively fringe use cases
<ogra> mpt, lots
<mjg59> Having something that *works* is more important
<HrdwrBoB> I suspend/resume my laptop all the time and I get sick of putting in my password, but I've no idea if I'm a common case or not
<seb128> mjg59: the patch to use gdm-signal? no, it's still used
<ogra> mjg59, for that i would go with the proven solution...
<\sh> HrdwrBoB: when u have your laptop all the time in your view...it's ok...but if it's standing around and others can touch it, I like it more secured
<Nafallo> HrdwrBoB: I would rather put in my password then let Joe User come bye and play with my system :-).
<seb128> \sh: I'll try with a fresh boot from the command line
<\sh> seb128: k
<HrdwrBoB> \sh: yeah
<Nafallo> where, "Joe User" == girlfriend ;-)
<mjg59> seb128: Oh, right. I missed it because it's using some insane build system
<HrdwrBoB> realistically this is something that needs to be in a 'power management' dialog
<\sh> Nafallo: your solution should be: delete pr0n stuff ,)
<Nafallo> \sh: baah. that's on the server. she can use her own client to fetch those :-).
<mpt> HrdwrBob: yeah, screensaver config <-> power management config is a really ugly continuum
<sabdfl> do i need xlibs-data?
<seb128> mjg59: cdbs and simple-patchsys is nice
<mpt> Windows and OS X are both annoying in that respect
<ogra> sabdfl, for gnome-screensaver ?
<sabdfl> at all?
<seb128> \sh: and I'll not install KDE to try that :p
<mjg59> seb128: It means if I do apt-get source, I need to do other things to actually get the source that will build, which is always a pain...
<sabdfl> nothing seems to depend on it
<\sh> seb128: hehehe....coward ,-)
<ogra> sabdfl, ... i think its a transitional package 
<seb128> mjg59: oh, that, right
<seb128> \sh: anyway, I'll comment on the bug after trying from the command line
<Nafallo> sabdfl: if you got space for it you could aswell keep it till daniels says otherwise ;-). that policy wfm :-).
<\sh> seb128: actually we need only on piece of evidence for blaming at least kernel, apps or libs, or the beast 
<ogra> sabdfl, it pulls in xcursor-themes and xkeyboard-config 
<seb128> sabdfl: I update and use gnome-screensaver for 2 months, it's nice and works fine
<\sh> s/on/one/
<sabdfl> bugger it, i'll let the system remove it and see what happens
<sabdfl> nothing seems to depend on it
<sabdfl> seb128: ok, in your hands i have a lot of confidence already :-)
<mdz> ogra: speaking of sound, we should disable that by default
<Nafallo> famous last words... ;-)
<sabdfl> let me play with it
<mdz> that @#$@# fireworks screensaver woke me up last night
<seb128> sabdfl: thanks :)
<sabdfl> errr.. sound?
<sabdfl> oh
<mdz> BOOM BOOM BOOM
<seb128> sabdfl: Novell guys did a security review and said there is no issue with it too
<mpt> I use that screensaver, I didn't realize it had sound
<sabdfl> dude, you live in l.a.
<mdz> I close my windows at night
<ogra> mdz, we're just tracking 14967 in esd direction... i was thinking about ripping it out :)
<Nafallo> Fireworkx?
<\sh> ogra: esd is not to blame
<\sh> ogra: it happened to me without esd
<ogra> \sh, sure ? 
<ogra> gah
<\sh> ogra: yes
<mdz> ogra: I don't even see a checkbox in preferences for it
<seb128> that's a plain inotify bug imho
<ogra> mdz, oh, you mean xscreensaver (i'm so in edubuntu)
<Lathiat> the only thing that annoys me about gnome-screensaver is that its horribly slow bringing up the unlock dialog and even more so when the system is under cpu or i/o load (it took 25 seconds once) it really needs to cache this window or something
<\sh> seb128: play with the console and check again
<ogra> mdz, sabdfl #15284 for your amusement :)
<Nafallo> Lathiat: ehm, and xscreensaver just pops it up?
<Lathiat> Nafallo: xscreensaver is instant all the timer
<Lathiat> gnome-screensaver can typically take at least a second or two
<schweeb> gnome-screensaver is fucking slow
<Nafallo> hmm, this laptop _should not_ try to do gl :-P
<mpt> fwiw, the OS X unlock dialog regularly takes 10~20 seconds
<Lathiat> if they could fix that issue i'd love it
<mdz> Lathiat: it'd be a good match for gdm then
<\sh> ogra: this is a joke, right?
<Lathiat> mdz: eh?
<ogra> \sh, nope, thats a serious bug :)
<mdz> \sh: most likely, but the premise is valid
<sabdfl> seb128: think you can fix the time-to-display problem?
<Lathiat> mpt: wow, screw using macosx. :)
<mdz> Lathiat,sabdfl: gdm slowness bug is http://bugzilla.ubuntu.com/show_bug.cgi?id=15373
<\sh> mdz / ogra: this bug should be in the top 10 ,-)
<seb128> sabdfl: need to figure why it's slow first, but probably yep
<ogra> heh
<sabdfl> being slower to start screensaver is better than slower to exit
<sabdfl> so, in theory, to setup fglrx should just require which command?
<mdz> mjg59: can that code be in one place instead of 2?
<mjg59> mdz: The hdparm stuff? There's no reason why not
<mdz> sabdfl: I was just noticing recently that we don't seem to have an equivalent of nvidia-glx-config
<mdz> sabdfl: we ought to
<seb128> brb, trying inotify
<Burgundavia> sabdfl, fglrx is nasty to setup, with much breakage
<sabdfl> ok
<Lathiat> mdz: equivalent to nvidia-glx-confnig for what?
<Lathiat> mdz: fglrx?
<mdz> Lathiat: yes
<Burgundavia> sabdfl, contrast https://wiki.ubuntu.com/BinaryDriverHowto/ATI with https://wiki.ubuntu.com/BinaryDriverHowto/Nvidia
<Lathiat> betweeen my ATI and my Nvidia, all i ever had to do was stick fglrx/nvidia in my xorg.conf and it worked
<Lathiat> no loading modules, etc
<\sh> Lathiat: because it's loading automatically 
<Lathiat> \sh: whatever the cause those pages appear to be unncesarily complicated
<Lathiat> well, nvidia isnt so bad
<ogra> Lathiat++
<Lathiat> NoLogo is nice for nvidia tho
<\sh> Lathiat: correct
<Lathiat> cus it delays X startup 
* \sh awaits seb128 report 
<Burgundavia> Lathiat, you are lucky, a lot of people have trouble with nvidia/ati drivers
<Lathiat> Burgundavia: yeh?
* Lathiat seems to always be lucky
<ogra> Lathiat, but its not nice to advise the user to edit xorg.conf without a warning that automated upgrades wont work anymore
<Lathiat> things work for me all the time that never work for anyone else, but the bugs i do get *no-one* else gets
<Lathiat> ogra: yeh well the wiki has alot of sucky guides
<ogra> it was better once
<Lathiat> maybe when im bored one day i'll go do some mass non-sucking
<Burgundavia> Lathiat, feel free to edit
<Lathiat> #ubuntu is terrible too
<Burgundavia> Lathiat, CategoryCleanup
<ogra> at least the nvidia/ati page
* Lathiat stopped going there as he ended up there for hours
<mpt> wikis are addictive
<Burgundavia> the doc team hasn't worked on the wiki much, been working on the shipping docs
<HrdwrBoB> Lathiat: #ubuntu is bad because the general clue of the users in there has gone down
<bob2> f/scroe
<HrdwrBoB> because most semi intelligent life forms have worked out how to use it by now
<Lathiat> HrdwrBoB: its never really been much good for quite a while
<Lathiat> as such i get stuck there whenever i join
<Lathiat> blind leading the blind
<HrdwrBoB> yeah
<Burgundavia> a lot of us have also fled #ubuntu as the level goes down
<seb128> got the bug from the command line 
<seb128> on box startup with no gdm
<\sh> which is normal with all support channels...when the hype comes...
<seb128> that plain inotify bug
<\sh> seb128: hmmmm....
<\sh> ok
<karlheg> Isn't the gnome-panel "System --> Administration" menu only supposed to show up if you are in group 'admin' now?
<ogra> \sh, i stopped esd an hour ago, no disappearing menu so far...it never persiste this long yet
<\sh> ogra: u have load on your box? 
<ogra> persisted even
<seb128> karlheg: the code for it is here but the .desktop have not been updated
<Lathiat> what bug are we chasing?
<\sh> seb128: I just /etc/init.d/gdm stopped it
* Lathiat has notification stuff in panel, nautilus, etc die all the time
<\sh> Lathiat: http://bugzilla.ubuntu.com/show_bug.cgi?id=14967
<seb128> I mved this file away and reboot the box
<ogra> \sh, just normal stuff going on, but it disappears after some minutes normally
<seb128> so command line boot
<Lathiat> ah that one
<seb128> I had a load of 7 when it happened, maybe it need to be pushed a bit over 
<\sh> ogra: well...I checked my system the last times quite good..and the load was always near 1 or above
<\sh> ogra: and when I did the test without esd I produced load up to 3 
<seb128> one updatedb and one pbuilder is a good way to push it :)
<\sh> seb128: pbuilder qt two times ;) 
<seb128> maybe that's not the load but the IOs
<ogra> \sh, i never needed to produce any load to make it disappear
<karlheg> seb128, Ah.  Can I help?
<Lathiat> 4 times for extra effect
<Lathiat> having 4 pbuilders on the go usually eats mjy machine
<seb128> karlheg: not really, the changes were just a bit on the limit with the freeze so they got delayed
<\sh> ogra: no...if you have something running which produces cpu/io load this could be the bug...but I'm really not sure ... /me is just a "idonknonothing" ,-)
<ogra> \sh, i'm just telleing what i observe... there was never any special load on the box when my menu disappeared
<seb128> \sh was saying that too 2 days ago
<seb128> when I said that ross and me have the issue when the box is loaded
<ogra> i'll produce some load...
<\sh> seb128: add applications is not translated?
<seb128> mvo changed the title to drop /Remove this week
<seb128> so I guess translators have not catch up yet
<seb128> that a .desktop to translate
<\sh> hmm
<seb128> you speak about the panel entry or the app?
<\sh> think my gnome is completly screwed...the gksu box is in english and the rest german...
<\sh> seb128: the panel entry
<sabdfl> seb128: any reason we don't include gnome-splashscreen-manager?
<\sh> and I hve two
<ogra> seb128, agreed, it goes with the load
<sabdfl> oh
<sabdfl> ruby
<ogra> sabdfl, the same why we dont include gnome-art 
<sabdfl> so, with gnome-screensaver, should i remove xscreensaver and xscreensaver-gl?
<seb128> sabdfl: nobody asked to ship it, and yeah ruby ...
<\sh> hmm...
<sabdfl> daniels: +1, fglrx Just Worked for me
<Burgundavia> sabdfl, g-s will simply overide xscreensaver
<sabdfl> will run screensavers all night and see if its solid
<seb128> sabdfl: no, GNOME uses gnome-screensaver first when installed and it uses xscreensaver hacks when they are installed
<sabdfl> ok
<ogra> sabdfl, if you want to use the hacks, leave them in place 
<sabdfl> hacks?
<\sh> update-manager -> updating package lists -> the toaster appeared too late
<ogra> the single screensavers are called hacks
<seb128> sabdfl: the graphics, themes or whatever you call that ... they use "hacks" for them
<mdz> elmo: does dholbach have an @ubuntu.com email now?
<seb128> sabdfl: we should split xscreensaver to make a -data package 
<sabdfl> hmm..system->lock screen stopped working
<ogra> mdz, he has an launchpad account
<sabdfl> seb128: yes, and by default only include the screensavers we turn on
<Lathiat> sabdfl: have to start the daemon (since you didnt logout first)
<sabdfl> have a -extra package for the rest
<mdz> ogra: that is not the same thing
<sabdfl> i have two screensaver items in System -> preferences
<Nafallo> sabdfl: I can confirm that :-).
<seb128> sabdfl: is gnome-screensaver running? It's started with the session, not sure if it starts by itself when you get it from a running session
<sabdfl> ok, will log out
<seb128> sabdfl: yeah, that will be fixed before GNOME 2.12.1
<lifeless> is it expected that closing the laptop lid during boot stops X coming up ?
<ogra> mdz, but the result is quite similar
<mdz> ogra: creating a launchpad account does not result in an ubuntu.com email alias
<ogra> mdz, he has a valid ubuntite launchpad account 
<Lathiat> ogra: i thought you had to be a member to get the email
<ogra> mdz, dh@ubuntu.com should work afaik
<ogra> Lathiat, yes, dholbach is a member
<mdz> Lathiat: you do, and at any rate, it isn't automated
<mdz> at least not fully
<\sh> mdz: what about changing the LP username, is the alias renamed as well? but I think this is more a question for elmo
<ogra> \sh, nope for #launchpad
<mdz> \sh: elmo or #launchpad
<Nafallo> \sh: I think so. slomo did that :-).
* mdz wonders what the most popular misspellings for 'dapper' will be
<Nafallo> \sh: a cron.hourly had to be runned or something :-P
<mdz> we've enjoyed 'warthy' and 'horry' and now 'brezzy'
<ogra> heh
<\sh> You don't have permission to access /~lamont/buildLogs/byDate/today.html on this server.
<\sh> bah
<ogra> \sh, http://people.ubuntu.com/~ogra/buildlogs/
<mjg59> Ah, shit.
<mjg59> Can't add hibernate support without adding a string.
<bddebian> mdz: ??
<bddebian> Ohh, missed the misspelling statement
<Burgundavia> mjg59, where?
<bddebian> Drapper, Diaper, ...
<\sh> ogra: just hit the cron job ;)
<ogra> i think "daper" has already some popularity
<Burgundavia> mjg59, it is likely the doc team has not even documented where you adding a string
<ogra> \sh, heh, yes, now my script has it too :)
<mjg59> Burgundavia: Keyboard shortcuts interface
<Burgundavia> mjg59, just a sec, I don't think we talk about it
<Nafallo> hehe, string freeze exceptions on the way :-P
<\sh> last cigarette for this night
<ogra> good idea (even it wont be the last tonight) :)
<Nafallo> \sh: s/night/life/ and I would've been happy for you ;-)
<Burgundavia> mjg59, go ahead, we don't have docs that mention the keyboard stuff
* Nafallo haven't even tested that stuff :-)
<Burgundavia> mjg59, and the upstream gnome ones are hopelessly out of date anyway
<\sh> Nafallo: no ways ;) actually not for this year  ;)
<\sh> hmm..libxine1 has unmet dep
<Nafallo> \sh: see, I won't be happy for you :-P
<bddebian> \sh: You're a workaholic ;-)
<Nafallo> bddebian: haven't you figured yet? ;-)
<\sh> bddebian: I'm bored
<Nafallo> \sh: with you onboard we will have the DapperGoals in before it starts :-P
<bddebian> Hehe
<\sh> Nafallo: Hey, sometimes I have a life ;)
<karlheg> \sh I quit smoking ten years ago.  It was the best thing I ever did for myself.
<\sh> and some other work to do ;)
<Nafallo> \sh: like when? ;-)
<\sh> karlheg: well...I just tried it 2 years ago...with some nicotine spray from ZA ;)
<\sh> karlheg: Name is "Quit" 
<\sh> karlheg: I just stopped for 6 months...after that the spray was empty ;)
<ogra> sladen, "xscreensaver can be put into 'suspend' mode" ??
<\sh> mdz / Kamion: am I allowed to upload xine-lib to fix libmodplug0 unmet dep?
<mdz> \sh: just a rebuild?
<bddebian> \sh: So what have you left for me? :-)
<\sh> mdz: yepp...testing now
<\sh> bddebian: many things ;)
<\sh> libmodplug0 is now libmodplug0c2 so it has to pull in the new dep
<karlheg> \sh Just Do It.  Crumble the pack and make a basket.
<bddebian> Hmm, reminds me, I need a cig. ;-)
<karlheg> \sh Every time the "little voice" or "little urge" nags you to smoke one, tell it to go to hell.
<karlheg> \sh Take a few deep breaths of air instead.
<karlheg> bddebian, Poison!
<sabdfl> hey guys
<Nafallo> \sh: my libxine1c2 wants libmodplug0c2 already
<Nafallo> sabdfl: yes? :-)
<ogra> sabdfl, everything fine ? 
<\sh> Nafallo: you're right....what is with my cache files
<Nafallo> \sh: my girlfriend upgraded lately, so I was a bit puzzled :-).
<\sh> Nafallo: no...I shows me ubuntu3.1
<\sh> strange
<Nafallo> sounds like -security...
<\sh> no..I don't have these sources in my sources.list
<Nafallo> \sh: you are looking at libxine1c2, right?
<Nafallo> well, .X use to be security anyway :-)
<\sh> Nafallo: moment..let me renew everything...all my cache files..this is quite strange
<\sh> hmm...gone
<\sh> I think I have to do a complete new setup of breezy tomorrow
<\sh> mdz: forget the requet
<\sh> +s
<bddebian> Heya sabdfl 
<mdz> seb128,dholbach: all my icons are broken after my most recent upgrade
<mdz>  onoly a few package schanged, incuding rsvg
<sabdfl> hiya bddebian
<bddebian> ubuntu3.1? wtf is that?
<Lathiat> workgroup edition
<ogra> bddebian, security update
<bddebian> Ohh
<bddebian> Lathiat: *lol*
<\sh> Nafallo: what does LC_ALL=C apt-cache -i unmet give you as the first hit?
<seb128> mdz: nautilus? panel? both? what theme do you use? 
<bddebian> \sh: OK hero, tell me what I should work on next ;-)
<seb128> mdz: I've not updated librsvg2 yet, dholbach worked on the update ... lemme try here
<cave> I can confirm the same png problem in the panels.
<\sh> bddebian: FIXME ,-) there are a lot of packages with your name ;)
* bddebian changes the name to StephanHermann
<bddebian> Done! ;-)
<mdz> seb128: it was uploaded
<seb128> cave: which one?
<mjg59> seb128: http://www.codon.org.uk/~mjg59/tmp/hibernate_key.diff
<\sh> strange
<mdz> seb128: most menu icons, all panel icons, some nautilus icons
<mdz> seb128: all the svg ones maybe?
<Nafallo> \sh: Package php4-sqlite version 1.0.2-7build1 has an unmet dep:
<Nafallo>  Depends: phpapi-20020918 | zendapi-20020429
<seb128> mdz: what theme do you use?
<cave> The same as matt had i think. got some info on that on ubuntu.se
<cave> had/have
<sabdfl> seb128: .png icons are broken for me
<mdz> seb128: human
<mdz> seb128: with the human icon theme
<seb128> k, so .png is broken for everybody
<cave> human here also.
<\sh> Nafallo: which should be corrected
* seb128 kicks dholbach
<seb128> he said he would break the panel one day, not the icons 
* seb128 updates
<ogra> hmm, the changelog doesnt reflect that...
<mdz> ogra: what would be involved in porting your ltsp xscreensaver patch to gnome-screensaver?
<bddebian> WTH where you peole thinking scheduling UBZ over Halloween? :-(
<\sh> Nafallo: since wednesday
<ogra> mdz, i think gnome-screensaver already has an blank only option, let me look...
<Burgundavia> ogra, yes it does
<Nafallo> \sh: well... I update from archive.ubuntu.com through apt-proxy every halfhour. :-)
<ajmitch> bddebian: some of us don't do anything for halloween :)
<Burgundavia> ogra, should g-s be tunring the lcd backlight off?
<Nafallo> \sh: did it build on amd64?
<bddebian> ajmitch: Sacriledge :-)
<\sh> Nafallo: http://people.ubuntu.com/~lamont/buildLogs/p/php4-sqlite/1.0.2-7build1/
<ajmitch> \sh: looked like it must have FTBFS
<ogra> Burgundavia, no idea, i didnt work much with gnome-screensaver yet... i only inspected it once
<ajmitch> \sh: why build1?
<seb128> mdz: k, I get the issue too
<\sh> ajmitch: because of  ./configure --with-php-config=/usr/bin/php-config
<mdz> seb128: I think it's rsvg
<\sh> ajmitch: I checked on my local pbuilder...it pulls in the correct phpapiver...at least here
<Nafallo> \sh: hmm, 1.0.2-7build1 is the version I have though.
<mdz> the only things changed were:
<ogra> Burgundavia, from where do you know that g-s has a --blank-only function ? it hasnt even a manpage... not to talk about broken --help
<mdz>   acpi-support acpid alsa-utils libgksu1.2-0 libnewt0.51 librsvg2-2
<mdz>   librsvg2-common python-newt readahead readahead-list whiptail
<sabdfl> seb128: gnome-screensaver rocks
<\sh> ajmitch: it's different from the others
<seb128> sabdfl: cool :)
<Burgundavia> ogra, I run it. You can select blank only
<sabdfl> pls discuss going ahead with this with mdz
<sabdfl> id like to change the dialog though
<ogra> Burgundavia, thats not what i'm looking for
<sabdfl> get rid of the "Welcome to $host"
<Burgundavia> ogra, hmm
<seb128> mdz: sure that's librsvg2-2, I've just apt-get install to update that and I get the issue
<sabdfl> and shrink it vertically
<mdz> seb128: can we back it out?
<seb128> sabdfl: k
<sabdfl> moving the padlock down till its aligned next to the text/login
<seb128> mdz: let's figure what is broken
<sabdfl> mpt: ack?
<ajmitch> \sh: ok, but it still has the old version in the binary produced
<mdz> I wonder why it didn't break for dholbach when he tested it before uploading
<mjg59> Ok. Is the plan to go with gnome-screensaver?
<seb128> mdz: maybe he didn't restarted anything or maybe he uses an another theme
<Nafallo> mjg59: sounds like it :-)
<ogra> mjg59, sounds like 
<mjg59> Right. I'll sort out acpi-support support later on.
<\sh> ajmitch: php4-kadm5 
<mdz> mjg59: leaning in that direction
<mjg59> How often does stuff hit the archive?
<mdz> mjg59: assuming there are no problems carrynig over our customizations
<mdz> mjg59: 30 minutes
<mjg59> Ok
<\sh> ajmitch: this one I changed to phpapiver=$(shell php-config --phpapi)
<mjg59> It would be nice if some hacks from xscreensaver could be brought across
<mjg59> Ideally not the utterly insane ones
<mjg59> (And not that bloody Matrix one that results in faces peering out of my screen at me)
<Nafallo> mjg59: they are, if you got xscreensaver installed.
<ogra> mjg59, all we shipped before :)
<ogra> Nafallo, thats unclen, we need to spilt them out
<mjg59> Nafallo: Having gnome-screensaver depend on xscreensaver would be... less than optimal
<ogra> mjg59, xscreensaver-data with the hacks we had enabled by default before should be right
<mjg59> ogra: Yeah
<mjg59> ogra: Though the Matrix one only became freaky and irritating post-Hoary, IIRC
<ajmitch> \sh: php4-kadm5 had the phpapi depend hardcoded in debian/control
<ogra> mdz, i have a /apps/gnome-screensaver/mode gconf key, that can be set to blank-only :)
<mjg59> Argh why do people have hibernation issues that I can't reproduce on *identical hardware*?
<Burgundavia> mjg59, ask them to reinstall and the first thing they do is hibernate
<mjg59> seb128: Did you grab that patch?
<cogumbreiro> seb128: i've fixed all the bugs on serpentine! :) i'm happy
<seb128> mjg59: nop, could you copy the URL again?
<seb128> cogumbreiro: cool
<mjg59> seb128: http://www.codon.org.uk/~mjg59/tmp/hibernate_key.diff
<seb128> thanks
<sabdfl> cogumbreiro: good work
<cogumbreiro> thx sabdfl :)
<cogumbreiro> Daniel Holbach talked with me about the bugs remaining on serpentine, does that mean that if I do a release (in a few minutes) it will make it in breezy?
<ogra> cogumbreiro, you should apply for membership ;) thats a major contribution
<cogumbreiro> membership? ubuntu membership?
<ogra> sure
<cogumbreiro> cool! :)
<tseng> iirc upstream maintainership != membership
<tseng> not to be a downer
<tseng> just the precedent
<ogra> tseng, iirc apply for != youre accepted already
<cogumbreiro> i would also like to create some events envolving linux in my university, don't know if it would be a plus on the membership
<cogumbreiro> (*membership proposal)
<ogra> cogumbreiro, vreate a wikipage about you that outlines who you are and what you have done for ubuntu...
<ogra> create even
<cogumbreiro> ogra: will do
<ogra> cogumbreiro, and add yourself here https://launchpad.net/people/ubuntumembers/+join and here https://wiki.ubuntu.com/CommunityCouncilAgenda and come to the next CommunityCouncil meeting :)
<cogumbreiro> cool :) thx alot ogra
<ogra> ;)
<ogra> cogumbreiro, would be nice to have you aboard :)
<ajmitch> ogra: why haven't you recruited him for MOTU as well? ;)
<bddebian> Yeah
<ogra> ajmitch, step by step ;)
* bddebian still doesn't know why he got "recruited" :-)
<cogumbreiro> lol
<tseng> because you wouldnt leave
<tseng> :P
<bddebian> tseng: Ohh, ouch.  That was a good one. :-)
<Nafallo> haha
* ogra would love to see a ubuntu conference with tseng and bddebian sharing a room... *g*
<tseng> hah
* Burgundavia would rather not
<tseng> it would be fun.
<ogra> thats what i imagine :)
<cogumbreiro> lol
<tseng> maybe for dapper+1
<tseng> we'll both be there
<ajmitch> bddebian: I'm surprised you haven't gone to visit tseng yet :)
<tseng> oh thats right
<ajmitch> both in PA?
<tseng> yeah
<Nafallo> :-)
<bddebian> You are in PA?
* tseng demotes the converstation to universe
* bddebian forgot that
<tseng> (sorry).
* ogra lols about tseng
<Nafallo> hehe
<bddebian> ogra: Why, I have no problems with tseng  :-)
<ogra> *grin* tseng anastacia hale
<ajmitch> bbl, lunchtime
<Nafallo> wow! those bittorrentclients posted to the mailing-list seems stunning by the screenshoots
<Nafallo> something tells me we will switch client for dapper :-P
<ogra> Nafallo, you mean avalanche ? 
<Nafallo> ogra: well, I still consider freeloader to. let's make this a fair competition ;-).
<cogumbreiro> Nafallo: my opinion would be to fix the problems of gnome-bittorrent
<Nafallo> cogumbreiro: well, I haven't tried those two yet. I always found gnome-bittorrent not filling my demands on a good client though.
<ogra> Nafallo, thats a competition that began before hoary.... 
<Nafallo> ogra: well, those two should be in universe early in the next cycle ;-)
* Nafallo downloads :-)
<ogra> Nafallo, absolutely
<ogra> Nafallo, if the transitions and fixing finishes early, we could look into getting them even in breezy...
<cogumbreiro> haven't seen freeloader
<Nafallo> ogra: indeed
<\sh> ogra: early?
<ogra> \sh, i mean not arly in the morning ..
<ogra> early even
<\sh> ogra: u saw the "FIXME" list of bddebian?
<ogra> \sh, thast bddebian's list... thats special ;)
<\sh> ogra: bah
<ogra> *g*
<Nafallo> both seems to be rather dead upstream looking at the release dates of their latest versions
<\sh> ogra: and the rest of apt-get.org ;9
<ogra> yup
<seb128> mdz: I've an idea on the SVG issue
<bddebian> \sh: Nah, I changed them all to StephenHermann ;-P
<seb128> cogumbreiro: around?
<\sh> bddebian: good..it's not me ;)
<mdz> seb128: what is it?
<seb128> mdz: a min, trying my change
<mpt> sabdfl: So you want a bit of love to gnome-screensaver's dialog? sure
<seb128> mdz: gdk-pixbuf-query-loaders
<tseng> daniels: oh so i have my photos back
<seb128> mdz: basically previous definition is 
<seb128> ""<?xml" "" 50
<seb128> "<svg" "" 100
<seb128> "<!DOCTYPE svg" "" 100"
<seb128> mdz: the new version drop the <?xml option
<mjg59> Ah.
<cogumbreiro> seb128: yes
<seb128> mdz: and /usr/share/icons/Human/scalable/apps/mozilla-firefox.svg by example start with <?xml
* mjg59 finally manages to hang swsusp
<cogumbreiro> seb128: trying to make the Muine plugin compilation an option in configure...
<seb128> cogumbreiro: does serpentine manage translations now?
<cogumbreiro> seb128: yes, and already has a PT translation
<seb128> cogumbreiro: we want the new version! :)
<cogumbreiro> seb128: ehehe cool :D
<ogra> yay
<mjg59> jbailey: Ping?
<cogumbreiro> seb128: just let me tame configure.ac :P
<cogumbreiro> when and where is the next ubuntu reunion?
<seb128> cogumbreiro: /j #ubuntu-meeting and read the topic :)
<cogumbreiro> cool :)
<mjg59> jbailey: Would it be possible to have a two-pass hotplug run on boot - once for internal storage devices, followed by a resume attempt, followed by the rest of the boot?
<\sh> cogumbreiro: wiki.ubuntu.com/Calendar 
<mjg59> jbailey: In fact, it looks like that would be quite easy
<cogumbreiro> \sh: thx :)
<ogra> cogumbreiro, if you want to go further and become a package maintainer, you should start hanging around in #ubuntu-motu ;)
<cogumbreiro> lol, so many channels :)
<ogra> yes, ubuntu has grown a lot ...
<seb128> mdz: patched librsvg uploaded
<mdz> seb128: fantastic, thanks
<seb128> mdz: np
<seb128> mdz: the issue is quite Ubuntu theme specific :)
<mdz> seb128: we should test these changes with Ubuntu themes ;-)
<ogra> seb128, huh ? arent other themes not using svg artwork ?
<seb128> mdz: they dropped the <?xml case but usually icon match <svg ....excepted than Ubuntu icon (ie: /usr/share/icons/Human/scalable/apps/mozilla-firefox.svg) have some lines on comment before it which breaks the detection
<mdz> why did they make that change?  it doesn't sound like a bug fix
<seb128> s/icon/icons/
<daniels> sabdfl: excellent
<seb128> mdz: "make so that non-svg things don't get passed to us" according to the changelog
<daniels> Treenaks: ... what of it?
<daniels> Treenaks: oh, that.  yeah, the l-r-m changelog is a little midleading.
<daniels> misleading, also.
<daniels> tseng: cool
<seb128> mdz: <?xml is generic xml, svg icons have to use <svg anyway, so they don't catch wrong files
<seb128> mdz: maybe we should change the 100 chars for "<svg'" 200 rather than using "<?xml". I'll discuss that with them tomorrow, but the patch fixes the issue for the moment
<ogra> seb128, i doubt the people designing themes for gnome-look.org care for the header their svg app throws out... i know lots of svg pics that have the xml header
<seb128> ogra: they have <svg too
<ogra> seb128, yes...
<seb128> ogra: better to match on <svg than <?xml, so you don't get non-svg listed as svg
<ogra> hmm, true
<tseng> oh
<tseng> installing procmail would help if you forward all your mail to it
<tseng> and wonder where its going
<ogra> heh
<ogra> tseng, oh, btw, did you sort out the n-m upload with elmo ?
<tseng> ogra: no ive not seen him
<tseng> both of us working alot during the day, i guess
<tseng> Nafallo: any chance you could try to sort it?
<tseng> Nafallo: since you touched it last :P
<ogra> hmm, ok, i'll care for it then, i'll try not to forget to ask him if i meet him next time..
<tseng> ok
<tseng> thanks
<Nafallo> tseng: sure :-). I'll find him ASAP
<Nafallo> or ogra, whichever :-)
<\sh> hmm..MOTUs never sleep ,-)
<bddebian> Damn tootin' ;-)
<Nafallo> \sh: I tried to :-P
* ogra looks up sleep
<Nafallo> \sh: now I'm making a NEW package ;-)
<tseng> `wtf sleep`
<Nafallo> hehe
<\sh> Nafallo: I just saw that knoda isn't building cleanly so I fix this now 
<Nafallo> btw, postgis should be multiverse. I've mailed elmo about that :-).
<Nafallo> libpgjava resides there, and is a build-dep.
<\sh> going /quit
<ogra> \sh, wow, short night for you ?
<\sh> hehe...crappy dsl
<Nafallo> hehe
<bddebian> hehe
<seb128> time to sleep here, 'night
<ogra> night seb128 
<\sh> seb128: long ago ;)
<Nafallo> gnight seb128 
<\sh> seb128: g'night...going as well..
<cogumbreiro> good night seb128 :)
<ogra> night \sh 
<ajmitch> \sh: some of us have to sleep
<Nafallo> gnight \sh :-)
<bddebian> Gnight \sh, rockin' as always :-)
<cogumbreiro> man serpentine is not make dist'ing :(
<\sh> ajmitch: u slept already ;)
<ajmitch> \sh: yes
<\sh> ajmitch: btw..all php4 stuff is ok now...
<ajmitch> \sh: I can't work 23 & 1/2 hours a day on MOTU stuff like you :P
<ajmitch> good
<\sh> ajmitch: what should I do with my free time?;)
<jbailey> mjg59: Yes, easy enough.  I can do it for this upload, I think.
<ajmitch> \sh: fix the universe
<jbailey> mjg59: So we're clear that means that hiberation can only be resumed from local storage, not usb, firewire or nbd, then.
<\sh> ajmitch: I will find the answer to 42...someday
<ogra> \sh, 42 *is* the answer
<\sh> ogra: the question of course ... u see I'm tired
<ogra> :)
<ogra> yes, i know what you mean...
<ajmitch> :)
<mjg59> jbailey: For now, yeah
<mjg59> jbailey: I have a patch, if you'd like it?
<\sh> hmmm
<\sh> ok..that's for knoda...uploading and sleeping g'night gentlemen
<ajmitch> night \sh 
<\sh> *yawn* and gone
<mjg59> jbailey: http://www.codon.org.uk/~mjg59/tmp/initramfs.diff
<jbailey> mjg59: Sweet, thanks.
<mjg59> jbailey: Probably wants the resume code to be a bit nicer, but still
<jbailey> mjg59: Hmm.  Where did you delete the old resume code from?
<mjg59> I didn't
<mjg59> I thought I'd leave that up to you :)
<jbailey> Okay. =)
<jbailey> It's just one file to delete I guess.
<mjg59> Yeah
<jbailey> This still leaves me with the ugly problem that I can't tell if the USB bus scan is finished.
<mjg59> Yeah, though it's no worse than before...
<jbailey> I wonder if I should have some way that if the device isn't available to sleep 2, redo the udevstart and try again?
<mjg59> One thing that has suddenly struct me, though
<wasabi_> struct. haha
<mjg59> If you load uhci-hcd first, then devices may end up bound to that
<mjg59> When you actually want them to be bound to ehci-hcd
<mjg59> I shouldn't IRC while I've got code in another window
<jbailey> Do I intentioanlly load them at all?  I thought I had all of that as autodetection based on PCI Id.
* jbailey looks
<jbailey> (I have about 2 mins before my wife hauls me off for dinner)
<mjg59> jbailey: Yeah. But you might hit uhci-hcd first
<mjg59> I'm not sure what happens in that case
<jbailey> Do they coexist in the system, or serve the same devices?
<mjg59> They coexist
<jbailey> Joy.
<jbailey> Umm.
<jbailey> So should I look for that and queue it?
<mjg59> Possibly. Is the modprobe you have there sufficiently good to deal with a modprobe.d?
<mjg59> If so, just add something that pre-loads ehci-hcd on uhci-hcd loads
<jbailey> Is ehci always present in uhci systems, or is that just cruft lying about in memory then?
<mjg59> ehci is only present in USB 2 systems
<jbailey> It's the regular system modprobe.  The one in busybox doesn't work on all of our archs.
<jbailey> Will it just fail to load then?
<mjg59> It may appear with either uhci-hcd or ehci-hcd
<jbailey> Mm, no.
<mjg59> Nah, it'll probably load and hang around
<jbailey> It'll be just useless.
<mjg59> Check the use count afterwards and unload it if it's 0?
<jbailey> But I guess better than having all your USB2 devices pretending their 1.1
<mjg59> Hm. No, that doesn't actually work
<mjg59> jbailey: It's fine for devices that are plugged in after boot, but there's a small race there on boot
<mjg59> It's actually biting me on resume at the moment - uhci-hcd tends to get loaded first, so devices end up wrongly bound
<jbailey> Oh, hmm.
<jbailey> Lemme chew on this, Angie's calling me.
<jbailey> I'll try to have a solution for tomorrow for you.
<mjg59> Ok - see you
<mjg59> Rock
<bur[n] er> anyone familiar with what would be prompting me for evolution usernames and passwords when I right click the gnome-panel and click properties??
<tseng> daniels: so dude
<bur[n] er> doh... thought I was in #ubuntu :\ sorry ;)
<tseng> daniels: according to http://www.gnome.org/~lcolitti/gnome-startup/analysis/
<tseng> daniels: having a font server configured but not available causes an extra 5 seconds in X start time
<tseng> daniels: due to paging the server over and over
<daniels> eheh, nice
<tseng> any reason to have it in the default config?
<daniels> xorg (6.8.2-66) breezy; urgency=low
<daniels>   * Disable font server in dexconf for mad startup time victory.
<daniels>  -- Daniel Stone <daniel.stone@ubuntu.com>  Fri, 16 Sep 2005 11:25:05 +1000
<tseng> oh
<tseng> you are elite
<tseng> and a day ahead of me
<tseng> in more ways than one
<bob2> TOO SLOW, tseng 
<ajmitch> bob2: like you can talk :)
* tseng grumbles in .au's general direction
<bob2> ajmitch: you guys only have an hour on us
<ajmitch> 2
<jdub> daniels: http://lists.slug.org.au/archives/slug/2005/09/msg00208.html
<daniels> jdub: he's using the binary driver
<daniels> jdub: so watch how little I care
<jdub> not sure that's the most useful response
<jdub> is the hoary binary driver known to not work very well on amd64?
<daniels> it's known to have rendering issues, yes
<daniels> so is the one from brezy, actually
<daniels> and the one from warty did too
<jdub> on amd64 specifically?
<daniels> on all architectures
<daniels> it's more a varies-by-card than varies-by-arch thing
<jdub> so if i suggest that he try nv, that will work more reliably?
<daniels> jdub: probably, but not guaranteed
<daniels> jdub: some cards just have weird-shit flaws that need to be specifically worked around
<lamont> elmo: postgis is being annoying
<elmo> lamont: ?
<lamont> repetitive give-back
* lamont actually looks at the log
<lamont> E: Couldn't find package libpgjava
<lamont> let me guess: libpgjava is multiverse?
<elmo> yes
<elmo> why has this suddenly come up
<lamont> because I finally looked at p.u.c/~lamont/byDate/today.html
<elmo> and why's it in main in sid
<elmo> libpgjava's in main in sid, I'm going to promote it to universe
<lamont> elmo: danke
<elmo> lamont: can you have a look at where dict-gcide went?
<elmo> sigh, we have uninstallables again
<wasabi_> *sigh* evms stil nicely crashes.
<wasabi_> and lvm is still weirded out
* jdub is just evms-ing his new disk
<wasabi_> Watch out.
<wasabi_> If I use EVMS to add a new pv to a LVM...
<wasabi_> it seg faults.
<wasabi_> and leaves teh vg in a inconsistant state.
<wasabi_> Now I'm stuck with 500GBs of broken data, again.
<jsgotangco> j #ubuntu-motu
<jsgotangco> morning guys
<ajmitch> hi
<Burgundavia> jdub, any chance I can get my hands on one of the MS OEM packs? I am interested in helping build something similar for Ubuntu
<Burgundavia> jdub, nev mind, jsgotangco has got one
<jsgotangco> i actually got inquiries during LWC about it
<gabaug> is there a tutorial on how to take an existing ubuntu pkg and upgrade it (for one's own purpose) to a newer version of the software it's packaging?
<Burgundavia> gabaug, best to ask taht in #ubuntu-motuy
<Burgundavia> gabaug, best to ask taht in #ubuntu-motu
<bob2> hint: uupdate and careful testing
<lamont> elmo: old .upload file... most strange
<lamont> dict-gcide inbound
<elmo> grr
<mdz> jbailey: does initramfs-tools call depmod after each module it adds?
<mdz> no wonder it takes ages
<jdub> eek!
<jdub> mdz: you using evms at home?
<mdz> jdub: yes
<jdub> mdz: for a basic raid1 root system, would you recommend segments for /boot, / (md region) and swap?
<jdub> the evms faq is all about "this answer coming soon!"
* lamont ponders the best way to get a 2.4 kernel booted on a machine with PCMCIA support, from the collection of hardware that he has available.
<mdz> jdub: straight segments, as opposed to volumes?
<mdz> I make everything volumes, myself
<jbailey> mdz: Eh?  No, it should do it once at the beginning of load_modules.
<mdz> jbailey: it also does it in every manual_add_modules
<jdub> mdz: hrm, so i don't need to make a /boot segment to boot from?
<mdz> I am upgrading my router to breezy (i486) and was watching depmod run again and again in top
<jdub> or does that just not matter given our initramfs?
<mdz> jdub: as long as grub can load the initramfs, everything from there should be cake
<mdz> so grub needs to understand /boot
<mdz> beyond that, go nuts
<jdub> mmm, so this is why i am thinking that i need a boring /boot partition :-)
<jbailey> Oh hmm.
<jbailey> And nothing appears to use the result of that depmod either...
<mdz> jdub: surely grub can grok raid1
<jdub> hmm, but i can make swap a volume
<mdz> and root
<jbailey> mdz: I'll try removing that depmod for my tests tomorrow morning.  That would be a lovely svings. =)
<jdub> grub still doesn't do raid1
* Lathiat boots off raid1 with grub
<Lathiat> or is it lilo *thinks*
<Lathiat> no reason it shouldnt do raid1 ?
<jbailey> lilo definetly does.
<Lathiat> its not like its hard
<jdub> lilo does, with grub you have to fake it (ie. you're not booting from raid1, you're booting from one of the mirrors)
<jbailey> I think it's just an extra MD header, so it ought to be fine on /boot raid1.
<jbailey> grub-install I don't think will automatically install itself on two drives.
<mdz> jdub: that's better than having a non-redundant /boot
<jdub> yes
<mdz> you can install grub twice, once to each disk, each pointing to the corresponding /boot
<daniels> fabbione: also, I guess that fglrx-control and xorg-driver-fglrx now conflict, unless you checked and fixed that one.
* lamont wanders off
<jdub> argh!
<jdub> segfault :-)
<mdz> jbailey: why does initramfs-tools depend on lvm2 and mdadm, rather than just using them if present?
<jdub> hrm, seems to be surviving better when i save as i go
<jdub> daniels: !!! (re xfs in fontpaths)
<daniels> jdub: good or bad?
<jdub> good
<daniels> yes
<daniels> although we still have a big hardware delay
<daniels> i know this because my config only had one font path in it, which was local
<daniels> and there was only one actual font installed in that path
<jdub> heh, fixed?
<daniels> fixed, with cursor aliased to same
<daniels> i'd kill for proper modesetting on i8xx
<daniels> but alas, it is not to be
<cogumbreiro> hmmm, guys I've just released a new serpentine version. I want to mark the bugs in ubuntu, do I leave them open and add a comment, mark them with UPSTREAM or mark them with PENDINGUPLOAD?
<daniels> just comment on the bugs that they're fixed in the new upstream version, don't touch the status
<cogumbreiro> daniels: kk
<fabbione> morning
<fabbione> daniels: sorry i have only one "also, I guess that fglrx-control and xorg-driver-fglrx now conflict, unless you checked and fixed that one."
<fabbione> i don't have anything else in the backlog
<daniels> fabbione: that was it
<fabbione> daniels: no i didn't check.. why should they conflict?
<daniels> at a guess, fireglcontrol being in both
<fabbione> daniels: hmmm crap ok
<fabbione> xorg-driver-fglrx:
<fabbione>   Depends: lib32gcc1 (>=1:4.0.1) but 4.0.1-4ubuntu6 will be installed
<fabbione> MEEEE
<daniels> just have a look with dpkg-deb
<fabbione> daniels: yeah i am looking at it
<fabbione> that's on amd64 
<fabbione> i think we just hitted that shlib thing Mithrandir was mentioning
<jdub> jbailey: still about?
<jdub> jbailey: n/m
<fabbione> daniels: do we still need to ship fglrx-control at all?
<daniels> fabbione: yes
<fabbione> why?
<fabbione> the 2 binaries land even in different directory
<fabbione> and one is called fireglcontrol and the other fireglcontrolpanle
<fabbione> there is no overlap that i can see
<daniels> okay
<fabbione> daniels: should i also do the /usr/X11R6/bin -> /usr/bin transition for fglrx-control?
<fabbione> or are you happy as it is?
<daniels> should be transitioned, yes
<fabbione> ok
<fabbione> daniels: how would you feel if we update the nvidia driver to 7676 ?
<fabbione> daniels: did you hear any horror story about it?
<daniels> i haven't heard anything good or bad, but 7667 seems to be pretty stable, so I didn't bother making the update myself
<daniels> only reason I updated to 8.16 was because .14 was totally stuffed on laptops, DVI, and newer chips
<fabbione> make sense
<cogumbreiro> gnight all
<fabbione> daniels: #15533 is either gcc-4.0 or dhshlibs faults
<fabbione> because all libgcc* is epoched.. lib32gcc1 isn't
<fabbione> hey mdz
<mdz> hi
<mdz> just finished upgrading my router to breezy
<fabbione> mdz: i just ordered the new pieces for my workstation. I will be back 200% during this week.. hopefully...
<fabbione> working in this small env is sort of limiting
<mdz> fabbione: what happened to your workstation?
<fabbione> burned
<mdz> by fire?
<fabbione> no, my best guess is that the temperature sensor on the chipset is deteriorated into junk, since the machine randomically shutdown with no predicatble enviroment
<fabbione> and at random times
<fabbione> mdz: the positive side is that i will get an amd64
<fabbione> and hopefully within the next 2 weeks a ppc
<fabbione> so i can cover all 3 arches :)
<mdz> fun
<fabbione> mdz: it took me 3 days of hw testing.. it's not fun.. trust me
<fabbione> specially when you have almost a tera of data connected to it
<bob2> hah
<bob2> you have entirely too much porn
<fabbione> bob2: not really..
<fabbione> i moved all of it on DVD :P
<fabbione> humpf...
<fabbione> GO GCC-4.0! it's your BIRTHDAY
<fabbione> daniels: #15533 -> gcc4.0
<fabbione> for once i was sure i didn't do anything dumb
<doko> morning
<fabbione> doko: fix #15533. kthxbye
<sabdfl> mornign all
<sabdfl> doko: could you fix gcc to say (Ubuntu  4.0.1-4ubuntu6) please? rather than (Debian...)
<doko> which one, gcc-4.0, or all (gcc-4.0, gcc-3.4, gcc-3.3)?
<doko> sabdfl: ^^^
<sabdfl> all of them please
<doko> sabdfl: fixing all of these for breezy will kill fabbione's buildd for a week
<sabdfl> best it be this week, then
<sabdfl> please also fix similar issues in other packages
<sabdfl> no gratuitous branding, or if branding is needed, Ubuntu
<doko> yes, upstream asks for this kind of branding for patched versions
<pitti> Hi
<sabdfl> doko: that's fine - but then it should read Ubntu
<sabdfl> erk
* sabdfl worries you might actually make it say Ubntu ;-)
<sabdfl> Ubuntu
<sabdfl> otherwise, keep it neutral - no distro name
<fabbione> doko: don't worry about sparc...
<fabbione> doko: it will manage..
<fabbione> hey sabdfl 
<sabdfl> mornin fabbione
<fabbione> doko: just do it right away please
<daniels> mdz: permission to upload xresprobe with the patch in debian #328551?
<daniels> mdz: it's correct, and just gave me one of those 'oh, shit' moments
<Kaloz> re
<Kaloz> fabbione: will you have an intaller for breezy? :)
* Kaloz is just getting two netra 105 boxes
<fabbione> Kaloz: i truely hope so
<fabbione> there is a major issue with klibc atm
<fabbione> but the hoary installer and upgrade to breezy should work
<fabbione> module one line in a config file to use initrd instead of initramfs
<Kaloz> i hope finaly i get time to do that nubuntu thing for drake at last
<Kaloz> okay, thanks :)
<fabbione> Kaloz: no problem.
<doko> fabbione, lamon, infinity: please skip gcc-4.0_4.0.1-4ubuntu7, just proceed with gcc-4.0_4.0.1-4ubuntu8
<doko> lamont: ^^^
<jdub> daniels: someone else provided a helpful answer to that question i pointed to earlier - check out the whole thread
<jdub> http://lists.slug.org.au/archives/slug/2005/09/msg00208.html
<fabbione> doko: ok thanks
<daniels> doko: it doesn't matter for our buildds
<fabbione> doko: did you also fix that lib32gcc1 problem?
<sabdfl> fabbione: can we detect that one-liner and make it automatic?
<fabbione> sabdfl: for sparc?
<sabdfl> for everybody
<daniels> jdub: nvagp -> completely the wrong solution
<daniels> sabdfl: if you're talking about the nvidia thing jdub posted, no
<daniels> sabdfl: it sort of works for a random subset of people, breaks horribly for others (including previously working systems)
<fabbione> sabdfl: sorry.. i am lost.. what one liner are you referring to?
<sabdfl> daniels: no, talkin about the issue where hoary systems don't upgrade properly because of a one-liner in some config file, choice wemade ages ago that's biting now
<jdub> daniels: given the mess we're already in, surely "working" is better than "correct", right?
<daniels> sabdfl: oh, okay, sorry
<fabbione> sabdfl: there is no need for other arches. it's a sparc specific problem that i hope to address before release
<daniels> jdub: 'working for one dude who complained on slug and possibly breaking it in indeterminate ways for everyone else who has it working' vs 'correct, supported by upstream, may break for one person on the slug lists'
<jdub> daniels: well, two. plus, it's been grumbled about elsewhere.
<fabbione> sabdfl: basically klibc that lands in the initramfs builds only in 64bit mode but busybox used to execute the stuff is 32bit. the mistmatch makes baby jesus cry
<daniels> jdub: in general, no.  this close to release, absolutely not.  i mean, fabbione's the l-r-m maintainer these days, so you can convince him if you like it, but no way would I ever do that.
<sabdfl> daniels: pot. kettle. black.
<daniels> sabdfl: hey, I'm happy taking risks on things I can evaluate and measure.  this I can't.
<sivang> Morning all!
<Burgundavia> daniels, I see this bug https://bugzilla.ubuntu.com/show_bug.cgi?id=14071 ONLY when not connected to a monitor/projector. Is it the same issue. i915 graphics
<doko> fabbione: -> changes
<daniels> Burgundavia: not with i915, no
<Burgundavia> daniels, should I file a new bug about that?
<fabbione> doko: thanks
<fabbione> so the shlib is the same as before..
<sivang> daniels:discussing specific l-r-m bug?
<fabbione> = i don't need to rebuild the package
<daniels> sivang: yeah
<daniels> Burgundavia: not really, we already have a 'should know how to program modes properly' bug, but short of intel becoming slightly less schitzophrenic, there's not much we can do about it, as that's your video BIOS doing the mode switching for us.
<Burgundavia> daniels, ok
<sivang> daniels: what's the # ?
<daniels> sivang: not on bz
<doko> fabbion: yes
<fabbione> doko: oky
<fabbione> hmmm one of the last security patches did break the kernel on sparc... FUN...
* fabbione sighs
<fabbione> sabdfl: did you test the new fglrx driver?
<fabbione> sabdfl: and how is it going with the new kernel?
<sabdfl> fabbione: perfect
<sabdfl> well, not the new kernel
<sabdfl> i'm still running the one you gave me
<sabdfl> and fglrx justworked perfectly
<fabbione> sabdfl: they have the same fixes...
<fabbione> sabdfl: ok great
<sabdfl> and survived a long night of gl screensavers
<sabdfl> so far, so great
<fabbione> the kernel i gave to you was the one in our repo
<fabbione> i only builded it for you
<sabdfl> now i'm going to run baz merge all day on it, at the same time as the screensavers
<fabbione> kudos and such should go to ben ;)
<sabdfl> then we will know
<sabdfl> thanks BenC
<fabbione> ok i will close the fglrx bug than..
<fabbione> 3 success reports are enough :)
<tepsipakki> are apu-{server|client} packages available somewhere?
<tepsipakki> apu = auto-pkg-update
<tepsipakki> i'd like to try them
<sivang> fabbione:will this be suported out of the box without manual intervention? or already is? (re:fglrx)
<fabbione> sivang: i am not following you..
<fabbione> what should be supported out of the box?
<sivang> fabbione: sorry, my bad, never mind
<fabbione> uh ok :)
<lifeless> fabbione: are there known issues with hibernate ?
<fabbione> lifeless: mostlikely..
<fabbione> lifeless: just check bugzilla for component linux
<lifeless> ok
* lifeless breakfasts
<fabbione> hey pitti
<pitti> Hi fabbione, just debugging hibernation
<fabbione> pitti: did you notice that the last pmount is FTBFS?
<pitti> fabbione: oops, no? will look at it, thanks
<fabbione> no problem
<fabbione> mdz: can you please make me the owner of lrm & co on bugzilla?
<fabbione> mdz: thanks
<pitti> Kamion: can you do syncs from Debian?
<pitti> mvo: did you see liveless' scary upgrade report? any idea how to mitigate this?
<mvo> pitti: the one that "auto-upgrade" from the cd wanted to remove so many packages?
<ivoks> daniels: ping
<pitti> mvo: yes
<pitti> mvo: that might be because the CD contained a new libc or whatever, and the other installed programs had no new version on the CD?
<fabbione> huuhuh
<fabbione> now..
<pitti> fabbione: BOOOOH!
<mvo> pitti: yes
<pitti> mvo: however, ISTR that I did CD-based upgrades, they always went fine
<fabbione> mdz: i did track down the hplip failure on sparc. that check fails because my chroots are clean.
<mvo> pitti: it can only be solved by adding the needed entries in the sources.list
<fabbione> mdz: the check is wrong anyhow...
<daniels> ivoks: pong-ish
<mvo> pitti: I guess you upgraded a system with little additional packages? i.e. a test-system?
<ivoks> daniels: i wanted to ask you will you include that hr symbols in breezy that i posted on #14667
<daniels> ivoks: if it's just adding the alt variant, then yeah
<ivoks> daniels: yes, nothing else
<daniels> ivoks: 'kay
<ivoks> daniels: thanks
<daniels> np
<jdub> jbailey, mdz: ping (re: evms root and initramfs)
<pitti> mvo: actually I upgraded my laptop (productive system)
<pitti> mvo: well, however, I upgraded it every week or so with the newest CDs
<mvo> pitti: interessting. I don't have a non-test/non-breezy system at hand but 416 libs is really scary. I'll followup asking for details
<Mithrandir> how long are we going to wait for feedback from bug reporters?  Currently, we have bugs which are a few months old with no response which means that it's impossible to triage.
<sabdfl> Mithrandir: close them if they are more than 3 months with no response
<sabdfl> unless they are obviously confirmed and understood
<Mithrandir> sabdfl: ok.   What resolution should be used?
<jdub> INVALID?
<Mithrandir> it might not be invalid, though
<sabdfl> Mithrandir: we should have something specifically for this case, shouldn't we
<Mithrandir> I would think so, yes.
<jdub> mmm, and it might not be NOTABUG
<Mithrandir> jdub: I'm not sure what the difference between invalid and notabug is, really.
<Mithrandir> sabdfl: nosubmitterresponse or something like that.
<Mithrandir> submitterfallenoffplanetearth
<sabdfl> GONESILENT
<sabdfl> hey!
<Mithrandir> ;-)
<ivoks> :)
<Mithrandir> we can change that code once we get our first bug from the ISS.
<fabbione> hey Mithrandir 
<fabbione> lol
<jdub> gnome uses INCOMPLETE for this
<Mithrandir> jdub: incomplete or gonesilent sounds good to me
<ivoks> gnoesilent is much cooler :)
<ivoks> gone, even :)
<doko> Mithrandir: just s/from/to/ :)
<doko> Mithrandir: just s/off/to/ :)
<Mithrandir> doko :-)
<doko> Mithrandir: please look at ubuntu-users (Re: Openoffice fails to start). I thought that was fixed in l-r-m, or this a problem in an older l-r-m as well?
<Mithrandir> doko: you need to give me an URL; u-u is too busy, so I'm not on the list
<doko> http://lists.ubuntu.com/archives/ubuntu-users/2005-September/048942.html, http://lists.ubuntu.com/archives/ubuntu-users/2005-September/049040.html
<Mithrandir> doko: those seems to be two different issues?  The ia32-libs thing is something I don't know what's up with; it might be that daniels or fabio broke it with the last upload
<Mithrandir> doko: I'm doing ooo2-amd64 and ooo-amd64 now, I can look at lrm afterwards
<doko> Mithrandir: ok, just did remember that you did a similiar fix
<Mithrandir> doko: yes, I did, and it might have gotten lost.
<Kamion> pitti: technically yes, but I don't normally (indeed, I never have)
<doko> hmm, what are our suggested minimum hardware requirements for breezy? do we have these documented somewhere?
<pef> hi
<j^> why are removable ide media in group plugdev but /dev/raw1394(used to capture DV, but can also be used to access firewire disks) in group disk?
<pitti> j^: because nobody complained about this so far
<pitti> j^: however, firewire disks should have a separate /dev/sd* node
<j^> pitti i did and was told its a security risk
<j^> now usb disk are a security risk too
<pitti> hm?
<j^> pitti i need raw1394 for my DV camcorder
<j^> and i do not like running kino as root
<j^> right now the default user can not use kino
<j^> one has to add it to disk or change permissions of raw1394
<pitti> j^: please never add an user to disk
<j^> pitti please change the raw1394 to plugdev 
<pitti> j^: instead, in /etc/udev/permissions.rules, change KERNEL=="raw1394",      GROUP="disk"   to plugdev
<pitti> j^: however, I'm still confused why you want the raw device
<pitti> j^: why not use /dev/video1394 /dev/dv1394?
<j^> pitti because raw1394 is the most stable and current way to use DV
<pitti> j^: and video and dv are not working?
<j^> gstreamer, kino and dvgrab all use raw1394
<pitti> j^: what are the current permissions of raw1394, are they ok? i. e. readable and writable for group?
<j^> kino also has legacy support for /dev/video1394
<j^> pitti right now /dev/raw1394 is crw-rw----
<j^> root disk
<pitti> j^: ok, that's fine
<j^> but since raw1394 is used to access iso dv streams on the ieee1394 bus one needs read/write access
<j^> pitti group disk is not fine
<pitti> j^: hm, why is video1394 "legacy"?
<pitti> j^: I mean the permissions are fine, not the group
<j^> pitti yeah permissions are ok
<j^> let me check if i can fine the statement on linux1394.org...
<j^> pitti anyway gstreamer only supports raw1394 afaik
<pitti> grumpf
<pitti> that's dumb - the purpose of video1394 is to use it...
<seb128> where is dholbach?
<j^> pitti if linux1394.org would be up i could point you to the statement that its should not be used
<pitti> j^: ok, please file a bug for now; if you have some documenting URLs, they should be added to the bug
<pitti> j^: but right, we shuold get this working
<pitti> j^: the only problem is that this would allow any plugdev user to circumvent device permissions on storage devices, that's why I don't like it
<seb128> I hate printing
<seb128> that never works
<Lathiat> daniels: mad startup time victory?
<j^> pitti but it was just changed that this is possible for plugable ide devices
<daniels> Lathiat: ~5sec
<Lathiat> daniels: wow
<pitti> j^: nope, plugdev users can only read the raw device, not write it
<j^> pitti which would be a start for raw1394 too
<pitti> j^: so read-only access would be enough?
<pitti> somehow I doubt that, you need to send commands etc.
<mvo> is it known that openoffice1 on amd64 does not run (without changing ~/.sversionrc)?
<j^> pitti never tried, but since you can controll the camcorder you send commands i guess
<hunger> fabbione: Are you sure the /dev/input/mice issue is udev-related?
<hunger> fabbione: I see it almost always when using the ubuntu 2.6.12 kernel and never when using a custom 2.6.13.
<hunger> j^: NM is not that bad on a one-user laptop:-)
<seb128> k, who broke cups
* seb128 looks at pitti
<j^> hunger you have a two-user laptop? do you have a pic of two users using one latop at a time?
* pitti hides
<pitti> seb128: what breaks exactly?
<fabbione> hunger: i am pretty sure...
<hunger> j^: Well, a laptop that is only ever used by one admin-kind of person (aka. me;-)
<mdke> Kamion, is there any more information you need on #15513, I'm going to try to partition manually today
<fabbione> because i workaround it here modprobing the mouse before hotplug
* j^ hoped for a laptop with two keyboards
<bob2> is NM going to be fixed for breezy?
<hunger> fabbione: I am just wondering... The problem went away when I upgraded to my custom 2.6.13 kernel... and now that I am using the kernel you put up on your site I have it again.
<Lathiat> j^: i saw a nifty laptop with two screens and one woudl commonly become n onscreen keyboard (obviously it was touch sensitive)
<j^> bob2 http://bootlab.org/~j/NetworkManager-breezy/ fixes NM for breezy
<bob2> j^: yeah, I know, but will it actually be in breezy?
<hunger> bob2: It works well.
<Lathiat> j^++
<bob2> yes, I'm using it
<bob2> but personal site != being in breezy
<hunger> bob2: From what I read several people were trying to upload it.
<bob2> surely just one person could test it and then upload it?
<Nafallo> bob2: did
<bob2> Nafallo: you've uploaded j^'s fixed version? great!
<Kamion> mdke: don't think so, thanks
<mdke> cool
<Nafallo> bob2, j^: accepted :-)
<Lathiat> Nafallo: oh, rock!
<elbi> j^: any difference between nm currently in breezy and your packages?
<Lathiat> elbi: yeh, "it actually works" ;)
<opi_> /m nickserv identify amiga.com.pl
<opi_> sfck
<Kamion> Nafallo: just a note, when uploading something that's multiple versions newer than the current version in the archive, use the -v switch to dpkg-buildpackage (or debuild) to make sure that breezy-changes gets a full record of the changes
<Kamion> so 'debuild -S -v0.4.1+cvs20050618-3build1'
<elbi> Lathiat: maybe i should give his packages a try then :)
<Kamion> elbi: wait ~20 minutes, upgrade breezy
<Nafallo> Kamion: ah, thanx :-)
<Kamion> elbi: (er, no, sorry, ~50 minutes to allow time for binaries to build)
<Lathiat> fabbione: ping
<fabbione> Lathiat: pong
<Lathiat> fabbione: did that sata change go into the new kernel?
<fabbione> yes
* Lathiat couldn't see a specific reference in the changelog
<Lathiat> ok cool
<fabbione> it's the first entry in the changelog
<elbi> Kamion: oh, just wondering why bind9 is a dependency
<fabbione> iirc
<Lathiat> it is? hrm maybe i skipped over it ;p
<elbi> Kamion: i'm using a danish mirror, maybe we should say a couple of hours :)
<bob2> one day I'd like to invent a pastry treat called the "australian"
<Lathiat> hmm i wouldnt think so but nevertheless if its in im happy
<mdz> fabbione: you now have editcomponents privileges
<Lathiat> bob2: does it involve mince and tomato sauce ?
<mdz> fabbione: set up the component ownership as you wish
<bob2> Lathiat: and quokkas
<Lathiat> bob2: heh
<seb128> mdz: is that ok to update to the new serpentine version?
<mdz> daniels: #328551 OK
<seb128> mdz: the new version can be translated which is a big advantage over the current one
<mdz> seb128: how do you feel about it?
<Kamion> elbi: if it's da.archive.ubuntu.com, that's the same as archive.ubuntu.com
<elbi> Kamion: oh, i didn't know the mail resp. was located in denmark :)
<Kamion> it's not
<elbi> err, mail = main
<seb128> mdz: I'll play with it before, but I've spoken with upstream and that should ok. The new version is mainly bugs fixing
<Kamion> *.archive.ubuntu.com == archive.ubuntu.com unless we have (and have got round to recording) a better option
<elbi> Kamion: why not point the record to one of the danish mirrors?
<mdz> seb128: ok, let's do it
<bob2> what's jdong's nick?
<Nafallo> bob2: jdong
<seb128> mdz: thanks
<sabdfl> seb128: i will make a list of screensavers, is it ok to get that to you around Sep 25?
<elbi> j^: why is bind9 a nm dependency?
<sabdfl> so we can split them into -data and -extra-data
<bob2> elbi: because it runs a local caching nameserver
<elbi> bob2: yes, but why make such thing a dependency?
<\sh> morning gentlemen *yawn*
<j^> elbi NM provides a local dns resolver that can use diffrent dns servers for diffrent names, provided by vpn connections, bind9 provides this
<bob2> elbi: because it needs it? lots of thigns have broken nameserver caching, e.g. mozilla
<Mithrandir> we should just fix libc instead.
<Kamion> elbi: mail james.troup@ubuntu.com
<Kamion> mdz: ok to merge mkvmlinuz 14 for #15570? I've eyeballed the patch, looks fine
<j^> Mithrandir you can provide diffrent ns per namespace in libc?
<bob2> Nafallo: who are bug reports about backport things supposed to go to?
<Mithrandir> j^: most apps just use the resolver functions in libc, and libc should recheck resolv.conf
<elbi> j^: oh, neat
<mdz> Kamion: yep
<Lathiat> Mithrandir: thats a separate issue
<bob2> Nafallo: e.g. the fact you're breaching the license of various bits of software?
<Lathiat> Mithrandir: j^ is talking about say, sending *.murdoch.edu.au to 134.115.1.1 and * to 45.11.23.1
<Nafallo> bob2: dunno. ask Mez.
<elbi> Kamion: ok, let me ask the mirror host first, thanks
<Nafallo> bob2: or rather... what backports are we talking about?
<bob2> http://acm.cs.umn.edu/ubp/hoary-extras/restricted/binary-i386/, for reference
<Mithrandir> Lathiat: uh, that's crack. :-)
<Lathiat> Mithrandir: no it snot
<bob2> Nafallo: hoary-extras contains all sorts of stuff you do not have permission to distribute
<Lathiat> Mithrandir: it makes perfect sense on vpns and things
<bob2> Nafallo: e.g. realplayer, java, acrobat
<Nafallo> bob2: jdong I guess. that's non-official stuff.
<crispin> mjg59: bug 12498; that was uploaded wasn't it ? (it is still marked as PENDINGUPLOAD)
<Nafallo> bob2: don't forget w32codecs :-P
<Mithrandir> Lathiat: then just ask your VPN NS for everything, or you could fix libc to handle that case too, yes.
<Lathiat> Mithrandir: vpn ns isnt always usefull in that regard, and "fix
<Lathiat> ing it is a bit tricky
<bob2> Nafallo: that's whack
<Lathiat> altho i agree that using bind9 is a bit crack in its own right
<bob2> Nafallo: and really really unfair on your mirrors
<\sh> bob2: mez can help u as well
<bob2> \sh: he's not here
<Nafallo> bob2: sure, but like I said. that's not archive.ubuntu.com's hoary-backports.
<Mithrandir> Lathiat: I think it's wrong to bring in a nameserver because you want your resolver to behave differently.
<bob2> and the last time I brought this up, apparently you all forgot you were breaking the law
<bob2> Nafallo: right
<Mithrandir> Lathiat: it's an instance of the all-too-common "let's another layer of indirection instead of fixing the problem".
<bob2> Nafallo: I can tell that because elmo hasn't dug a shallow grave for you yet ;)
<\sh> bob2: Mez is the Backports SPoC
<Nafallo> bob2: well... it's not _us_ that have that repo.
<Lathiat> Mithrandir: its for 2 reasons, both make sense, not necesarily the best solution, and if we start modifying the /etc/resolv.conf format it could break apps etc, but yes your right
<seb128_> sorry, dsl IP change
<seb128_> sabdfl: you want to split them to 2 packages, the default ones and the extra ones?
<seb128_> mdz: any opinion on #14763 ? The new comment state that the issue is due to boot order
<Nafallo> bob2: why would he do that for me? I have never even touched a backport of any kind.
<bob2> Nafallo: oh, ok
<bob2> Nafallo: sorry, my mistake :)
<sabdfl> seb128_: yes please
<sabdfl> and only install the default ones
<sabdfl> i think that's like bug #5 in bugzilla, or something
<seb128_> sabdfl: k, no problem, just let me know the list of defaults when you have it
<sabdfl> i'll work through them all again on the plane tonight and make the list
<seb128_> k
<sabdfl> there are some nice new ones
<sabdfl> which packages should i install to make sure i have ALL the hacks, to select from?
<mdz> seb128_: not entirely surprising; most of the world starts at S20
<mdz> seb128_: where does slapd start?
<mdz> seb128_: his comment about usplash doesn't make much sense; hotplug runs _way_ before that
<sabdfl> mdz: breezy is looking awesome.
<sabdfl> i rebooted last night and thought "usplash is stunning"
<sabdfl> kudos to the artwork guy behind that one
<mdz> usplash is teh rox
<Mithrandir> sabdfl: we should add a thin border to the progress bar, though
<Mithrandir> so you can see how far it'll progress
<Lathiat> and if those fonts could be a little less ugly..
<sabdfl> +1 Mithrandir
<Lathiat> perhaps not bold as it appears to be
<mdz> sabdfl: artwork came via mjg59 from "someone who can draw"
<sabdfl> can we make the fonts disappear unless you press a key?
<seb128_> mdz: S19slapd
<sabdfl> mjg59: please send thanks, praise, & kisses if appropriate
* Lathiat likes having the progress
<mdz> sabdfl: hide the progress messages? yes, but as to whether it's a good idea...
<sabdfl> pressing a key makes them appear?
<pitti> Hi mdz 
<mdz> usplash is currently entirely non-interactive
<fabbione> sabdfl: messages are good...
<mdz> and we like it that way, for the sake of simplicity
<sabdfl> ok
<fabbione> sabdfl: can we keep them at least for breezy?
<pitti> mdz: it just got into my mind that we never dropped mozilla from supported, although we agreed on it. Can I unseed it?
<sabdfl> fabbione: sure, i've already shelved the battle plans ;-)
<mdz> pitti: yes
<fabbione> sabdfl: :)
<mdz> fabbione: is there an upstream kernel release which is known to build correctly with gcc 4.x?
<seb128_> fabbione: the inotify bug is plain inotify issue
* \sh is listening the #14967 wakeup call
<jdub> Mithrandir, sabdfl: yes, there is a progress bar border on its way
<jdub> sabdfl: i'll pass on your regards to cliff
<Mithrandir> jdub: it's a < 10 line patch to usplash.
<sabdfl> jdub: warmest regards?
* Nafallo always figured the progressbar was sized to the logo :-)
<jdub> Mithrandir: wanted to do it in the image
<Mithrandir> jdub: why?
<mdz> jdub: you saying cliff did the new usplash artwork?  he didn't mention it...
<jdub> Mithrandir: to make it prettier (softer, rounded corners)
<jdub> mdz: yes, and we only took about three revisions
* jdub just wishes he had more time with cliff :-(
<mdz> jdub: it's not really in line with the desktop artwork...the current stuff anyway
<mdz> jdub: he wishes he had more time with us, too
<jdub> mdz: that's intentional, given the black background preference
<sabdfl> i think usplash fits in nicely
<sabdfl> it has the warm, woody / human colours
<fabbione> mdz: the tetex-* stuff has been cleared
<jdub> kamion's switching isolinux to the same image
<mdz> jdub: it's already done
<fabbione> mdz: just let me know if you have any objections with my last comment
<jdub> brill
<sabdfl> is there a daily livecd i can burn and test?
<mdz> fabbione: iirc your last comment said everything was OK
<mdz> sabdfl: of course
<Mithrandir> sabdfl: http://cdimage.ubuntu.com/daily-live/current/
<sabdfl> thanks Mithrandir
<fabbione> mdz: yes, in theory we should merge the changes into our package, but that's an insane amount of work
<mdz> fabbione: if the copyright is OK, merging the changes is secondary
<jdub> atm, cliff is doing a splash and background (done a few revisions of background, still needs work)
<fabbione> mdz: ok
<sabdfl> mdz: should we use the 686 kernels for the livecd?
<mdz> sabdfl: do we want to make the livecd useless for <686?
<sabdfl> is it useful for < 686 right now?
<fabbione> sabdfl: that will kick a bunch of machines out of livecd
<sabdfl> ok
<bob2> that would stop it working on via c3s, too
<bob2> which aren't still being made
<sabdfl> in that case, forget my crackpipe idea
* mdz passes the pipe along
<sabdfl> i guess a livecd is slow because of CD, not kernel
<fabbione> sabdfl: are these the first symptoms of getting older? ;)
<mdz> sabdfl: give me a week to make it fast
<Mithrandir> sabdfl: the live cd is quite nice on a dualcore athlon64 with plenty of memory.
<Nafallo> Mithrandir: ;-)
<sabdfl> fabbione: i'm already wayyy.... past first symptoms
<Mithrandir> ogra: ogra@ubuntu.com gets to you, right?
<fabbione> sabdfl: well you are not much older than i am :)
<mdz> sabdfl: currently there is rather little reason to use -686
<sabdfl> mdz: understood, it was a dumb idea, i'll just return to LP now
<mdz> in olden times (5 months ago) it was necessary in order to get highmem
<highvoltage> fabbione: duck.
<mdz> LP has almost as many subsystems as Ubuntu now
<Keybuk>    * Add /etc/X11 to the default search path.  Don't look at how it's done,
<Keybuk>      just accept that it works and move on with your life (closes:
<Keybuk>      Ubuntu#14952).
<Keybuk> heh
<bob2> does katie poke bugzilla?
<Kamion> bob2: no
<sabdfl> bob2: only after dark
<Kamion> but the annotation's useful for history-grubbing
<sabdfl> elmo likes to watch
<mdz> oh god, thomas beckett  is visiting
<mdz> with an alternate email address
<Kamion> who he?
<mdz> of debian infamy
<Kamion> YM Thomas Bushnell?
<mdz> him too, but it's beckett who's now posting to ubuntu-devel
<mdz> good night, all
<Kamion> never heard of him before, I don't think
<Kamion> night
<mvo> the guy fighting fascism?
<fabbione> mdz: night
<mdz> maybe I've heard of him in non-debian context then
<sabdfl> good luck here
<seb128> 'night mdz
<sabdfl> this is fascism central
<mdz> fascism 'R' us
<mdz> night
<jdub> mdz: so, is your evms machine breezy?
* jdub is getting a little cranky at evms now.
<jdub> after copying all my data to it, it decided it didn't like my lvm
<jdub> and would not initialise it
<jdub> so now i'm rebuilding and recopying many gigs!
<fabbione> jdub: how did you configure LVM?
<fabbione> lvm works perfectly here
<jdub> via evms
<fabbione> than you are using evms :)
<fabbione> not lvm directly
<jdub> yes, but it was the lvm that it didn't like
<jdub> and given that breezy won't boot evms yet
<fabbione> use lvm2 directly
<ajmitch> jdub: what did evms complain about?
<jdub> i'm almost tempted to forget it and just go back to md
<fabbione> vgs
<fabbione>   VG   #PV #LV #SN Attr  VSize VFree  
<fabbione>   mofo   1  20   0 wz--n 1.09T 139.62G
* ajmitch had evms complaining about wrong number of sectors on the PV
<jdub> ajmitch: there was a size mismatch between the pv metadata and the partition itself
<fabbione> jdub: ^^ lvm2 on top of md
<ajmitch> jdub: ah, same as I had
<jdub> ajmitch: yes
<jdub> ajmitch: you configured it with evms?
<ajmitch> jdub: except it only occurred with 1 of the PVs that I had created
<jdub> same here
<ajmitch> no, I didn't, it complained on bootup that it wouldn't initialise though
<jdub> the swap one was fine
<ajmitch> I wasn't using that PV yet
<ajmitch> although I'll probably need to soon, to build more packages
<jdub> i'm now using evms from the hoary livecd ;)
<bob2> fabbione: out of interest, what's the point of splitting up a 1TB array into LVs?
<fabbione> bob2: different mount points
<fabbione> i don't like the idea of having everything under /
<fabbione> or at least.. in one lv
<bob2> hm
<fabbione> my idea is that i can boot in init 1 in less than 20 seconds
<fabbione> without having to fsck /pr0n
<bob2> is it just taste, or am I missing a technical point?
<bob2> hah
<fabbione> a fsck of 600GB can take time
<fabbione> while 512M of / doesn't
<fabbione> so i tend to split stuff up...
<fabbione> and tuning the auto fsck at boot with different parameters
<fabbione> so for each reboot different volumes are checked
<fabbione> and never all at the same time
<fabbione> (use prime numbers with tune2fs)
<bob2> haha
<bob2> ETOOGEEKY
<torkel> and if you by mistake fill up one volume you don't fill the whole disk
<fabbione> torkel: that's not possible as user..
<fabbione> only as root
<fabbione> at least on ext3
<fabbione> i don't use other fancy file systems
<torkel> everything under / and the user fills /tmp
* ajmitch just has /tmp using tmpfs
<fabbione> bob2: not really.. a 4x400GB raid5 takes around 8 hours to sync.. if you add the fsck on top, it will never boot
<fabbione> torkel: as user you still can't
<fabbione> torkel: check man e2fsck for the -m option
<fabbione> torkel: by default it's 5%
<fabbione> so if you don't trash it manually. you are safe
<torkel> fabbione: true
<doko> fabbione: you do have you RAID now? which controller?
<fabbione> doko: i use software raid.. more flexible...
<fabbione> specially because you can still poke at low level on the disk and fix superblocks to recover from a total failure 
<fabbione> and software overhead is minimal at runtime
<fabbione> it tends to suck resources if the raid needs to be resynced (like after a crash)
<fabbione> but it's not any different from hw raid
<fabbione> in terms that the I/O slow down is the same
* fabbione -> food
* jdub mistrusts hw raid now
<Treenaks> jdub: it died on you?
<jdub> i had a bad run-in with an overeager raid controller
<mdke> Kamion, another problem with the installer, you available?
<jdub> luckily it was raid1, and i had the other disk not plugged in
<Kamion> mdke: yes
<mdke> Kamion, i partitioned manually and it worked, then installing the base system failed because of a problem with "bootstrap". It refers me to a log that isn't there (/target/var/log/bootstrap.log) :(
<Kamion> try /target/debootstrap/debootstrap.log
<mdke> k
<Kamion> I know the message is buggy; unfortunately it's a pain to fix due to translations
<mdke> Kamion, ok that is better
<Kamion> if I merge debootstrap 0.3.1.6 before breezy, that'll switch back to /var/log/messages / tty3
<Kamion> which will be an improvement
<mdke> Input/Output error would tend to suggest a problem with the CD right?
<Kamion> yes
<Kamion> 100% either CD or CD drive
<mdke> ok thanks for your help
<Kamion> np
<ajmitch> hi JaneW 
<pitti> seb128: I need an opinion about #14338
<pitti> seb128: in Hoary, pressing the power button on apple iBooks just caused STR
<pitti> seb128: now it also opens the logout dialog
<pitti> seb128: we should do just one, and since the logout dialog does not offer suspend (at least not for me), I think doing the same as in hoary makes sense for nw
* desrt blinks
<pitti> seb128: do you know where I can deactivate this?
<pitti> Hi desrt 
<desrt> that's my bug :p
<desrt> anyway.... you can fix it in pbbuttonsd conf file
<pitti> desrt: oh, indeed :-)
<desrt> (if you want to go that way)
* pitti boots ibook
<desrt> plus
<desrt> suspending on power switch is silly since you can just close the laptop to acheive that effect
<pitti> desrt: hm, well, right
<pitti> desrt: so we should display the gnome logout dialog for the power button, and STR when closing lid?
<desrt> yes.
<seb128> pitti: no real opinion on that. The dialog should have a suspend though
<desrt> sorry for not following up about this in the bug
<desrt> to fix it though:
<desrt> onAC_KeyAction = none
<desrt> onBattery_KeyAction = none
<desrt> mxpxpod and i found it the other day
<pitti> seb128: well, it doesn't. The dialog has STD on my desktop, wich actually works, but there is no suspend option on my laptop
<pitti> seb128: pmi is installed
<JaneW> hi ajmitch 
<pitti> seb128: and "pmi capabilities" shows "suspend"
<pitti> seb128: so where could the bug be?
<mjg59> sabdfl: I got it via jdub
<seb128> pitti: grep Command /etc/gdm/gdm.conf
<seb128> pitti: if that's an old install and you have no used the gdm.conf changes from the package
<\sh> oh good morning JaneW 
<pitti> seb128: it's a Breezy preview install, clean and fresh
<Diziet> Why oh why oh why are we carrying _50kloc_ of patches to firefox ?
<pitti> Diziet: only Ubuntu, or Ubuntu and Debian?
<pitti> Diziet: I think the real thing that hurts is the lack of a patch system
<pitti> Diziet: mozilla and tbird are much easier to maintain and merge
<JaneW> hi \sh
<pitti> Diziet: however, IIRC you recently closed that bug that asked for it
<Diziet> Debian are carrying about half of that.
<mjg59> pitti: You've edited /etc/default/acpi-support ? Or is this PPC?
<pitti> mjg59: ppc
<pitti> mjg59: well, are you talking about the bug followups this morning? or about above double-action on the power key?
<mjg59> What you're discussing now
<pitti> yes, that's powerpc
<mjg59> I've no idea about the other PPC issues (I don't have a PPC laptop)
<pitti> pbbuttonsd issue
<Diziet> Which bug did you mean ?
<pitti> mjg59: the pmi failures mentioned in the bug followups from this morning are for my amd64 desktop
<pitti> Diziet: there was a bug "Please add a patch system to firefox"
<mjg59> pitti: Am I CCed?
<Diziet> Oh, that.  You must be joking.  How could things get worse ?
<pitti> mjg59: yes, you are the assignee of both
<Diziet> The problem isn't that I can't tell these patches apart.  The problem is that they're there at all.
<pitti> Diziet: at least maintaining the Ubuntu specific patches with dpatch or whatever would make merges and submissions to Debian much easier
<mjg59> pitti: Ah, fun
<pitti> Diziet: oh, ok; I found the diff.gz and single patches very hard to sort
<pitti> mjg59: the fun part is that the die-hard kernel way works and all the script magic which is supposed to fix things makes it break
<ogra> morning
<mjg59> pitti: Oh, the USB stuff? Yeah, that'll be fixed in the next initramfs-tools upload
<ogra> Mithrandir, yes
<pitti> Good afternoon ogra :-)
<mvo> good morning ogra 
<pitti> mjg59: and the deconfiguration of ethernet?
<ogra> :)
<mjg59> Should also be sorted
<pitti> cool
<pitti> mjg59: so some cards need to be shut down before suspend?
<Mithrandir> ogra: you've got mail, then.  Marilize would be happy for an answer, I think.
<pitti> mjg59: my eth1 has a plain static fixed configuration, and yet it was not brought up again on resume
<ogra> Mithrandir, yup i read my mail before IRC :)
<Mithrandir> ogra: heh, 'k
<mjg59> pitti: It's set to auto in /etc/network/interfaces ?
<pitti> mjg59: yes
<pitti> auto eth1
<pitti> iface eth1 inet static
<pitti>         address 172.16.0.1
<pitti>         netmask 255.255.255.0
<mjg59> Right. Then I've no idea why it doesn't come up.
<mjg59> Putting set -x into resume.sh would be helpful
<pitti> mjg59: ok, I dig a bit further; thanks
* ogra wipes the laughing tears from his eyes after reading sabdfl's comment on 15284
* ajmitch reads
* Mithrandir chuckles
* Nafallo reads
* fabbione dies
<ajmitch> sabdfl: well put :)
* pitti tries to revive fabbione
<ogra> lol
<Nafallo> lol
<sabdfl> well, 'strue, innit
<ogra> *g*
<sabdfl> still it is a bug
<\sh> but a computer running while doing the family planning? I thought I'm ill
<pitti> me too, I always have the feeling that the IRC crowd is watching :-)
<Nafallo> maybe the co-op planner surprised him :-)
<ogra> pitti, we do !! phear us ! :)
<pitti> ogra: that's why I switch my box off when I don't use it
<Kamion> \sh: that would be "sick" rather than "ill", if I catch your meaning correctly
<Mithrandir> or maybe he's got a computer close to where he sleeps.
<\sh> Kamion: right...sick, ill, whatever ;) 
<ogra> Mithrandir, i heard rumours that there are people who switch them off
<Nafallo> that reminds me of when my girlfriend took her cloth of the first time and I told her she got a webcam behind her :-)
<Mithrandir> ogra: weird people.
<ogra> yup :)
<pitti> Nafallo: lol
<pitti> Mithrandir: conserve power, save the planet!
<Mithrandir> Nafallo: she wore more than one piece of cloth when you visited.
<Mithrandir> pitti: I live in a place where there's a need for heating approximately 3/4 of the year.
<Nafallo> Mithrandir: true :-)
<pitti> Mithrandir: I'm not, that's why I switch it off :-) in my place I keep the balcony door constantly open for 7 months per year
* \sh needs to go shopping...curd cheese for my eyes
<\sh> pitti: I thought u r living in germany ;-)
<pitti> \sh: I do :-)
<pitti> \sh: so what, 18 degrees is more than enough in my room
<Nafallo> pitti: brrr. I have _atleast_ 25 ;-)
<bob2> lamont: how come linux-wlan-ng isn't being tried on amd64 anymore?
* pitti recognizes that we are WAY OT
<bob2> lamont: the drivers that require it build as part of the kernel still
<ajmitch> pitti: just a bit
<Nafallo> hmm. we are talking about computers and problems with temprature :-). this discussion is SO on topic. like... why do we build stuff? :-)
<Nafallo> to keep the temprature on the right level of course. what else could be the reason? ;-)
<pitti> Nafallo: hm - do the folks in the northern part of the world use Gentoo more than, let's say, the Italians?
<ajmitch> pitti: CCed you on malone 1559
<Nafallo> hehe, I did for a year or so. now I'm rather testbuilding stuff ;-)
<Kamion> cjwatson@jackass:~$ sudo -u katie /srv/buildd.no-name-yet.com/bin/wanna-build -b amd64/build-db --info linux-wlan-ng
<Kamion> linux-wlan-ng: not registered
* Kamion looks baffled
<pitti> ajmitch: thx
<bob2> Kamion: should I file a bug?
<Kamion> bob2: no, wait until lamont turns up, he might understand it
<bob2> Kamion: sure
<Lathiat> pitti: about?
<Kamion> oh, it's P-a-sed
<bob2> ahh
<Kamion> %linux-wlan-ng: i386 powerpc arm alpha hppa                           # ANAIS [?] 
<pitti> Lathiat: about what?
<Kamion> lamont: can you add amd64 to linux-wlan-ng in P-a-s, or was there a reason it was removed?
<Lathiat> pitti: looking at a security patch for trac/hoary, theres no debian/patches infrastructure, should i add some in or just jam the patch in? (i prefer to add some in in universe generally but not sure if i should do it differently for security stuff)
<pitti> Lathiat: just applying it inline is fine then
<ogra> whaa, what made my edubuntu CD 1MB bigger ?
<Lathiat> its only 2 lines
<Lathiat> so nothing major
<pitti> Lathiat: there won't be any other patches than security for stables, so it doesn't matter
<Lathiat> pitti: is there any changelog convention? closing malone bugs? cve references?
<pitti> Lathiat: https://wiki.ubuntu.com/SecurityUpdateProcedures
<Lathiat> pitti: okie
<pitti> Lathiat: the CAN number is crucial, Malone bug number is good, and we need a good description
<Simira> mjg59 : ping
<Kamion> ogra: that can easily happen
<Kamion> but you're not oversized, so ...?
<ogra> Kamion, yup... i was just a bit shocked to be at 700MB
<Kamion> although of course you have that 700MB allowance in the oversizedness check
<mjg59> Simira: Hi
<ogra> Kamion, i'll consider to drop stuff from powerpc.... its odd to have at least 50MB space on the other arches and not being able to use it..
<Kamion> it's your distro ;)
<ogra> :)
<jbailey> jdub: I'm here now if you're awake. =)
<jbailey> mdz: The md dependancy of initramfs-tools isn't needed.  The lvm2 one is to make sure that the minimum version is met.  (The minimum version could be looser than it is, but it at least needed to be newer that either Warty's or Hoary's IIRC)
<ajmitch> morning jbailey :)
<jbailey> Heya Andrew =)
* fabbione would like to officialy thanks Kamion for the first Ubuntu sparc image @ http://cdimage.ubuntu.com/ports/daily/current/
<ogra> wow, cool
<fabbione> (but it will mostlikely not even boot)
<spacey> :] 
<Treenaks> still, cool :)
<fabbione> well i am rsyncing to test...
<chmj> hold thumbs 
<torkel> mvo: ping?
<mvo> torkel: pong
<ogra> elmo, around ? 
<torkel> mvo: apt-listchanges still barfs when you are not allowed to connect to the disply
<mvo> torkel: so it still fails?
<torkel> mvo: yes
<mvo> torkel: with the same error as descriped in your bugreport?
<ogra> Kamion, i've split out a xscreensaver-data package for usage with gnome-screensaver (just uploaded), could you NEW it if it hits the archive ? 
<torkel> mvo: if possible gtk should only be imported when the gtk-frontend is selected (or if you are allowed to connect to the display)
<torkel> mvo: yes
<sabdfl> ogra: does it include all the RSS screensavers too?
<Kamion> if it's urgent
<Diziet> Hmmm.  It seems our firefox has been compiled with -O0 because of some vague hints of trouble in the past.
<torkel> mvo: not sure how to do it though
<ogra> sabdfl, for now i've splite them all out into a -data package to have something to work with
<mvo> torkel: it's a bit tricky with the code in apt-listchanges, but I'll have a look now
<Kamion> ogra: I have to go out to the pet shop now though, may be a little while
<ogra> sabdfl, i'll move the ones we dont want back into the core package later
<sabdfl> ogra: and does that -data package include the really-slick-screensavers (GL) asn well as the ones that come with xscreensaver and gnome-screensaver?
<torkel> mvo: just poke me if you have something you want me to test
<ogra> sabdfl, nope, these are separate already
<mvo> torkel: looking at it now, thanks
<slomo> does someone know where i can get the canonical ca certificate?
<sabdfl> ogra: did you see the conversation i had with seb128 earlier
<ogra> sabdfl, no need to package them again
<ogra> nope...
<ogra> sabdfl, oh, you mean yesterday night, yes, i was there 
<sabdfl> ogra: no, this morning
<sabdfl> here's what i would like
<sabdfl> all the screensavers we turn on by default in a single package
<sabdfl> that includes the ones from realy slick screensavers
<sabdfl> gl
<sabdfl> normal xscreensaver
<sabdfl> gnome-screensaver
<sabdfl> that should be -data
<sabdfl> and then everything else in a -extra-data package
<ajmitch> alright, bug day has started :)
<sabdfl> then, gnome-screensaver can just depend on -data
<sabdfl> and so can xscreensaver
<sabdfl> make sense?
<ogra> sabdfl, yes...
<torkel> is that really wise? You probably don't want to run the gl ones on a slow unaccelerated machine?
<ogra> sabdfl, just that the rss ones are from another source, i'll have ot investigate that
<sabdfl> torkel: they are all turned on by default
<sabdfl> folks can turn them off
<torkel> in xscreensaver yes. But not in gnome-screensaver when using random
<ogra> in fact xscreensaver-gl only contains hacks
<Kamion> any reason we couldn't look at xdpyinfo to find out if you have direct rendering, and if not disable the GL ones by default?
<Diziet> No, actually, about:buildconfig lies.
<Kamion> the usual cause for my laptop running slowly is that somebody else logged in on another display has a GL screensaver running
<ogra> Kamion, yuo cant en/disable them in gnome-screensaver ... the ines installed are used
<ogra> the ones even
<Kamion> we should add a random-nogl then
<Kamion> or whatever
<bob2> is it unreasonable to get lintian synched from Debian again?
<ogra> sabdfl, if you say it includes the ones from rss, do you mean all ? 
<Kamion> bob2: it'll require a merge, but I don't see why not
<ogra> (i think they are all worth being shipped)
<torkel> ogra: I just filed a bug in b.gnome.org about disabling hacks
<ogra> torkel, thanks... but i doubt it will make it until release :)
<slomo> sabdfl: hi... do you know where i can get the canonical ca certificate? i need it for malone bug 1956 (inclusion into ca-certificates)
<ogra> i'm pretty sure we'll have a rocking gnome-screensaver in dapper... for breezy we need to make the best out of what we have
<ogra> else we'll make mdz cry with late changes :)
<sabdfl> Riddell: what's amarok?
<sabdfl> slomo: i don't think our root should be widely distributed
<sabdfl> we're not really setup to be a PKI
<sabdfl> we should in fact get more certs from someone who does that for a day job
<slomo> sabdfl: ok... it's probably just annoying for new users to get the warnings about an untrusted ca while logging into launchpad for example ;)
<ogra> sabdfl, amarok is a rhythmbox clone for KDE
<\sh> ogra: u can't say that
<\sh> ogra: amarok has (a lot) more features then rhythmbox has
<ogra> \sh, why ? 
<ogra> heh
<ogra> \sh, yes, its KDE :)
<sabdfl> slomo: we need to get proper certs for LP
<sabdfl> ogra, Riddell: is a move to amarok 1.3 insane at this point?
<\sh> ogra: I want to see a autoscrobbler plugin for rhythmbox...and no not this cli tool ;)
<sabdfl> a reviewer expressed some disappointment
<Lathiat> amarok 1.3 is nice, but is it a stable release?
<\sh> sabdfl: if u say yes, I'll prepare one ,-)
<\sh> Lathiat: yes
<Lathiat> i was using svn a bit back and it has some real nifty new stuff
<\sh> 1.3.1 is latest stable with bugfixes
<ogra> sabdfl, taht'd be a mdz decision... but i trst \sh's judgement about KDE apps...
<ogra> trust even
<sabdfl> within kubuntu, \sh and Riddell have lots of say too ;-)
<sabdfl> if its something users will notice and miss, then we should consider making an exception.
<sabdfl> especially if upstream is stable
<sabdfl> and there is a good package
<sabdfl> and testing goes smoothly (hint hint)
* Lathiat will test new packages
<lamont> bob2: %linux-wlan-ng: i386 powerpc arm alpha hppa                           # ANAIS [?] 
<slomo> sabdfl: ok... then i'll just close that bug... can't you get the ssl certificates signed by thawte? at least it was your company before ;)
<\sh> sabdfl: I'll prepare some packages to test
* lamont adds it
<sabdfl> slomo: have to buy 'em like everybody else
<Treenaks> openid maybe?
<sabdfl> elmo: status on proper certs for mail.canonical.com, launchpad.net?
<bob2> lamont: is there a reason it wa P-a-sd?
<sabdfl> i'm rebooting a fw that is now running breezy kubuntu
<lamont> bob2: dunno - I don't think it was me.
<sabdfl> if i'm not back in 10mins
<sabdfl> ...
<sabdfl> NO NEW AMAROK FOR YOU!
<ogra> :)
<lamont> but if the package says 'amd64' in the arch list, then it should work...
<\sh> lol
<lamont> elmo: new PaS, if you would be so kind.
<\sh> I should told him, that I'm busy with new wine ;)
<Lathiat> haha
<bob2> lamont: thanks
<pitti> OMG, our pbbuttonsd is stone old, and the upstream changelog mentions 10.000 bug fixes since then
<ogra> pitti, update :)
<pitti> ogra: I'd like to, the new version works fine since two weeks for several people
<ogra> 10.000 is a good number for a UVF break :)
<pitti> but we are in FREEZE
<pitti> :-/
<jbailey> pitti: That's the ppc64 daemon that likes to eat CPU, right? =)
<pitti> jbailey: right
<jbailey> (Or that's how I usually think of it right before I kill ilt)
<jbailey> s/ilt/it/
<pitti> jbailey: I just try to find the change that fixed it
<pitti> jbailey: but reading the changelog alone takes 15 minutes
<jbailey> Ouch.
<ogra> seb128, ok with you if i upload a gnome-screensaver package that depends on xscreensaver-data ? 
<pitti> jbailey: try http://people.ubuntu.com/~pitti/packages/pbbuttonsd_0.7.1-1ubuntu1_powerpc.deb
<seb128> ogra: I'm not convinced that a Depends is right
<seb128> ogra: Recommends seems to be right
<pitti> jbailey: that's the version I gave to the bug submitters
<ogra> oki
<jbailey> Starting pbbuttonsd: ERROR: The file '/dev/pmu' doesn't exist.
* Lathiat wishes apt-get paid attention to recommends
<ogra> seb128, we'll seed it anyway :)
<seb128> ogra: we should rather list if for "desktop"
<seb128> yep
<jbailey> pitti: ^^
<bob2> Lathiat: someone should base something on libapt that does that...and records when things were recorded just as dependencies for other things...and had a curses interface...you could call it aptitude!
<pitti> jbailey: * Use MAKEDEV to create the pmu file, depends on makedev (>= 2.3.1-78)
<pitti> jbailey: also fixed
<jbailey> pitti: No, that's from your package.
<Lathiat> bob2: curses interface is overrated
<Kamion> Lathiat: you can use aptitude from the command line as an apt-get replacement
<jbailey> pitti: MAKEDEV won't do much usefully on a udev system.
<Lathiat> Kamion: oh?
<Lathiat> Kamion: does it supoprt the same commands?
<Kamion> pretty much
<Kamion> aptitude --help
<pitti> jbailey: oh, interesting; does the current package work?
<Lathiat> hrm, neat
<jbailey> pitti: reverting, just a sec.
<pitti> Kamion: I suppose updating to pbbuttonsd 0.7.1 is out of question?
<jbailey> pitti: It might be why I haven't noticed the slow down in a little while.
<bob2> Lathiat: oh, I was being sarcastic; you can alias apt-get=aptitude, more or less
<Kamion> pitti: I'd rather not make that call
<Lathiat> bob2: i knew you were being sarcastic ;)
<Lathiat> are you ever not?
<jbailey> Feh, it's not in my apt archive.  /me fetches
<bob2> Lathiat: at LCA I was too sick to be sarcastic, you missed out
<jbailey> pitti: No, it fails to work too, although it doesn't mention why.
<Lathiat> bob2: damn
<pitti> http://cvs.sourceforge.net/viewcvs.py/pbbuttons/pbbuttons/pbbuttonsd/  - BAH! Go, SF
* Mithrandir kicks NM in the head.
<ogra> Mithrandir,  thought the new NM in universe would be so rocking cool ? 
<Mithrandir> a) it generates an invalid resolv.conf (no, ; is not a comment sign in resolv.conf) and b) it touches my resolv.conf.
<pitti> well, that's resolvconf's fault, I suppose
<Nafallo> Mithrandir: well, that's no change from the old version ;-)
<pitti> (I know it sucks, it always breaks my networking)
<Nafallo> pitti: that NM nukes the symlink and make a static file of resolv.conf? :-)
<mvo> torkel: fixed version uploaded, please let me know if there are problems
<torkel> mvo: sure
<pitti> Nafallo: no idea, I haven't looked at it for a while
<Nafallo> pitti: well, always did that since thom uploaded it in the middle of the cycle :-)
<Mithrandir> Nafallo: it should _stay away_ if it hasn't generated the file itself.
<Nafallo> Mithrandir: I agree :-)
<Nafallo> Mithrandir: hack it please ;-)
<eruin> is avahi 0.4 what's going to be released with breezy?
<Lathiat> eruin: 0.5
<eruin> yay
<eruin> :)
<Lathiat> whatcha wondering for?
<eruin> rhythmbox head, plus I'm going to attemt to write a small client for my local network
* Lathiat nods
<Lathiat> eruin: feel free to stop by #avahi
<eruin> done
<dholbach> hellas
<dholbach> finally internet from home
<pitti> Hi dholbach 
<pitti> yay
<ogra> yay
<dholbach> :)
<mvo> good morning dholbach 
<pitti> dholbach: seb128 missed you
<ogra> hehe
<dholbach> i'm SOO relieved
* mvo missed dholbach as well
<dholbach> thank you mvo :)
<seb128> hi dholbach
<seb128> dholbach: so you broke everything and runned away ;)
<dholbach> i'm not aware of breakage, seb - ogra just tried to tell me so
<dholbach> i restarted my box yesterday to test the svg crack and it worked particularly well
<Treenaks> svg crack?
<dholbach> the guy who reported an svg bug on malone tested it and he was fine too
<seb128> dholbach: didn't work with Ubuntu SVG icons
<dholbach> hm?!
<seb128> dholbach: they don't match the new loader definition because of the long comments
<seb128> dholbach: I had to debug that at 2am when matt, etc said that was b0rked for everybody using the Human theme :p
<dholbach> oh man :-(
<seb128> just when I was going to close my IRC to sleep
<seb128> anyway no big deal, tomorrow is saturday I'll sleep :)
<dholbach> i will pay the beer at ubz to you
<ogra> seb128, ahah
<ogra> seb128, who should belive that ??
<dholbach> ogra: are you french? you laugh backwards :)
<seb128> dholbach: thanks :)
<jbailey> mjg59: This patch attempts to resume before ide-disk and friends are loaded.  Is that what's supposed to happen?
<ogra> dholbach, just adjusting my speech for my counterpart ;)
<seb128> dholbach: the short story is that new librsvg doesn't match <?xml but <svg on 100 chars ...
<seb128> dholbach: and edit /usr/share/icons/Human/scalable/apps/mozilla-firefox.svg to understand why it doesn't work
<dholbach> what did the guys from #librsvg say about that?
<seb128> dholbach: at 3am? nothing, I went to bed after doing a fix-upload
* dholbach hugs seb128 
<seb128> dholbach: and I was waiting for you to discuss it today :)
<mvo> s/discuss it/beat you/ ;)
<\sh> mvo: u got my bugreport regarding update-manager/update-notifier?
<mvo> \sh: bug-nr?
<\sh> mvo: #15550
<lifeless> mjg59: ping
<mvo> \sh: yes, answered already and prepared a fixed version
<mvo> \sh: didn't realized it was from you though :)
<\sh> mvo: well..fast machine is not exactly what I have here ;)
<\sh> mvo: but the updates were almost installed when the toaster appeared ;)
<doko> Kamion: is there still place on the amd64 CD to add lib32gcj6?
<doko> 4.8MB
* pitti fears about even more language packs being dropped
<pitti> how big does OOo still want to get? *sigh*
<mjg59> jbailey: Hmm. Probably not.
<mjg59> jbailey: (It seems to work though, so I'm a touch confused...)
<doko> pitti: I thought, powerpc is the CD which is the critical one
<lifeless> mjg59: hey there
<pitti> doko: not only
<pitti> doko: oh, it is only for amd64, not i386
<pitti> doko: however, there are *no* language packs *at all* at the live CD
<doko> doko: yes
<lifeless> mjg59: my hibernate button does't :[
<pitti> doko: we can't cut down langpacks on the amd64 live
<lifeless> doesn't
<Mithrandir> pitti: just wait for ooo4 or 5, the source package won't fit on a DVD.
<pitti> doko: in fact, we need to cut down amd64 by 16 MB
<pitti> Mithrandir: *cry*
<doko> Mithrandir: I just need to copy the OOo2 source a few times, then it won't fit today :)
<doko> pitti: drop some lang-packs :-P
<marcin_ant> hi all - sorry because it's propably #ubuntu question but no answer there
<pitti> doko: *THERE* *ARE* *NO* *LANGPACKS* any more
<marcin_ant> question is: is there a package with java 1.5 for breezy somewhere?
<ogra> doko, you want a new schooltool upstream version ? 
<pitti> doko: I guess we have to cut down the WinFOSS stuff on amd64
<mjg59> lifeless: What hardware?
<lifeless> mjg59: my dell X1
<doko> ogra: well, sabdfl pulled the last one as well, but for now I want one which doesn't include the zope3 source
<mjg59> lifeless: Ok, should be fixed soon
<lifeless> http://people.ubuntu.com/~robertc/codes.txt
<ogra> doko, ok
<sabdfl> NO NEW AMAROK FOR YOU!
<lifeless> mjg59: also I have a hibernate won't-resume bug, that I mailed to the list
<doko> sabdfl: but a new schooltool? ;-)
<mjg59> lifeless: With luck, also improved with the next initramfs-tools upload
<sabdfl> definitely
<sabdfl> back to school everybody
<lifeless> mjg59: sweet
<ogra> fun
<lifeless> mjg59: when is that :)
<ogra> AND USE EDUBUNTU AT SCHOOL !!
<mjg59> When jeff does it :)
<sabdfl> fabionne: seems like there's a conflict between fglrx and radeonfb
<jbailey> mjg59: Do you have ide-disk and ide-generic in your /etc/mkinitramfs/modules ?
<mjg59> jbailey: Don't think so
<jbailey> mjg59: Err..
<jbailey> It's the only way this should vaguely even work. =)
<mjg59> jbailey: I guess just call ide_boot_events after that rather than later on?
<\sh> sabdfl: u want to test amarok-1.3.1?
<sabdfl> \sh sure
<lifeless> jbailey: puhlease
<jbailey> mjg59: Well, i2o, scsi, and ide.
<mjg59> sabdfl: radeonfb is not expected to work with fglrx
<\sh> sabdfl: ok...let me apply one more patch...and U are the first one who is able to test ;)
<jbailey> I think IDE might have to be reordered to last, since I'm going to forcably always load ide-generic in there.
<sabdfl> mjg59: interesting. on my desktop, enabling fglrx doesn't cause a problem. on the fw, it did
<jbailey> (it appears ide-generic devices are not hotplug enabled yet)
<mjg59> sabdfl: Yeah. It's, well, crack.
<sabdfl> seems so, yes
<sabdfl> nasty, binary crack too
<mjg59> I told you not to ship them, but noooooooooooooo....
<mjg59> :)
<\sh> sabdfl: i386? add to your sources.list deb http://archive.linux-server.org/ breezy/i386/
<\sh> sabdfl: and wait for my go in 20 mins ;)
<ogra> \sh, if he cant use kubuntu, he cant test amarok :) fix kubuntu first ;)
<\sh> ogra: he can test amarok with gnome ;)
<\sh> ogra: whats wrong with kubuntu?
<ogra> \sh, dunno, i didnt test it :p
<Lathiat> \sh: i'll have amarok 1.3 too
<ogra> \sh, ask the tester 
<seb128> \sh: it starts with a "k"
<ogra> *g*
<\sh> come on guys...I'm fixing kde stuff running gnome 
* \sh should order some food
<seb128> \sh: you should fix GNOME stuff running GNOME :)
<ogra> hehe
<ogra> and a bit of kdeedu for edubuntu :)
<\sh> sabdfl: ok...add the new source deb http://archive.linux-server.org/ breezy/i386/
<\sh> sabdfl: run apt-get update and apt-get upgrade ,-)
<\sh> I hope it works ;)
<\sh> I have to see after the xorg dance
<jdub> seb128: despite sensory overload, amarok kicks the crap out of the music players in gnome land - too much split effort :-)
<sabdfl> \sh: looks great
<sabdfl> lets DOIT
<sabdfl> Riddell, \sh, your call, it introduces no new dependency changes
* lifeless loves rb still
<\sh> sabdfl: no
* ogra too
<Lathiat> malone is starting to be pretty sweet
<sabdfl> so, your call, but let mdz know about htis conversation
<seb128> jdub: I don't listen music on my computer a lot to be honest, and rb is good enough to play an album
<pitti> lifeless: I can still reproduce the "bzr mv" exception with the latest bzr
* torkel too - execpt it currently can't play mms:// rtsp://
<lifeless> pitti - are you using the package, or a source download ?
<pitti> lifeless: jbailey's daily snapshot package
<\sh> mdz: ok with you to break Freeze for amarok-1.3.1? (regarding the chat with sabdfl?) 
<lifeless> pitti: please try with a source download, or try tomorrow
<pitti> lifeless: but I also tried it on rookery, there I use pure bzr.dev
<lifeless> pitti: hmm. 
<\sh> sabdfl: I will talk to mdz first
<sabdfl> \sh cool, i'm sure it will be fine
<pitti> lifeless: I "bzr pull" again on rookery and try again
<lifeless> pitti: is the file in the tree from previous commits? or new ?
<pitti> lifeless: CHANGES has always been there - I just want to rename it to ChangeLog to adhere to GNU standards for autotoolization
<pitti> lifeless: ouch - bzr pull failed as well - interested?
<torkel> mvo: apt-listchanges works now. Thanks for fixing it!
<seb128> jdub: bah, apt wants to use 83M to install amarok :)
<ogra> seb128, rewirte it ;)
<pitti> yes, replace it with a 10-line shell script
<dieman> heh
<bddebian> Morning
<bddebian> pitti: ping?
<WaterSevenUb> kamion, remember that issue with "ubuntu configuration" not translated after install reboot? it still seems to be there....
<lifeless> pitti: do another pull
<ogra> pitti, add additional 20 lines with zenity love for a gui ;)
<lifeless> pitti: I'm recording that poull bug now, we need a test for this
<elmo> lamont/infinity: ?
<pitti> Hi bddebian 
<bddebian> pitti: Hi.  How did you / are you fix pgadmin3 without libpgtcl?
<pitti> lifeless: did you get my /msg?
<pitti> bddebian: I can't without libpgtcl 
<pitti> bddebian: when I find some minutes of non-work time, I can deal with my Debian stuff and fix that
<pitti> lifeless: hmm, the second "bzr pull" succeeded for some reason
<pitti> lifeless: ah, you fixed that bug recently and the first pull pulled enough code to make the second try work? 
<mdke> there was a report on the -it mailing list this morning of a hoary->breezy upgrade where the system was not proeprly localised after upgrading and the user had to install the relevant gnome language pack, is this problem known
<mdke> ?
<pitti> lifeless: cool, bzr mv works now as well - thanks a million
<lifeless> pitti: nope, but I know how it works :[
<lifeless> sweet
<pitti> lifeless: I don't use bzr.dev at home any more since bzr pull just broke too often, so I use jbailey's daily debs now
<lifeless> k
<pitti> also, a single pull probably downloaded tenfold the amount of stuff than just upgrading the deb
<pitti> but that should get better with weave, I suppose
<lifeless> mjg59: ping
<mjg59> lifeless: Hi
<lifeless> mjg59: just did a kernel upgrade
<mjg59> Ok
<lifeless> gnome thinkgs I can still hibernate
<lifeless> *thinks*
<mjg59> Gnome ought to think that
<lifeless> why?!
<mjg59> Oh, I see what you mean
<lifeless> Yes.
<mjg59> That's done statically on gdm startup
<lifeless> can we at least make the prepare.sh fail noisily if the kernel version needed is not present anymore a, and set the kernel as default if it is present ?
<lifeless> would you like a bug report ?
<lifeless> mjg59: ^^ ?
<mjg59> There's already a bug open about this
<bddebian> pitti: libpgtcl is broken in Debian?
<ogra> seb128, is it intentional that evo suddenly has no trash anymore ? i loast some mails through that...
<Kamion> WaterSevenUb: yes, we haven't rebuilt debconf since pitti took it out of pkgstriptranslations
<seb128> ogra: no ... imap trash ? local one ?
<pitti> bddebian: s/broken/disappeared/
<Kamion> WaterSevenUb: I'll do it now
<ogra> seb128, local from a pop3 account
<bddebian> pitti: Ohh
<WaterSevenUb> kamion, :) 
<pitti> bddebian: somebody needs to package it from http://gborg.postgresql.org/project/pgtcl/projdisplay.php
<lifeless> mjg59: is there ? 
<ogra> seb128, the summary shows 79 deleted mails, but i dont see them... i didnt change any config options...
<pitti> bddebian: earlier it was built from the postgresql sources, but upstream removed it since it is a separate project now
<bddebian> OK
<pitti> bddebian: and I don't know a bit about Tcl, so I'm not particularly interested
<lifeless> mjg59:  do you remember the # ?
<bddebian> Well I don't know anything about anything but maybe I'll give it a shot. ;-)
<Kamion> WaterSevenUb: done. thanks for the reminder
<ogra> seb128, it also stopped downloading pics from the net recently, so i cant see the replica watches in my spam anymore
<seb128> ogra: view menu, "show deleleted messages"
<ogra> seb128, nm, i'm an idiot... i had a serch filter set
<seb128> k
<ogra> i miss that very often, i wonder how to improve it
<hughsie> mjg59: ping..
<hughsie> ogra: you got a minute?
<ogra> hughsie, a short one :)
<hughsie> cool, thanks. in breezy, what commands will hibernate and suspend the machine?
<hughsie> you have scripts right...
<hughsie> just redesigning the hal launchers a bit
<seb128> hughsie: pmi action suspend and pmi action hibernate I guess?
<ogra> highvoltage, pmi
<ogra> err hughsie 
<mjg59> pmi action suspend force and pmi action hibernate force
<hughsie> seb128, ogra: what path is pmu in?
<ogra> hughsie, pmi capabilities shows whats available for the machine
<seb128> /usr/sbin
<mjg59> It's in /usr/sbin
<WaterSevenUb> kamion, there was a detail... don't remember quite well "Download language support" was translated to pt_BR despite we have selected pt from the beggining.... there is still this issue...
<hughsie> cheers guys
<ogra> mjg59, hmm, force is undocumented it seems
<Kamion> WaterSevenUb: I haven't uploaded your Portuguese translation of archive-copier yet; it's committed to my archive, but I tend to wait a while rather than make uploads with just one translation change
<hughsie> mjg59: on elast question. does pmi let you set a low power state, a-la laptop mode?
<WaterSevenUb> kamion, aah.. right :) 
<pitti> Lathiat: thanks for the trac update, uploaded
<Kamion> WaterSevenUb: uploaded now
<zyga> hello
<Keybuk> spell checking is utterly rodneyed in openoffice.org2
<pitti> Keybuk: you have interesting verbs...
<Keybuk> why thankyou, I water them every day
<hughsie> seb128: does pmi deal with laptopmode? ala powersaving?
<seb128> hughsie: not a question for me
<lamont> Setting up ntp-server (4.2.0a+stable-8ubuntu2) ...
<lamont> Installing new version of config file /etc/init.d/ntp-server ...
<lamont>  * Starting NTP server...                                                [ ok ] 
<lamont> Setting up ntp-simple (4.2.0a+stable-8ubuntu2) ...
<lamont>  * Stopping NTP server...                                                [ ok ] 
<lamont>  * Starting NTP server...                                                [ ok ] 
* lamont giggles
<hughsie> seb128: okay, n/p
<mjg59> hughsie: It doesn't, no. It probably should do.
<mjg59> hughsie: If you'd like to define something, I can implement that.
<mjg59> ogra: Yeah - I should update the docs. "force" means that it'll go to that state even if the configuration file says not to.
<hughsie> mjg59: well, i was just looking at how powersave does it.
<hughsie> mjg59: just setting a few kernel variables == easy
<elmo> ogra: ?
<bddebian> OK, I think I'm too stupid to package pgtcl :-(
<stratus> fabbione: it seems that ath_rate_onoe kernel module into 2.6.12-8-686 was compiled into 2.6.12-3-686 or i'm missing something.
<stratus> fabbione: is it the latest?
* Diziet curses tla's build system.
<doko> Diziet, Keybuk: diversion question: is dpkg supposed to remove a diverted file/symlink on package removal and purge?
<lifeless> Diziet: tla ? 
<Diziet> tla, yes.  Don't mind me, I'm just muttering to myself.
<Diziet> doko: Do you mean is it supposed to remove A's /usr/bin/a which has been diverted to /usr/bin/a.b by B, when you purge A ?
<Diziet> Or something else ?
<Diziet> It might be clearer if you were less abstract :-).
<Diziet> tla, in fact:
<Diziet> struct rel_record { rel_field * _c; }
<Diziet> va_arg (rp, rel_record)
<stratus> php-banana has a nice short and full description
<stratus> what's that?
<Diziet> rel_add_records (&answer, /*...stuff...*/, 0);
<doko> Diziet: yes, it does remove it, but I think, it's wrong
<Diziet> 0 is not a valid value of type struct !
<Diziet> Surely it should remove it ?  If you just installed B and it diverted /usr/bin/a to /usr/bin/a.b then you'd still not have a /usr/bin/a.b.  So surely after deinstalling A /usr/bin/a.b should be gone.
<Diziet> Although diverted conffiles are known not to work properly.
<Diziet> FSVO `properly'.  It's not clear what the semantics ought to be of attempting to divert a conffile.  `dpkg has detected that the package maintainer is on drugs.  Continue anyway ?'
<doko> Diziet, wait elmo found the problem in another place, nothing to do with diversions ...
<elmo> OGRA
<ogra> elmo
<ogra> whats wrong ? 
<Keybuk> doko: I was conveniently sitting next-to-ish elmo
<elmo> ogra: pls fix xscreensaver-data KTHXBYE
<Diziet> Anyone here know anything about ppc calling conventions ?
<Diziet> Is it the case that with a varargs function, int args and pointer args are passed differently ?
* Diziet finds a slightly doubtful web page.  Looks like structs are passed differently to unstructed values of the same type.
<Diziet> This is going to be a big patch.
<ogra> elmo, do you have a hint for me whats wrong with it ? 
<elmo> ogra: missing Replaces: on xscreensaver
<elmo> how on earth did you even manage to install test it?
<ogra> elmo, replaces ?? its an additional package it shouldnt replace anything
<pitti> sjoerd: here?
<elmo> dpkg: error processing /var/cache/apt/archives/xscreensaver-data_4.21-4ubuntu11_i386.deb (--unpack):
<elmo>  trying to overwrite `/usr/share/man/man6/ant.6x.gz', which is also in package xscreensaver
<elmo> ogra: ^---
<ogra> hmm... there shouldnt be any manpages in xscreensaver for the hack... so i'll fix xscreensaver ... thanks, i had no such prob here while testing
<elmo> ogra: dude.  you can't fix xscreensaver
<elmo> I'm upgrading from xscreensaver_old-version; short of a time machine, that package is a done deal
<Keybuk> xscreenserver-data needs a Replaces on xscreensaver
<ogra> but i dont want to replace xscreensaver ... 
<Lathiat> isnt it supposed to replaces << last version
<pitti> but you do
<Keybuk> ogra: you do
<pitti> ogra: Replaces: does not (always) mean to replace the whole package
<pitti> ogra: just replaces some files
<ogra> err.. yup
<Keybuk> Replaces != RPM Obsoletes
<pitti> ogra: if you replace a whole package, you shuold additionally conflict to it
<Keybuk> Replaces in dpkg means "I need to overwrite files"
<ogra> sorry, i'm slow today it seems
<Keybuk> Replaces+Conflicts is an "Obsoletes"
<dholbach> elmo: could you pretty please sync  gnome-vfs  (the old one, universe) from sid?
<Diziet> Joy.  173 calls to this function to be fixed.
<ogra> ohhh, seb128 look at /apps/gnome-screensaver/themes :) we dont need to work around en/disabled screensavers apparently :)
<ogra> how nice :)
<elmo> dholbach: done
<dholbach> elmo: merci beaucoup
<seb128> ogra: right
<dholbach> Mithrandir: thanks for that bug report
<Diziet> (breezy-chroot)iwj@davis:~/tla-1.3.3$ find -name '*.c' | xargs ../fix-varargs rel_add_records rel_record_null 
<linuxsbartley> Can anyone tell me who is the best person to talk to about cups on 5.04 server install. i.e. w/out gnome tools.
<jdub> pitti
* pitti whistles
<elmo> Diziet: are you working on the tla powerpc ftbs?
<pitti> btw, since tla is orphaned upstream, shouldn't we drop it to universe?
<elmo> Diziet: if so, maybe we should consider just demoting tla and tla-tools instead
<lifeless> Diziet: its all fixed in baz. just ship baz.
<lifeless> _seriously_
<lifeless> I'm no at all biased here or anything.
<Lathiat> of course not
<lifeless> :)
<linuxsbartley> I have an 5.04 server installed system.  I have added xfce4 and cups.  I want to be able to configure printers using the localhost:631 swat configuration.  By default, it wants the root user and password.  I have added a root password, restarted cups etc... still can not get cups to access admin functions.
<occy> who would I talk to about what gets included as far as the firmware for the ipw2200 wireless network card into Breezy?
<pitti> linuxsbartley: please try "sudo adduser cupsys shadow"
<dholbach> whats up with the bug announce bot?
<dholbach> who turned it off?
<pitti> linuxsbartley: that makes cupsys able to read /etc/shadow and thus it can verify your password
<pitti> linuxsbartley: it's in /usr/share/doc/cupsys/README.Debian
<linuxsbartley> pitti, ok.  is there any security risk with that?
<pitti> linuxsbartley: not an actual one, we just disabled it by default for proactive security
<linuxsbartley> ok. cool. thx.
<pitti> linuxsbartley: since on the desktop cupsys doesn't need it (privilege minimization)
<occy> is this a support channel?
<occy> heh
<pitti> occy: no, #ubuntu is
<occy> yeah, that's what I thought.
<occy> just wondering if linuxsbartley's question is OT.  (no offense intended linuxsbartley)
<pitti> of course we can't help ourselves and occasionally answer supportish questions here
<linuxsbartley> sorry for the support type question.  #ubuntu did not have the details.
<linuxsbartley> the why behind the how.
* pitti adds a highlight to cupsys
<linuxsbartley> pitti, thx again.
<pitti> linuxsbartley: you're welcome
<occy> so, anyone know who to contact regarding firmware that gets shipped with a stable release?
<occy> *crickets chirping*
<dholbach> WOW, what happened to the gnome-screensaver preferences?
<torkel> dholbach: you got all the xscreensaver hacks?
<dholbach> seems so
<occy> any of you guys developers?
<sabdfl> ogra: whats with /apps/gnome-screensaver/themes
<sabdfl> ?
<\sh> occy: no ;)
<occy> heh
<occy> \sh, did you see my question?  re: firmware ?
<occy> need to ascertain who maintains the ipw2200 firmware that is distro'ed with Ubuntu.
<sabdfl> occy: BenC is kernel maintainer
<\sh> occy: benc or fabbione 
<dholbach> occy: do you look for this: /lib/modules/2.6.12-8-686/kernel/drivers/net/wireless/ipw2200/ipw2200.ko ?
<occy> My main thing is that the default drivers shipped with Hoary for my card are ancient.
<sabdfl> occy: could you test breezy, please?
<occy> and I want to see if they'll include the update for breezy *heh*
<occy> sabdfl, hmm, good point
<sabdfl> i'm running breezy, how do i tell version number for you?
<occy> well... I think it only pulls up if you have that type of card.
<occy> ie,  dmesg |grep ipw2200 
<occy> heh
<Keybuk> apt-cache policy "package"
<ogra> sabdfl, it holds the list of enabled screensavers ;) it wasnt there last tim i looked at the code :)
<sabdfl> [4295068.858000]  ipw2100: Intel(R) PRO/Wireless 2100 Network Driver, 1.1.2
<Keybuk> gah,ww
<occy> sabdfl, ahh you have the "same" card.
<occy> (I think the 2100 is the brethren of the 2200)
<sabdfl> occy: different driver
<sabdfl> someone with a t42 will have to help you ;-)
<occy> sabdfl, well... 0.19 is what Hoary has.  
<occy> sabdfl, hehe
<Diziet> elmo etc.: Yes, I'm fixing the tla ftbfs.  Should have it done this afternoon.
<occy> np
<sabdfl> occy: sec
<occy> sabdfl, any way we can find out what version breezy has via a file some place?
<Diziet> Are we really messing about with ideas like `drop it and switch to baz' now ?
<occy> sabdfl, yessir
<Diziet> Oh, and do we have any other code by the same author ?  It needs a review looking for misuse of 0 and the end of a varargs list.
<Diziet> s/and the/at the
<dholbach> Thu, 28 Jul 2005 09:07:02 +0200: - Update ipw2200 to 1.0.6.
<sabdfl> dholbach: even that's pretty old, isn't it?
<sabdfl> BenC: ping
<pitti> Diziet: well, bazaar is in Ubuntu main since hoary, so it's not really a "switch"
<dholbach> sabdfl: to be honest, i have no idea - that's just what i found out in /usr/share/doc/linux-image-2.6.12-8-686/changelog.Debian.gz
<occy> dholbach, wow
<occy> dholbach, that's in breezy?
<dholbach> occy: yep
<pitti> Diziet: the question is just whether we should support a package for 18 months that has a good replacement and is orphaned upstream
<occy> dholbach, kick ass
<occy> oops, sorry for cursing
<dholbach> :-D
<sabdfl> occy: (16:42:52) cvd: sabdfl: [4319191.367000]  ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, 1.0.4
<occy> hmm
<occy> that's cool... that's what I have now via some howto.
<dholbach> occy: you should try the livecd - that should give you the info most easily
<Diziet> pitti: Is that the question ?  The answer to that is probably `no'.  But also, the answer to `should we remove stuff from main at this stage' is probably `no' too.
<occy> dholbach, that's a good idea too... 
<Keybuk> I suspect the fact we ship tla in main is an accident
<occy> Well, thank you guys.  I do appreciate your time.  I don't want to clog up the channel with my stuff :)
<sabdfl> that's pretty old
<sabdfl> Diziet: we put stuff in main that we want to support for 18 months
<occy> I just wanted to make sure someone was working on updating the drivers.
<sabdfl> do you think tla should qualify?
<occy> as usual, Ubuntu is on top of things.
<occy> :)
<sabdfl> occy: 1.0.4 is not the latest
<pitti> Diziet: I don't see a problem with it, we are even putting stuff into main still; but it was just a suggestion to direct our working power into sensible fields
<occy> sabdfl, well, it's better than 0.19
<sabdfl> but i believe there was a problem with 1.06, so we've rolled back
<Diziet> Oh, right.  This code is rather bad.  How's baz ?
<occy> sabdfl, yah, that's what I've read.
<sabdfl> Diziet: baz is much better. but even that is EOL'd
<sabdfl> i think we should have baz in main, tla in universe for breezy
<Diziet> I see.  Um, we should support something along these lines.  Can baz publish tla format changes ?  (Sorry, I'm a bit behind on this kind of stuff.)
<sabdfl> Diziet: baz can read them
<pitti> Diziet: yes, it can
<sabdfl> ok
<pitti> Diziet: you can even create tla archives with it
<pitti> (and commit to them, of course)
<Diziet> If it can write them then baz is just a replacement for tla with less bad code, which sounds good to me.
<Diziet> I'll finish off this ftbfs though.
<lifeless> why ?
<pitti> Diziet: the UI is different (better mostly), but it is archive-compativle
<Diziet> Well, I'm 80% through it.
<lifeless> there is a patch on the list
<lifeless> its just a nonsense size promotion bug
<lifeless> tom kept doing that again and again
<lifeless> 0 != (void *)0
<Diziet> No, it's not just size promotion.  He's also got   struct { foo*; }  which he varargs for but he passes just  `0'.
<lifeless> yes
<Keybuk> hmm, are we going to keep support for baz for 18 months?
<sabdfl> Keybuk: we more or less have to
<Diziet> What do we have to replace it with ?
<sabdfl> it won't be in dapper/main, but bzr is NRY
<jsgotangco> hey guys, i just came home after speaking about ubuntu and edubuntu in linuxworld philippines. Guess what, I actually WON an RHCE training and exam pack..hehehehe
<Diziet> Is bzr going to read and write tla format archives ?
<sabdfl> jsgotangco: nice going
<Lathiat> see, you speak about ubuntu, and they try to convert you!
<Lathiat> ;)
<sabdfl> Diziet: no
<sabdfl> there will be a conversion tool
<jsgotangco> sabdfl: yeah, people are really hyped about edubuntu anyways (the goverment people actually came)..it was our first linuxworld even in the country
<Diziet> sabdfl: Hmm.  I think that means we're going to have to support either tla or baz (so, baz) for quite a while.
<sabdfl> Diziet: baz it is then
<sabdfl> Keybuk: could you get the seeds right for tla -> universe, baz -> main, and bzr -> main for breezy, please?
<Diziet> I'll take tla out of the seeds for breezy.
<sabdfl> cool, thanks
<elmo> sabdfl: baz is already in main
<elmo> bzr would need a main inclusion report
<sabdfl> elmo: cool, thakns
<elmo> Diziet: be sure to kill it in edubuntu and kubuntu too
<sabdfl> lifeless: we need to coordinate the latest-best bzr into breezy, please
<elmo> sabdfl: cvd is making "WTF isn't he packing" noises ;-)
<lifeless> sabdfl: next week ok? about to release 0.0.8
<lifeless> sabdfl: so wednesdayish would be good
<jdub> bzr in main sounds a bit wonky
<sabdfl> elmo: cvd is so NEW around here
<sabdfl> lifeless: sounds fine
<sabdfl> jdub: yeah, i could live without it
<sabdfl> but perhaps its something we would be happy to push new versions into updates for
<sabdfl> we know its moving very fast at the moment
<sabdfl> and we know we would like it to be widespread
<Keybuk> elmo just broke down in tears
<jdub> lifeless: is bzr in the bazaar.canonical.com repo? might be better to point breezy users there while it's in RADICAL DEVELOPMENT phase :)
<sabdfl> so getting it in, then making newer versions available through updates (it has minimal dependencies) would work
<lifeless> it won't be stable till month or two after brezzy goes out
<lifeless> jdub: not yet, may do so once things get a bit more formalish
* jdub wants CoTD bzr! ;-)
<lifeless> jdub: jbailey has that for you
<jdub> jbailey has all the new hotness
<jbailey> jdub: I don't have the sources.list bit to put in handy.
<jbailey> But you want bzr and bzrtools from it. =)
<jdub> heh
<jdub> 'sok
<jdub> might be a little while before i start using it in anger
* jdub is going to give the Planet a bzr cut
<jbailey> jdub: deb http://people.ubuntu.com/~jbailey/snapshot/bzr ./
<jbailey> jdub: What were you pinging about with the evms root?
<jbailey> jdub: If you'r doing that, you need my new initramfs love in my people directory.
<jdub> ah, bummer.
<jdub> i reverted to md after evms was giving me hassles (over and above lack of current initramfs support)
<jbailey> Yeah, so far evms doesn't much love me either.
<jdub> evmsn was segfaulting and stuff too
<jbailey> But I can boot with /dev/evms/lvm2/Ubuntu/root as my root now. =)
<jdub> elite
<jdub> i'm going to muck around with it on another machine though, something less... mission critical (ie. does not host pipka's mail)
* Lathiat smirks
<Lathiat> is this the kind of thing we want to be installed by default? ;)
<jdub> well, it's not used by default
<jdub> and we've only just scored autosetup of lvm (sans evms)
<sabdfl> mdz: ping
<jdub> (though i wouldn't be too excited about putting evms on a "WOW FEATURES!" list any time soon)
<Keybuk> but it's soooo shiiiny
<sabdfl> who knows about the post-update notes?
<sabdfl> jbailey: ?
<sabdfl> can we make it detect dups and not show them?
<ogra> sabdfl, mvo ?
<sabdfl> mvo: ^?
<mvo> sabdfl: here
<mvo> sabdfl: dups like two identical kernel notifications?
<elmo> can we make it not show the language pack stuff too
<sabdfl> mvo: thats the badger
<mvo> elmo: what's wrong with the language pack notification?
<Diziet> Hmm.  Are we going to pull tla-tools ?  It turns out that tla is in main because of tla-tools.
<elmo> mvo: I think it's horribly confusing and meaningless to the average user
<elmo> Diziet: yes
<Diziet> I assume; I haven't checked the germinate output.
<elmo> Diziet: we should drop tla-doc too
<Diziet> tla-tools look like they'd be useful with baz too, or am I mistaken ?
<mvo> sabdfl: can you please mail me the content of you /var/lib/update-notifier/user.d/?
<Diziet> tla-doc> Quite so.
<sabdfl> mvo: notification-2.6.12-8-386  notification-2.6.12-8-686
<sabdfl> 3/686
<mvo> elmo: update-notifier is just the message here, but I think the message should be reworded to "run language-selector" (it will detect the needed actions
<mvo> sabdfl: thanks, I'll work on it
<mvo> elmo: arg, that should read "is just the messenger..."
<elmo> mvo: yeah, sorry, I wasn't having a go at you, just the message :)
<bddebian> w00t, at least I finally got pgtcl to run configure. Sheesh
<mvo> elmo: sure :) I'll bug pitti about it when I see him next time
<jbailey> sabdfl: post-update?
<mvo> jbailey: I take care of it, no worries
<jbailey> Thanks.
<Diziet> baz--
* Diziet fights it with lock-revision -b.
<lifeless> Diziet: lock-revision <give it a 'version'>
<lifeless> Diziet: it still accepts revisions, but it has a DWIM mode
<sabdfl> cheers all. a week's holiday. omg, i don't know if i'll be able to stop lunchpadding
<sabdfl> ADDICT
<ogra> sabdfl, enjoy the weekend (especially sunday)
<dholbach> sabdfl: have a nice weekend :)
<sabdfl> thanks guys
<Diziet> lifeless: No, the problem is that if my commit bombs out halfway through (eg, because my signature program broke), it leaves the lock in the repo.  Barmy !
<Diziet> Kamion told me to use lock-revision -b to break the lock again, which `fixes' it.
<lifeless> Diziet: for the ancestry file yes, unloikely to fix that one.
<dilinger> ah, memories of tla/baz
<mdz> morning
<elmo> ogra: why did you add Conflicts?
<bddebian> Hello mdz
<ogra> elmo, isnt that common ? 
<mdz> jdub: yes, my evms machine is breezy
<elmo> ogra: it's unneeded and causes dpkg to do the Wrong Thing
<jdub> mdz: have you used evmsn much, or is it all set up and rolling ok? (i assume with jbailey's evms-enabled initramfs stuff)
<mdz> jdub: I use it sometimes, more often evmsgui
<mdz> jdub: no, I don't use evms root here
<jdub> aha
<ogra> elmo, i'll fix it in the next upload, i dont think it does any harm currently..
<bob2> wtf
<bob2> the upstream mozilla crash agent thing uses motif
<ogra> mvo, dont you think 14944 is an X issue ?
<mvo> ogra: I don't think so
<ogra> if the screen is locked, nothing should leak through... 
<ogra> you cant patch all the notification apps..
<mvo> it should be enough to patch notification-daemon
<ogra> what about zenity notifications for example... 
<mvo> i "just" need to know when the screensaver is active
<mvo> how does zenity do it's notifications?
<ogra> zenity --notification --text "blah"
<ogra> try it
<ogra> hmm, it doest show bubbles...
<ogra> doesnt 
<ogra> mvo, forget it :)
<bob2> it doesn't seem to do anything but add a tray icon
<mdz> ogra: what is the purpose of xscreensaver-data?
<ogra> mdz, it holds the hacks
<mvo> ogra: :)
<ogra> mdz, we can drop xscreensaver 
<mdz> ogra: then it's not data, but programs?
<ogra> mdz, yes
<mdz> ...
<mdz> Diziet: I filed a bug about that ages ago
<Diziet> mdz: The baz lockfile problem ?  Yes, I assumed it was known.
<Diziet> But while you're here:@
<Diziet> s/\@//
<Diziet> This kernel-package dependency bug you passed on to me, 15488.
<Diziet> Which kernels do not compile with our current default gcc-4 ?
<ogra> Diziet, all ?
<Diziet> The bug report suggests that just adding a dependency will DTRT but the actual kernel sources don't seem to go out of their way to select a different compiler.
<Diziet> ogra: I was worried it might be something along those lines :-).
<ogra> Diziet, the kernel is gcc3.4 afaik
<\sh> *yawn* that was good
<mdz> Diziet: the kernel sources ought to have gcc-3.4 in the makefile
<mdz> Diziet: the headers do
<\sh> mdz: g'evening :) I hope u had a good sleep :)
<Diziet> Not all kernels have gcc-3.4 in the makefile, just recent ones, AIUI.
<mdz> Diziet: it's OK with me that since there will be no kernel in breezy which builds correctly with the default gcc, that  kernel-package in breezy assume that any -source package it builds will need gcc-3.4
<mdz> Diziet: well, in Hoary, the kernel built with the default gcc
<mdz> but breezy kernels have used a non-default compiler ever since 4.0 became default, early in the cycle
<mdz> \sh: not bad
<mdz> I would have liked to have slept longer
<Diziet> Right, yes, obviously it should depend on whatever it wants to build with.  But AFAICT the machinery for making it use the right compiler isn't perfect.
<\sh> mdz: I know this feeling :) 
<mdz> Diziet: if there are bugs there, we should fix them.  is there something specific it isn't doing yet?
<\sh> mdz: did u read the backlog about amarok 1.3.x and sabdfls wish to include it, cause community wants it? 
<Diziet> Well, what I did was: downloaded our current kernel-package .dsc and unpacked and built it.  Installed the resulting .deb.  Unpacked a stock linux 2.6.13.1, cd'd into it.  Said  make-kpkg kernel-image.   It's using `gcc'.
<Diziet> So either (a) 2.6.13.1 is OK with 4.0 (which I thought wasn't the case) or (b) at the very least make-kpkg should pick the right compiler.
<mdz> Diziet: (b)
<Diziet> Right.  So it's not just a dependency problem.  NP, I can fix it.  I just wanted to check that I wasn't confused, because the bug report suggested just changing the deps would help.
<Diziet> As an aside, how do our own kernel-image packages get built ?
<Diziet> Do we have some weird systems with gcc symlinked to gcc-3.4 or something ?
<Diziet> I'll go ask in #ubuntu-kernel.
* \sh needs new tobacco...buying
<mdz> Diziet: well, the bug report was about what happened when someone installed linux-headers, linux-source, etc. and then tried to use them
<mdz> Diziet: they can't be used without gcc-3.4
<Diziet> Right.  But even if you have gcc-3.4 installed you have to know to give the build special flags.  That's probably OK for the source package, which you're supposed to use if you know what you're going.
<doko> Diziet: no weired symlinks
<Diziet> But it's no good for the make-kpkg kernel-image, which is supposed to be at least mostly automatic.
<Diziet> So it's done in our diff ?  We patch the toplevel Makefile to select the right compiler ?
<mdz> Diziet: you shouldn't need to specify anything special, at least with linux-headers.  it has HOSTCC=gcc-3.4
<mdz> I don't know how it works
<mdz> it wasn't the case in the past and I was going to file a bug about it when I noticed it had already been changed
<Diziet> Right, if you get the linux-source package from archive.ubuntu, and untar it and cd into it, it will DTRT.
<Diziet> But if you get a stock kernel from kernel.org and untar it and make-kpkg it will DTWT.
<mdz> good
<mdz> apparently
<mdz> but that's a separate issue
<Diziet> Well, yes, but if I'm editing kernel-package I could fix both.
<mdz> if it's straightforward
<Diziet> Looks it.  I can see the bit where it picks `gcc'.
<Diziet> I want to do people this favour because miscompiled kernels are a bad rathole for novices.
<mdz> sure, just don't let it block the other fix
<\sh> mdz: so the question is, if we're allowed to break the freeze to bring amarok-1.3.1 into breezy
<mdz> \sh: we already had this conversation on ubuntu-devel...has something changed?
<mdz> is it still a beta or is it a final release?
<\sh> mdz: final
<ogra> mdz, i dont think -data is the wrong name, even if its binary data, it gets installed in /usr/lib/xscreensaver and gets executed by the screensaver app
<mdz> \sh: does anything depend on it?  does it have the potential to break anything other than amarok?
<\sh> mdz: no..no new deps 
<\sh> mdz: nothing which depends on amarok
<mdz> \sh: ok, let's do it
<mdz> plenty of time to back it out if necessary
<\sh> mdz: thx...
<jbailey> lamont: Shouldn't uname -m under linux32 return 'parisc' for you?
<jbailey> lamont: I thought that it always returned the 32bit variant (Isn't that the point?)
<cepear> hi ppl
<dholbach> hey cepear 
<cepear> somebody tried breezy/amd64 with nvidia?
<cepear> I own a 5200 fx and I can't make it work with latests kernels
<cepear> well, the nvidia module loads, which doesn't starts up is X
<mdz> ogra: so we are ready for gnome-screensaver now?
<ogra> mdz, yup
<sivang> hey all, is there anybody to sponser me on a gnome-panel fix? (make lpi integration consistent with mpt's  spces..
<sivang> bah, this irssi + gnome-terminal is annonying
<ogra> mdz, sabdfl still wanted to have some changes to the lock window, mtp is preparing tham, but we should change the seeds asap i think
<ogra> s/tham/them
<bob2> xterm it u
<mdz> ogra: can gnome-screensaver conflict with xscreensaver now?
<mdz> otherwise upgrades will get both
<ogra> mdz, it only needs xscreensaver-data, i can make it conflict
<mdz> sivang: perhaps \sh can help
<\sh> sivang: what?
<sivang> mdz: thx
<\sh> sivang: whats your problem?
<mdz> \sh: he's looking for someone to sponsor an upload to main, see above
<\sh> mdz: if it's ok with you and seb128 sure
<sivang> \sh: yep :-) I need to do a small fix for gnome-panel which was already discussed with seb128 and mpt, I Want to know if you could sponser my upload
<mdz> I haven't seen the code
<sivang> mdz: that's just dropping the context menu patching from the applets, and leave it for the panel alone
<sivang> mpt: around?
<whiprush> Sweet! Bouncing cow in gnome-screensaver!
<ogra> yes, we still need to disable a lot
<torkel> ogra: #316462 is the bug I filed in b.gnome.org re disabling themes in gnome-screensaver (in case you are intrested)
<ogra> torkel, i already found the gconf key, but thanks )
<ogra> :)
<torkel> ogra: :-)
<torkel> ogra: you "only" have to hack the preferences to change the key then? :-)
<ogra> we'll just provide a default setting for the key in the package ;)
<jdub> mdz: whoa, we're shipping gnome-screensaver?
<mdz> jdub: seb128, ogra and sabdfl are all behind it
<jdub> ... so who swapped the release management juice for the SHINY juice? :-)
<Surak> Hello, I'm having an odd issue with debian-installer.
<Riddell> kdebluetooth is on the kubuntu CD but it doesn't get installed, why could that be?
<Surak> In live cd's boot, if i type live debian-installer/locale=pt_BR , it will not work. But if I set the locale to es, it works. This live cd already have the pt langpack...
<mdz> jdub: guess
<jdub> haha
<Surak> What can be wrong?
<Surak> Are the language-pack-pt and language-pack-pt-base enough for d-i? Or there are different stuff for this?
<bob2> bold fonts in xterm look fucked
<Riddell> Surak: live CD ubuntu breezy doesn't ship -pt language packs on i386 according to the seeds
<Surak> Yes Riddell. This is a custom cd, with both packages installed. 
<\sh> bob2: gnarf..that's why daniels didn't want to deal with it anymore..now my ass is fcked
<Riddell> Surak: then you also need the language-pack-gnome-pt and language-pack-gnome-base-pt
<Surak> but my problem is before gnome. What happens is nothing when I type that d-i command at boot time.
<Surak> d-i seems to ignore it when I type it with pt_BR. It will ask me language and keyboard. If I set for instance to "es" locale, it will ask me nothing.
<seb128> \sh, sivang: what?
<Surak> Riddel: and both packages are installed.
<\sh> seb128: sivang whats to have a sponsor for his gnome-panel lpi patch
<\sh> seb128: when u r available, you can deal with him :)
<seb128> \sh: has somebody reviewed the patch?
<seb128> \sh: nobody pinged me :p
<sivang> seb128: I wasn't aware you are still here, I will post a debdiff in a sec.
<bob2> NM doesn't do wpa?
<whiprush> nope
<bob2> suck
<\sh> seb128: mdz mentioned it...but I never seen a piece of code
<dholbach> wifi-radar recommends wpasupplicant though
<\sh> why the hell...gdm is depending on xterm?
<dholbach> \sh: because you can have a term-session-login-only-thing-too
<\sh> dholbach: i see...*grmpf*
<ogra> mdz, #3044 would introduce two additional packages (sabdfl wanted xscreensaver-extras) do we really want that ?
<doko> elmo, fabbione: please could I have 2Gig disk space on concordia?
<ogra> mdz, its possible to make a preselectin in a gconf key for gnome-screensaver, the only issue is diskspace
<fabbione> doko: checking right now
<\sh> dholbach: funny thing that xterms behaviour is completly different in gnome then running e.g. fluxbox...
<fabbione> doko: keep an eye on a rm -rf process with my user..
<\sh> have to investigate
<ogra> mdz, since we separate gl and non gl we'd have: xscreensaver-data (non-gl), xscreensaver-gl, xscreensaver-extras, xscreensaver-extras-gl
<fabbione> doko: when it's done there will be 3.5G free
<seb128> \sh: due to xrdb?
<fabbione> but it's all ccache.. do it will take some time
* fabbione -> off
<\sh> seb128: du u think xterm +ls is xrdb?
<doko> fabbione: thanks
<mdz> ogra: note that I removed the 5.10 milestone from that bug
<ogra> mdz, oh, ok
<fabbione> doko: np
<\sh> seb128: or export PROMPT_COMMAND= ; xterm +ls == set title to whatever but not xterm?
<\sh> seb128: which should be the default
<\sh> seb128: but I will check this just now with fluxbox ;) 
<\sh> or kde
<seb128> \sh: no, xrdb just change the style: color, etc
<\sh> seb128: no...xrdb can tell xterm to behave as loginshell or not..but cli switches should have higher prio
<mdz> Diziet: who said that tla is being demoted to universe?
<\sh> seb128: but it's not working just like it should
* mdke searches in vain for his address bar in nautilus
<lamont> jbailey: dunno... just reporting what it does...
<mdz> l-r-m is larger than the kernel itself
<mdz> that is so evil
<sivang> wow
<seb128> mdke: what bar?
<seb128> mdke: ctrl-L ?
<occy> is there a reason why dma = on isn't set for /dev/cdrom by default when Ubuntu ships?
<mdke> seb128, yeah, that one
<mdke> seb128, what happened to it?
<mdke> occy, yes, there is an enormous bug about it in bugzilla, check it out
<seb128> mdke: still working here
<mdke> seb128, it works now I pressed ctrl L :) Not before that though
<seb128> mdke: you have a bar of button like the fileselector one
<mdke> yeah
<mdke> and until you told me ctrl L, I couldn't figure out from the menus how to get my address bar back
<ogra> jbailey, http://people.ubuntu.com/~ogra/edubuntu/edu_usplash.png
<jbailey> ogra: Show off. =)
<ogra> :)
<mdke> not to rant or anything, but does it bother anyone else that this ctrl L nautilus behaviour is not available from the menu?
<ogra> which menu ?
<mdke> any menu
<mdke> but I would have thought it would be trivial to have it accessible from the View menu
<ogra> mdke, its in the "go" menu
<\sh> gnarf
<ogra> L = Location
<mdke> oh how irritating
<mdke> thanks anyway
<mdke> the "Location bar" entry in the View menu is quite confusing then
<ogra> hmm, it should probably be called "path bar" but the place is right
<mdke> ogra, so am I right to say that I can't turn on my address bar permanently? I have to press ctrl L every time?
<ogra> yup
<mdke> man that sucks
* ogra uses spatial anyway
<jay>  /apps/nautilus/preferences/always_use_location_entry
<jay> If set to true, then Nautilus browser windows will always use a textual input entry for the location toolbar, instead of the pathbar. 
<mdke> jay, it's not in the preferences menu?
<jay> mdke: doesn't look like it.  you know GNOMEites and their preferences ;)
<mdke> man that sucks
<mdke> users aren't supposed to play around in gconf-editor
<jay> what user is going to want to ctrl-l and type in their location? ;)
<jay> it's not GNOME's target
<jay> audience.  but it's in gconf for advanced people to change
<mdke> it's a browser
<mdke> firefox has an address bar
<ogra> its a file manager ;)
<mdke> in browser mode?
<ogra> its still a file manager
<mdke> anyhow, it's all a matter of opinion
<cavediver> Sorry to disturb. But where do I report bugs? It seems gnome-terminal bluescreens with screen from time to time. And no - that's not a joke :P
<mdke> all I would have liked is the option to turn it on in the preferences
<mdke> cavediver, see the topic, bugzilla.ubuntu.com
<Lathiat> cavediver: heh, let me guess, irssi & screen right?
<cavediver> l
<cavediver> Lathiat: yes
<\sh> bob2: can u do me a favour?
<cavediver> mdke: ohh sorry. Will file it there then.
<Lathiat> cavediver: long standing bug in vte, theres a bug open somewhere at http://bugzilla.gnome.org
<cavediver> Ok, so no bug-filing for me then :)
<Lathiat> cavediver: hitting ^L will refresh.. but it'l only go back, i just ahve to restart the terminal :\ not much to do, it sucks. 
<jay> only happens when you use tabs iirc
<Lathiat> jay: nah
<Lathiat> jay: it just happens more often when you use tabs
<jay> oh lol
<Lathiat> also if you change font/theme/something it gtriggers it
<cavediver> I use no tabs.
<Lathiat> cavediver: so yeh, dont change fonts, themes, or anything, dont use tabs (only on the window you use irssi with) and uh, pray to the gods
<jay> lol
<cavediver> Lathiat: well.. maybe in 2.14 it will be fixed :)
<jay> you could use another terminal like aterm or xterm
<cavediver> I like gnome-terminal in fact, even though it is a total memory eating application
<cavediver> Although it uses much less resources in 2.12
<Lathiat> anyway this is a little offtopic now
<\sh> we are in serious trouble  ;)
<Lathiat> \sh: ?
<cavediver> Yeah sorry. Thanks for your answer anyway.
<cavediver> bye
<stockholm> elmo: ping
<\sh> ok...I just checked some xterm/rxvt/aterm (will be checked now)
<Lathiat> checking them for what?
<\sh> any of these terminals are honoring the `-T "Title"` cli switch
<\sh> anymore...cause something is causing it to override 
<ogra> whhe, \sh thats really release critical
<\sh> with $PROMPT_COMMAND
<\sh> ogra: it's not the default...and shouldn't happen.
<\sh> and I don't know what the cause is...export PROMPT_COMMAND="" doesn't help
<ogra> but serious trouble is something else :)
<\sh> and actually it will override as well the `-n "icon title"`
<\sh> ogra: well I have to fix those bugs and I don't really know where to search
<Lathiat> \sh: bash will be updating it
<Lathiat> \sh: note that it will change as you change directory etc
<\sh> Lathiat: but only via PROMPT_COMMAND
<\sh> Lathiat: and PROMPT_COMMAND is disabled, actually empty
<Lathiat> \sh: sure, but since its in /etc/bashrc, it still has it when you launch the xterm
<Lathiat>  /etc/bash.bashrc
<\sh> Lathiat: running xterm from cli and exporting prompt_command before that has higher prio then /etc/bashrc
<Lathiat> \sh: uh... why?
<Lathiat> \sh: when you run bash inside the xterm it will read /etc/bashrc
<\sh> Lathiat: /etc/bash* are only defaults when ~/.bashrc is not there
<Lathiat> \sh: which will overwrite the environment it inherited from the parent terminal
<Lathiat> \sh: its in .bashrc too, i assume from /etc/skel
<\sh> Lathiat: xterm +ls == no login shell
<\sh> .bashrc / /etc/bashrc should be read when it's loginshell right?
<\sh> Lathiat: in the early days this was the default
<Lathiat> \sh: it should read both afaik (tho its /etc/bash.bashrc), unless it is a login shell (not not a login shell)
<\sh> Lathiat: but it shouldn't read it when I start it with +ls , which means, accordingly to man xterm, no login shell
<Lathiat> \sh: a login shell means its a "new login" shell, e.g. when you open from minicom
<Lathiat> \sh: and that woudl be -ls, +ls means not to
<Lathiat> \sh: iirc login shells read /etc/bash_profile, .bash_profile
<\sh> Lathiat: yes...and "no login shell" should not read them, right?
<Lathiat>  /etc/profile rather
<Lathiat> \sh: /etc/profile sources /etc/bash.bashrc
<Lathiat> \sh: so no, it shouldn't, but yes, because its done explicitly
<Lathiat> yes, in our case
<\sh> no wonder
<\sh> bangshishead
<Lathiat> :)
<\sh> this is a complete wrong behaviour
<Lathiat> \sh: whats wrong?
<\sh> how can I fix this without annoying some people
<Lathiat> \sh: fix "what" exacly
<Lathiat> \sh: the fact you cant set the title ?
<\sh> Lathiat: it shouldn't do that...when the user tells xterm to use -T "his title" it should be "his title" and not our stuff
* Lathiat nods
<Lathiat> its a bit tricky
<\sh> Lathiat: but more difficult is this: even the "-n" switch is just like this...so -T + -n == wrong (-n == icon name ==> gets the -T title which is $PROMPT_COMMAND)
<\sh> and it's the bloody default bash.bashrc
<Lathiat> how does that one work
<\sh> Lathiat: -n "b0rkness" should show you in the icon bar the icon title "b0rkness"
<mpt> sivang: pong
<\sh> Lathiat: but setting PROMPT_COMMAND will override this setting as well, the same as with -T
<Lathiat> hrm
<\sh> Lathiat: I just removed the PROMPT_COMMAND setting in my .bashrc and in the global bash.bashrc
<Lathiat> -T works fine then
<Lathiat> \sh: where do you get the list of available icon names
<\sh> Lathiat: no not icon name it's an icon title...you see in gnome the "icon bar" ...there is left the icon and next to the icon is the title of the window...so -n set this title explicitly
<Lathiat> \sh: ohhh, i see
<Lathiat> window title vs windowbar title
<mvo> does anyone of you have a runing hoary at hand?
<Lathiat> mvo: i do
<Lathiat> mvo: gui or !gui ?
<mvo> Lathiat: does the hoary version of synaptic already has "File/History" ?
<Lathiat> hang a sec
<siretart> Diziet: around?
<\sh> Lathiat: I have a workaround
<Lathiat> \sh: which is?
<\sh> Lathiat: case in /etc/profile...asking for xterm*|rxvt*) and then for "if [ $COLORTERM == "gnome-terminal" ] ; then # set PROMPT_COMMAND fi 
<\sh> Lathiat: if it's not gnome-terminal then don't do anything...and remove the xterm case from bash.bashrc
<\sh> Lathiat: just tested
<Lathiat> \sh: well, thats arguable
<\sh> Lathiat: it's a better solution for users using xterm as in old times ;)
<Lathiat> sure, but it breaks people wanting titles now
<Lathiat> (like i said, arguable ;)
<Lathiat> mvo: yes
<Lathiat> mvo: there is a file->history
<mvo> Lathiat: thanks!
<\sh> Lathiat: doesn't work :(
<Lathiat> \sh: what doesn't?
<\sh> Lathiat: moment...ah that's why...
<\sh> Lathiat: sorry..it works :)
<\sh> Lathiat: there must be a solution to choose
<\sh> Lathiat: and the solution is to set it in .bashrc for the user 
<\sh> and leave the global stuff without the PROMPT_COMMAND
<Lathiat> i like that solution
<Lathiat> leave it out of /etc/bash.bashrc, leave in /etc/skel
<Lathiat> its not a complete solution however
<\sh> Lathiat: it's better then to have the global stuff
<cogumbreiro> lo all
<\sh> doko: ping
<doko> \sh: pong
<\sh> doko: bash.bashrc and PROMPT_COMMAND will override everytime -T / -n switches from xterm 
<\sh> doko: can we remove this, and put it only in /etc/skel/.bashrc for the user...
<\sh> (where xterm== *term) 
<doko> \sh: what kind of difference does it make?
<ogra> \sh, that does only work for new installs then
<\sh> doko: the user can choose if he wants this override or not...
<ogra> \sh, existing installs will be missing PROMPT_COMMAND completely
<\sh> doko: if he removes the PROMPT_COMMAND in .bashrc, it will always come up with bash.bashrc
<ogra> at least for th eexisting users
<\sh> ogra: ?? it's right now the default in global and userbased
<ogra> oh its in both ?
<\sh> ogra: yes
<\sh> ogra: and this is what annoyes some people
<\sh> http://bugzilla.ubuntu.com/show_bug.cgi?id=15122 e.g.
<doko> I don't mind
<doko> it was requested in the past
<\sh> doko: it's just that it's a wrong behaviour...users cli switch should have higher prio then global PROMPT_COMMAND...but right now it's not the case
* mvo goes to bed now
<dholbach> good night, mvo
<mvo> good night dholbach 
<\sh> lamont-away / infinity: can u please check what's up with gfcui (upload 2005-09-15) buildd status: not-for-us..but it's in universe, thx
<cogumbreiro> might I ask one question regarding Serpentine and its integration with GNOME?
<dholbach> fire away
<cogumbreiro> regarding this bug: http://bugzilla.ubuntu.com/show_bug.cgi?id=14137
<dholbach> cogumbreiro: could the upstream nautilus-cd-burner guys bring some light into this issue?
<cogumbreiro> yeah, I think so, I'm going to mail them then
<dholbach> super, thank you
<cogumbreiro> dholbach: so, should i wait for a release after their reply?
<dholbach> you could try to catch them on irc
<cogumbreiro> i will
<Lathiat> hrmm, hwdb.ubuntu.com is connection refusing on the webserver
<hunger> hehe... just managed to get those two strange keys on my thinkpad to work properly:-)
<hunger> Could those "back" and "forward" keys get enabled by default in X?
<vrln> are there daily breezy snapshots available?
<Mithrandir> vrln: cd images?  Yes, look at cdimage.ubuntu.com/daily/
<vrln> I'm thinking about installing the preview, but I guess RC1 should be out soonish, so I'm not really sure
<Lathiat> vrln: yes, although the preview is probably a better idea
<vrln> Mithrandir: exactly - thank you :)
<ogra> Lathiat, ?? works fine here
<Lathiat> ogra: eh its fixed now
<Lathiat> ogra: i noticed cus your buildlogs page was using the show thing
<vrln> Lathiat: since ubuntu is in feature freeze, I'd imagine the daily images to be more stable than the preview :)
<vrln> that said, the preview livecd works perfectly here
<Lathiat> vrln: well they probably work :)
<Mithrandir> vrln: both should work quite well. :-)
<vrln> Mithrandir: yeah - I'm downloading the daily snapshot right now, thanks again - switching from gentoo :)
<\sh> Mithrandir: can u apt-get build-dep partimage? :) thx :)
<vrln> now if only e17 would be accepted as a backport, then everything would be perfect (tm) (and sorry for the off-topic talk, I know this is supposed to be a devel channel)
<Mithrandir> \sh: you're insane.  (running)
<\sh> Mithrandir: it's bug day :)
<Mithrandir> \sh: seriously, you're going to waste a few days on it, but feel free, stuff's installed
<\sh> Mithrandir: as I said...I have to pay my depts in some beer at ubz
<\sh> Mithrandir: thx :) 
<Mithrandir> \sh: if you fix partimage to work correctly at ubz, I think I owe you beers.
<\sh> Mithrandir: hmmm...u can test it?
<Mithrandir> \sh: well, if you get it to run first, sure.
<Mithrandir> \sh: it's used for our livecd builds to make rsyncable images, iirc.
<\sh> Mithrandir: can I run it via fakeroot? ,-)
<Mithrandir> \sh: that should work, yes.
<\sh> Mithrandir: nice...so I could see the result on ravel
#ubuntu-devel 2005-09-22
<cogumbreiro> ok, the bug is filled: http://bugzilla.gnome.org/show_bug.cgi?id=316527
<cogumbreiro> so, for the time being I can use nautilus-cd-burner key, what do you guys think?
<cogumbreiro> i'll take that as a yes :)
<ogra> mdz / Kamion, for the liveCD you should set the boolean gconf key /apps/gnome-screensaver/lock to false in the default settings ;)
<mdz> ogra:     gconftool-2 -t bool -s /apps/gnome-screensaver/lock false
<mdz> ?
<ogra> sounds ok
<dholbach> good night everybody
<ogra> night dholbach 
<cogumbreiro> gnight dholbach
<Lathiat> jbailey: about?
<jbailey> Lathiat: Just back.
<Lathiat> jbailey: ah nevermind, was looking at https://launchpad.net/malone/bugs/1805, turns out its a bug in the package
<jbailey> Lathiat: Cool, so I don't need to worry about it being a subtle glibc thing?
<Lathiat> jb	yep
<Lathiat> jbailey: they use LD_PRELOAD stuff, and __libc_connect is supposed to be the real connect, its been fixed upstream in debian
<\sh> Mithrandir: partimage is bah
<jbailey> Ah.
<jbailey> "Play thou not with the internals of glibc" type of thing. =)
<Lathiat> :)
<lamont> \sh: all the n-f-u's are from the c++ transition... do we know that all of it's dependant libs are built?
<\sh> lamont: all the what? 
<lamont> not-for-us
<lamont> \sh: gfcui in this case.
<\sh> lamont: oh....gfccore is build long ago...
<\sh> lamont: wasn't even on the http://cerberus.0c3.net/~adconrad/frozenapps.txt
<lamont> \sh: dealt with, although it'll take it a bit before it builds
<\sh> lamont: np
<lamont> it'll realize that it needs to build it in about 30 minutes...
<\sh> lamont: I think it is not so important...but I was missing it in the buildlogs ;)
<\sh> lamont: thx :)
<\sh> lamont: do u have another list of apps which are "n-f-u"s ? I can only see these one from infinitys list
<lamont> I'd just grep the file...
<\sh> lamont: ok...
<lamont>  /dbbalancer_1: Not-For-Us [:] 
<lamont> universe/libs/gfcui_2.3.1-2build1: Not-For-Us [optional:out-of-date] 
<lamont> universe/math/oleo_1.99.16-7build1: Not-For-Us [optional:out-of-date] 
<lamont> universe/devel/gql_1: Not-For-Us [optional:] 
<lamont> on i386
<lamont> well, modulo gfcui
<\sh> lamont: ok...gql will be morgued
<\sh> and oleo...well...I'll have to fix it, or morgue it ;)
<jbailey> morgue it. =)
<jbailey> =)
<\sh> hihi
<jbailey> \sh: Dude, I used to be the Oleo maintainer. =)
<\sh> I transitioned the lib the day before yesterday ;)
<\sh> jbailey: so u morgue it ;
<lamont> jbailey: I need klibc love
<jbailey> lamont: Yes.
<jbailey> gimme a sec.
<\sh> jbailey: ok...I'll put it on the list
<\sh> lamont: modula oleo ;)
<\sh> modulo even
<jbailey> \sh: I mean, unless you think there's a serious population using a text-mode only spreadsheet. =)
<jbailey> \sh: The X interface was horrible.
<jbailey> We hacked together a GTK interface and it was so ugly, Miguel went off and wrote Gnumeric.
<jbailey> They had talked about adding a text controller to gnumeric at one point, and we realised that noone cared. =)
<\sh> jbailey: I don't even know that oleo exist ;) as I mentioned last time I don't know 90% of the software I touched...
<\sh> jbailey: but if u say it's obsolete...then it's obsolete and will be burried :)
<jbailey> \sh: Well, lemme take a look at the changelog, I guess.
<jbailey> It was obsolete 5 years ago, I can't imagine that it's less so now.
<\sh> jbailey: if there is a new release please let me know...
<\sh> jbailey: it's ftbfsing 
<jbailey> 797945 Mar 10  2001 oleo-1.99.16.tar.gz
<jbailey> Roundfile it, dude. =)
<\sh> k
<jbailey> I do have to say that I have a soft spot in my heart for oleo.
<jbailey> If *only* because there's nothing like:
<jbailey> 1) Cleaning up after Tom Lord
<jbailey> 2) Working on a spreadsheet
<jbailey> To teach you *more* than you ever wanted to know about C and pointers.
<bddebian> moi? :-)
<jbailey> bddebian: No, dear. =)
<bddebian> Yeah, I know it all already ;-)
<jbailey> Excellent.
<\sh> jbailey: thx...but I learned enough about pointers in C when I coded bloody win32
<jbailey> I'm sure the FSF would love another Oleo maintainer. =)
<jbailey> \sh: I tried coding in win32 C too early.  The event loop confused me, and the documentation sucked.
<jbailey> \sh: In hindsight I get it know, but event driven programming drove me nuts. =)
<jbailey> I couldn't figure out how to register time based events and I didn't know threads, so I kept adding a function at the beginning of my events to do processing.
<jbailey> If you wanted it to do anything you had to hit a key or move your mouse occasionally. =)
<maswan> jbailey: heh. I think I've seen expensive software with similar "features"
<maswan> released software anyway
<\sh> jbailey: hehe...well I was completly confused when I received the MS C/c++ with the MFC (1.0 at this time)...and I switched back to plain C win32
* lamont sighs, wishes mdz had said he was uploading a new lrm
<mdz> it was an impulse
<mdz> why?
<lamont> mdz: because the build-deps are b0rked for all of the SCC architectures...
<lamont> and I was just doing my final pre-upload testing.
<lamont> well, s/b0rked/missing completely/
<mdz> should be a trivial merge; nothing changed in debian/ but the minors
<lamont> mdz: mind if I fix it?
<lamont> ah, coolness.
<lamont> and my change is just changelog and control*
<lamont> (and that just the Build-Dep line)
<mdz> lamont: fine with me
<\sh> mdz: thx for the bugs :)
<tseng> \sh: want some more?
<mdz> \sh: I think Mr. Stomp wanted the new version so he would have a reason to file some bugs ;-)
<tseng> *g*
<\sh> mdz: the first one is easy ;) audiocds only with ioslaves ;) so he needs some part of kde ;-)
<bddebian> Audioslave?  Not bad, I like Chris Cornel
<tseng> bddebian: i liked him 10 years ago.
<bddebian> Yeah, I don't like Audioslave near as much as Soundgarden
<tseng> anyway, yay for rrdtool update
<\sh> argl...amarok is kde...so u need some parts of kde...at least kdelibs and base ,-) i should amarok depend on kdebase ,-)
<\sh> mdz: ok with u to fix at least khelpcenter bug?
<lamont> well. that was fun
<mdz> \sh: sure; it's harmless enough
<\sh> mdz: regarding the mem leak...yes it's there (was there also with 1.2.4 ;) and I think it's something in gstreamer-mad cause playing audiocds doesn't increase my mem consumption)
<lamont> mdz: I also took the liberty of making linux-restricted-modules-2.6.12-8-sparc* be arch: sparc. :-)
<\sh> tseng: I have enough to work on ;)
<\sh> good night gentlemen...enough fun for today
<ogra> night \sh 
<\sh> cu ogra
* lamont wonders why firefox bitches about XML parsing errors
<sladen> ogra: the ubuntu splash has the reflection blurred which makes it look more like a refection
<ogra> sladen, i'll try to get this in the edubuntu splash...
<ogra> thanks for the suggestion :)
<sladen> ogra: another thing.  see the two dots on the left hand side about 2 pixels away from each othere.  There's no way the reflection dot should be brighter and sharper than the original above it :)
<ogra> ok, will fix that tomorrow :)
<sladen> ogra: and the reflection needs to go 1 pixel to the left ;-)
<ogra> thanks :)
<jbailey> ogra: If you're touching it up,
<sladen> ogra: if you have the pre-dithered one, I can try fixing those for you
<jbailey> ogra: The bottom of the 'ed' letters isn't faded the same as the others.
<lamont> removing mozilla-firefox fixed things... /me wonders if that's been captured anywhere....
<jbailey> But hey, you saw my skills, so don't worry about what I say. =)
* lamont tries to remember who to bitch at when PCMCIA cards arent' detected.
<jbailey> lamont: Define 'detected'?
<jbailey> lamont: Is it showing up in /sys at all?
<lamont> I plug it in, no files created in /dev
<ogra> sladen, i didnt keep the pre dithered one... i'll do a new one on ethe weekend, that was only a first try to mimic the ubuntu one... the colors arent right either...
<ogra> (the reflection needs to be a lot darker too)
<lamont> jbailey: here's a giggle:
<lamont> root@rover3:/sys/bus/pcmcia/devices/1.0# grep . *
<lamont> grep: card_id: No such device
<lamont> grep: func_id: No such device
<lamont> function:0x00
<lamont> grep: manf_id: No such device
<lamont> grep: prod_id1: No such device
<lamont> grep: prod_id2: No such device
<lamont> grep: prod_id3: No such device
<lamont> grep: prod_id4: No such device
<jdub> GOOD MORNING FREEDOM LOVERS!
<magnon> morning, jeff
<ogra> good night jdub :)
<magnon> also good night :P
<magnon> you guys will have to keep me away from all the cheap beer in montreal
<ogra> heh
* magnon has had money for the first time in long and is somewhat hammered
<ogra> magnon, congrats
<magnon> thanks.
<magnon> it doesnt feel good atm. :P
<ogra> magnon, get some sleep :)
<magnon> omw
<ogra> )
<magnon> just had some.. issues to fix
<bddebian> Good morning jdub 
<jbailey> magnon: Almost all the beer is cheap in Montral.
<jbailey> It's sold in corner stores here.
<magnon> jbailey: the norwegian definition of "cheap" is useless in Canada
<jbailey> magnon: True.  An expensive ring here might buy you a bag of chips.
<magnon> where the hell did you get that bag of chips you keep mentioning?
<jbailey> 7-11 =)
<magnon> who ever buys chips at 7-11 :P
<magnon> we have Bunnpris
<magnon> tiny, cramped stores who are allowed to be open on sundays
<jbailey> It was close to the school where debconf3 was hosted.
<magnon> oh, at the subway station?
<jbailey> I guess.
<magnon> there's a Bunnpris 100m from it :p
<jbailey> It wasn't underground.  Is it still a subway?
<magnon> yes, it ends up underground at a point :p
<jbailey> 'k.  Mostly making sure we're talking about the same thing.
<magnon> hehe
<magnon> bunnpris have normal grocery prices and are open like 8-23 every day
<magnon> that means only 25 kr for a beer if youre there before 20.00, and 69 for a packet of cigs
<magnon> in comparison 7-11 in denmark sells 6 beer for about 50 kr 24/7 :P
<magnon> time to sleep off some more-expensive-than-gold beer
<magnon> goodnight!
<sladen> who has leet magic powers on Bugzilla to view http://bugzilla.ubuntu.com/show_bug.cgi?id=7263 ?
<bddebian> Not me
<ogra> sladen, wow, thats intresting... i even have editusers privileges but cant view it... probably mdz can, else its something to poke kiko with
<mdz> weird, not sure how that happened
<mdz> it's unrestricted now
<bddebian> OK, who knows about .desktop files darnit?
<bmonty_laptop> bddebian: there is a wiki page on desktop files
<bddebian> Do you know where?
<bmonty_laptop> https://wiki.ubuntu.com/UniversePackageWithoutDesktopFile
<bmonty_laptop> there are examples linked off that page
<bddebian> gnomeappdir is what I'm looking for, I just don't know if I should fix the Makefile or copy it as you say in debian/rules
<bddebian> bmonty_laptop: Uhm, that page is worthless :-)
<sladen> on that subject, what's the procedure for getting edit-powers back, I've just found I can't retitle this bug
<sladen> mdz: ta
<mdz> sladen: HelpingWithBugs
<bddebian> mdz: You know .desktop stuff?
<mdz> a bit
<bddebian> It's a simple problem.  gnucash is putting the desktop file in the wrong place.  Do I patch the Makefile(s) or just copy the file in debian/rules?
<mdz> since it's not specific to the packaging, and should be installed in the standard place regardless of how it's installed, I'd patch it
<bddebian> Ack, I hate patching config and/or makefiles :-)
<bddebian> Thx though
<mdz> sladen: just let me know that you've read it so that we're all working from the same assumptions, and I'll set editbugs
<Lathiat> http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/v/vpnc/0.3.3-0ubuntu1/vpnc_0.3.3-0ubuntu1_20050917-0138-ia64-failed.gz
<Lathiat> WARNING: The following packages cannot be authenticated!
<Lathiat> etc 
<sladen> mdz: https://wiki.ubuntu.com/HelpingWithBugs could do with some guidance on the priority field---I've still failed to work out whether P1 or P5 is more important (*blushes*)
<sladen> mdz: yes, read it and the several other linked pages (and the GNOME triage hints at the moment :)
<phlaegel> lamont-away: those firefox xml errors can come from installing an updated package without restarting the browser
<ugo> hi guys....i seem to be having a problem compiling open afs on hoary
<crimsun> ugo: -> #ubuntu
<ugo> aargh....the real men are here....!
<ugo> :-)
<ugo> ok...
<fabbione> mdz: thanks for fixing madwifi
<lamont-away> phlaegel: I could have sworn I killed all of the old browser instances off
<jdub> holy crap
<jdub> trilug have over 100 comments on their petition blog now
<whiprush> we have 17.
<zack> sweet, vpnc got updated - now it works with network-manager-vpnc. thanks, \sh_away
<crimsun> jdub: damned straight
<jdub> crimsun: interesting discussion about agnosticism on the mailing list
<crimsun> jdub: heh, when we actually do discuss Linux-related stuff, it's a miracle ;)
* jdub has not yet been to another LUG that really competed with SLUG for radness, but trilug looks like it might. :-)
<crimsun> yeah, we're just zany
<jdub> /dev/md1      ext3    187G   56G  122G  32% /
<jdub> /dev/md0      ext3     23M  8.3M   14M  39% /boot
<jdub> yay
<jdub> server's back
<jdub> back again
<jdub> server's back
<jdub> tell a friend
<fabbione> jdub: tsk.. you forgot lvm on top :)
<jdub> i dodged the bullet for now ;)
<fabbione> chicken :P
<mdz> fabbione: I'm not sure how it happened; 'make clean' works in that dir
<mdz> sladen: in general, it's appropriate to leave priority alone, for the assignee and me to use
<mdz> sladen: anyway, you have editbugs now
<fabbione> mdz: no idea either..
* fabbione just got the new workstation spare parts!
<fabbione> AMD64!
* fabbione goes to mount his new playtoy
<[Chameleon] > Is Malone for Breezy bugs?
<[Chameleon] > I'm not clear on its purpose compared to bugzilla.ubuntu.com
<Mithrandir> [Chameleon] : it's for universe bugs.  Bugs for main still goes to bugzilla
<[Chameleon] > OK, thanks.
<[Chameleon] > that should be indicated on the Participate page in the QA section.
<[Chameleon] > http://www.ubuntu.com/community/participate
<Treenaks> Any udev-people awake here?
<[Chameleon] > I'm awake
<[Chameleon] > though not a udev person
<[Chameleon] > I know a tiny bit about it, but I'm not a developer of it.
<Treenaks> well, it breaks my system :)
<Treenaks> I think it tries to enable DMA or something on one of my IDE drives (the one which does not support DMA.. it's a CF card)
<Treenaks> because it doesn't try once
<Treenaks> it tries 100s of times
<Treenaks> until other parts of the system start to suffer (another IDE bus starts getting timeouts because the kernel can't keep up)
<[Chameleon] > bummer
<Treenaks> yeah.. it should try once (or not at all) and leave it
<Treenaks> had to sit in a datacentre for 1.5 hours before I figured this out though :(
<[Chameleon] > file a bug in bugzilla please.
<Treenaks> and I still don't know the exact bug
<Treenaks> that's the problem
<[Chameleon] > hmm
<Treenaks> (and I can't really test, the machine serves websites + mail for a few friends)
<Treenaks> but I'll try :)
<Treenaks> (I have logs)
<pef> hello
<Treenaks> #15640 ! :)
<dholbach> good morning
<bob2> udev tries to enable dma?
<bob2> that sounds odd
<Treenaks> bob2: it tries to do _something_ with my /dev/hda
<Treenaks> bob2: but it fails, retries, fails, retries, until it takes the rest of the system with it
<stratus> mdz: thank you for fixing that linux-restricted-modules. is there something like incoming.d.o into ubuntu ? i want to test the new package asap and i see it reach the breezy-changes ML.
<bob2> things hit the archive within about 30-odd minutes of being uploaded
<stratus> 30 minutes? wow
<stratus> btw, thanks bob2
<pitti> Hi
<dholbach> morning pitti
<sivang> moning pitti 
<sivang> dholbach: 
<\sh> infinity: u awake? I have a patch for ace, if you want to test it
<\sh> mdz: I think suggests is better for khelpcenter, then recommends, cause it has nothing to do with the functionality. (#15613)
<[Chameleon] > sivang, pitti: I finally got around to writing up that other g-c-m bug.
<[Chameleon] > https://bugzilla.ubuntu.com/show_bug.cgi?id=15646
<sivang> [Chameleon] : I think pitti already fixed that, have you tried a latest upgrade of breezy?
<sivang> [Chameleon] : (it works for me now)
<[Chameleon] > sivang: 1 sec
<[Chameleon] > well, I'll be a monkey.
<[Chameleon] > he sure did.
<[Chameleon] > I'll close it.
<[Chameleon] > fastest. bugfix. evar.
<[Chameleon] > good thing I wear egg on my face well.
<sivang> hehe
<sivang> [Chameleon] : it appears that cupsys was mangeling the conffile's permissions, and now it dont' 
<[Chameleon] > yep
<[Chameleon] > I recall that
<[Chameleon] > sivang: heh, your Ubuntu Membership is not complete.
<sivang> [Chameleon] : what do you mean?
<[Chameleon] > https://wiki.ubuntu.com//UbuntuMembers
<sivang> [Chameleon] : maybe because i haven't uploaded a GPG key yet ;-)
<Treenaks> sivang: do that then ;)
<[Chameleon] > :>
<sivang> Treenaks: yes, planning to, then I would get my u.c email finally 
<jdub> BenC, fabbione: ping
<fabbione> jdub: pong?
<jdub> fabbione: hey, have you tried the latest kernel?
<fabbione> jdub: installing it right now on my new shiny amd64
<jdub> i just rebooted to find that /dev/input didn't exist, my ipw2200 firmware wouldn't load, and a bunch of other mess
<jdub> no soundcards found
<fabbione> no idea
<fabbione> i didn't really upgrade any of the machines yet
<fabbione> it's only installing on the new one
<fabbione> i will give it a try tomorrow
<jdub> ok
<fabbione> on i386
<crimsun> jdub: which, 2.6.12-8.13?
<fabbione> right now i don't have (yet) spare boxes to play
<jdub> crimsun: yeah
<crimsun> seems to work fine on i686
<jdub> that's what i'm running ;)
<fabbione> jdub: what arch?
<fabbione> ok
<jdub> ipw2200 looks like it's trying to load the wrong file
<jdub> (doesn't include the uname -r bit in it)
<fabbione> jdub: that's hotplug...
<dholbach> 2.6.12-8.13 runs nicely on my amd64
<fabbione> ipw2200 only asks hotplug for a file
<fabbione> passing a filename
<fabbione> it's hotplug that does the uname -r magic
<jdub> hrm
<jdub> so dmesg said it can't load the firmwar
<fabbione> jdub: check with hotplug
<fabbione> you can enable debugging in the script
<fabbione> and see what is called/why/and what is missing
<fabbione> and with this
<crimsun> jdub: cat /sys/class/firmware/timeout
* fabbione -> off
<jdub> i'm going to try again with a fresh mkinitramfs too
<jdub> crimsun: 10
<crimsun> jdub: please echo 100 to it and reload ipw2200
<jdub> ok, but rebooting atm
<jdub> (usplash is teh rawk)
<jdub> aha!
<jdub> new initramfs appeared to fix the lack of /dev/input
<jdub> and everything else
<jdub> hmm~
<jdub> hmm!
<jdub> jbailey: ping
<ugo> the most recent openafs fails to compile with gcc-3.4
<rob^> hey whats the current status of getting a graphical installer in ubuntu?
<dholbach> i'll do some shopping
<dholbach> be back later
<jdub> rob^: the only likelihood of something like that appearing will be UbuntuExpress (install from livecd)
<crimsun> ugo: 1.3.82-1?
<rob^> jdub, do you mind if I have a play with PGI and see what it can do?
<jdub> why would i mind? :)
<rob^> hehe ok
<torkel> ugo: I filed a bug about it a while ago, and also asked ogra to request a sync of 1.4rc from unstable
<jdub> rob^: keep in mind though, it's not something we'd be interested in
<rob^> so we don't want a graphical installer at all, or we only want a live cd?
<torkel> ugo: https://launchpad.net/malone/bugs/2157
<rob^> (from which to install from)
<jdub> there's not a lot of interest in doing the graphical installer on d-i work
<jdub> and not a lot of interest in using something other than d-i for the basic installer
<jdub> it's quick and mostly painless, so not really worth the effort
<jdub> however
<rob^> it might be nice at least for the partitioning phase
<jdub> UbuntuExpress gives us a great opportunity to do a really good graphical installer, far beyond what current basic graphical installers can do
<jdub> (because when you have the whole desktop available to you... lots of interesting things can happen)
<torkel> ugo: upstream has released 1.4rc4, with some critical fixes, hopefully it will hit Debian unstable soon, and then I will start poking MOTUs again :-)
<rob^> so the plan is to only have one cd that does both live and install then?
<jdub> rob^: 
<jdub> rob^: for mass distribution, yeah
<jdub> rob^: but we'll have an install cd too, particularly for the server use case (and possibly even dedicated to that use case)
<rob^> ok, makes sense, saves money too
<rob^> and for that it only needs to be text based
<jdub> aye
<rob^> I might check out UbuntuExpress then :)
<jdub> :-)
<rob^> whats the current target release for UbuntuExpress?
<rob^> Breezy?
<jdub> no
<jdub> hopefully dapper
<jdub> didn't make it for breezy
<rob^> ah I see its been deferred
<jdub> (though its absence in breezy may make it less likely for dapper...)
* jdub boggles
<jdub> somehow my laptop thinks my work maildir is 2.1T
<sladen> crimsun/jdub: I've seen the ipw2200 firmware timeout several times too
<ugo> thanks torkel...
<\sh> woot? do i read #15299 correctly, that sky2 is sk98lin driver for marvell yukon2 included in 2.6.12-8.14?
<ugo> before i leave though...how do i send these red highlighted messages to ppl
<ugo> thanks crismun also...
<rob^> just use thier name
<rob^> their *
<\sh> BenC: if this is correct...u rock man :)
<vrln> (slightly off topic) this is not strictly a development related question, but it is at least a technical one: what does the default ubuntu initrd in Breezy contain? I am wondering if it's used for USplash or the filesystems
<ugo> torkel: hey from your bug report you mentioned ure running 1.4RC1
<ugo> torkel: is this on ubuntu using debian's packages...and can i replicate this...? just an overview will suffice im sure i can hack it out myself given that
<tseng> mdz: can you please add me to ubuntu members lp group
<terrex> the new wine packages at breezy are the same that can be found at winehq.com?
<mdke> is there a gui that controls bluetooth devices?
* sivang hopes there's going to be a key signing party in UBZ
<Robot101> jdub: how do I make "awesome desktop-integrated IM and VOIP" a goal for dapper? :)
<sivang> tseng: I'm also having troulbe with my membership - but I havn't uploaded a key yet.
<sivang> does anybody know why apt-listchanges gives nothing when invoked on a .deb ?
<jdub> Robot101: we'll have to write a spec :-)
<sivang> Robot101: \sh is also itnerested in this, you might want to talk to him as well
<\sh> Robot101: this is already planned :)
<\sh> Robot101: http://linux.blogweb.de/archives/94-Thinking-about-the-future.html
<Robot101> \sh: ipcf.freedesktop.org
<\sh> Robot101: kopete + kaddressbook have something like this..but it's really crap...
<\sh> Robot101: 1. we should concentrate on opensource protocols like xmpp
<\sh> Robot101: 2. all applications on all desktops need to have implementations...
<Robot101> \sh: no, kopete + kaddressbook share presence information
<Robot101> this is sharing the entire IM/VOIP server connection over dbus
<\sh> Robot101: but let us discuss this in #ubuntu-im ;)
<Robot101> I'm about to catch a train, but consider me interested (we're writing this framework anyway)
<\sh> Robot101: I would like to work with you on this spec...this is one of the goals which are not really dapper specific..but we have to start :)
<sivang> \sh: we should start a wiki page about it probably
<Robot101> \sh: the goals are to provide IM/VOIP/presence functionality wherever it makes sense
<Robot101> \sh: by using IPCF in the background to do the SIP/Jabber connections
<Robot101> \sh: then you want to make sure evolution is wired into galago, nautilus lets you send files to people, some other IM app does the chat stuff (gossip if we write it an ipcf backend?)
<\sh> Robot101: removing MSN/ICQ stuff and all propietary things..
<\sh> Robot101: gajim is state of art ;)
<Robot101> not really, no...
<Robot101> you can put whatever crack you want into the connectin managers
<Robot101> a phone app for making calls... it's all about having the appropriate domain-specific UI for the various functionality of IM/VOIP systems
<rob^> can the ubuntu installer resize ntfs partitions or not?
<rob^> it doesn't work for me, but others claim it can
<rob^> (thought I'd get the answer from the horses mouth)
<jdub> rob^: supposedly it works very nicely (though i haven't tried it)
<rob^> how long has it been able to?
* Robot101 has used it
<\sh> Robot101: the idea is, like google talk mentioned it, to add to jabber a sip signalling :)
<Robot101> \sh: yes, we can trivially accomodate that. you're not thinking big enough though
<tseng> Robot101: the network IS the computer!!!
<tseng> erm.
<\sh> Robot101: actually, I want to have all functionality in one app...doesn't matter if you're using single apps for jabber/sip/email or using only one app like evolution to integrate all possibilties...
<Robot101> \sh: no, that's crap. there's a reason all IM applications have completely ass UI, it's because they do a handful of totally disparate things
<sivang> Robot101: so you're suggesting seperating GUI according to funcionality ?
<sivang> rob^: never worked for me also
<rob^> weard
<Robot101> sivang: http://robot101.net/files/tmp/IPCF.png
<Robot101> sivang: you use a phone app to make calls, an IM app to do text, nautilus to send files
<rob^> or weird even
<Robot101> sivang: so yes
<Robot101> sivang: and it doesn't matter what the protocol underneath is, all the presence is reported to galago and referenced with your address book
<Robot101> sivang: we're starting with jabber and SIP
<\sh> Robot101: IM is more then text
<ugo> oh so were calling the next version dapper eh....nice...
<\sh> especially xmpp is more then only text chat...
<Robot101> yes you need a presence app, buddy list or so
<ugo> reminds me of dapper dan from oh brother where art thou
<Robot101> \sh: yes, but the jabber connection manager splits apart the services and makes them available /in the right place/
<\sh> Robot101: how do you want to incorporate xmpp video streaming? another app, or just a jabber client with support for it?
<sivang> Robot101: nice. We achive higher trivial integration, since each app has it's "net blessed" capabilities and you don't have to fire up the IM for instance, in order to be able to send files and vice versa
<Robot101> sivang: right :)
<Robot101> \sh: another app or an existing one, whatever takes your fancy
<Robot101> \sh: when I say "IM app" I mean presence and text messaging. the other functionality is in other places. the connections to eg Jabber/SIP/MSN/IRC/whatever are in dbus services available across your desktop
<Robot101> \sh: Evolution tells you if you can IM or phone or video call someone when they e-mail you
<Robot101> \sh: in nautilus you go right click, Send File To -> Bob, and it will use Jabber or MSN or however bob's available to send files to
<Robot101> anyway I reallly do need to go
<Robot101> more later
* Robot101 runs off
<sivang> Robot101: also, if we have the lib, then every frontend author can use it up to make what he sees fit, and those can all coexist happily. tht would enable us to suit each user preference. I tend to like this.
<\sh> Robot101: think about it like this: there is no need for propietary protocols anymore...so u need to implement at least some type of xmpp client which supports several JEPs and distribute via whatever to the correct apps
<\sh> Robot101: which is an awesome goal :)
<jdub> \sh: the idea is to integrate numerous different presence systems into one coherent interface
<\sh> jdub: which doesn't work even for jabber transports...yahoo/aol/ms are changing there specs when they want, and you have to work after...which isn't good...so use at least one open protocol which is very well documented and has a future
<jdub> \sh: users can use whatever they want
<\sh> jdub: but leave this to the server .. and concentrate on one access method and protocol specification
<jdub> that's not really the poitn
<\sh> on client side...speak presence manager/connection manager
<cogumbreiro> lo all
<jdub> and it certainly doesn't satisfy user requirements (you know, make it actually work)
<\sh> jdub: yes it is...see gaim or kopete when aol changes some things in icq/aim connections...u have to fiddle with a lot of crap 
<jdub> \sh: that's a totally different issue
<\sh> jdub: the presence manager/connection manager has to deal with several propietary protocols then...so something changed for some "really kewl presence and messaging protocol" you have to work on it for every change
<sivang> \sh: how do you really plan to solve this issue? people will continue to use the prop protocols ....and we would still have to stay on front of tracking them to keep stuff not falling
<\sh> sivang: as I said...it's a server issue...which can be solved with xmpp transports
<jdub> \sh: via separately upgradeable plugins. but that really doesn't matter, and is not different from the current situation.
<jdub> it's not a server issue
<jdub> because that doesn't solve the problem for most people
<\sh> jdub: the problem would be solved, when the companies are revealing their secrets 
<jdub> and they're far more likely to be disconnected than every separate user
<jdub> right, so now you're in the realms of fantasy, not problem solving :-)
<sivang> \sh: I don't see this happening too early from now ;)
<\sh> jdub: what are u using most of the time when you are using icq?
<jdub> gaim
<sivang> \sh: I use gaim
<\sh> jdub: text chats, or the network games?
<jdub> ?
<\sh> jdub: I'm talking about integrating those protocols in the software...which is here on client side...and if somethings changed, most of the devs are reengineering the protocols
<\sh> jdub: I know, I'm a bloody xmpp fanatic ;)
<\sh> hmmm...lets see if I can get Peter on board
<ogra> grmpf
<jdub> ogra: nice to see gnome-screensaver in (though it's so late in the cycle!)... but sad to see your stylish lock dialogue antics go ;-)
<ogra> jdub, i dont care about the lock dialog... :) it was clear that its an interim...
<jdub> ;-)
<ogra> ut gnome-screensaver has still lots of issues to solve :/ i.e. i dont like to make the screensaver preselection through packages, but the gconf key they use for a preselection list isnt working yet :/
<jdub> boh
<ogra> so we'll need a xscreensaver-data, xscreensaver-data-extras and a xscreensaver-gl-extras package to make sure only the ones we want to show are installed...
<ogra> thats an ugly solution
<jdub> not a very beautiful delta from debian either
<ogra> worst case i even need to split rss-glx 
<ogra> yup
<ogra> but the preselection feature is still in planning, unlikely it will make it...
<jdub> could do a quick hack with an ini file... :)
<ogra> as well as setting options for single screensavers... the ones wher thats essential are out though (electricsheep for example)
<ogra> we have a gconf key, but thats not respected it seems, i'm just juggling with the schema file
<jbailey> jdub: pong
<jdub> jbailey: yo!
<jdub> jbailey: can you think of an instance in which an initramfs for an older kernel was built during kernel upgrade?
<jdub> s/instance/possible instance/ :-)
<jbailey> jdub: No.  The kernel passes the new release string to mkinitramfs, and it doesn't have any logic to infer it.
<jbailey> So if there's a bug there, I don't see where it could be.
<jbailey> jdub: Starting next week or so, other apps will start regenerating your initramfs for you, but they'll do whichever one is pointed to by your symlink.
<jdub> am i going to russia?
<jdub> other packages will do that in their postinst, or...?
<jdub> was that depmod-every-module thing true, btw?
<jbailey> Right, like usplash
<jdub> roll on triggers!
<jbailey> depmod-every?
<jbailey> Oh, in load modules
<jbailey> Rather.
<jbailey> manual_add_module
<jbailey> Yes, I haven't done timing comparison.  It's certainly excessive. =)
<jdub> heh :-)
<jbailey> atm I'm more worried that Matt has an IDE chipset that doesn't show up in lspci, doesn't have a modalias, doesn't have a specific chipset driver, but appears to still exist.
<bddebian> Morning
<jdub> wow
<jdub> nice one
<jbailey> And so I'm still trying to guess how it ought to be detected.
* jdub should try and sucker through some promise TX4300 support
<jbailey> I *think* that the installer currently just loads ide-generic always, and that the old initrd-tools' rootfs detection went 'Hey! IDE!' and just installed the needed pieces.
<jbailey> Promise?  Is that the IDE Raid controller?
<jbailey> I think the drivers are all in there.
<jbailey> My hatred of the promise driver isn't big enough to cause me to leave it out. =)
<jdub> nah, sata
<jbailey> *sigh*
<jbailey> That means they're growing rather than silently going out of business.
<jdub> the chipset is one click above a chipset added in 2.6.13 ;-)
<jbailey> The promise suckage is that it lets the OS see the underlying drives.
<jdub> oh, i don't dabble with the raid mess
<jbailey> So you get UUID conflicts and whatnot.
<jdub> it's a well supported chipset family for libata though
<jbailey> The solution that I heard about at OLS was that they're slowly teaching Linux about all of the different on-disk formats so that it will treat those like software raid and respect that.
<jbailey> So you then have a bios that can boot software raid.
<jdub> haha
<jdub> rad
<jbailey> Yeah it's cool.
<jdub> sucks when you shift drives or controllers though ;-)
<jbailey> Dude, if you're using hardware raid, the only read answer is DONT DO THAT. =)
<jdub> ha ha
<jdub> "bios taht can boot software raid"
<jdub> :-)
* jdub isn't fond of hardware raid
<jbailey> Mmm, hardware raid should be faster and possibly more redundant.
<jdub> that's right
<jbailey> It also means that you're using the better tested code path in the kernel (Just a standard driver)
<jdub> it's more redundant
<jdub> :-)
<jdub> hw raid is not that much faster
<jdub> besides, if the kernel knows what's going on, it can adapt
<jbailey> Dude, I've spent half my life building large server farms and lights-out rooms =)
<jbailey> redundancy *good*
<jdub> <- has preferred software redundancy in his half life spent in DCs :-)
<jdub> i didn't always have pointy hair :-)
<jbailey> There's just something beautiful about being able to walk up to an HP Proliant, look at the drive with the yellow light, grab the clips, pull it out, put in the new one, and know that it didn't stress your system. =)
<bddebian> Heh
<jdub> these new sun boxes are interesting
<jbailey> 'these'?
<jdub> the latest galaxy series
<jbailey> Ah, I haven't seen them.
<jdub> they're nforce4 ultra based
* jbailey googles.
<jdub> they're all over the sun.com front page
<torkel> ugo: packages for both hoary and breezy are available at: http://www.hpc2n.umu.se/staff/torkel/Ubuntu/ 
<torkel> ugo: I will try to follow and repack the openafs packages in Debian at least until 1.4 is released
<ugo> torkel: its ok i just compiled from source
<torkel> ugo: that works too :-)
<ugo> torkel: however whats a good tool to resize a reiserfs partition 
<ugo> torkel: openafs and reiser apparently dont mix
<sivang> meh, I've trying to cdbs-edit-patch 12_autotools from gnome-panel source package, it failes on patching just before letting me in the temp source tree, anyone idea?
<sivang> s/I've/I'm/
<ogra> jbailey, youre a xinerama user, right ? 
<torkel> ugo: nope you have to use ext2 or ext3. Upstream recommends ext2, but a lot of people seems to be using ext3 without problems
<torkel> ugo: there is a resize_reiserfs in reiserfsprogs
<jbailey> ogra: Not at the moment.
<jbailey> ogra: I swapped my Xinerama setup for a single widescreen monitor.
<ogra> hmmkay
<jbailey> ogra: I could setup Xinerama if I need to sometime later today.
<jbailey> (I need to set that machine back up for other things anyway)
<ogra> jbailey, let me see if i find someone whi doesnt need to set it up first :)
<ogra> who even
<jbailey> Sure. =)
<Robot101> \sh: yes the XMPP client will be the jabber connection manager and distributes via IPCF to whatever is the correct app
<Robot101> \sh: this doesn't commit us to or preclude the existence of eg an MSN or an Oscar or whatever connection manager
<Robot101> \sh: but we're not writing one (at the moment anyway)
<Robot101> \sh: we are writing a SIP one though, so initially we should be compatible with Google Talk :)
<Mithrandir> ogra: I use xinerama, why?
<ogra> Mithrandir, could you test gnome-screensaver ? 
<Robot101> \sh: (and the SIP signalling over Jabber can be exposed to the phone app in the same way that actual SIP signalling is... it doesn't matter from the client author's perspective)
<ogra> Mithrandir, its not complied with xinerama support it seems, i want to know if it work or not
* hunger thinks the start/stop scripts definitly need a bit more work.
<WaterSevenUb> kamion, how r u? did u receive the email about that synaptic language detail?
<hunger> Isen't there any guideline for writing start/stop scripts?!
<hunger> most exit 0 if the binary daemon they are supposed to start is missing. Some log_fail in that case, LSB has a special exit code for that but nobody seems to be using that.
<hunger> Some even claim success independent of whether the service was started or not:-(
<ogra> hunger, you mean like exitcode 6 for missing config etc ? 
<hunger> ogra: IIRC there is a exitcode for missing binary, too.
<ogra> hunger, yup
<ogra> hunger, but nothing uses this output yet...
<ogra> so why bother with adding it ?
<hunger> ogra: Is there any ubuntu document for start/stop scripts? I'd love to file bugs, but I do not know which ones are the offenders.
<hunger> ogra: I don't.
<hunger> ogra: But I do not care for several different behaviours in something as essential as init.d scripts.
<ogra> afaik we have no such guide yet
<hunger> ogra: bind9: exit 1 if named is not there, powernowd: exit 0, ect.
<hunger> ogra: I am sure I saw something exit 106 if the binary was missing....
<hunger> ogra: Everybody seems to be using different syntax to print informational texts (so people even seem to use log_failure for that purpose!).
<hunger> ogra: Powernowd reports "[ ok ] ", even if the daemon failed to come up...
<hunger> ogra: It all is a HUGE mess!
<Treenaks> hunger: isn't it all policy-defined?
<Treenaks> hunger: (i.e. is everyone ignoring policy?)
<Mez> wow.
<hunger> Treenaks: Debian has a policy which does not fit with ubuntu's LSB stuff.
<Mez> 280Mb of upgrades in 5 Days
<Treenaks> hunger: great!
<hunger> Treenaks: I have not yet seen any document for this in ubuntu.
<hunger> Treenaks: From what I can tell each developer uses whatever he sees fit.
<tseng> whats up Mez 
<Mez> tseng the ceiling
<Mez> *&yawns*
<Mez> I got 4 days off work now
<Mez> w00t
<hunger> How can I help fix the init.d mess?
<CarlFK> wget is no longer installed on a server install.  is that expected or should I file a bug report?
<jdub> CarlFK: certainly sounds like something worth reporting :-)
<jdub> morning Znarl 
<CarlFK> roger
<rob^> have the latest security problems for xchat been patched against the xchat in breezy?
<rob^> err, security problem "fixes"
<jdub> CarlFK: so, wget is in ubuntu-standard
<Kano> is here someone how knows dbus/hal?
<jdub> CarlFK: which i'm sure is part of the server install
<jdub> Kano: pitti is a good person to ask when he's around
<jdub> Kano: but ask away, someone may be able to help (and #ubuntu for user side issues)
<Kano> not specific to ubuntu
<Kano> but you use it
<Kano> and i want it 
<Kano> i dont know what is needed to detect usb-storage devices
<jdub> not sure i understand the question
<Kano> well i do kanotix
<Kano> and i try to activate udev+hal after hd install
<Kano> but is is not working
<Kano> maybe it is a simple thing that i am missing
<jdub> Kano: it's not all that simple, getting them working nicely requires a lot of deep system integration work
<Kano> well i want that it works with latest kde
<Kano> it works basically for cd/dvd
<Kano> but not for usb storage devices
<Kano> usb-storage module is not loaded
<jdub> post to the hal and utopia lists
<Mez> fabbione: ping
<Kamion> WaterSevenUb: sorry, but it's my weekend; I probably won't look until Monday
<WaterSevenUb> Kamion, wow.. by any means!:-))) Enjoy it as much as you can :-)) 
* CarlFK sings "It's my weekend and I'll slack if I want to..."
<Kano> bye
<mjg59> jbailey: Any chance of a new initramfs-tools?
<wasabi_> Ahh hah found the EVMS/LVM/MD problem!
<wasabi_> Seems when evms makes md devices it uses dm-* notation someplace somehow...
<wasabi_> And so lvm doesn't consider the real devices as part of a md array, and thus scans them
<jdub> iiiinteresting
<wasabi_> And so LVM tries to add the real devices that are raid 1'd and then comes up with a duplicate uuid error
<wasabi_> eureka!
<wasabi_> Yup. That's the problem. Hmm. Now how to fix that!
<wasabi_> Guess this is LVM's fault. It should be checking for a real MD super block, not just ownership by a MD array.
<thesaltydog> wasabi_, could this have affected also my huge hard-disk loss of performances in breezy?
<wasabi_> no.
<CarlFK> breezy: "E: Package libdvdcss2 has no installation candidate" - should I bug this?
<azeem> CarlFK: which package complains?
<CarlFK> libdvdcss2 
<azeem> eh
<mjr> libdvdcss is legally questionable in some jurisdictions, thus not included
<azeem> why do you want to install it?
<CarlFK> to read DVDs with vobcopy
<CarlFK> libdvdread3 shows Suggested packages: libdvdcss2
<CarlFK> but I can't find a trace of it on http://packages.ubuntu.com
<azeem> well, one can suggest packages which are not part of the archive
<mjr> indeed
<thesaltydog> suggested is not mandatory
<CarlFK> but it was in restricted/uni/multi (i think)
<thesaltydog> I realized I have 2 different screensavers in Gnome->System->Preferences... what's happening? 
<CarlFK> it seems odd to sugest something outside of those
<mjr> CarlFK, IIRC, I installed mine from Marillat
<azeem> CarlFK: anyway, this is #ubuntu stuff
<wasabi_> /usr/share/doc/libdvdread3/examples/install-css.sh
<wasabi_> Run that script. ;)
<CarlFK> azeem - my Q was "should I bug this?" not "help me install"
<wasabi_> Naw, it's known about.
<CarlFK> thats what I was looking for
<wasabi_> decss is legally questionable. So the package may require it, but it's not going to go get it for you.
<CarlFK> I thought that's what restricted was for
<wasabi_> restricted stuff is not legally questionable as far as I can tell.
<wasabi_> It's just not open source.
<azeem> ...
<CarlFK> got it
<jbailey> mjg59: I still need to know why it's working on your system with that test...
<jbailey> mjg59: I don't think it should be.
<jbailey> At that point there's no ide-disk nor ide-generic or anything.
<jbailey> There shouldn't be a device to resume from...
<jbailey> mjg59: Can you try adding a panic in there, make sure the ide bits aren't loaded and do the resume by hand?
<mjg59> jbailey: Well, the obvious thing to do is just to load the IDE driver stuff then...
<jbailey> =(  I hate not knowing which it's working when it shouldn't be
<mjg59> Heh.
<jbailey> s/which/why/
<mjg59> It's possible that it's actually falling through.
<mjg59> Let me have a quick play now, then I need to head out
<jbailey> Oh, and getting hit by the other resume script.
<jbailey> That would make sense.
<mjg59> Which would explain why it resumes, but not why USB works
<mjg59> Oh, fucking yenta-socket
<nathanel> the lesstif package seems to be broken and needs a recompile against current libraries; I already added a comment to #14943, but I'm not sure if I should open a new bug on lesstif directly...
<mdz> tseng: the CC admins that group
<mdz> \sh: I think having no help in the program is enough to justify a recommends, personally.  how much stuff does khelpcenter pull in?
<mjg59> Why would yenta-socket have a use count of 1 when there's no modules depending on it and there's no inserted PCMCIA card?
<Treenaks> mjg59: because it's buggy?
<mjg59> Well, yes
<Treenaks> otherwise, try cardctl eject
<mjg59> I have done. That drops it from 2 to 1.
<mdz> mjg59: stop cardmgr?
<mjg59> mdz: Tried
<mdz> ogra: schoolbell wants to move to universe
<mjg59> jbailey: Weirdly, I can't actually find the machine that I did it on.
<mjg59> jbailey: Would it be possible to just do the "obviously correct" thing and then do an upload? :) It would help to be able to track down which hibernation bugs are down to this and which ones are entirely different
<jbailey> mjg59: 'k
<mjg59> Right.
* mjg59 has to run to the station
<jbailey> mkinitramfs run time dropped from 13 seconds to 6 by dropping the unneeded depmod and not using gzip -9
<mjg59> Cool
<wasabi_> just reboot after dpkg-reconfigure?
<mdz> jbailey: gzip -9 could be a win though
<mdz> if we have to read fewer blocks at boot, that's a recurring savings
<ogra> mdz, thats ok, i only need libschoolbell
<jbailey> mdz: It's 5273286 vs 5249530
<wasabi_> brb
<mdz> so ~30k?
<jbailey> Yeah 'bout that.
<jbailey> It's mostly executables, so it doesn't seem worth it if people are noticing.
<mdz> could be several disk seeks depending on how fragmented things are
<mdz> disk I/O from grub is a lot slower than fancy DMA access when the system is up
<mdz> I have a box here which takes a minute or so just to read the initrd from flash
<jbailey> Ouch.
<jbailey> MODULES=dep should be your friend. =)
<mdz> oddly enough, it doesn't seem significantly worse than it did with initrd
<mdz> subjectively; I haven't timed it
<jbailey> They're about the same size.
<mdz> really?
<jbailey> So if reading it your biggest issue, then it shouldn't be
<jbailey> Yeah.  The initramfs is always gzip'd.
<mdz> but it contains more modules by default
<jbailey> The initrd's were just a cramfs filesystem.
<mdz> yes, which doesn't compress quite as well as a single gzip stream but should be darn clse
<mdz> close
<jbailey> -rw-r--r--   1 root root 5316608 2004-07-26 14:06 initrd.img-2.6.7-1-686
<mdz> it compresses 32k blocks I think
<wasabi_> jbailey, no luck
<wasabi_> /sbin/evms_activate still missing
<mdz> -rw-r--r--  1 root root  6549504 2005-06-29 13:12 initrd.img-2.6.12-3-k7
<mdz> -rw-r--r--  1 root root  5129269 2005-08-27 12:29 initrd.img-2.6.12-7-k7
<jbailey> wasabi_: Did you regenerate the initramfs after you installed the package?
<wasabi_> I dpkg-reconfigured my kernels.
<wasabi_> I assume that was it.
<wasabi_> -rw-r--r--   1 root root 5110403 2005-09-17 11:34 initrd.img-2.6.12-8-k7
<wasabi_> Last changed 6 minutes ago
<wasabi_> So yeah.
<jbailey> wasabi_: Can you check to make sure you have /usr/share/initramfs-tools/hooks/evms ? 
<wasabi_> I do.
<wasabi_> I just popped it open to read it.
<wasabi_> found your prob
<wasabi_> if [ ! -x /sbin/ectivate ] ; then exit 0; fio
<wasabi_> fi
<wasabi_> It's /sbin/evms_activate
* jbailey grumbles
<jbailey> Why did it work when *I* tested it? =)
<mdz> jbailey: MODULES=dep would be clearer as MODULES=minimal or MODULES=detect or such
<wasabi_> Do you have a /sbin/activate? haha
<jbailey> mdz: Yeah, it's inherited from mkinitrd
<jbailey> wasabi_: I wonder.  I'm guessing I must.  My wife has the laptop for her meetings this weekend.
<jbailey> Fixed in my tree, could you try it again? =)
<wasabi_> doing so
<wasabi_> wasabi@kyoto:~$ apt-file search /sbin/activate
<wasabi_> lilo: sbin/activate
<wasabi_> I don't have lilo.
<jbailey> that would do it.  That machine has lilo instlled for testing.
<wasabi_> brb
<mdz> wasabi_: it's "ectivate"
<wasabi_> success.
<wasabi_> usplash and everything
<harrytuttle> hi. is there a complete list of the possible preseed options for the installer?
<Kamion> harrytuttle: no, not really
<Kamion> the source code ;-)
<Kamion> but most of the interesting ones should be in the installer manual
<jbailey> wasabi_: Sweet.  Is the his plan evms, or is this the evms on lvm on md1? =)
<harrytuttle> Kamion: ok thanks
<wasabi_> evms on lvm on md
<jbailey> w00h00
<wasabi_> I'm really confused about how evms handles md though, it's really causing probs
<wasabi_> md1 : active raid1 dm-9[2]  sdc2[1] 
<wasabi_>       48837504 blocks [2/1]  [_U] 
<wasabi_> See, it added dm-9 just now.
<wasabi_> WHich is really sdb1
<wasabi_> So now lvm won't think sdb1 is used by md, and will see the duplicate uuid
<wasabi_> It seems like rebooting fixes it though.
<wasabi_> I suspect it's because md redetects itself instead of being activated by evms
<wasabi_> and md scans the real device nodes to do so
<wasabi_> You know what rocks though, after the reboot into a new kernel....
<wasabi_> my devices renumbered themselves.
<wasabi_> probably some random udev or kernel change or something.
<wasabi_> But everything still worked.
<wasabi_> sdb used ot be sda and sdc used to be sdb
<jbailey> The new udev (afer UVF, not for breezy) will do /dev/by-name and /dev/by-uuid as well.
<jbailey> So hopefully we'll never have to think about what partition, etc it thinks everything is on anymore.
<wasabi_> We don't right now with evms
<wasabi_> evms uses uuids and stuff to mark every device.
<wasabi_> So they are all scanned and mapped to virtual node names.
<jbailey> True.  I have to admit evms still kinda scares me. =)
<wasabi_> EVms itself is totally awesome.
<wasabi_> It's the layering with other things that kinda messes around with it.
<wasabi_> This is specifically a LVM bug that I'm having I believe.
<jbailey> I think perhaps I wish it were just obvious what the One True Way of doing things were. =)  Even if it's evms with it's magic plug-in based mapping, that would be fine. =)
<wasabi_> evms really is just a good interface too.
<wasabi_> the core of it just uses md and lvm anyways.
<wasabi_> lvm to me seems like the One True Way.
<jbailey> Then what purpose does evms serve on top of that?
<wasabi_> The interface.
<wasabi_> And API.
<jbailey> ..
<wasabi_> It lets you manage all those systmes in an agnostic way.
<jbailey> You mean the curses interface?
<wasabi_> evmsgui too
<wasabi_> And easily layer and combine those different features, and keeps them in check.
<jbailey> Ah, I haven't met evmsgui
<wasabi_> Like it won't let you edit a md device that's used by a lvm that's exported as ext, because ext needs to be unmounted before expanding.
<wasabi_> It knows about all that.
<wasabi_> However it will let you expand a lvm partition that exports xfs because xfs can handle it, and it will expand xfs for you too
<wasabi_> in teh case of ext3 it makes you umount it, then it can expand it.
<wasabi_> All those plugins expose generic interface and stuff like "can expand" and such, and the API builds a big list of all the pieces involved in any operation and knows if it's possible or not.
<jbailey> So does it handle all the magic expanding and such for you?
<wasabi_> Yup.
<jbailey> Ah, hmm..
<wasabi_> Mostly the plugins just call the actual cmdline programs.
<wasabi_> Some actually use APIs.
<wasabi_> It'd be neat to have plugins that know about hardware raid devices, and expose that info to EVMS< so one interface could be used to deal with them, too.
<tseng> touching hardware raid from a running linux system sounds scary
<wasabi_> That's the point of ... hardware raid.
<wasabi_> Heh.
<wasabi_> no downtime for common changes, etc.
<bitmastro> hi guys, i have a question: why autocompletion is disabled by default?
<jbailey> bitmastro: Autocompletion?
<tseng> bash-completion
<bitmastro> yes
<jbailey> Ah, no idea.
<tseng> bitmastro: the .bashrc in /etc/skel is based on debians
<tseng> bitmastro: who dont install bash-completion by default last i checked
<tseng> but still the check would exit gracefully
<tseng> meh.
<wasabi_> Wow crazy.
<bitmastro> why don't enable it be dafualt in breezy (just a suggestion)?
<wasabi_> md just reorganized my two MD devices.
<wasabi_> md1 became md0 and md0 became md1, on reboot.
<tseng> bitmastro: search for/file a bug
<wasabi_> But I'm still here to speak about it.
<bitmastro> ok
<tseng> thanks.
<jbailey> wasabi_: md likes to do that.  The mdrun script goes through some effort to preserve it.
<jbailey> wasabi_: There's a prefered device number in the superblock of the MD device, but frequently it doesn't reflect how the system had it running before.
<bitmastro> another question... to use my laptop (hp zv6000) fine there is a need to patch the kernel.. there are other solutions but they still lack something.. 
<bitmastro> what should i do?
<wasabi_> Interesting. Now that md has reordered itself, evms is confused.
<wasabi_> LVM is fine though.
* wasabi_ sigh.
<HWolf> bitmastro, file a bug, append the patch, describe the problem
<wasabi_> Maybe I should just ditch evms until it's fixed and use pure lvm
<bitmastro> thank for the help
<bitmastro> bye :-)
<wasabi_> What is this volatile modules mount thing?
<jdub> wasabi_: prop drivers
<wasabi_> Why keep them there though?
<tseng> we relink them on boot to keep away the ATI boogey man
<wasabi_> So how can I get xorg reconfigure to redetect everything that it can, vs just reusing existing values?
<Chipzz> tseng: this create other problems though
<Chipzz> +does
<Chipzz> wrt upgrading/removing kernels
<Chipzz> it leaves the mountpoint lingering behind
<jc-denton> hi all
<jc-denton> not sure if this question is allowed here :D
<jc-denton> i'm running breezy and wondering about swsusp
<tseng> it works great for me, but please hit bugzilla if you think something is amiss
<tseng> im not the right guy to talk to about your kernel
<jc-denton> i do # echo "disk" > /sys/power/state
<jc-denton> then it suspends
<jc-denton> but i cannot resume
<jc-denton> i appended resume=/dev/hda3 (this is my swap parition) in grub to the kernel
<mdz> jbailey: the 'sleep 2' in dep_add_modules doesn't seem necessary; that's only copying and not actually loading modules, no?
<jbailey> mdz: Right, it's a pasto.  Removed.
<mjg59> Right. On closer inspection, the trains are not useful today, so I am home again.
<HWolf> who is the right person to ask fixing an easy bug with lirc?
<ivoks> HWolf: launchpad.net/malone
<HWolf> ivoks, lirc is main.
<ivoks> pool/universe/l/lirc/lirc_0.7.0.1-1ubuntu2_i386.deb
<ogra> jbailey, http://www.grawert.net/edubuntu/edusplash.png
<ogra> jbailey, i think thats the one you can take :)
<xTina> Hm. Is it on purpose that the new nvidia-glx-legacy package tries to overwrite /usr/lib/libGL.so.1 from libgl1-mesa, while at the same time depending on that package?
<Mithrandir> it should divert it.
<wasabi_> jbailey, it occures to me that adding evms to the init script doesn't seem like it should be done only if the evms package is installed, but if the root device is mounted on evms.
<Mithrandir> xTina: excellent observation, that probably explains another bug I've seen.
<infinity> The diversion hackery probably didn't get copied over from the other nvidia-glx maintainer scripts.
<wasabi_> Or yeah, maybe if the evms package is installed. That sort of covers it anyways.
<infinity> At a guess.
<\sh> Mithrandir: can u please apt-get install tk8.4-dev on ravel...actually I could fix ace...with good luck and thumbs up
<jbailey> ogra: Cool, thanks!
<jbailey> wasabi_: In most mode, the initramfs contains anything you might need for running the system.  dep mode is the detection.  I only actually run evms_activate at boot time is the root volume starts with /dev/evms/ or if you're running lilo.
<Mithrandir> \sh: that removes tk8.3-dev, but I guess you want that.  (done)
<wasabi_> Ahh ok
<\sh> Mithrandir: yepp...new build-dep somehow
<wasabi_> That error that evms activate gives about not having a engine lock, is that worth worrying about?
<jbailey> wasabi_: Look in /usr/share/initramfs-tools/scripts/local-top/evms
<wasabi_> I suspect that's just saying that it might be unsafe during the duration it takes evms_activate itself to run
<\sh> Mithrandir: thx
<jbailey> wasabi_: No idea.  Do you have the exact error?  I'd love to feed it through google.
<wasabi_> No, I can reboot to find it though, basically it's saying it can't write to a lock file in /var
<wasabi_> which makes sense, as that's teh initramfs
<jbailey> wasabi_: My testing didn't get much furhter that "Hey it boots if I set my root to /dev/evms/lvm2/Ubuntu/root" =)
<sladen> ogra: do you have the pre-dithered version of that?
<wasabi_> haha
<jbailey> wasabi_: If all it needs s a mkdir to make it happy, we should probably do that.
<wasabi_> is the initramfs ro?
<jbailey> Nope
<wasabi_> Hmm. I wonder then weither it's a good idea to trick it like that then
<wasabi_> Since when / is remounted the lock file is dead.
<wasabi_> but I don't know if it matters, give me a sec.
<jbailey> Right.
<sladen> ogra: I think of Edubuntu being more red (the letter mostly is)... what about picking a slightly more reddish hue?
<jbailey> But if evms copes, then it's fewer bugzilla reports saying that people have scary messages at startup. =)
<jbailey> ogra: I could take sladen out back and beat him around if you'd like... =)
<wasabi_> Okay there it is.
<wasabi_> While an evms client app is running, it creates /var/lock/evms-engine
<wasabi_> To prevent any other client apps from running, evms_activate is one of those.
<wasabi_> SO it just complains about not being able to create that lock file.
<jbailey> wasabi_: So when evms_activate is done it should remove it?
<ogra> sladen, http://www.grawert.net/edubuntu/edusplash.xcf pre dithered and pre blurred
<wasabi_> Yes.
<jbailey> Sounds like a good candidate for a gratuitous mkdir -p /var/lock
<wasabi_> Yup
<sladen> jbailey: i was thinking about suggesting changing the evms startup message to  'Detecting evms partition (if in use)...' to try and make it less scary
<wasabi_> Actually, no, it doesnt' remove it.
<wasabi_> It leaves it.
<jbailey> wasabi_: Hrm
<wasabi_> I assume it closes it.
<jbailey> so is it still using it?
<wasabi_> let me check!
<jbailey> Or is that just something to lock for fun and profit?
<jbailey> Thanks! =)
<wasabi_> Yeah, I think it is the former.
<wasabi_> It should probably clean it up on it's own, but it doesn't.
<jbailey> that it's still using it?
<jbailey> Ah
<jbailey> Hmmm.
<jbailey> So do I put this in the evms script, or have this available for everyone?
<jbailey> Everyone, I guess.
<wasabi_> I dunno. Seems to me that the initramfs should have /var/lock
<jbailey> ZZ
<jbailey> feh, EWINDOW
<wasabi_> haha
<wasabi_> this initramfs thing is pretty cooll... all well organized
<ogra> sladen, if you edit the logo, note that the base color used everywhere in edubuntu is yellow
<ogra> so dont make it to red please
<\sh> mdz: khelpcenter pulls not much in...it should be pulled in by kdemultimediaplugins ;)
<sladen> ogra: *nod*
<wasabi_> jbailey, in the lvm local-top script, it does some stuff with /dev/mapper/.
<wasabi_> What exactly does that mean?
<jbailey> That's it detecting if the start ${ROOT} begins with /dev/mapper
<wasabi_> My root is /dev/vg0/root =)
<jbailey> Fun string manipulation in pure posix shell! =)
<wasabi_> lvm makes vgs directly under /dev too.
<jbailey> Wow, I bet that doesn't give you lvm then. =)
<wasabi_> Bet not!
<wasabi_> I bet evms takes care of it though
<wasabi_> In my case.
<jbailey> Right, but if your path doesn't start with /dev/evms, then evms_activate won't get started.
<wasabi_> Yeah.
<wasabi_> So for normal lvm stuff, if you're using /dev/VG it won't work
<wasabi_> It also occures to me that the possible layering isn't exactly right...
<wasabi_> like md isn't always first. ;)
<wasabi_> You can make md's out of lvm vols, and vica versa.
<ogra> wasabi_, have you seen https://launchpad.net/malone/bugs/1800 ? i have several complaints from edubuntu users about that
<wasabi_> ahh. Yeah, seen that before.
<wasabi_> I thoguth that was fixed in GCJ a long time ago.
<ogra> hmm, does it probably clash with blackdown ? many of the edubuntu users install blackdown aside because they need the plugin for teaching stuff...
<wasabi_> Naw.
<wasabi_> It's just a GCJ bug.
<wasabi_> Well, classpath more specifically.
<ogra> ok... so i should poke doko ? 
<wasabi_> Yeah, I just don't have eclipse set up here to mess with right now.
<schweeb> LordHunter317: I'm not even sure I've seen him on the ubuntu chans much
<schweeb> err
<schweeb> wrong window
<\sh> saturday night..time for a beer
<ogra> \sh, prost :)
<\sh> ogra: cheers man :) 
<\sh> ogra: just saw the first three episodes of go-open...very interesting tv format...
<ogra> i havent had the time yet to watch it...
<ogra> s/havent had/didnt take/
<\sh> ogra: well...I think I have to save some money for next year to go down to ZA and get some infos about the s. foundation and all...it looks quite interessting to help them...
<Treenaks> \sh: and to start your biltong-importing business ;)
<\sh> Treenaks: YES !
<\sh> volunteering for biltong ;)
<\sh> wasabi_: should eclipse-platform work on hoary?
<wasabi_> No clue. I don't think I had anything in for Hoary.
<\sh> +eclipse (3.1-0ubuntu7) breezy; urgency=low
<\sh> +
<\sh> +  * Removed debian/bin hackery.
<\sh> argl
<\sh> there is a mirror who is mirroring hoary+breezy but only have latest breezy packages
<jbailey> mjg59: There?
<ivoks> one silly question...
<ivoks> in gnome print dialog, job tab is empty... that's normal?
<phlaegel> ogra: do you work on gnome-screensaver?
<siretart> wasabi_: ping
<wasabi_> pong
<siretart> wasabi_: do you intend some new uploads to eclipse for breezy?
<wasabi_> I doubt it.
<siretart> wasabi_: I noticed that there were some uploads to debian
<siretart> thats why I ask
<jbailey> mjg59: This hack doesn't work with LVM swap
<bob2> Mez: are you involved in the extras repository?
<Mez> bob2: sort of
<bob2> Mez: are you aware you're illegally distributing software?
<Mez> which software
<bob2> acrobat
<bob2> flash
<bob2> java
<bob2> w32codecs
<Mez> dragged straihght in from marillat IIRC
<bob2> realplayer
<Mez> and... er.
<bob2> that doesn't mean you're not breakign the law
<Mez> acrobat is in breezy
<bob2> and placing your mirrors in jeopardy
<Mez> http://packages.ubuntu.com/cgi-bin//search_packages.pl?version=all&subword=0&exact=1&arch=any&releases=all&case=insensitive&keywords=acroread&searchon=names
<Mez> bob2: the extras coordination isnt up to me... It's up to john
<\sh> Mez: u r the SPoC right?
<bob2> does anyone check this sort of thing?
<bob2> surely being involved in free software has made you all aware of what software licenses mean
<Mez> \sh - for backports
<\sh> Mez: kick jdong then to show up here to get his a** whipped ;)
<bob2> what's john don'gs email address then?
<bob2> also, it's a bit crap none of the backports people are in #ubuntu
<bob2> http://www.adobe.com/products/acrobat/distribute.html
<bob2> acrobat shouldn't be in multiverse, afaict
<\sh> bob2: elmo should have a look
<bob2> yes
<bob2> but I can't file a bug on it in LP
* bob2 emails elmo
<\sh> bob2: deal directly with it...don't file a bug
<\sh> bob2: it's a serious issue I think
<bob2> yes, I know
<azeem> acroread has been in multiverse since warty, it seems
<Mez> bob2 - I would be in tere if it wasnt for the shitty redirect thing
<\sh> bob2: and ask elmo to remove w32codecs from extras 
<bob2> Mez: so identify already
<Mez> and bob2 - john.dong@gmail.com
<bob2> \sh: extras isn't hosted on canonical machines, afaict
<Mez> bob2 - I always identify, but the thing shoves me in there whether I identify or not
<jlj> many moons ago I mailed gentoo-dev about their illegal mirroring of w32codecs, I gave up after realizing that not a single person on the list knew anything about copyright
<Mez> unless I join manually
<bob2> azeem: 5.0 had a less useless license, iirc
<Mez> bob2:L extras isnt no
<\sh> bob2: right
<bob2> jlj: yeah, I kinda expected people to in ubuntu-land :|
<\sh> I'm mixing it every time up with backports ,-)
<bob2> \sh: I'm going to email jdong about the rest
<Mez> I can remove the stuff from extras
<Mez> but It'll take me a while
<Mez> I havent updated from the svn repo in ages
<bob2> the repository is in svn?
<bob2> are you joking?
<Mez> no
<Mez> lol
<Mez> nothings been updated
<Mez> just the extras stuff's been put together
<Mez> bob, what needs removing?
<Mez> ./dists/hoary-extras/restricted/binary-i386/acroread-plugins_7.0-0.9~5.04ubp2_i386.deb
<Mez> ./dists/hoary-extras/restricted/binary-i386/acroread_7.0-0.9~5.04ubp2_i386.deb
<Mez> ./dists/hoary-extras/restricted/binary-i386/w32codecs_20050216-0.0_i386.deb
<bob2> mozilla-acroread, perhaps, haven't lookged inside it
<bob2> realplayer, sun-j*
<bob2> unless you went and asked for permission
<Mez> *shrugs*
<bob2> they gone now?
<Mez> mez@apathy:/backports/tree/backports$ svn commit
<Mez> Deleting       dists/hoary-extras/restricted/binary-i386/acroread-plugins_7.0-0.9~5.04ubp2_i386.deb
<Mez> Deleting       dists/hoary-extras/restricted/binary-i386/acroread_7.0-0.9~5.04ubp2_i386.deb
<Mez> Deleting       dists/hoary-extras/restricted/binary-i386/realplayer_10.0.4-0.2~5.04ubp1_i386.deb
<Mez> Deleting       dists/hoary-extras/restricted/binary-i386/sun-j2re1.5_1.5.0+update04_i386.deb
<Mez> Deleting       dists/hoary-extras/restricted/binary-i386/sun-j2sdk1.5_1.5.0+update04_i386.deb
<Mez> Deleting       dists/hoary-extras/restricted/binary-i386/w32codecs_20050216-0.0_i386.deb
<Mez> Deleting       dists/warty-backports/universe/binary-i386/sun-j2re1.3debian_0.17.6-4.10ubp1_all.deb
<Mez> Deleting       dists/warty-backports/universe/binary-i386/sun-j2re1.4debian_0.17.6-4.10ubp1_all.deb
<Mez> Deleting       dists/warty-backports/universe/binary-i386/sun-j2re1.5debian_0.17.6-4.10ubp1_all.deb
<Mez> Deleting       dists/warty-backports/universe/binary-i386/sun-j2sdk1.3debian_0.17.6-4.10ubp1_all.deb
<Mez> Deleting       dists/warty-backports/universe/binary-i386/sun-j2sdk1.4debian_0.17.6-4.10ubp1_all.deb
<Mez> Deleting       dists/warty-backports/universe/binary-i386/sun-j2sdk1.5debian_0.17.6-4.10ubp1_all.deb
<Mez> Committed revision 549.
<Mez> that'll take a while to be sent out to the mirrors
<bob2> er
<Mez> poop
<bob2> those last ones sound like installer packages
<Mez> ..?
<bob2> they're arch: all
<bob2> which java is not
<Mez> yeah
<Mez> they were installer packages
<Mez> mkdeb
<Mez> or something from java
<bob2> installer's are probably ok...
<bob2> the issue is distributing sun's code yourself
<Mez> *rolls eyes*
<\sh> sun-j2re1.5_1.5.0+update04
<\sh> sun-j2sdk1.5_1.5.0+update04_
<\sh> were the problems
<bob2> sorry, I thought it was clear I meant the ones containing sun code
<bob2> also
<bob2> isn't freenx under the GPL?
<Mez> they do contain sun code though
<bob2> it doesn't just download the tar file or you?
<Mez> no.
<Mez> It contains a tar and then compiles it
<bob2> ok
<bob2> that doesn't sound arch: all...
<bob2> distributing FreeNX without the source violates the GPL, too
<Mithrandir> bob2: freenx is a bash script.
<bob2> haha
<Mithrandir> bob2: seriously. :-)
<bob2> hm, I thought it was a gpl version of NX
<bob2> my mistake
<\sh> ok gentlemen...I will go early to bed today...g'night 
<Mez> bob2, old backports/extras has a lot of issues
<Mez> backports are brought into line now
<Mez> and I'm working on getting extras into line
<bob2> where's the, er, canonical location for extras?
<Mez> ermmmm....
<Mez> there technically isnt one thats open to the public
<Mithrandir> bob2: well, !M NX is just a compiled perl script.. it can fairly easily be decompiled,.
<Mithrandir> s/,//
<bob2> ah
<Mez> bob2, btw, you can field the complaints on the fourmns
<bob2> bleh forums
<Mez> You may not otherwise alter or modify the Software or create a new installer for the Software. 
<Mez> from the Acrobat licence
<Mez> does that count?
<bob2> How to distribute Adobe Reader software
<bob2> You may post Adobe Reader software on company intranet sites or local networks. You may also distribute Adobe Reader on a CD or any other physical media as long as you accept the terms and conditions of the electronic Adobe Reader Distribution Agreement.
<bob2> </paste>
<bob2> http://www.adobe.com/products/acrobat/distribute.html appears to be the rules for distirbuting it
<Mez> Please complete the Adobe Reader distribution request only if you are interested in distributing Adobe Reader software via internal Web site, CD, or other media, or are interested in placing an "Includes Adobe Reader" logo on your printed material. As an alternative, you may want to create a link on your CD directly to the Adobe Reader download page.
<Mez> "other media!"
<Mez> can tecnically be via internet
<bob2> er
<bob2> I think they get to define "media"
<Mez> they dont though
<bob2> also
<bob2> Third-party Web sites are required to link directly to Adobe.com for the download of Adobe Reader software. Hosting the software independently is not permitted.
<bob2> which explicitly forbids it
<Kamion> if a local web site counts as media then one could fairly easily argue the extras site does too (but they'd still have to complete the distribution request, and would have to do so on behalf of all their mirrors)
<Mez> Kamion: what about in ubuntu ? acroread has been in ubuntu since warty... doesnt that break the same guidelines
<bob2> warty has 5.0
<bob2> which had a different license, iirc
<Kamion> right
<Kamion> and yes, multiverse probably has the same issue
<Kamion> what happens in multiverse is basically sabdfl's call though
<azeem> bob2: I'm pretty sure Debian removed acroread from non-free before 5.0, though
<Mez> hmmles...
<ogra> phlaegel, yup
<Mez> multiverse is one of those "gray areas" really
<bob2> azeem: I can't seem to find the debian-legal discussion atm
<bob2> Mez: breach of copyright is pretty clear-cut
<Kamion> Mez: distinction between components is a matter of policy, not legality
<dholbach> i'm off - see you guys
<Kamion> azeem: acroread was removed because we weren't allowed to recompile/relink it to fix a zlib security hole
<Kamion> (er we == Debian)
<azeem> ah, right
<Kamion> although I think 5.0 was already out then, and apparently had an unacceptable licence, but I don't remember the discussion clearly enough to comment further
<Mez> Kamion: yes, I know... but.. as I was saying, multiverse is where the gray area stuff goes (stuff that can be distributed, but not used unless you have the right licence)
<Mez> IIRC
<Kamion> you might find it in -private archives
<Mez> weird that it's been updated to 7 in breezy
<Kamion> debian/copyright lied about the licence
<Kamion> so nobody noticed the change
<Kamion> however as I say it's sabdfl's call
<Mez> actually, acroread seems to be pulled from marillat
<Kamion> indeed
<Mez> ah well, i suppose if we're p;ulling things from apt-get.org - might as well pull things from marillat too
<Kamion> multiverse pulled stuff from marillat long before it pulled stuff from apt-get.org
<Kamion> fyi
<cogumbreiro> i don't know if here is the place to talk, how do I ask to be the manager of Serpentine on launchpad?
<Kamion> cogumbreiro: #launchpad would probably be a good start
<cogumbreiro> thx Kamion
<Kamion> np
<Mez> fair enough kamion :D I didnt know that
<Mez> but... meh
<Mez> as you said
<Mez> it's sabdfl's call
<Mez> :D
<Mithrandir> Kamion: Acrobat> Adobe changed the licence of all versions when 5 was released, iirc.
<Mithrandir> so 4 suddenly got undistributable.
<martinald> hi guys
<sivang> hi martinald 
<bddebian> Hello martinald, sivang 
<martinald> can someone prod bug 11237
<phlaegel> ogra: ping
<sivang> hey bddebian 
<ogra> phlaegel, pong
#ubuntu-devel 2005-09-23
<phlaegel> ogra: I've noticed that I can't use brightside (screen corner actions) to prevent gnome-screensaver from starting when I watch a movie. do you know if the problem would be in g-s or in brightside?
<ogra> no idea, i dont even know brightside, but i guess it needs adjustment to set the gconf key that controls if gnome-screensaver is enabled
<Mithrandir> brightside is teh love.  We should desktop seed it
<ogra> Mithrandir, after we made it work with gnome-screensaver indeed :)
<ogra> it should set /apps/gnome-screensaver/mode to disabled and afterwards back to the former state
<phlaegel> ah, here's what it does with xscreensaver: "implemented by running xscreensaver-command -deactivate every 30 seconds"
<ogra> phlaegel, yes, that nedds to be changed to a gconftool-2 call that sets the key to disabled
<torkel> or changed to run gnome-screensaver-command --deactivate :-)
<mjg59> jbailey: Oh nnnnnnngh.
<mjg59> jbailey: Can we do the LVM setup there as well?
<Mithrandir> ogra: it should probably rather use libgconf, though.
<phlaegel> gnome-screensaver has the a command line --deactivate option as well... which way would be better, cmdline or gconf?
<Mithrandir> I think gconf, but that might just be me
<phlaegel> well, after looking at the brightside source, switching to support gnome-screensaver would be really easy (even I, a non C programmer) could do it.
<phlaegel> But really, it should detect whether xscreensaver or gnome-screensaver is in effect and only manipulate the righ tone.
<Mithrandir> that's a bit harder, though.
<Mithrandir> it could just run -deactivate on both
<torkel> expect that gnome-screensaver uses -- and xscreensaver - :-(
<torkel> unless you want to run both g-s-c and x-c 
<Mithrandir> yes, that was my suggestiong
<Mithrandir> suggestion, even
<torkel> ah
<ogra> torkel, with my next upload you wont be able to run both... they clach if you run both daemons and you got two identical entrys in the menu
<ogra> i'll make the packages conflict...
<torkel> ogra: great
<torkel> ogra: might be an idea to make an xscreensaver-command wrapper in gnome-screensaver?
<torkel> it would ease the migration to gnome-screensaver
<ogra> hmm, i wonder if we'd really need that, the desktop itself works out of the box without it... and we wont see problems with universe apps
* Kamion unearths the debian-cd installation he used to build Sounder 1
<Kamion> wow
<ogra> :)
<ogra> Kamion, for you http://www.grawert.net/edubuntu/edu_isolinux.png
<ogra> 639x320@16
<Kamion> thanks, could you mail me that?
<ogra> yup
<Kamion> er, the URL
<Kamion> I'll set it up on Monday
<Kamion> thanks
<ogra> sure, take your time :)
<Riddell> how can I add a trusted key to apt?
<Mez> Kamion: is that for the usplash?
<Mez> I was wondering about getting a version for that
<Mez> Riddell - man apt-key
<ogra> Mez, thats for the CD splash, not usplash
<Mez> ah
<Mez> shame be cool for usplash for kubuntu/edu/ub
<ogra> Mez, http://www.grawert.net/edubuntu/edusplash.png thats for usplash
<ogra> (in fact its the same pic, just cropped down for isolinux)
<Mez> ogra: so there are going to be seperate usplash's for the different ones?
<Mez> does that mean kubuntu#'ll get one
<Kamion> hopefully
<ogra> dunno, depends on Riddell's atr team ;)
<ogra> art even
<Mez> the new art is looking nice
<Riddell> ogra: Mez likes my art at least :)
<ogra> Riddell, that was no criticism :)
<Mez> Riddell, you made the art?
<Mez> I do like the loading screen...
<Mez> very tacky, but, still - cool
<Riddell> what's the status of usplash support for different graphics?
<Riddell> Mez: it's based on the stuff in 3.5
<ogra> Riddell, jbailey called for graphics last week... so it seems we'll have them soon
<Mez> Riddell: I'm on about the letters being used as the markers... so you slowly revela the word "kubuntu" as you login
<Mez> tacky, but uber
<Riddell> Mez: yeah, got that idea off someone on kde-look
<Mez> lol
<Mez> If I'd seen that a few years ago, i would have thought "how tacky" and gone off the distro
<Mez> but, it's done well
<sladen> Mez: the easter egg is that it changes to   h a h a h a !  on 2006-04-01
<mjg59> Right. Is there anything I'm supposed to be fixing right now?
<mjg59> Other than yenta-socket and hibernate
<mjg59> And gnome-screensaver integration
<Mez> lol@ sladen - I woiuldnt be surprised
<ogra> Mez, you will be... if it loads GNOME afterwards ;)
<sladen> mjg59: my R52 doesn't turn the blacklight off when blanking the screen.  Is that your fault?
<Mez> ogra: lol - I've not ever really used ubuntu :D
<mjg59> sladen: I don't know. What does xset dpms force off do?
<ogra> mjg59, do we want dpms in gnome-screensaver on by default ? 
<ogra> i'm just twiddling with the defaults in the package
<mjg59> ogra: Yes
<ogra> ok
<jdub> GOOD MORNING FREEDOM LOVERS!
<jdub> jbailey: ooh, good upload! :)
<magnon> goood morning jeff :)
<bddebian> Heya jdub 
<bddebian> Why would xfonts-terminus source be in main but package in Universe?  Or am I reading apt-cache madison output incorrectly?
<Mez> bddebian, some packages get overriden if they're inconsequential parts of a source package
<Mez> like - technically, k3b-mp3 should be overriden to be put in restricted/multiverse :D
<bddebian> Mez: But they are the only part of the source package?
<Mez> bddebian, a source package can provide multiple binary packages
<bddebian> Aye, I know that
<bddebian> I see what you are saying.  X binary package out of Y source package may end up in universe.
<bddebian> Right?
<Mez> yep
<Mez> though for some reason - that seems like a weird package
<bddebian> Why?
<Mez> Source package: xfonts-terminus (4.12-2ubuntu1)
<Mez> The following binary packages are built from this source package:
<Mez> console-terminus
<Mez>     Fixed-width fonts for fast reading on the Linux console
<Mez> xfonts-terminus
<Mez>     Fixed-width fonts for fast reading.
<Mez> console-terminus = in main
<Mez> the rest arent
<bddebian> Guess someone felt console-terminus was important? ;-)
<bddebian> So can I upload a fix to the xfonts-terminus binary without affecting main?
<Mez> er
<Mez> no
<bddebian> That's what I thought
<bddebian> OH well, that bug stays open :-)
<Mez> you need to have main upload rights for it as the source package is what your uploading which is in main
<Mez> :d
<Mez> :P
<Riddell> is P1 or P5 highest priority in bugzilla?
<Riddell> ah, there's priority and severity
<Riddell> I'll go for severity, at least that has descriptive names
<tseng> Riddell: http://www.livejournal.com/users/spyderous/51021.html
<Riddell> tseng: thanks
<tseng> Riddell: nps.
<ajmitch> hi
<tseng> hi andrew
<tseng> thanks for the "beagle leaks" bug
<tseng> i need to cool off before addressing it
<tseng> w/o sounding like a cock
<jdub> thought: why aren't we shipping mysql 4.1 as the unversioned 'mysql-server' package (thus replacing 4.0 in main)?
<ajmitch> it looked like a bit more than the usual leakage
<tseng> not really
<tseng> im not sure what people think happens when you try to index 10s of gigs of data
<jdub> tseng: interdimensional quantum cluster indexing?
<tseng> jdub: yeah dude
<jdub> it's more efficient
<tseng> i was just talking to abock about the same thing
<tseng> we are going to invent CFQ-MissCleo
<jdub> obviously we need to support the atomchip
<tseng> miss cleo being a popular psychic on tv in the US
<tseng> it will read your mind and assign IO accordingly
<ajmitch> jdub: and the quantum optical memory?
<tseng> jdub: I hear their x86 emulation is amazing
<tseng> jdub: i bet breezy runs out of the box.
<tseng> in russian only, though.
<tseng> ajmitch: 70 GIGWATZ
<tseng> +A
<ajmitch> yeah
<ajmitch> you require your own fusion plant to run it then?
<tseng> jdub: so dude, not making UBZ, but whiprush and I are going to totally hit up the summit
<tseng> jdub: SEE YOU THERE.
<tseng> (badger badger badger)
* ajmitch is still considering whether to spend the cash on flying to UBZ
<sladen> Riddell: http://www.paul.sladen.org/ubuntu/usplash/kubuntu-usplash/ now in exchange, can I steal your living room back to go to sleep?  :-)
<tseng> ajmitch: bio-diesel
<sladen> jbailey: riddell says "Nice", so you can add the above the initramfs pr0n collection now
<tseng> can we get nipples on usplash?
<tseng> or too much to ask.
<jdub> tseng: oh, elite!
<jdub> tseng: well, half elite.
<sladen> tseng: 14 colour breast representations... mmm.
<jdub> sladen: nicely done
<Riddell> sladen: you can have the living room back in a minute yes
<tseng> jdub: only half?
<jdub> tseng: given !UBZ
<tseng> oh, well
<ajmitch> tseng: no time/$ for UBZ?
<tseng> claire said i smell awful and she would not be having me in the same hotel again
<ajmitch> sounds fair
<tseng> ajmitch: i could afford it
<tseng> ajmitch: but its not worth it for me
<tseng> i can get my fix at the boston summit for much less
<tseng> and less time off work
<ajmitch> that's what I'm thinking of too
* Mez pokes sladen
<sladen> C. needs a bigger fleet of private jets to taxi people
<jdub> tseng: plus there will be more mono love at the summit
<sladen> Mez: yo
<tseng> jdub: yes!
<jdub> sladen: we could buy the ones that novell's investors are suggesting they ditch
<tseng> jdub: i cant wait to meet miguel
<ajmitch> a pity I won't be at the summit then
<ajmitch> tseng: you'll have to represent the mono love in ubuntu
<Mez> sladen: you were doing the ubuntu t-shirts were you not?
<tseng> ajmitch: miguel already represented it at GUADEC
<jdub> tseng: i think you will dig hacking with nat, rml, joe and trow
<sladen> Mez: nope.  I do the Debian ones...
<tseng> jdub: oh man, joe and trow are elite!
<ajmitch> tseng: in ubuntu?
<tseng> jdub: and nat, but thats given
<Mez> sladen: I must have misheard then when you were trying to pedal the debian ones :D
<tseng> ajmitch: someone at GUADEC asked when mono will go in fedora
<tseng> ajmitch: miguel says "probably never, just get NLD.. actually, get ubunut"
<tseng> ubuntu rather
<tseng> this was at the keynote, live streaming and all that
<ajmitch> hah
<ajmitch> nice
* tseng fanboi'd
<sladen> Mez: artwork rather than flog.    https://wiki.ubuntu.com/t-shirt  has details of the ones Simera is flogging
<Mez> ty sladen
<ajmitch> I just don't know if it's worth me coming to UBZ, given the cost
<tseng> exactly
<ajmitch> tseng: btw I felt like doing something crazy & hacking DPAP support into f-spot
<tseng> ajmitch: dude save it for LCA or something
<tseng> ajmitch: hm i heard talk of that on #g-h a few times
<ajmitch> LCA is only a short walkl down the street for me
<ajmitch> seriously
<tseng> i think it was David
<tseng> davyd
<ajmitch> wouldn't surprise me
<jdub> ajmitch: i'm sure we'll have another summit much closer to .au/.nz
<Mez> why is it that the only semi-decent linux things in england are never near me
<ajmitch> jdub: I hope so
<jdub> ajmitch: we're going for regions
<Mez> only one I've managed to pull off getting to was LRL
<ajmitch> jdub: I would have liked to push a couple of things at UBZ, and take a bit of a holiday in the area afterwards
<ajmitch> jdub: I expect you'll be at LCA, of course?
<Mez> ajmitch: then come, or pass them off to someone else to push at it
<sladen> Mez: Linux Expo is in a fortnight, if you come and do there stand you might be lucky enough to get an exclusive Ubuntu t-shirt :)
<jdub> ajmitch: on the VP's arm :-)
<ajmitch> jdub: good :)
<Mez> sladen: I was meant to get one at LRL  but noone was around
<Mez> and I'm working when it's on
<Mez> hence why I cant make it
<sladen> Mez: ah, if you did the stand there and didn't get one, it might be possible to sort one out
<Mez> I sort of did
<Mez> but because the guy i was meant to talk to - I couldnt find
<Mez> causde noone was on the stand
<Mez> the best I could do was stand in front talking to people (inluding you)
<sladen> Mez: the problem with Ubuntu stuff in the UK is everyone with 1 foot in Ubuntu is too busy pimping Debian, KDE or other $foo of choice
<jdub> sladen: i think this is a 'problem' in general, but it's easy to work around
<jdub> sladen: ubuntu is a great vehicle for pimping your other projects
<jdub> [ the plural 'your' ;-) ] 
<Mez> :P
<Mez> sladen: too true
<sladen> jdub: indeed :-).  I think the better take to solve this is probably to sucumvent the other projects and get the GNOME stand demo'ing Ubuntu, KDE Ubuntu, LTSP... etc
<Mez> lol
<sladen> get it into people's heads that Ubuntu is the _means_ rather than the _end_
<Mez> :P
<Mez> and how you gonna get that to happen
<jdub> sladen: though that becomes problematic in some circumstances (GNOME is very aware of its distributors, so favouring one seems unfair)
<sladen> Mez: know any other people who aren't working.  Need to find about 15 people for the Ubuntu stand, onto of about 15 for the Debian stand, minus all the ones that Canonical won't let have time off...
<jdub> LTSP are very ubuntu focused atm, but that may change
<sladen> (* and it's release date about then)
<jdub> why do you need 15?
<jdub> that's a *lot* of people
<Mez> sladen: not anyone that'd want to do it
<sladen> jdub: that's about what it takes to man the Debian stand at the expo.  We normally have a constant 7-10 conversations happening and it's nice to give people time off over the two days
<Mez> anyways
<Mez> I'm gonna walk the dog
<Mez> sladen: did you get my /query?
<sladen> Mez: yes, and I even replied to it
<Mez> hmm
<Mez> I didn gtet your reply
<Mez> weird
<Mez> sladen: you're not id'd to nickserv thats why
<Mez> and I cant seem to turn off +E
<sladen> ta, solved.
<jdub> bddebian: please stop destroying global productivity by uploading new versions of wesnoth. kthxbye.
<bddebian> Uhm, is that sarcasm?
<jdub> no. wesnoth is a stain upon the free software movement.
<jdub> it must be stopped.
<bddebian> Well someone needs to tell me this stuff
<jdub> whatever you do, don't play it.
<jdub> don't even test the packages.
<jdub> it's just too dangerous.
<bddebian> Oh I've played it before.  Sorry, it doesn't compare to NeverWinterNights ;-P
<ajmitch> tseng: is there a monodoc 1.1.8 floating around the net?
<bddebian> infinity: ping?
* wasabi__ fun with sasl
<bddebian> jdub: Well you will be happy to know that I broke wesnoth
<jdub> ha ha ;-0
<jdub> ;-)
<jdub> that will keep the evil at bay!
<bddebian> :'-(
<wasabi__> I seem to be unable to get libnss-ldap to work with gssapi properly. =(
<LinuxJones> Can someone pop in #ubuntu and kick Hommm he's a spamming/annoying twat !!
<bddebian> mdz: You around?
<Lathiat> hrm, i'm not getting DRI with fglrx despite xorg.log showing it all good
<bddebian> Heya tritium 
<tritium> Hi bddebian 
<bddebian> tritium: Got any extra space in NM? ;-)
<tritium> bddebian, sure, are you driving through>?
<bddebian> tritium: Nah, I think I'm going to have to go into hiding :-)
<tritium> bddebian, oh?  Why's that?
<bddebian> For being stupid :-)
<tritium> bddebian, I'm sure it's nothing too serious.
<bddebian> I asked for a sync of Wesnoth and somehow missed a dep on ttf-dejavu.  Which wouldn't be so bad because it would be new to us.  However, ttf-dejavu build-deps on a newer version of fontforge, which is in main.. :'-(
<tritium> bddebian, don't beat yourself up about it
<wasabi__> we need bigger uid space. =(
<wasabi__> I wonder perhaps if we shouldn't be using uids past a certain range as part of the system (nobody comes to mind)
<elmo>    * Rebuild for glibc
<elmo> bddebian: eh?
<bddebian> elmo: Malone bug #1082.  Bad description,sorry
<crimsun> elmo: not sure if someone else to requested this; please sync openafs from Sid
<crimsun> wow, I can't type. "...if someone else has requested..."
<elmo> crimsun: done
<crimsun> thanks!
<tritium> hi crimsun
<crimsun> 'lo tritium 
* fabbione larts evms and glibc
<mdz> bddebian: am now
<spstarr> thanks for making hplip (HP Printing daemons) optional with /etc/default/hplip :-))
<jbailey> sladen: Eh, what? =)
<pef> hello
<jbailey> mjg59: The problem with doing the lvm setup there is that in the multipath case, some of the components of the LVM volume might be on the USB, so you risk corruption.
<jbailey> mjg59: What I've done for now is test if the device exists at that point.  If not, I proceed as before.
<jbailey> So for people with USB that doesn't suck they can recover from it too.
<sladen> jbailey: http://www.paul.sladen.org/ubuntu/usplash/kubuntu-usplash/kubuntu-usplash-640x480-14.png  however I've just noticed that the gradient on the reflection looks better the other way up, so there'll probably be a newer version later
<jbailey> sladen: Nice. =)
<jbailey> sladen: Is this correctly pallette matched for foreground/background/failed text?
<jbailey> (0,2, and 12 or 13 IIRC)
<jbailey> Mm, no 0 has to be background.
<sladen> jbailey: nope, because I couldn't find what they were.  There's 14 colors meaning there are two to play with and two that should be stealable
<jbailey> Lemme look them up, justasec.
<sladen> jbailey: I'll do a wiki page if you let me in on the secret :)
<jbailey> #define TEXT_BACKGROUND 0
<jbailey> #define TEXT_FOREGROUND 2
<jbailey> #define RED 13
<jbailey> #define BACKGROUND_COLOUR 0
<jbailey> #define PROGRESSBAR_COLOUR 1
<jbailey> Those are hardcodes atm, and should probably stay that way for breezy.
<jbailey> When we have time for cleverness, they can become configurable.
<fabbione> hey jb
<jbailey> Heya Fabio!
<jbailey> sladen: I'll even tell you what the alternative will be once I get it setup.
<jbailey> I'm not in much shape to be hacking atm.
<sladen> jbailey: don't worry.  btw, do you/Kamion know off the top of your head what isolinux uses to select its colours?
<jbailey> I have no experience with isolinux
<sladen> ogra: for edubuntu-artwork, is it possible to make it use dpkg-divert against ubuntu-artwork if not much has changed?
<Kamion> sladen: don't worry about that, I can deal with the isolinux palette when running ppmtolss16 to convert to rle format for isolinux
<Kamion> sladen: just make sure one colour in the palette is black or very close to black (for background) and one is close to white (for text underneath the image)
<Kamion> isolinux wants background as colour 0 and text as colour 7, but the conversion program has options to rearrange the palette arbitrarily
<jdub> sladen: and you can use any of those colours in your image (they're not changed, they're just used for other things)
<sladen> Can $people fixup https://wiki.ubuntu.com/Usplash/Artwork
<ogra> sladen, nope, it uses many of the ubuntu-artwork contents, i just set some cdd gconf keys and use other splash and background images
<ogra> thats why edubuntu-artwork depends on ubuntu-artwork
<Micksa> gnyah
<Micksa> how do I get ~/.xsession to run?
<Micksa> or achive the same effect - per user X startup commans
<mdke> Micksa, try #ubuntu for support
<Micksa> ubuntu doesn't like me
<Micksa> #ubuntu even
<mdke> sorry to hear that
<mdke> keep trying though!
<mdke> someone will help
<elvirolo> hi all
<elvirolo> is it relevant to report bugs related to internationalisation yet ?
<mdke> sure
<elvirolo> ok thanks
<elvirolo> cause about 20 % of kubuntu isn't translated into french 
<\sh> elvirolo: please join #kubuntu-devel ,-)
<elvirolo> ah yeah you're right :)
<vrln> I think I found a serious bug in sudo @ breezy (updated ~1 hour ago), should I file it or can I just say it here? I don't have a bugzilla account
<vrln> vrln@core:~$ sudo echo "opt/e17/lib" >> /etc/ld.so.conf
<vrln> bash: /etc/ld.so.conf: Permission denied
<vrln> --> the ">>" isn't working perhaps?
<vrln> I can sudo nano /etc/ld.so.conf and edit it manually
<vrln> and the permissions for /etc/ld.so.conf are ok
<Lathiat> vrln: that is not a bug
<Lathiat> vrln: the redirection is done by your shell
<Lathiat> vrln: as such runs outside the sudo
<vrln> ehm, sorry, so it's bash related instead? :)
<vrln> I don't see anything wrong with the syntax though
<\sh> vrln: use tee ,-)
<Lathiat> vrln: its not a bug at all
<\sh> vrln: echo "opt/e17/lib" | sudo tee -a /etc/ld.so.conf
<vrln> ok, sorry - and nevermind :)
<tseng> ajmitch: nope.
<tseng> ajmitch: 1.0.7->1.1.9
<ajmitch> tseng: right, I built avahi 0.5 without monodoc support anyway
<tseng> ajmitch: nod
<tseng> new monodoc would be a pretty serious repackage
<ajmitch> so we'll have a new libavahi-cil in soon ,I guess
<ajmitch> yeah
<tseng> stuff was split into a seperate package
<tseng> we cant do it.
<ajmitch> I wasn't expecting it in breezy
<tseng> rock on
<Lathiat> ajmitch: have you got me a patch i can send to ross yet? :)
<ajmitch> Lathiat: if you really really want
<\sh> mjg59: http://www.flybook.biz/en/?section=generic&page=flybook <- something for your notebook collection? ,-)
<ajmitch> but the debdiff would include the 0.4->0.5 code changes
<Lathiat> ajmitch: why wouldnt i want it?
<ajmitch> unless I just diff the debian dirs
<Lathiat> ajmitch: cant you just diff the debian dirs
<infinity> debdiff *dsc | filterdiff -i */debian/* > 0.4-0.5.debdiff
<infinity> (If you don't want to diff the twon unpackaged trees by hand)
<ajmitch> infinity: thanks :)
<fabbione> hey guys
<fabbione> who is fluent in "SQL"?
<fabbione> i need help for a couple of query...
<tseng> fabbione: i can help you with the basics
<tseng> fabbione: no crazy view/subselect whatever is the rage now
<fabbione> tseng: i need nothing too fancy
<tseng> great.
<fabbione> it seems that all my sql tables contains tons of duplicate entries
<fabbione> note that i did a dump -> import
<fabbione> so that might have gone wrong
<fabbione> so i would like to kill all the duplicates
<infinity> Good argument for having unique keys. :)
<fabbione> infinity: i am not a SQL god..
<tseng> http://www.petefreitag.com/item/169.cfm < google wins
<infinity> fabbione : Are the rows identical (ie: yo udon't even have an auto_increment ID tag or something?)
<tseng> http://www.sql-server-performance.com/rd_delete_duplicates.asp
<infinity> If the rows are completely identical, there's no way to identify one from another, so there's no way to delete one without deleting both.
<fabbione> infinity: they look perfectly identical
<fabbione> or it looks like
<tseng> oh, ew
<tseng> is it an option to drop the db and import again?
<infinity> In that case, you want a query that will collapse identical rows, then dump the whole table into a temp table.
<fabbione> tseng: yes it is
<infinity> Then turn around and rotate your temp table back over your original.
<fabbione> infinity: i can do that.. it's no issue..
<fabbione> infinity: i just need to figure how :)
<infinity> Which SQL engine?
<fabbione> mysql
<tseng> add each item to a keyed array with the most unique field?
<tseng> so you overwrite the block w/ each duplicate
<fabbione> you guys talk already too complicate for me
<tseng> if you do a select on the table, and do a foreach on every row
<tseng> say there is a field 'joe@blah.com' that is "unique"
<tseng> make an array from each row with array['joe@blah.com'] 
<fabbione> that should be unique
<tseng> and all the data
<fabbione> and now it's duplicated
<tseng> then
<tseng> the next time you see joe@blah
<fabbione> i skip it
<tseng> it just overwrites that bit of the array with no data
<tseng> sure, or check for that row and skip it
<tseng> "row" being array item
<fabbione> there is always data.. where there is duplication, the entire row is duplicated
<fabbione> i wonder if i could do that with grep...
<tseng> s/no data/the same data
<tseng> you coul do it with | sort | uniq if you have a way to put the output back in the table
<fabbione> sure..
<fabbione> dump/restore?
<tseng> hm yeah i bet the rows in the .sql do look the same
<tseng> but the sort will screw things up
<fabbione> we will know in a few secs :)
<tseng> if you get the table header below the body :P
<mjg59> jbailey: Argh.
<infinity> NO need to sort, if you have uniq.
<tseng> oh yeah?
<tseng> for some reason i thought uniq required sorted input
<tseng> thats handy
<tseng> or, it does and his file will already be in that kind of order
<fabbione> tseng: in both cases it is not an issue..
<tseng>        Discard  all but one of successive identical lines from INPUT (or stan
<tseng>        dard input), writing to OUTPUT (or standard output).
<fabbione> the table creation is 20 lines..
<fabbione> anc i can copy paste them
<tseng> good :)
* infinity is still trying to figure out how to do this in SQL, for sheer personal curosity.
<infinity> I don't think I've ever had a table without a unique constraint on at least one column.
<tseng> i should learn some more clever sql trickery, i usually do simple stuff in sql and let my programs sort the rest
<tseng> usually faster for the db to do it
<infinity> Oh, duh.  It's been too long since I've done SQL.
<infinity> select distinct * from test;
<tseng> (oh yeah...)
<infinity> I feel very incredibly lame for not remembering that.
<tseng> infinity: we suck.
<infinity> Oh well, my excuse is that I've been SQL-free for quite a while now.
<fabbione> ehehe
<infinity> (And hope to continue that trend, professionally)
<fabbione> dump | sort -u | reimport is a good alternatice
<fabbione> alternative even
<fabbione> well it seems to be working fine
<\sh> infinity: deal first with ace ;) 
<infinity> \sh : I saw something up there about you messing with it.  Did you give up again?
<\sh> infinity: the patch is crap
<infinity> Right. :)
<\sh> but if you want...I can send it to you ;)
<infinity> What was it a patch to do?
<\sh> this patch disables -fvisibility-inlines-hidden for amd64 and powerpc
<infinity> Compile the libs with -fPIC?
<\sh> but
<\sh> 00list looks like this
<\sh> #if defined(DEB_BUILD_ARCH_amd64) || defined(DEB_BUILD_ARCH_powerpc)
<\sh> /* this patch disables -fvisibility-inlines-hidden for amd64 and powerpc */
<\sh> 93-compiler-options-for-noni386
<\sh> #endif
<\sh> but it doesn't apply correctly :( 
<infinity> Ahh, I see, it is compiled with -fPIC, but g++ is doing Really Bad Thngs.
<infinity> Well, send me your patch, and I'll let you know what you did wrong. :)
<fabbione> thanks guys!
<fabbione> you rock
<\sh> infinity: it's bmonties ;)
<infinity> Well, whoever. :)
<infinity> -e 's/your patch/the patch you have/' -e 's/you did wrong/they did wrong/'
<\sh> infinity: dcc or mail?
<infinity> Mail.
<\sh> on its way
<infinity> People still DCC in today's age of triple-NATs and fascist firewalls?
<\sh> infinity: we can use as well jabber bytestream proxy ;)
<tseng> infinity: my facist firewall is no match to ssh tunnels over port 443 authenticated to the proxy
<\sh> and what firewall can prevent xmlrpc bugs :(
<Kaloz> fabbione: around?
<Kaloz> fabbione: do you know about any problems regarding silo with 1gb memory? :p
<fabbione> Kaloz: hmm what problem do you have?
<Kaloz> fabbione: well, with 1gb memory, the boot cds give me "Fast Access MMU Miss" after "S" of SILO
<fabbione> Kaloz: and if you leave 512Mb does it boot?
<Kaloz> both you hoary installer (silo 1.4.8) and sarge's (1.4.9)
<Kaloz> yep
<Kaloz> this is on a netra t1 105
<fabbione> Kaloz: we should ask BenC
<Kaloz> slowaris 10 works perfectly, but i hate it :p
<fabbione> he is one of the silo upstream authors
<fabbione> Kaloz: but i never had this problem
<fabbione> well in older versions of silo i did boot on a E10000K with 32GB of RAM
<Kaloz> as I saw almost everyone is running his 105 with 512 ram only
<fabbione> so i am not exactly sure how 1GB exactly can make that problem
<Kaloz> maybe it's t1 specific
<fabbione> i do have only 512MB here on the Netra T1
<Kaloz> well, i know it works on a 420r with 2gb of memory
<Kaloz> so it has to be smg with the netra only
<fabbione> Kaloz: i really dunno...
<fabbione> BenC: ping?
<Kaloz> fabbione: hmz.. okay, same after obp upgrade (3.10.24 -> 3.10.27), so that doesn't helps
<fabbione> Kaloz: we need to ask BenC
<Kaloz> i see, just wanted to say i've just tried that, too :)
<bddebian> Hmm, what does uploads to main are flowing again mean?
<HiddenWolf> bddebian, bugfixing again in progress.
<HiddenWolf> bddebian, after stopping everything to fix preview-critical bugs a bit before it's release
<fabbione> Kaloz: that's nice :) for breezy we might have even install CD's
<fabbione> Kaloz: we published one, but it doesn't boot yet
<Kaloz> :)
<Kaloz> to be honest, it would be nice to fix this CHS crap d-i intrioduced
<bddebian> HiddenWolf: Can that include fixing my screwups? :-)
<Kaloz> with the old woody, partitions were detected right on sparc
<HiddenWolf> bddebian, chuckle
<spayne> why are there now two screensaver properties in GNOME 2.12?
<spayne> there is xscreensaver (nicer imho)
<spayne> and gnome screensaver
<spayne> well, gnome screensaver is actually nicer thinking about it
<spayne> since it passwords it automatically
<spayne> will one of them be removed?
<jdub> yes
<jdub> just remove the xscreensaver package
<mdke> is that going to be the solution for breezy?
<jdub> it's in at the moment
<spayne> but it will be removed at some point?
<infinity> \sh : Uploaded, BTW.
<jdub> spayne: no, we're going to leave it in to confuse all of the users
<spayne> and the age old question, will the gnome foot be replaced by the ubuntu logo?
<spayne> jdub: good thinking ;-)
<jdub> the applications menu one will if the human icon theme becomes the default
<jdub> (or we may do it anyway)
<spayne> nice
<infinity> \sh : For future reference, using CPP preprocessing in 00list doesn't work unless you enable dpatch's optional CPP parsing. :)  (DPATCH_OPTION_CPP=1 in debian/patches/00options)
<bddebian> infinity: Can I ask what is probably a dumb question?
<spayne> jdub: from my experience, most people seem to do it anyway
<infinity> bddebian : I suppose.
<jdub> spayne: this word, "most"... i do not think this word means what you think it means.
<mdke> jdub, i have a quick question about the recent menu changes
<jdub> mdke: ja?
<bddebian> infinity: sawfish-xmms is supposed to be built from rep-xmms source.  Building here locally works and the deb installs but it's not showing up in the archive.  How would I check that out?
<spayne> jdub: i personally love the Human theme, what is the chance of it becoming default for breezy?
<mdke> jdub, is there going to be discussion at UBZ to try to ensure that they happen a bit earlier, rather than very late?
<mdke> we are struggling a bit with the docs
<jdub> spayne: not wildly fantastic atm. but we'll see.
<jdub> mdke: yes, i'm going to pitch for a ui review two weeks before preview freeze.
<mdke> jdub, that would be good
<mdke> mark gets a lot of ideas right at the last minute :D
<jdub> dunno if a "mark's bright ideas" freeze is going to fly
<bddebian> Heh
<mdke> :)
<bddebian> infinity: I take it that was a dumb question? :-)
<infinity> bddebian : Check the build logs, notice that rockhopper (the i386 buildd) was configure to to arch-only uploads back in 2004, when the package last build, go "oh, that's weird", then upload a new 0.4-4build1 with no changes, so the i386 buildd will now upload the arch:all sawfish-xmms package you want.
<infinity> bddebian : And then wait for someone to process it in binary NEW.
<bddebian> infinity: Great thanks.  I was gonna try that but wasn't sure.
<\sh> infinity: thx :) 
<\sh> infinity: so u can remove dbbalancer as well from the frozenapps list ;)
<infinity> bddebian : For future reference, arch"all packages are always supposed to be built on i386 (and only on i386), so if you check the i386 build log, and see "arch-dependent upload, not including arch-indep packages" (or whatever), and the .changes in the build log doesn't include the _all.deb, you know something went horribly wrong.
<infinity> bddebian : If it's a recent build log, yell at me (but it should never happen now), if it's an ancient build log (as in this case), just push a rebuild.
<infinity> \sh : Once ace build and installs everywhere, yes.  It takes a while to build. :)
<bddebian> infinity: OK, thanks.
<\sh> infinity: actually it's finished...argl....w8
<infinity> Uh.
<infinity> Finished?
<\sh> that reminds me of something
<\sh> infinity: cxx transition
<\sh> libace5.4c2 libacexml5.4c2 libciao1.4c2 libkokyu5.4c2
<\sh> I think I have to do it after it's build ;)
<infinity> Yeah, it'll be a while.
<infinity> The builds will start in the next 15 mins, I figure they'll all be done and installed in another 2 hours or so.
<bddebian> OK, so the next question is what to do about my wesnoth fuck up.. :-(
<infinity> The "I synced a version that's too new" fuckup?
<\sh> infinity: want to have another one? http://bugzilla.ubuntu.com/show_bug.cgi?id=11387
<bddebian> infinity: Yep, that'd be the one
<infinity> Did it build?
<infinity> If not, you may be able to bed elmo to UNACCEPT the source.
<infinity> If it did, you're better off uploading a package with a really ugly version like "0.9.7-1+really0.oldversion" that is the old version, masquerading as "slightly newer than the new one you uploaded".
<bddebian> infinity: Yes.  The problem is is that it has a depends for ttf-dejavu, which could be a new package, but ttf-dejavu depends on a newer fontforge which is in main.
<infinity> See, for instance, firefox in warty for an example of this kind of ugly.
<infinity> Either that, or make ttf-dejavu work with the fontforge in main.
<infinity> OR, justify a UVF exception for fontforge, if it's not a massive upgrade.
<bddebian> I don't think it is.  It only has 3 rdepends, one of which it builds itself
<jdub> elmo: ping
<infinity> Then talk to mdz about it.  Test the new version first, including testing the rdepends, and take that info to him.
<infinity> And make sure the debian BTS doesn't have any new bugs against the new version.
<bddebian> infinity: Fair enough, thanks
<SteveA> Kamion: ping?
<slomo> elmo: ping?
<SteveA> can anyone tell me which key is used to sign md5sums of CD images?
<Mithrandir> SteveA: gpg: Signature made lr 17-09-2005 10:26:50 CEST using DSA key ID FBB75451
<SteveA> ah -- how did you get that?
<Mithrandir> wget http://cdimage.ubuntu.com/daily/current/MD5SUMS.gpg -O -  | gpg
<SteveA> would be nice if the "releases" page gave the fingerprint or key id
<Mithrandir> yeah
<Mithrandir> file a bug, I guess.
<SteveA> willdo
<SteveA> cheers
<Mez> who is Wouter Stomp?
<jdub> whiprush: ping
<tseng> jdub: YARRRRR
<jdub> tseng: AHR!
<spayne> hmm, gnome-obex-server is crashing on me
<spayne> giving me a libc6 error
<spayne> *** glibc detected *** double free or corruption (!prev): 0x080ead80 ***
<spayne> what does that mean?
<bob2> it's bug-e
<spayne> bug-e?
<bob2> it's ab ug
<bob2> er, "A bug"
<spayne> i somehow guessed that
<bob2> it's a bug in gnome-obex-server, where, as it says, it's freeing the same bit of memory twice, or it corrupted it's own heap
<bob2> valgrind will probably help with debugging it
<spayne> is there any way around it?
<spayne> i will do that
<spayne> but atm, what can i do?
<bob2> not use it?
<bob2> or find a workaround
<spayne> i am trying
<spayne> obexserver also fails
<\sh> doko_: ping 
<spayne> i am building 0.5.1 from tarballs
<eruin> Lathiat, got any ~eta on avahi 0.5?
<Mithrandir> ogra: ew, gnome-screensaver looks _horrible_ in xinerama setups
<ogra> Mithrandir, inwhich respect ?
<Mithrandir> ogra: the dialog is in the middle of two screens
<Mithrandir> ogra: want a picture?
<ogra> ok, thats what i expected... its complied without xinerama support, i'll correct that in the next upload... 
<\sh> Mithrandir: winndows behaviour ;-)
<ogra> i just wanted someone to confirm that
<ogra> Mithrandir, thanks for now
<Mithrandir> ogra: ok, good
<ogra> i'll ping again after the next upload ;)
<\sh> ogra: what did u do...we will have cdu+spd ,)
<ogra> not my choice..
<ogra> and no final numbers, wait ... ;)
<shackan> why if a program crashes and I chose 'close' instead than 'restart', the program is restarted anyway ? this leads often to (boring) infinite loops
<ogra> shackan, #ubuntu please
<shackan> k
<sivang> mjg59: ping, you around ?
<bddebian> Hi folks
<Kaloz> fabbione, BenC: re. from hdd, silo works happily with 1gb ram. so it has to do smg with silo vs isofs
<bddebian> mdz: You around?
<shackan> your nautilus-python seems buggy, the latest cvs works fine, is there any chance to update it ?
<sivang> hey bddebian 
<bddebian> Heya sivang 
<sivang> bddebian: what are you up to?
<sivang> ;-)
<bddebian> Breaking stuff :-(  You?
<sivang> bddebian: the same, I have a prbolem with gnome-panel and cdbs-edit-patch that is a PITA
<sivang> bddebian: I am trying to edit the 12_autotools patch, but to no avail - moreover the weirdest thing is the when I edit each patch befpore that one it works, and even when I attempt debuild -us it, it works as well
<sivang> only cdbed-edit-patch gets angry
<sivang> and this is with a prestine ubuntu source pkg :-)
<sivang> any idea?
<bddebian> I'm probably the wrong person to ask at this point in the game :-)
<adamh> When I try booting to a USB device (with usb-storage), I get a complaint that /dev/sda1 doesn't exist, and then I'm dumped to a busybox shell. If I "modprobe sd-mod" and run "udevstart", I can create /dev/sda1. As far as I can tell, that's my only problem with booting from USB. What files do I edit to make my system boot? :)
<sivang> bddebian: I see, anyway, what were you breaking if we speak ?
* adamh exits irssi so he can start up sshd so he can actually open more than one frickin' terminal...
<bddebian> sivang: wesnoth
<sivang> bddebian: /me apt-cache show info
<sivang> bddebian: nice, what p[roblem do you have with it?
<sivang> bddebian: (may I try to help?)
<bddebian> sivang: I asked for a sync of a new version (first mistake) and didn't catch the depends on ttf-dejavu which needs a newer fontforge, which is in main (biggest mistake). :-(
<bddebian> sivang: I have a "fix" thanks, I just need to catch mdz or someone
<sivang> bddebian: so you need someone from main to sync in a new version ?
<bddebian> sivang: Of fontforge yes but I need approval
<adamh> So, anybody know how to boot from USB flash? Or how to reorder udevstart, sd-mod loading, or anything else I could have done wrong?
<mdz> bddebian: yes?
<bddebian> mdz: I made a major boo boo and was hoping we could sync the latest fontforge from Debian
<bddebian> I have tested it as well as rebuilding all the rdepends.
<Mithrandir> bddebian: why does it need a newer fontforge to get ttf-dejavu, really?
<bddebian> Mithrandir: I don't know specifically but there is a BTS bug on it as well
<bddebian> What's a little strange is that I don't see anything in main that redepends on fontforge
<bddebian> Err rdepends even :-)
<sivang> Mithrandir: maybe you can help me as well? I have some gnome-panel fix I need to do but cdbs-edit-path just won't let me do it, and I Sense there is something wrong with the source pkg due to that
<Mithrandir> sivang: hmm, that might be; is it something I could take a look at, or is it a more complicated patch?
<sivang> Mithrandir: now , couldn't be more trivial then that - and you can test it with my patch using the source pkg from the repo
<sivang> s/now/no/
<sivang> Mithrandir: apt-get source gnome-panel; cd srctree; cdbs-edit-patch 12_autotools and see how it fails
<Mithrandir> sivang: can you send me a mail about it then?  I'm off to bed soonish and would rather do uploads when I'm awake :-)
<mdz> bddebian: germinate will show you what depends on it
<mdz> bddebian: what's the bug?
<sivang> Mithrandir: sure think , I thank you very much for your help
<sivang> Mithrandir: remind me your email address? :-)
<Mithrandir> tfheen@ubuntu.com
<sivang> Mithrandir: cool, thanks
<magnon> has anyone ever found _the_ solution to openoffice being a bitch, by the way?
<Mithrandir> thanks to you too.
<sivang> Mithrandir: about what?? ;-)
<Mithrandir> sivang: I appreciate it when people submit fixes for problems. :-)
<sivang> Mithrandir: ah well, I acutally somewhat created the problem....and it's only my responsibility to fix it and not let someone else to do it.
<sivang> Mithrandir: I had the idea that launchapd should pop to the user out of any applet , not just the gnome-panel, but it seems that most people think it should be only for the panle itself as it clutters the some of the applets menus.
<sivang> Mithrandir: so my change is to drop individual patching of the applets, and leave lpi on for only the panle itself/
<Mithrandir> sivang: ah, sounds fine.
<bddebian> Ohh, its a build-dep for ttf-freefont
<bddebian> mdz: ^^  Oh and which bug?  You mean the ttf-dejavu one?
<mdz> bddebian: the bug which you need the newer fontforge to fix
<bddebian> mdz: Oh, I asked for a sync of wesnoth (like an idiot).  It needs ttf-dejavu which build-deps on the newer fontforge.
<mdz> it's a new upstream, it hasn't made it into testing yet, and things in main build-depend on it
<bddebian> Which, fontforge?
<Mithrandir> I would rather say we should roll back wesnoth
<bddebian> Would it hurt to try ttf-dejavu with the older fontforge?
<sladen> or just distribute a pre-compiled .ttf in the ttf-dejavu source
<magnon> man, people STILL bother ranting about utf-8
<bddebian> Any thoughts folks??
<mdz> bddebian: it wouldn't hurt to try, but presumably the maintainer  versioned the dependency for a reason.  the changelog probably has details.
<mdz> reverting wesnoth may be the best option
<bddebian> pitti: !!
<bddebian> pitti: I was trying to package libpgtcl but the site says it was built for postgresql 7.4.. :-(
<Lathiat> bddebian: .. ?
<bddebian> Lathiat: ??
<bddebian> mdz: Nope, it won't build with the older fontforge.  FuXX0r
<shackan> sorry, when reporting a bug on lauchpad, I use the package name in the "Source Package Name" field, but it insists that 'python-nautilus' is an invalid value, why ?
<shackan> what format does it expect?
<robertj> hrmm, has anyone heard from the UbuntuExpress folk recently?  The last mention I can find was on the 6th.
<CarlFK> can someone name a package that might let a user create a dialup connection.  If I can't get it to work, it will be the package I file a bug report against, even if that just results in some other package being named
<CarlFK> the mail list pointed me to https://wiki.ubuntu.com/NetworkMagic but I don't see how that fits
<Lathiat> CarlFK: system->administration->networking
<CarlFK> Lathiat - sorry, I forogt: user as in no root/sudo privs
<Lathiat> CarlFK: uh no, you could however modify sudoers to say, allow only execution of that command (network-admin)
<CarlFK> right. which I have heard is "bad" in the big picture and was trying to get this item into the to be fixed list
<Lathiat> grrrrrrrr, i thought the ubuntu-forums ubuntu-devel forum was read only
#ubuntu-devel 2005-09-24
<CarlFK> at this point I am not so interested iin getting it working as getting it docomented that it dosn't work as smooth as it should
<CarlFK> im just not sure where to put the note
<ogra> CarlFK, if it didnt change since i used dialup the last time (which is quite a while ago), its enough if you add the user to the dialout group
<ogra> then  he can use dialup with something like the network admin tool or gnome-ppp
<CarlFK> network admin tool does way more then just bring up the conection, so I can see that needing root privs.  ill look at gnome-ppp
<ogra> hmm, i can undestand why network-admin wants sudo privs, but i cant understand why the modem applet should nee them
<CarlFK> woa... gnome-ppp is working
<CarlFK> I will swear it wanted privs before...
<ogra> it shouldnt for the dialot group... but modem-applet shouldnt do that either
<ogra> dialout even
<CarlFK> is modem-applet = gnome-ppp?
<ogra> modem-applet is the, hum, modem applet your panel offers in the applet selection...
<CarlFK> oh that...
<ogra> its a cool app, but its useless for non sudo users... thats wrong imho...
<ogra> it should raher check if you are in the right group instead of generally requiring sudo
<CarlFK> right - just confirmed. it wants sudo pw
<ogra> CarlFK, #15752 feel free to follow up :)
<tseng> r0bby: yarrrr
<CarlFK> I was trying to figure out what package to bug
<ogra> :)
<wasabi_> haha i think i found my problem.
<wasabi_> I think it's a bug in libpam-modules
<wasabi_> woo hoo
<CarlFK> firefox does not like the package list ;)
<xTina> wasabi_: what problem was that? (had fun with libpam-modules myself lately)
<wasabi_> Looks like pam lastlog breaks on my uid.
<wasabi_> That's my suspision, haven't gotten into the code yet.
<wasabi_> It's not my full problem though, it's just one of them. =(
<xTina> wasabi_:  ah. i had fun with pam_unix's password changing mechanism. it's very broken for nis, and it doesn't seem to be getting much better in higher upstream versions, just differently broken :(
<wasabi_> =(
<wasabi_> I'm working with pam_krb5
<xTina> wasabi_: ah, that's what i'll have to deal with "soon", we're supposed to move to krb at some point in the near future.
<tseng> wasabi_: ive not noticed anything strange with pam_krb5
<tseng> wasabi_: i ddint really try to, either
<wasabi_> tseng, my uid is 262715738
<wasabi_> It seems to dislike it. ;)
<tseng> erm
<wasabi_> Playing around with high UID allocation schemes for distributed ldap/kerberos stuff.
<xTina> neat
<eruin> is anything blocking avahi0.5 atm?
<desrt> avahi has a breakneck release schedule
<desrt> it's quite frightening
<eruin> yes, but Lathiat promised me! *sobs*
<eruin> which reminds me to take this to #-motu instead
<ajmitch> eruin: no, the debs are working
<ajmitch> eruin: I just have to pass them to ross to check, and we can upload, I guess
<eruin> ah, great. that makes me feel better :)
<ajmitch> I just had to get the packaging for mono bindings done :)
<shackan__> alsa mixer: Master Level volume to zero, and I still can hear sound !
<zul> maybe its the voices in your head ;)
<shackan__> uhm, the voices used to tell me to kill people, now they play electro music ?
<bddebian> heh
<jdub> mdz: ping
<magnon> does anyone know who is responsible for ppc-laptopts?
<infinity> magnon : No one specifically, though lots of us own them (not I, however)
<magnon> ah
<magnon> I think we got the newer powerbooks working as well as they can over here now :)
<magnon> just wondered if I should try to get some of it into wherever makes it get to other users ;)
<infinity> Filing bug on the packages you had to change would be a good start.
<infinity> With patches. :)
<infinity> s/bug/bugs/
<magnon> I'd need to talk to whoever knows how and what detects the type of powerbook tho :)
<magnon> to like, make it work better before submitting stuff
<infinity> Well, given that it's still Sunday (or very early Monday morning) in most of the world, you'd probably have better luck looking for people tomorrow.
<magnon> True :P
<magnon> I'll hack further on the xkb maps.
<wasabi_> Hmm. gnome-screensaver has some sort of Pam problem.
<wasabi_> Doesn't seem to like my pam setup, won't let me unlock.
<wasabi_> Anybody wanna talk about the implemtnation of a desktop kerberos key daemon thingy dealy i want to work on sometime? :)
<wasabi_> Basically it will just keep your key renewed, and give you messages when you need to renew it, or do something... etc etc
<jdub> wasabi_: you might want to ask around the red hat crew, and search for krb stuff on cvs.gnome.org
<wasabi_> Do you know anythin about gnome-screensaver and pam? LIke, does it use pam?
<wasabi_> I don't see it linking too it at all.
<wasabi_> Ahh there it is.
<poningru> guys can I sound off my suggestions in here about possible feature in dapper?
<poningru> well I want something to be added into dapper
<poningru> brb
<adamh> I want to put a "sleep 5" (or so) somewhere in the boot process (initrd) between when sd-mod is modprobed and when udevstart is called. How can I do that?
<adamh> I tried putting a file in /etc/mkinitramfs/init-premount and running dpkg-reconfigure linux-image-2*, but the resultant image doesn't actually contain or run the script.
<fabbione> morning guys
<infinity> fabbione : Awake before dawn again?
<bddebian> Heya fabbione 
<fabbione> infinity: yeah
<fabbione> hey bddebian 
<infinity> Ugh.  I just downgraded from Daniel's experimental modular X packages to the packages in breezy, and I'd completely forgotten how slow the radeon driver we're shipping is on this laptop. :/
* fabbione searches the last pieces he needs to complete another test box
<adamh> mkinitramfs doesn't seem to be including the files I add in /etc/mkinitramfs/*-* in the output image. What am I doing wrong?
<adamh> It *did* use my change to the "modules" file, though
<Kaloz> good (ugt) morning
<fabbione> hye Kaloz 
<fabbione> thanks for isolating that silo problem
<crimsun> adamh: what do you mean? /etc/mkinitramfs/modules?
<adamh> crimsun: yeah
<bddebian> infinity: You still here?
<infinity> bddebian : Yup.
<adamh> crimsun: So I mean that mkinitramfs *is* reading /etc/mkinitramfs/modules, but it's doing nothing with /etc/mkinitramfs/local-premount/wait-for-sd-mod, the file I created (permissions 775)
<Kaloz> fabbione: no problems :) i knew it should be smg weird :)
<bddebian> infinity: What is Needs-Build?  Does that mean it's waiting for a buildd?
<infinity> bddebian : Generally, yes.
<HrdwrBoB> is there a reason why ubuntu made my lo interface down? 
<HrdwrBoB> it makes some things very unhappy!
<infinity> bddebian : http://www.debian.org/devel/buildd/wanna-build-states
<bddebian> infinity: 
<bddebian> Err thx
<fabbione> is it just me or mozilla is crash-o-rama on amd64?
* Kaloz is a bitch when it comes to browsers
<Kaloz> opera ownes me for years now :)
<pitti> Good morning
<fabbione> hey pitti
<pitti> Hi fabbione 
<ajmitch> hello pitti, fabbione 
<fabbione> yo
<fabbione> infinity: ping?
<pitti> jdub: ah, sound-juicer finally got a --device argument, that means g-v-m can use it now for CD playing
<Mithrandir> yarrr
<fabbione> hey Mith
<pef> hello
<fabbione> Znarl: ping?
<fabbione> elmo: ?
<dholbach> good morning
<jdub> pitti: yes, ross is wonderful. mere mention of it and he remembered he'd been wanting to do it... :-)
<jdub> morning dholbach 
<dholbach> jdub: hey jeff, how's it going?
<jdub> sweet!
<jdub> ahr!
<dholbach> :)
<pitti> Hi dholbach 
<Burgundavia> jdub, are we talking s-j as default cd player?
<dholbach> pitti: hey martin :)
<lifeless> pitti: hey there
<lifeless> pitti: my CF card doesn't work under breezy either.
<pitti> Hi lifeless 
<jdub> Burgundavia: yes
<pitti> lifeless: can you please do http://wiki.ubuntu.com/DebuggingRemovableDevices and mail me the results? (or put them in a bug report)
<lifeless> pitti: I did before under breezy, you closed the bug last week :[
<lifeless> pitti: I presume doing it again will be useful ?
<pitti> lifeless: I closed it because I never got an answer, feel free to reopen :-)
<lifeless> pitti: k
<pitti> lifeless: yes, it would be useful to do it on the latest breezy
<pitti> lifeless: the existing logs are pretty old
<pitti> lifeless: thanks
<doko> mdz: still awake? do you have a preference for lp#2401?
<Lathiat> _WHOUGH_
<Lathiat> how much faster did gdm get
<dholbach> Lathiat: it's WAUGH, not WOUGH
* Lathiat grins
<Lathiat> that just spun me out how fast it started
<Treenaks> Lathiat: isn't it just readahead that actually started reading ahead now?
<Lathiat> i havent rebooted
<Lathiat> but i read in the gdm changelog
<Lathiat> that daniels did somethign to make it real fast
<Lathiat> and he said it was in the order of 5seconds
<Treenaks> Lathiat: wow, how did they do that? stip all stat() calls?
<jdub>   * Disable font server in dexconf for mad startup time victory.
<Treenaks> jdub: font server?!
<ajmitch> rather nice
<ajmitch> Treenaks: yeah, gdm was stalling with it
<Treenaks> we started that?
<Lathiat> also i found a new gdm theme and gnome splash that made the login even sexier ;)
<jdub> no
<jdub> but it has always been in the font path
<Treenaks> Ah!
<Lathiat> so what happened with readahead
<Treenaks> jdub: so the unix:7100 line was stripped and now it's lightning fast?
<jdub> aye
<Treenaks> cool :)
<jdub> Mithrandir: ping
<karlheg> I just pulled a baz checkout of 'network-manager', but it lacks the debian/ directory structure.  Where do I find that?  Why isn't it under revision control?
<karlheg> Is there a wiki page documenting this?  Am I in the right channel?
<Lathiat> karlheg: you apt-get source the package, debian package dirs are kept separate to the projects (well, usually)
<karlheg> Why are they separate?
<pitti> karlheg: it would neither help upstream nor distros if upstream tarballs were cluttered with build systems and patches for 50 different distros
<karlheg> Ok... I seem to remember seeing somewhere that 'baz' and 'tla' supports a checkout where each of several parts can come from separate repositories...?
<karlheg> Never mind.
<Lathiat> karlheg: sure but that doesn't mean that its being used, or that the debian upstream uses the same rcs, etc, etc
<karlheg> Hmmm....  I could check out the debian/ stuff from RC, in a directory next to the upstream, then go in there and make a symlink out to it.
<karlheg> That will do for now, I think.  The main thing is that I can make changes and get useable patches.
<Lathiat> does anyone have GL/dri with nvidia working properly? mine seems to be working, glxinfo says its ok etc but my GL performance is no better than software rendered
<Mithrandir> jdub: pong
<pitti> Lathiat: works fine for me (amd64, GeForce 5200)
<Lathiat> pitti: so gl applications give a decent framerate?
<Mithrandir> Lathiat: worksforme with 6600GT on amd64
<Lathiat> like glxinfo says yes yes yes, but glxgears does 300fps which is what mesa does, and actual games etc just choke to death
<Lathiat> weirde
<Lathiat> my ati doesn't work either
<Mithrandir> glxgears is not a benchmark. :-)
<Lathiat> this is annoying, sigh.
<Lathiat> Mithrandir: as i said, actual games choke to death
<pitti> Lathiat: video playback is much smoother, I didn't play tuxracer for a while
<pitti> Lathiat: I currently use nv since nvidia breaks hibernation
<pitti> Lathiat: but I can try tuxracer with nvidia if you want
<Lathiat> pitti: i have a guide on the wiki that gets hibernation working for me
<Treenaks> my ati works without 3D accel, or works with 3D Accel but at the wrong resolution (the new FGLRX doesn't understand 1280x800)
<jdub> Mithrandir: hey
<Lathiat> https://wiki.ubuntu.com/NvidiaLaptopBinaryDriverSuspend
<Mithrandir> jdub: yarrrr
<jdub> Mithrandir: was just look at the readahead list -> it looks like the results from warty
* Lathiat tries planetpenguin-racer
<Mithrandir> jdub: I was planning on writing something which is run as S01 and starts collecting the files and then stops at S99 and puts that into the list of stuff to readahead next time.
<Lathiat> Mithrandir: wasnt behdad working on that kinda thing
<pitti> Lathiat: oh, I'll try that
<Mithrandir> jdub: but I guess that's dapper, since we're way past featurefreeze
<Mithrandir> Lathiat: no idea, it should be about 100 lines of C, I'd imagine.
<jdub> how did thom make it earlier?
<Mithrandir> not sure.
<Mithrandir> I can ask him.
<Lathiat> Mithrandir: iirc his google SoC project was a fancy readahead thing
<jdub> Mithrandir: http://www.cs.toronto.edu/~behdad/blog/preload.txt
<Mithrandir> Lathiat: well, this wouldn't be fancy, it's trivial, really.
<jdub> Mithrandir: i noticed because the list includes loading industrial, not clearlooks ;-)
<Mithrandir> oh, that preload.  It looks crackful on first glance
<Lathiat> looked good to me
<Lathiat> its more than just simple startup readahead tho
<jdub> Lathiat: but you have a history of substance abuse
<Mithrandir> anyway, it looks similar to what I'd do with readahead too; this was discussed during the mataro sessions
<Mithrandir> I think he's putting _way_ too much "intelligence" into the system, really.
<Mithrandir> throwing bayesian filters and markov chains just sounds wrong.
<jdub> though fun.
<Mithrandir> over-engineering can be fun, sure.
<Mithrandir> it's still over-engineering, though.
<Mithrandir> what's the state of that codebase?
<jdub> Mithrandir: behdad is on #gnome-hackers
<jdub> on gimpnet
<Mithrandir> jdub: I'm not on gimpnet and ETOOMANYCHANNELS already. :-)
<jdub> :-)
<jdub> oh, he's here on #cairo too
<Mithrandir> jdub: I try to get _something_ else done besides ircing :-P
<sivang> Morning all!
<smurfix> Since I updated to Breezy, *something* is gdk_beep()ing at me all the time. Any ideas how to find the program which does it?
<Treenaks> smurfix: evolution ?
<sivang> Mithrandir: morning, did you get my email?
<Mithrandir> sivang: yes, I got it
<smurfix> Treenaks: Possibly -- I'll check. However, that answer doesn't solve the general problem. ;-)
<jdub> hey smurfix 
<jdub> smurfix: does it do it when you're not usign your terminal? :)
<smurfix> jdub: No, the terminal is not the baddie. Seems to be (or have been :-p) evolution. :-/
<smurfix> jdub: the question does however come up regularly when I talk to users
<Mithrandir> sladen: re 4262; do you think powernowd should have a similar big and evil override file?
<jdub> smurfix: interesting
<smurfix> so the best answer would be along the lines of "throw out a dbus message with details, and show them in the panel or whatever"
<smurfix> I'll file a Gnome bug, maybe somebody will feel motivated ;-)
<seb128> jdub: maybe an IRC notify
<Mithrandir> sivang: can't you just edit the patch directly in the tree?
<pitti> Lathiat: penguin racer runs with about 50 frames and is pretty smooth
<pitti> Lathiat: I will switch back to nv and compare at next boot
<sivang> Mithrandir: it's autogenerated, so I think not
<sivang> moins pitti 
<pitti> Hi sivang 
<pitti> seb128: hm, Ross Burton is "ross", right?
<pitti> seb128: the new sound-juicer option --device does not work for me
<seb128> pitti: correct
<seb128> pitti: slap him :)
<pitti> seb128: which timezone is he in?
<jdub> pitti: UK
<seb128> pitti: uk
* seb128 slaps jdub
* jdub slaps snowy
<Mithrandir> mjg59: what's the state of 5591
<Mithrandir> mjg59: ?
<seb128> pitti: I get "** (sound-juicer:18234): CRITICAL **: nautilus_burn_drive_door_is_open: assertion `drive != NULL' failed" messages
<pitti> seb128: same for me
<Lathiat> pitti: was pmount ever goign to get iso support?
<pitti> Lathiat: it will, but not in Breezy
<Lathiat> ok
<seb128> anybody here has a xinerama setup?
<ogra> seb128, Mithrandir 
<seb128> Mithrandir: ping?
<ogra> seb128, while we're at it, why is gnome-screensaver complied without xinerama and xrandr ? any known problems or can i safely enable it ? 
<seb128> ogra: it's not
<Mithrandir> seb128: pong
<seb128> Mithrandir: does gnome-screensaver work with xinerama for your (#15777)
<ogra> seb128, --with-xinerama-ext isnt set and xinerama doesnt work apparently
<seb128> s/your/you/
<Mithrandir> seb128: as of last night, no.
<seb128> k
<Mithrandir> seb128: hm, though, both screens are locked
<Mithrandir> but the greeter is displayed in the middle
<seb128> build log has
<seb128> checking for XineramaQueryScreens in -lXinerama... yes
<ogra> seb128, do you mind if i care for it ? i have made a lot of config modifications locally already
<seb128> ogra: no, but do you have a xinerama setup ?
<ogra> seb128, nope, but i'm testing with Mithrandir already
<seb128> checking for X11/extensions/Xrandr.h... yes
<seb128> too
<ogra> but apparently it doesnt use it
<seb128> ogra: create a gnome-screensaver bugzilla component and assign it to you so
<ogra> i think i cant edit components...
<seb128> hum, I can
<seb128> let's do it
<ogra>  Sorry, you aren't a member of the 'editcomponents' group, and so you aren't allowed to add, modify or delete components.
<seb128> what email do you use?
<ogra> yup, i cant :)
<ogra> ograqubuntu.com
<ogra> damned, my altgr is broken since yesterday
<ogra> ogra<at>ubuntu.com
<seb128> yeah, I assumed it was that from the previous line :p
<ogra> heh
<dholbach> morning ogra
<sivang> ogra: would be an interesting domain to buy though ;-)
<sivang> morning dholbach 
<ogra> moin dholbach 
<sivang> moin ogra 
<dholbach> hey sivang 
* ogra looks at the election results
<ogra> dholbach, what did you do !
<sivang> election for what?
<\sh> german elections ;)
<ogra> sivang, german government
<\sh> two losers
<sivang> eh, hehe
<\sh> or two winners...depends ;)
<ogra> 60 million loosers i'd say
<sivang> did dholbach tamper with the results? :-D
<ogra> sivang, sure, its all his fault ;)
<dholbach> i see
<ogra> ;)
<azeem> I thought it was Microsoft's fault.  Their logo was prominent on the vote polls
<ogra> hehe, yes, the NDR seems to have a goot connection to the court
<seb128> ogra: bug reassigned
<ogra> seb128, thanks :)
<pitti> Hi Kamion 
<fabbione> jdub: pinh?
<fabbione> ping even
<jdub> fabbione: pong
<seb128> fabbione: is somebody working on this inotify bug?
<fabbione> jdub: did you add my image to planet?
<fabbione> can i remove it from my webserver?
<fabbione> seb128: not me.. did you ask BenC?
<jdub> yeah
<fabbione> jdub: thanks
<jdub> planet uses its own
<seb128> fabbione: not yet
<seb128> BenC: are you working on the inotify bug?
<seb128> fabbione: do you know if we have 2.6.12 or 2.6.13 inotify code?
<fabbione> 2.6.13 
<fabbione> 2.6.13rc6 i think
<fabbione> that's last time i synced iirc
<seb128> k
<seb128> I had some mails with John McCutchan
<seb128> "Late in 2.6.13, Linus and I discussed changing where in the code we send
<seb128> the DELETE_SELF event. " he said
<seb128> and "
<seb128> It was supposed to fix a kernel problem, but I think we overlooked one
<seb128> case where this could be called when it wasn't from a delete operation."
<seb128> so I want to be sure we have current inotify code before replying
<fabbione> seb128: one second..
<SteveA> any breezy install CD gurus around?
<ogra> SteveA, not a guru, but i know some stuff on the surface
<pitti> infinity: is there something wrong with the buildds? they don't seem to attempt to build util-linux for {warty,hoary}-sec
<SteveA> i'm installing the latest colony on a new laptop
<SteveA> i asked to repartition
<SteveA> the installer stopped working.  i could type on that screen, and the text would appear.  in terminal 2, nothing strange in /var/log/messages
<SteveA> ctrl+c in terminal 1, and the partitioner seems to be preparing to run again
<ogra> SteveA, the CD is proven good ? not burned to fast, md5sum checked etc ?
<mjg59> Mithrandir: The smart battery support?
<mjg59> Mithrandir: The code hasn't been touched since then
<SteveA> i'll grab the CD and check it
<ogra> SteveA, make sure not to write fater than 8x if you burn it
<ogra> faster even
<Mithrandir> mjg59: ok
<ogra> Mithrandir, do you use xinerama on your amd64 ?
<Mithrandir> ogra: on one of them, yes.
* SteveA writes a new disc at 4x
<Mithrandir> ogra: my home box, not my work box.
<ogra> Mithrandir, could you test a (probably) fixed package ? 
<ogra> http://people.ubuntu.com/~ogra/screensaver/
<Mithrandir> ogra: when I get home, yes.
<ogra> Mithrandir, thanks
* seb128_ kicks the dsl ip change
<seb128_> if somebody said something for me, say it again
<siretart> ogra: is that package because of that probable mergedfb bug?
<ogra> siretart, for missing xinerama, your report differs from what i heard from others about broken xinerama...
<fabbione> seb128: the last update to inotify was done around the 19 Aug
<fabbione> seb128: there is another "off by one fix"
<fabbione> and that's it
<fabbione> after that there are no entries in the changelog
<seb128_> fabbione: k, I'll ping BenC about it and open a bug upstream if he's not working on it, thanks
<pitti> infinity: please forget about util-linux, all fine now
<fabbione> infinity: you around?
<ogra> siretart, but if you run xinerama on amd64, feel free to test 
<siretart> ogra: ok. when I get home, will check gnome-screensaver with twinview, does this count as xinerama?
<fabbione> ogra: i am on amd64+xinerama
<fabbione> what's the problem?
<ogra> fabbione, could you test gnome-screensaver for locking as is and with the package from http://people.ubuntu.com/~ogra/screensaver/ ?
<ogra> fabbione, xinerama seems not to work right, the unlock screen is shown in the middle between the two screens
<fabbione> ogra: ah.. i can't test that
<ogra> fabbione, that'd be cool
<fabbione> i know for sure that it appears on the monitor where you clicked with the mouse
<fabbione> ogra: read again.. i caN'T test that
<ogra> oh
<fabbione> not immediatly at least
<fabbione> i am on 3 heads
<fabbione> that would happen only with 2
<fabbione> because the center is in the middle
<seb128> pitti: re #15692, libao seems to have issues with esd as default though
<fabbione> but the center here is on a full monitor
<ogra> but it deosnt appeare always on the center monitor ? 
<fabbione> ogra: no
<ogra> ok
<fabbione> as i wrote before, it appears on the monitor where i have the mouse
<fabbione> so at the first movement is there
<ogra> then lest see what Mithrandir tells me later, he has the problem it seems...
<fabbione> ok
<seb128> ogra: the current package is built with xinerama ...
<ogra> seb128, sure its not only checked by configure but disabled ? 
* fabbione -> food
<fabbione> later
<fabbione> ogra: if you don't find anybody within the next hour or so i will test it
<seb128> ogra: the config.h list it as defined
<ogra> fabbione, ok, thanks
<seb128> ogra: and the configure.ac is quite clear, if it finds the lib it builds with it, which is the case since the Build-Depends are correct and the configure list it correctly
<fabbione> ahhh
<fabbione> ogra, seb128: you need something more than just xinerama for that
* fabbione digs the name
<seb128> fabbione: for what?
<fabbione> libxxf86vm-dev - X11 XFree86 video mode extension library (development headers)
<fabbione> libxxf86vm1 - X11 XFree86 video mode extension library
<fabbione> you need to be sure to have that library
<fabbione> or that gnome-screensaver actually uses it
<ogra> seb128, i dont see any useful mentioning of xinerama stuff in the code either... only a "disable MIT extension if xinerama is enabled"
<fabbione> xinerama is not enough to work on multihead
<ogra> ok, adding that
<fabbione> ogra: check for that one
<fabbione> it's a bit complex to explain
<fabbione> but basically xinerama gives you access to the extension
<ogra> ok
<ogra> fabbione, thaks a lot :)
<fabbione> but libxxf86vm is the one that returns proper disaply info to the program requesting them
<seb128> fabbione: checking for X11/extensions/xf86vmode.h... no
<fabbione> in the case you get something in the middle
<seb128> fabbione: that's probably it, thanks for the hint
<infinity> fabbione : Yes, I'm aorund, just not staring at this channel.
<fabbione> infinity: ok.. for how long are you going to be around?
<Kamion> \sh: when doing "resynchronise with Debian" uploads, please use debuild/dpkg-buildpackage's -v switch to include all changelog entries since the last version in breezy in the .changes file
<fabbione> ogra, seb128: without that lib the apps sees only on huge display made of the sum of the xinerama displays
<Kamion> ah, I see you did that for oo2c but not for gaphor
<ogra> fabbione, ah, that explains everything :)
<fabbione> ogra, seb128: that lib returns to the apps the proper info per screen/monitor
<seb128> fabbione: cool, thanks
<infinity> fabbione : Next couple of hourse, I'm sure.
<infinity> hours, too.
<seb128> fabbione: enjoy your lunch :)
<fabbione> infinity: ok.. than i am going to eat something and ttyl
<infinity> fabbione : Mmkay.
<pitti> seb128: it seems that the default libao output driver is already esd, so is there any action to be taken? (#15692)
<seb128> pitti: esd seems to have issue, so I was wondering if we should switch it
<seb128> pitti: if we keep esd we need to figure why gaim sound events don't work out of the box
<Lathiat> they dont? mine do and piss me off
<Keybuk> hmm, where do we remount filesystems readonly?
<Keybuk> sorry, I mean readwrite
<seb128> Lathiat: read #15692
<pitti> seb128: that's really  odd, why should esd fail for gaim when it works for other programs?
<seb128> pitti: what other program uses libao?
<seb128> pitti: not sure, maybe libao is bugged
<pitti> seb128: mpg321, gnomoradio, vorbis-tools, quake2 :-)
<pitti> seb128: I try mpg321 now
* ajmitch confesses to being last to touch quake2
<ajmitch> and I think I had sound issues there
<pitti> seb128: mpg321 works OOTB, and stops as soon as I kill esd
<seb128> pitti: cool
<daniels> er, what?
<pitti> seb128: lemme remove my gaim conf
<daniels> you don't need xxf86vm unless you want hardcore details like the exact timings of the current mode
<pitti> seb128: works perfectly OOTB
<pitti> seb128: not for you?
<seb128> pitti: gaim automatic and libao default works fine here
<seb128> pitti: WORKSFORME
<seb128> pitti: thanks
<seb128> pitti: BTW, did you ping ross about sj?
<bob2> wow, the version of host in breezy is a lot more chatty
<pitti> seb128: ross was not online in #gnome-hackers last time I checked
<Keybuk> hmm, interesting, syslogd hangs when I start it
<seb128> pitti: he's on jabber
<Robot101> redoing the sound was my first gaim patch... :)
<seb128> Robot101: using libao sucks :p
<Robot101> that wasn't me
<Robot101> it'd be trivial to patch it to use gstreamer
<Robot101> I nearly did once
<seb128> pitti: I pinged him on that
<Robot101> they might do for 2.0 if they're going multimedia stuff
<infinity> bob2 : bind9-host, or 'host'?... 'host' hasn't changed for eons, and has the behaviour/output I prefer, but people tell me I'm outdated and I suck.
<bob2> infinity: bind9-host, I guess
<bob2> maybe I just didn't have it installed on hoary
<Mithrandir> infinity: no, we just tell you you're outdated, not that you suck.
<pitti> seb128: I mail him (CC you)
<seb128> pitti: don't bother ... or you have a fix?
<pitti> seb128: I didn't look into the code, but it looks easy
<pitti> (I saw the patch)
<seb128> (what patch? the --device=?)
<pitti> yes
<fabbione> infinity: ping?
<bob2> baaaaaaaaaaaaaaaaaaaaaah
<bob2> dovecot-common indirectly conflicts with mysql-serv-4.1 in hoary
<infinity> fabbione : pong.
<fabbione> infinity: i think our chroots on the buildd are dirty.. but i need you to check with me if you have time
<fabbione> infinity: can you please bootstrap a clean buildd chroot and tell me if you have /usr/lib/menu ?
<fabbione> if so what pkg does own it?
<infinity> Is there a specific buildd you're concerned about, or just in general?
<fabbione> general
<fabbione> i think it's on all arches
<fabbione> like one pkg that hasn't been deinstalled properly
<infinity> buildd@yellow:~$ sudo chroot build-breezy/chroot-breezy/ su - root@yellow:~ # ls /usr/lib/menu ls: /usr/lib/menu: No such file or directory
<fabbione> infinity: ok can you please install hpliph build-deps
<fabbione> and tell me if you get that dir?
<fabbione> if so what file is in it?
* infinity tests this locally.
<fabbione> infinity: yes but please use a buildd chroot
<infinity> No difference between local and the buildds.
<fabbione> ok
<infinity> I assume you meant 'hplip'? :0
<fabbione> meh yes
<\sh> Kamion: thx...I forgot it for one package though...sry
<Lathiat> anyone with xorg clue about?
<infinity> (breezy)root@cthulhu:~ # ls /usr/lib/menu
<infinity> ls: /usr/lib/menu: No such file or directory
<Diziet> infiniti: You want adsnhost :-).  </plug>
<Diziet> s/iti/ity/; #oops
<Lathiat> for some reason on both my machines with ati and nvidia, the drivers load fine glxinfo shows DRI fine etc but performance is akin to mesa on both, i even tried installing the drivers official from nvidia.. so i think theres something whack happening, any clues?
<fabbione> infinity: ok, can you please build hplip now?
<fabbione> infinity: it should fail at dh_something
<infinity> Diziet : Hrm?
<fabbione> infinity: if you can also repeat the checks using /usr/share/applications
<fabbione> infinity: because that dir is not on a default buildd chroot
<fabbione> or shouldn't
<infinity> I have /usr/share/apps, but no applications.
<infinity> (with the build-deps installed)
<fabbione> what pkg is pulling it in?
<infinity> python
<fabbione> infinity: no i meant /usr/share/applications <-
<fabbione> in full path
<\sh> doko: ping
<Mithrandir> jbailey: isn't 13387 fixed with the last upload?
<pitti> seb128: cool, Ross sent a patch
<ogra> Kamion, ping
<Kamion> ogra: pong
<infinity> fabbione : Yes, like I said, I have no "applications" file/directory, just "apps"
<fabbione> infinity: ok perfect. can you please build hplip in that chroot+
<infinity> hplip is FTBFS before it hits any dh_ stuff.
<infinity> Dies in make install.
<ogra> Kamion, i had to split out anouther package from xscreensaver (xscreensaver-utils) since some hacks need the text and the image loader, could you new it after my next upload ? xscreensaver-data depends on it
<fabbione> infinity: ok thanks!
<Diziet> infinity: adnshost is a tool for querying the DNS from command lines, shell scripts, and the like.  It has sensible behaviour unlike the various versions of host (most of which are on crack).  host is usually trying to be a DNS _diagnosis_ tool which is not what you usually want, and of course if you wanted that you wanted dig not some lame luserified thing.
<infinity> rm -f ./
<infinity> rm: cannot remove `./': Is a directory
<infinity> make[4] : *** [install-data-hook]  Error 1
<fabbione> infinity: that means we had dirty chroot for a while, or one build-dep has changed...
<Kamion> ogra: is elmo not around? (please don't ask me unless he's not)
<fabbione> infinity: thanks for the tests
<fabbione> infinity: now the funny thing is that there is no way to tell configure about that dir without chainging configure.in test :/
<Keybuk> ... I think I may finally have a hold on what's causing missing /dev/input/mice
<ogra> Kamion, away since 7h ... i just want to avoid broken CD builds...
<Keybuk> it'd also explain why joysticks don't appear after boot
<fabbione> infinity: or pull in a build-dep of whatever pkg foo that has that dir
* infinity runs around looking for dirty chroots.
<infinity> fabbione : Dozens of packages have that dir.
<Kamion> ogra: you won't break CD builds; all binaries from a given source are held in the queue until the new ones are processed
<fabbione> infinity: yes.. but not hplip B-D :)
<infinity> fabbione : A nice lightweight one for /usr/lib/menu would be procps. :)
<ogra> Kamion, ok
<fabbione> infinity: check at least the 4 chroots that did build hplip last
* \sh needs an oberon-2 specialist ,-) http://bugzilla.ubuntu.com/show_bug.cgi?id=10140 and the buildlog http://people.ubuntu.com/~lamont/buildLogs/o/oo2c/1.5.9-4.1ubuntu1/oo2c_1.5.9-4.1ubuntu1_20050918-1824-powerpc-failed.gz
<fabbione> infinity: they managed to build with /usr/lib/menu or /usr/share/applications (i386 at least)
<ogra> Kamion, i'll mail him ...
<Kamion> ogra: elmo processes NEW pretty regularly; I don't think there's any need at all to nag
<ogra> Kamion, ok
<infinity> fabbione : Curious, amd64 was build on yellow, and that's the one I just checked.
<infinity> fabbione : The chroot WAS dirty, but not with those two directories.
<fabbione> infinity: probably when it was built, there was extra clutter
<fabbione> these 2 dirs, disappear on pkgs purge
<fabbione> so they are not left there or something
<infinity> fabbione : Or, a build-dep changed from under our feet.
<fabbione> that's possible too
<fabbione> now the question is..
<fabbione> where do we want these .desktop files?
<infinity> Dirty chroots don't clean themselves.  If there was a package installed with that dir, it would still have been isntalled when I got there.
<fabbione> ./usr/lib/menu or /usr/share/applications ?
<\sh> fabbione: the correct location is /usr/share/applications 
<\sh> fabbione: or /usr/share/applications/kde for kde application .desktop files
<infinity> \sh : BTW, I fixed up oleo for you (which was FTBFS)... You owe me a favour.
<\sh> infinity: arg...jbailey told me that we can morgue it ,-)
<infinity> \sh : Can you forward my changes to the Debian maintainer?
<\sh> infinity: but I have to transition the ace package...or did u change the rdepend package?
<infinity> \sh : I rebuilt dbbalancer.
<infinity> \sh : Was there anything else that needed a build?
<\sh> infinity: I don't think so...we will morgue yehia and gql 
<\sh> libhid I fixed
<\sh> the only lib which is left is aqsis (http://bugzilla.ubuntu.com/show_bug.cgi?id=11387)
<\sh> and this is upstream bug...but upstream never responded...
<infinity> Oh, I meant to smack you for that one.
<fabbione> infinity: well it makes absolutely no difference..
<fabbione> infinity: we only need to make the build happy..
<Lathiat> infinity: can you clear dep-waits?
<infinity> Using the term "FTBFS" with upstreams who aren't Debian is likely to cause great confusion. :)
<fabbione> the only .desktop is shipped somewhere completely different
<daniels> oh shit, I bet xresprobe got rejected earlier
<infinity> \sh : "FTBFS" is a pretty Debian-centric term.
<daniels> elmo: unstable -> breezy suite mapping in katie plskthx
<infinity> Lathiat : I can.  What's got a broken dep-wait?
<Lathiat> bochs
<Lathiat> assuming ajmitch didnt get it cleared earlier
<infinity> daniels : If that happened, I'd misfire Debian uploads at Ubuntu and they'd get accepted.  Best if we never have suite name overlap.
<\sh> infinity: well...it's not compiling thats all 
<infinity> \sh : Right, then say that. :)
<\sh> infinity: it's not compiling
<\sh> ,-)
<Lathiat> infinity: yeh so its dep-waited on aalib-dev but thats old and its been fix in the last sync to libaa-dev
<infinity> Lathiat : Done.
<Lathiat> infinity: cheers
<Mithrandir> doko: 15452, re the java support in ooo2.  Can you answer that?
<infinity> \sh : Have you seen Debian bug #317542?
<infinity> \sh : Looks like your GCC 4.0 failure is fixed ina newer CVS snapshot (and in Debian)
<doko> Mithrandir: that's mpeg2dec?
<Mithrandir> doko: uhm, sorry, wrong bug
<Mithrandir> doko: 15521 is the one I meant
<infinity> \sh : Shall I upload a fixed version for you?  (It will also require the patch from #324025)
<\sh> infinity: i will do it :)
<infinity> \sh : Alright, no need to request a sync, since you'll have to do a manual -Xubuntu1 upload anyway to include the patch from bug# 324025
<\sh> infinity: I think this patch I have included...anyways...I will work on this 
<Mithrandir> Kamion: have you gotten anywhere with the /part problem in partman?
<infinity> \sh : Note that nothing rdepends on aqsis-libs, so not renaming the package (as the Debian maintainer didn't do so either) is probably no big deal.
<\sh> infinity: k
<doko> ahh, ok: replace the first ooo2 with ooo2-writer, the second ooo2 with ooo2-base
<doko> Mithrandir: ^^^
<infinity> \sh : So, I'd just take his latest upload, apply the patch, call it -2ubuntu1, and upload.  But that's just me.
<doko> Kamion: what's the easiest way to see, if a package is on the livecd/desktop/ship ?
<Mithrandir> doko: for -base it's already there?
<Keybuk> usplash gets very upset if you don't switch to gdm afterwards
<Keybuk> shouldn't there be a chvt 1 as S99 if vt != X
<doko> Mithrandir: no
<Mithrandir> : tfheen@golem ~ > apt-cache show openoffice.org2-base |grep ^Recommends
<Mithrandir> Recommends: lib32gcj6 | java-gcj-compat | j2re1.4 | java2-runtime
<Mithrandir> doko: say again? :-)
<spacey> I'm running breezy on a server with 4GB memory, however the ubuntu kernels only see 3GB. is this supposed to be?
<doko> Mithrandir: please _read_ the report
<Mithrandir> doko: hmm
<infinity> Keybuk : Or something like that, yeah.  I was going to poke at it later to figure out what the least icky way to fix it is.
<Mithrandir> doko: why doesn't one of them suffice, and if it doesn't why isn't there a dependency in place?
<infinity> Keybuk : Especially ugly for server installs with usplash installed (though, I'm not sure why you'd do this)
<mjr> spacey, I take it it's a 32-bit server; you need to use a kernel where 4 gig addressing is enabled
<mjr> spacey, (it slows things down a bit so it may not be by default)
<spacey> mjr, to set it to 3 is a bit wierd?
<doko> Mithrandir: we already had this discussion ... one time the interpreter is called, one time, the library is dlopened, so you need both. we don't have a complete 32bit java runtime.
<infinity> Lathiat : Feh, there's no libsvga1-dev on amd64.
<Lathiat> infinity: hrm
<spacey> CONFIG_HIGHMEM4G=y is in the kernel config file
<Lathiat> doesnt it have an arched build-dep for that
<doko> Mithrandir: it was not a dependency, because you can use -base using another db as well. In 1.9.129, it will be a dependency, ooo2-writer will have a recommends, and ooo2 still has the suggestion
<Lathiat> oh i see, libsvga1-dev [i386 amd64] , to include it not exclude it ;)
<spacey> have to go now, i'll check further later. 
<Lathiat> infinity: weird, i cant see any attempts to build svgalib on !i386
<Lathiat> infinity: is something blocking it?
<Kamion> Mithrandir: partman-auto 41ubuntu5 is intended to get me more information, and maybe fix some of it
<Kamion> doko: look at the .list (install) / .manifest (live) files on cdimage
<Mithrandir> doko: I just think it looks _bloody_ ugly and would so much rather have java-gcj-compat produce a metapackage or something like that.
<doko> MIthrandir: why? it's only OOo2 dlopening libgcj6, I don't know of any other app
<Kamion> ok, it's deeply confusing that we're now getting security vulnerabilities discovered by "David Watson"
<Kamion> (since that's my father's name)
<Mithrandir> doko: I guess I'll make it a hard dependency on lib32gcj6, then.  Just to unbloat the depends line a little.
<doko> Mithrandir: ok with me
<doko> Mithrandir: hopefully there's still place on the amd64 CD, maybe Kamion knows better
<Kamion> you could look yourself :)
<doko> syncing :-)
<infinity> Lathiat : Yes, it's in Packages-arch-specific as i386-only.
<Kamion> http://cdimage.ubuntu.com/daily/current/, subtract displayed size from 650
<Kamion> you've got 9MB left on amd64
<Lathiat> infinity: it says Arhchitecure: any here..
<Lathiat> in showsrc
<Kamion> note that that isn't necessarily free-for-all space though; the more space we have left at the end to fill up with language packs, the better
<infinity> Lathiat : P-a-s is a file specifically to override that.
<Lathiat> infinity: oh right
<Lathiat> infinity: why is it overriden?
<Kamion> Lathiat: because people suck
<Kamion> (approximately :-))
<Lathiat> ;)
<infinity> Lathiat : What Kamion said.
<infinity> Lathiat : There's  along-held belief in Debian that a select few people are a bit less clueless than most of the developers.  While this view ois obviously unpopular, it turns out to be generally true.
<infinity> Also, typing skills do not correlate iwht clue, just in case you're about to invoke some irony clause.
<mjg59> seb128: Have you had a chance to include that hibernat key patch?
<Yagisan> G'day, is it too late to ask for a driver to be included in the kernel ?
<hunger> powernowd still claims [ ok ]  even when it failed to start:-(
<magnon> is there known problems with update-notifier? It keeps running away with my CPU on my powerbook :P
<Yagisan> Would it be possible to add the ITE8212 IDE driver to breezy's kernel ? It can be found in vanilla 2.6.13 /drivers/ide/pci/it821x.c
<Yagisan> There are people regularly asking how to use ITE8212 IDE interfaces on ubuntu-users so it would be really nice to have.
<sivang> mjg59: around?
<seb128> mjg59: not yet, I'll look that this afternoon
<fabbione> Yagisan: yes, it's a bit too late
<fabbione> Yagisan: kernel feature freeze was done quite a while ago
<fabbione> and full freeze is in less than 10 days
<Keybuk> *giggle* I like the fact that if you put "reboot" in your startup sequence, all the shutdown messages still go to usplash <g>
<fabbione> Keybuk: ahaha
<Keybuk> BenC: ping?
<fabbione> Keybuk: re 14131.. i will test it tomorrow
<jbailey> Mithrandir: Yes, several of them are.  I need to go through and do a mop-up of the initrd-tools/initramfs-tools bugs today.
<Mithrandir> jbailey: ook
<mjg59> sivang: Hi
<mjg59> seb128: Thanks
<sivang> mjg59: I've seeing weird hickups from my Dell 8200 Inspiron machine, everytime you attempt CPU speed scaling, everything freezes up until it's over, known?
<siretart> ogra: thank you for fixing gnome-screensaver :) - I closed the bug
<ogra> siretart, it works ? 
<sivang> mjg59: other then that, breezy now beats XP allowing this machine to work 1:20hrs instead of 20m 
<sivang> mjg59: so , power saving support rocks
<siretart> ogra: yepp, as expected!
<ogra> YAY !!
<siretart> :)
<ogra> thats a bug i carry with me since ages, even with xscreensaver :)
<mjg59> sivang: what processor is it?
<sivang> mjg59: Pentium M 1.8Gigs
<sivang> mjg59: sorry, Pentium IV MObile
<sladen> sivang: there'll be (a little) bit more from dynamic tick eventually
<sivang> (that is the older series)
<sivang> sladen: what do you mean? (Excuse my ignorance)
<mjg59> sivang: What cpufreq module is being loaded?
<sivang> mjg59: let me check, I'll pull it out and power it
<mjg59> sivang: Thanks
<mjg59> elmo: Is power management still broken on your Powerbook?
<daniels> it's still broken on my X40, but I'd rather complain than give you the debugging output you want
<magnon> hm :/ update-notifier keeps running away here
<mjg59> daniels: Yeah, and your mother dresses you funny
<bob2> siretart: crumbs.ertius.org/~rob/debian/lyx/ has been sitting there for a while, btw. not in sid yet due to gcc being broken.
<seb128> mjg59: have you tried the hibernate patch?
<sladen> Lathiat: are you confident that g-s-t is putting on the volume mute/change head-up-display.  I can't find it in the source
<Lathiat> g-s-*t* ?
<mjg59> seb128: No
<seb128> mjg59: "do_sleep_action ("gdm-signal -z");" but "do_sleep_action (char *cmd1, char *cmd2)", I'll put a NULL for the second argument, or do you have an alternative hibernate action?
<jdub> sladen: gnome-settings-daemon
<mjg59> seb128: Ah, shit, sorry. Yes, NULL is fine.
<seb128> mjg59: np, will do the patch/upload now. Any other patch/change for g-c-c since I'm working on it atm?
<daniels> mjg59: DOES NOT
<mjg59> Nope, should be fine
<seb128> k
<daniels> fabbione: please add a dep on libstdc++5 to xorg-driver-fglrx
<daniels> i thought I did this, but evidently not
<fabbione> daniels: argh ok...
<siretart> bob2: cool. I'll throw it in my pbuilder
<sladen> jdub: ah, gnome-control-centre, ta
<fabbione> daniels: why do we need that Depends btw? i can't remember
<siretart> daniels: is the xorg ati/radeon driver in breezy latest? I wonder if it is supposed to work with non rectangular desktop sizes in mergedfb mode ( I saw a commit message that this feature was ported from the sis driver)
<daniels> fabbione: fglrx_dri has a whole bunch of C++ code that links against it
<fabbione> ok
<daniels> so presumably dh_shlibdeps doesn't pack that up from within /usr/X11R6/lib/modules/dri
<fabbione> hmm strange because we force GCC and CC to 3.4
<daniels> siretart: no, and non-rectangular mergedfb support won't be added
<infinity> fabbione : Which means what, exactly, when shipping pre-build binaries we didn't compile?
<infinity> s/build/built/
<daniels> fabbione: yes.  but how much of the userspace stuff is compiled? :P
<fabbione> infinity: right...
<daniels> damnit.  outwitted by a combination of infinity and burstlag.
<siretart> daniels: :( - due to lack of time or because it is fundamentally broken?
<daniels> siretart: partially lack-of-time, partially because I have no desire to make our patchset even betigger
<fabbione> daniels: anything else?
<siretart> daniels: ok
<daniels> fabbione: not that I can think of
<fabbione> ok
<fabbione> daniels: fixed...
<fabbione> i am off for the day
<fabbione> can you please keep an eye that it will hit archive?
<fabbione> Successfully uploaded packages.
<daniels> mmm
<fabbione> dand: ?
<fabbione> ops
<fabbione> daniels: ?
<daniels> okay
<fabbione> thanks
<seb128> ogra: could you document from the changelog the files you modify when you change a GNOME package? thanks
<ogra> seb128, ok, sorry
<seb128> ogra: that makes the sync job with Debian much easier
<seb128> np
<ogra> seb128, yup... it was the schemas file, i think we'll use our own anyway in the future
<ogra> since the selection of the defaul saers is done there...
<ogra> default savers, grmpf
<Diziet> My `System / Preferences' menu has two entries labelled `Screensaver' with different icons.  Is this a known bug ?
<ogra> Diziet, upgrade ;)
<sivang> mjg59: how to check which modules are loaded?
<Diziet> ogra: That was from an hour or two ago.  If it's fixed since then, fine, I'm sure it'll sort itself out tomorrow :-).
<ogra> Diziet, the most recent gnome-screensaver solves that :)
<mjg59> sivang: lsmod
<Diziet> ogra: Fair enough.  Thanks for saving me writing a bug :-).
<ogra> :)
<sivang> mjg59:  no , I meant - should I grep for anything specific ?
<mjg59> sivang: clockmod or speedstep
<sladen> mjg59: please can you give me your preference on   {kernel driver, userspace daemon} that punts fake {acpi hkey events, keypresses matching your keycode map}
<sivang> mjg59: no clockmod, just speedstep stuff
<mjg59> sladen: Context?
<mjg59> sladen: If they're generic laptop hotkeys, then generate key events
<mjg59> acpi_fakekey is probably the easiest way of doing that
<mjg59> sivang: Ok. In that case, I'm not sure why you have the latency
<jbailey> Keybuk: *poke* re: 15103
<sladen> mjg59: thinkpads that don't have hardware volume.  aka R30, R31, R32, R40e
<jbailey> Keybuk: I accept the drop to enhancement for severity, since that's what it is.  I had placed it at major since it blocks two major bugs.
<sivang> mjg59: it more then latency, the machien stops for the duration of the attempt. 
<Keybuk> jbailey: right, but it can't block those bugs because we don't have a time-machine :)
<sladen> mjg59: and for doing head-up display of the changed state on all the rest of the laptops and hooking the [ThinkPad] /[Access IBM]  button
<Keybuk> so it can't be a fix for those bugs
<mjg59> sivang: Yes, that's what I mean
<jbailey> Right, but I need a suggestion from someone who knows dpkg/apt and such.
<Keybuk> implementing Breaks for breezy would only be useful for preventing those kind of bugs in future
<mjg59> sladen: Detect those machines and *only for them* send volume events
<sivang> mjg59: hmmm, apparently I get [X.Y]  cpufreq: change failed with new_state 1 and result 0 several constantly on the tty1
<mjg59> Look at the way that the Toshiba acpi scripts do it
<Keybuk> jbailey: what exactly is the problem, with which packages?
<mjg59> sivang: Ok, in that case we probably shouldn't be loading that module
<sladen> mjg59: yes but $what to "send volume events"
<jbailey> Keybuk: 11135 and 14661 shows the problems.
<mjg59> sladen: See /etc/acpi/volupbtn.sh
<Diziet> I think Breaks might be just a little late for breezy, unfortunately.
<mjg59> sivang: Which speedstep module is running?
<Kamion> yes, I was about to say the same; it's a big change
<sivang> mjg59: let' see:
<jbailey> Keybuk: glibc upgrade breaks partial upgrades of old initrd-tools (can't boot the system), and kills upgrades of any debconf using package when the user uses readline  mode.
<Keybuk> jbailey: why can't <package that causes the problem> depend on the <package that catalysts it> ?
<Kamion> Will breezy's apt fall over trying to read Packages files from dapper if dapper's Packages files start including Breaks fields?
<Mithrandir> Kamion: it shouldn't no.
<Kamion> hopefully not
<jbailey> Keybuk: initrd-tools and libreadline-gnu-perl aren't essential on breezy systems.  I don't want to force them to be installed.
<Mithrandir> Kamion: it should just ignore them.
<Mithrandir> jbailey: any idea on 8517 ?
<Kamion> although it wouldn't handle the upgrade properly to take account of them, so we'd have to wait 'til dapper+1 anyway
<jdub_> lifeless: please ignore recent transmission :-)
<jbailey> Mithrandir: I'd like to finish harrassing Scott on this if I could, first...
<Diziet> kamion: Indeed so.  The timeline for getting the new support working is quite long.
<Mithrandir> jbailey: please do.
<Keybuk> there really isn't any way to fix this kind of problem with the current dependency set
<sladen> mjg59: so answering part (b) Keycode 176 is your preference.  Now onto part (a) is a userspace daemon and accessing /dev/nvram better.  Or toshiba style kernel driver.
<Diziet> AIUI apt doesn't have the stuff that the dselect methods have, where first thing they try to do is upgrade the tools.
<Keybuk> you could make the preinst fail if an old version of one of those packages is installed and not to be upgraded
<Diziet> Urgh.
* jbailey squirms
<Kamion> Diziet: apt does upgrade dpkg and apt very early in practice, but it doesn't re-exec itself to recalculate the upgrade using any new algorithms therein.
<sivang> mjg59: speedstep_smi, speedstep_lib, freq_table, cpufraq_stats
<mjg59> sivang: Ok, you probably ought to be on speedstep-ich
<Diziet> k: Hmm.
<jbailey> Going once..
<jbailey> twice...
<mjg59> sladen: It's already exposed to userspace, so do it in userspace
<sladen> sivang: that's a fallback, can you get one of the other speedstep drivers to drive it
<ogra> seb128, do you know if there is any work for #12620 planned by the gnome-screensaver guys ? i see a fade option in the code, but it seems not to be used yet
<jbailey> Looks sold.  preinst check it is. =)
<mjg59> sladen: Sounds like the same problem with speedstep-ich not being loaded on machines it should be loaded on
<Diziet> Also, remember that Breaks would replace some other dependency fields, so you might well find that apt was working on a subset of the dependencies.
<Diziet> Now I come to think of it that might work rather well :-).
<mjg59> sladen: Any P4 is going to be on an ich system
<Diziet> dpkg would still know to autodeconfigure.  (I assume apt passes that option.)
<sivang> mjg59: AFAICT I am, this is a speedstep machine, as noted by the CMOS setup
<sladen> mjg59: yes, there's a bug and patch about it.  The regex that checks /proc/ioports needs a .* adding when grepping for ICH
<Mithrandir> mjg59: uhm, so my p4-clockmod fix is useless, really?
<sladen> mjg59: it's now showing up as  Intel 12345ICH  which no-longer matches the Regex 'Intel ICH'
<sivang> lol, so we need apply this patch and be done with it or is there more to that?
<sladen> mjg59: it's a 2 byte patch   s/Intel ICH/Intel.*ICH/ in the grep /proc/ioports line of cpufreq-detech.sh
<Kamion> Diziet: it doesn't appear to
<bob2> is the "print timestamps in dmsg" thing an ubuntu patch or a 2.6.12 thing?
<shackan> why my launchpad account does not work on bugzilla? do I need another registration for that ?
<Kamion> bob2: 2.6.12 I believe
<sladen> Mithrandir: I thought p4-clockmod was a hack so hackish that the author (davej) recommends against using it
<Mithrandir> sladen: that might be, but we're getting bugs about it not being enabled.
<mjg59> Mithrandir: No, some P4s don't have speedstep
<sladen> shackan: in future, you will only ever need *one* launchpad login, launchpad will take over your soul
<mpt> shackan: Bugzilla will be retired in a few months, so it's not worth implementing the shared login scheme
<sladen> Mithrandir: the correct response is that it shouldn't be
<sladen> Mithrandir: (IMHO)
<sivang> shackan: I think it's planned that launchpad's malone will be the sole bugtracker for ubuntu, so then you wouldn't have to have more the one account.
<jbailey> Mithrandir: The author of 8517 is confused.  Sarge's initrd-tools always loads fan and thermal.
<sladen> Mithrandir: hence the string that says "This is intentionally disabled"
<shackan> ok thanks, I've found a bug and posted it on malone, then I've been told to post it on bugzilla, I want to avoid duplicating stuff, what should I do ?
<sivang> shackan: you can open it up in bugzilla as well, and link it from malone, so both people using those will be alerted to the bug
<sladen> Mithrandir: could change it to  "workaround enabled.  p4-clockmod disabled"
<seb128> ogra: put a bug on bugzilla.gnome about it, upstream is quite responsive
<mjg59> sladen: Is the patch in bugzilla somewhere?
<mpt> sivang: in theory ;-)
<ogra> seb128, ok, i think the already planned it, else the option would make no sense... i'll look for a bug then...
<Mithrandir> jbailey: ok, so it's not a problem now that we've switched to initramfs?
<Robot101> yay initramfs :)
<sladen> mjg59: yes.  I was looking at it yesterday and did a couple of checks that it fixes other people's bugs too
<jbailey> Mithrandir: I don't think that the problem is any different than before.  Just that his assertion that it worked with Sarge seems unlikely.
<jbailey> Oh wait.
* jbailey rereads
<jbailey> HE's saying 'processor' is loaded and he doesn't want it to be?
<sladen> mjg59: http://bugzilla.ubuntu.com/15788
<mjg59> sladen: Thanks
<jbailey> mjg59: thermal loads processor.
<sivang> mpt: in theory re: cpufreq, or launchpad' tagging of bugzilla bugs? :-)
<mpt> sivang: the latter
<jbailey> mjg59: So I still maintain that it wasn't different in sArge, unless the older kernel didn't have this dependancy.
<sivang> mpt: lol, IIRC , I saw some bugs already linked that way, no? 
* sivang may be daydreaming
<sladen> mjg59: I've just viciously marked several as duplicates of that
<slomo> seb128: ping?
<seb128> slomo: pong
<bddebian> Morning
<slomo> seb128: do you plan to add a gst cdio plugin later? https://launchpad.net/malone/bugs/1750
<seb128> slomo: yep
<slomo> seb128: ok, already for breezy?
<seb128> slomo: https://wiki.ubuntu.com/MainInclusionReportLibcdio
<seb128> slomo: I'll ping mdz later, I've not noticed that pitti did approve the wiki page
<slomo> seb128: fine :) less work for me ;) otherwise i would've added it to gstreamer-plugins-multiverse for breezy
<slomo> seb128: libmms is already uploaded and should be in NEW currently
<mpt> sivang: Yes, they're linked, but the link doesn't do anything yet
<seb128> slomo: please don't create potential conflict for gst-plugins0.8
<seb128> slomo: I appreciate you packaging gst-plugins-multiverse, but that should be a place for non-free stuff, not for non-pushed-to-official-package ones
<slomo> seb128: ok, that's why i asked you before... but another question... would it make problems for the wavpack plugin for example when you add it to the official gst plugins later? when you keep the binary package name nothing should collide, correct?
<seb128> slomo: if 2 packages ship the same file we have an issue
<Lathiat> fabbione: did daniels say something about the libstdc++5 thing or did you just happen to pick that up at the same time as i was tlaking about it?
<seb128> slomo: and if -multiverse ship a package which should be moved to the official package we have to "Replaces" the previous version which create diff from Debian and sync work, and issues, etc
<slomo> seb128: even when the package name stays the same and just moves from one source package to another with higher version number?
<seb128> slomo: if the package name is the same no, but we can't ship 2 packages with the same name
<Mithrandir> Kamion: what do you think about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=315929 ?  (And the fix from bubulle)
<seb128> slomo: ie: you have decided to make a gstreamer0.8-wavpack, but you don't know if the Debian maintainer will do a separate package for it, or ship it with -misc by example, or if he will use the same name for the binary package
<slomo> seb128: ok... well, when wavpack is ready i won't ship it anymore so it should be no problem :) but in the future i'll talk to you about every new plugin i want to add unless it's clearly a multiverse candidate
* magnon wonders if there really should be bible study programs in universe :P
<ogra> magnon, why not ?
<sivang> mjg59: let me know if you have a testing package with the fix in, so I can test 
<mjg59> sivang: I'll upload one later today
<seb128> slomo: thanks. So we can at least talk with the Debian maintainer to pick the same choices
<slomo> seb128: hmm... -misc would be not intelligent as it adds one dependency imho... i'll talk to the debian maintainer when the time has come ;)
<sivang> mjg59: cool then, just if you need preupload testing.
<siretart> bob2: in lyx, you disallow python 2.4 (control states python << 2.4). Is this for a reason?
<seb128> slomo: you can talk about it on #gnome-debian (gimpnet) with lool
<seb128> he's the maintainer
<magnon> ogra, because "linux for human beings" should thereby include features for those studying the Koran or writings about Vishnu ;)
<Mithrandir> magnon: sure, is there free software which does that?
<magnon> never seen any
<Mithrandir> magnon: it's a bit hard to include non-existent software
<ogra> i heard about some quran software, nobody seems to have packaged it yet
<slomo> seb128: ok, i'll do when it has matured enough... currently it segfaults much too often :( i'll investigate further after my exams this and next week... shouldn't be that hard to fix
<magnon> we're just having a laugh of all the stuff lying around in Universe. Nothing more :)
<ogra> magnon, if someone writes/packages such software, we'll ship it
<seb128> slomo: thanks
<seb128> wb pitti, feeling better?
<bddebian> pitti: Hello.  Did you see my message about libpgtcl the other day?
<ogra> magnon, and a broken gnomesword at warty time caused a ML thread with a huge amount of msgs, so it seems this package is demanded a lot
<magnon> seems so
<Kamion> Mithrandir: bubulle's fix doesn't seem obviously wrong, but I'd have to test it in (a) normal path (b) backup (c) preseeding
<Mithrandir> Kamion: so post-breezy?
<magnon> Could anyone give me a tip in debugging update-manager?
<magnon> It chugs 100% CPU here all the time until killed
<magnon> it starts gracefully sometimes though, but seldomly
<Kamion> Mithrandir: no, if you want to run through a quick test of those three scenarios it can certainly be pre-breezy
<ogra> magnon, file a bug for mvo ?
<mvo> magnon: ppc?
<Mithrandir> Kamion: my d-i test environment isn't really working well atm due to a broken dvd burner
<magnon> mvo? (sorry, just got up)
<magnon> mvo, yeah
<pitti> seb128: slightly better, thnaks
<magnon> oh, mvo the person? :)
<mvo> magnon: good timing, I just build a package that may fix the problem
<pitti> bddebian: hm, not sure
<Kamion> Mithrandir: ah, ok, added to my list of stuff to test
<magnon> ah, ship it over if you want me to test it :)
<seb128> pitti: ross rolled a sj 2.12.2 with the patch and dholbach packaged it
<bddebian> pitti: I was tryin to package that libpgtcl from the URL that you sent me but I was looking over their site and it has only been built/tested against postgre 7.4 afaict.
<mvo> magnon: please give http://people.ubuntu.com/~mvo/update-notifier/update-notifier_0.40.8.fix1_powerpc.deb a try
<magnon> will do
<pitti> seb128: rock - that was fast :-)
<seb128> pitti: yep :)
<pitti> bddebian: it should be a mere client application, and only use libpq-dev
<mvo> magnon: can we discuss the details on #update-notifier? it's probably not interessting for everyone in this channel :)
<magnon> sure
<pitti> bddebian: therefore the server version should not matter
<bddebian> pitti: Hmm, ok
<ogra> desrt, who is john ? (#14967) 
<Keybuk> bah, well, I've rebooted this box nearly 200 times and still can't make /dev/input/mice vanish
<desrt> ogra; john mccutchan -- inotify coauthor
<desrt> we had coffee on the weekend and discussed all things inotify :p
<jdub> desrt: :-)
<jdub> cool
<ogra> desrt, you should probably mention the full name in bugreports, there are *some* other johns out there ;)
<WaterSevenUb> kamion, post-install "ubuntu-configuration" ... the strings "Installing Packages" and "Preparing X" package are not translated? The title now is translated (to pt.po). Did you see the email I mentioned to u during the weekend?:)
<desrt> jdub; arrrr!!!
<seb128> desrt: I mailed him, he said I should send a bug upstream
<desrt> ya.  he mentioned that the kernel actually has a _bugzilla_
<desrt> i had no idea
<seb128> "It was supposed to fix a kernel problem, but I think we overlooked one
<seb128> case where this could be called when it wasn't from a delete operation.
<seb128> "
<desrt> http://bugzilla.kernel.org/
<seb128> he said that
<seb128> oh cool, it was on my list to do
<seb128> "search the linux bug tracker :)"
<desrt> i'll do it
<desrt> i have a bit of time to kill before class
<jdub> seb128: oh, you looking into the icons-with-text-previews-disappear issue?
<ogra> desrt, that'd be sooo cool, its release critical for edubuntu to have this one solved :)
<seb128> jdub: I don't have this issue and the first bug we got today about this was today
<ogra> (since i mix gnome and KDE there)
<seb128> jdub: why do you speak about this like it was a known issue :)
<seb128> desrt: thanks
<jdub> boh! i thought i found a report
<jdub> oh man
<jdub> now i have this stupid feenode bot pinging me all the time
<seb128> jdub: we have "KDE entry are not listed by the GNOME menu" bog, but I found that a nice feature :)
<ogra> seb128, :P
<jdub> heh
<desrt> pitti; don't trust the dissenter! (your package is fine)
<mxpxpod> pitti: can you test something out for me on your ppc?
<pitti> desrt: I trust him, there is probably another bug somewher
<pitti> mxpxpod: sure, what?
<desrt> :)
<mxpxpod> pitti: wait, first is your ppc updated to the latest breezy?
<pitti> mxpxpod: nope, it has a preview install
<pitti> mxpxpod: I usually work on my amd64 desktop
<mxpxpod> pitti: I think that'll do... could you try running beagled --fg --debug from a terminal?
<mxpxpod> pitti: it keeps dying on me when it gets to the evolution data server plugin
<pitti> mxpxpod: ouch, I have to install a huge pile of packages for that, moment
<mxpxpod> pitti: sorry :(
<Kamion> WaterSevenUb: those strings are not translated because there are no up-to-date translations for them to pt
<Kamion> see the base-config package
<pitti> mxpxpod: is that the "beagle" package?
<mxpxpod> pitti: yup
* Keybuk boots his fresh and shiny warty install
<Treenaks> Keybuk: _fresh_ warty install?
<pitti> Keybuk: upgrade test?
<Keybuk> pitti: several people who had the /dev/input/mice problem said their boxes were upgraded into breezy, rather than fresh installed; and a few claim it went away on a fresh install
<Keybuk> so I'm trying this to see whether it's caused by a difference between an upgraded box and a fresh one
<Kamion> WaterSevenUb: your e-mail's in my queue of things to look it, which tends to be large after the weekend
<Keybuk> sweet, the box is actually installing security packages from the archive automatically at the same time as the CD install
<Keybuk> that's kinda cute
<desrt> uh guys
<desrt> what changed in the kernel update?
<pitti> jbailey: you tried pbbuttonsd  0.7.1, right? and you had a problem with it which I forgot the details about, but was that a regression to 0.6.6?
<sivang> hey desrt 
<desrt> my computer (normally solid as a rock) just took a dive *hard*
<Spec> I want to set up (for edubuntu) a system in order for all the clients (running edubuntu/ltsp) to view the Teacher's desktop (or a desktop that only the teacher has permission to read/write to), is the best way to do this via vncreflector?
<desrt> (having just rebooted it yesterday to upgrade to the new kernel package)
<jbailey> pitti: I don't know that it was a regression.  I hadn't noticed my machine slowing donw in ages, so it probably wasn't.
<desrt> sivang; 'sup
<pitti> mxpxpod: started
<mxpxpod> pitti: did it start OK?
<mxpxpod> or did you get an exception?
<pitti> mxpxpod: I get a DllNOtFoundException: glib-2.0
<mxpxpod> pitti: install libmono-dev
<pitti> mxpxpod: that can hardly be the solution?
<mxpxpod> pitti: (that makes no sense to me, but I guess that works...)
<pitti> mxpxpod: that rather looks like a missing dependency
<mxpxpod> pitti: yeah :)
<mxpxpod> pitti: but that's not the exception I'm talking about
<pitti> mxpxpod: now I get DllNotFoundException: glibsharpglue
<mxpxpod> pitti: that's strange
<mxpxpod> pitti: I keep getting DllNotFoundException: edataserver
<pitti> mxpxpod: in any case it seems that beagle needs much love - good that it is universe...
<mxpxpod> pitti: yeah..
<magnon> beagle is very unstable in breezy atm
<mxpxpod> magnon: obviously :)
<Diziet> I assume there's no good reason not to sync to Debian's foomatic ppd database ?
<Diziet> I've taken a look at the situation and it seems like we just ought to have the more recent version of the data.
<infinity> Diziet : Unless you see something specific in the changelogs to to contrary, the general rule with PPDs is "the newer, the better, please hurt my printer, oh please yes".
<mxpxpod> desrt: have you guys figured out the pbbuttonsd startup issue with 100% cpu being used?
<\sh> infinity: can u have a look on this http://people.ubuntu.com/~lamont/buildLogs/a/aqsis/1.1.0.20050815-2ubuntu2/aqsis_1.1.0.20050815-2ubuntu2_20050919-1510-amd64-failed.gz
<\sh> infinity: it says in the end in build-arch : dh_testdir not found...and this is not true ,-)
<desrt> mxpxpod; yes.
<desrt> mxpxpod; it's due to an event device being destroyed and pbbuttons spinning on trying to read() it
<desrt> mxpxpod; martin just uploaded a new one that should fix it
<mxpxpod> desrt: awesome!!
<lamont-away> \sh: sigh
* lamont-away ponders anew why sometimes we get _2_ buildd
<lamont-away> processes running
<pitti> mxpxpod: there does not seem to be "the" reason, but it works for 2/3 people
<mxpxpod> pitti: haha
<infinity> lamont-away : It used to happen all the time on one (and only one) m68k buildd, but I never bothered to figure out why.
<infinity> lamont-away : Did you fix up king already and give-back aqsis for \sh?
<lamont-away> dealing with it
<elmo> infinity/lamont: btw king was taken out by a build over the weekend
<WaterSevenUb> kamion, which package? I can provide updated translations.
<infinity> Oh, cool.  You rule.  Thanks.
<WaterSevenUb> kamion, the one of the "post-install" ... debconf?
<elmo> infinity/lamont: it'd be nice if you could find out what it was, and why it was being so unfriendly
<\sh> infinity / lamont-away: thx guys
<lamont-away> elmo: sigh. do we know which one?
<infinity> I'll compare log timestamps with /var/log/messages and see.
<infinity> Thanks for the heads up.
<lamont-away> infinity: I'll leave that task to you, since i'm supposed to be doing other things today
<infinity> Yeah, I'm supposed to be sleeping, but I just wrote myself a note to look at it in the morning.
<Kamion> WaterSevenUb: 15:16 < Kamion> see the base-config package
<Kamion> WaterSevenUb: that one
<desrt> pitti; pfah.  just admit it.  you're great and everyone knows it :)
<Robinho_Peixoto> why don't have update-manager in rosetta ?
<sladen> it is better to detect the model of laptop, at package install time;  at start up, or per invocation
<ogra_> pitti, ping
<mxpxpod> pitti: if only we could just get rid of pbbuttonsd :)
* desrt hits mxpxpod with rocks
<pitti> desrt: hehe :-) thanks
<pitti> mxpxpod: what's so bad about it? 
<desrt> pitti; it gives PC users jealousy.
<mxpxpod> pitti: well, it takes over volume, brightness, keyboard function key mode, mouse trackpad mode, and other things that should be left to GNOME or another userspace program
<mxpxpod> pitti: basically, it does too much for its own good
<desrt> mxpxpod; i'm honestly with pbbuttons handling all things things and not gnome
<desrt> *honestly happy
<mxpxpod> desrt: I would be too if they'd allow a way for gnome to hook into it
<desrt> mxpxpod; the only thing that would be nice is if it had a better configuration interface
<mxpxpod> desrt: I agree there
<mxpxpod> desrt: I tried HIG-ifying their interface, but I gave up
<desrt> oh also... s/notap/drag/ in martin's default config file would be nice too :)
<pitti> mxpxpod: you mean, it makes my iBook work like it should? :-)
<mxpxpod> pitti: :P
<pitti> desrt: what's wrong with powerprefs? this is a nice setup program
<mxpxpod> pitti: powerprefs has things hidden deep within it
<mxpxpod> pitti: it takes a lot of digging to find what you want
<WaterSevenUb> kamion, the strings "Preparing X" package... " are not in here https://launchpad.net/distros/ubuntu/breezy/+sources/base-config/+pots/base-config/pt/+translate. If they are in debconf, this package is 100% translated. Maybe they aren't simply in the POT.
<Diziet> infinity: re ppds> That was what I thought :-).
<WaterSevenUb> kamion, plus "Installing package"... "Configuring X"
<Diziet> So should I ask one of the infrastructure people to sync it ?  Just importing the current Debian version would be fine (our only local patch is included).
<ogra_> pitti, another ping
<Robinho_Peixoto> when it goes to happen the string frezer
<pitti> ogra: I'm right here, sorry
<ogra> pitti, http://hwdb.ubuntu.com/buildlogs/?show=http://people.ubuntu.com/~lamont/buildLogs/x/xscreensaver/4.21-4ubuntu13/xscreensaver_4.21-4ubuntu13_20050919-1239-amd64-failed.gz
<ogra> pitti, pkgstriptranslations is freaking out it seems
<ogra> pitti, it works on all other arches tho...
<pitti> ogra: hm, that rather looks like a buildd problem
<ogra> infinity, pinggg
<pitti> ogra: can you please ping infinity?
<pitti> ah, ok
<ogra> infinity, ^^^
* zyga nags pitty about .pot and .po extractor as he requested
<zyga> pitti: you are being nagged
<pitti> zyga: ah, ok :-) what was the issue again? you need all pot files from all packages?
<zyga> pitti: yes, but not only that
<zyga> pitti: if possible it would be really usefull to get all strings from the source
<Kamion> WaterSevenUb: I don't know whether Rosetta is out of date on this. It might be. I'm absolutely certain that base-config is not fully translated into pt.
<pitti> zyga: ok, added to my TODO list
<zyga> pitti: thank you :)
<zyga> pitti: any news on when will rosetta export really work? (so that breezy will recieve translation upgrades) ?
<Kamion> WaterSevenUb: alternatively perhaps nobody told me that base-config had translation updates in Rosetta. base-config is one of those packages where I have to import the translations manually; language packs don't work for it.
<pitti> zyga: I tested a new tarball at Friday; it was better, but still not usable
<Diziet> Can anyone answer my question about synching a package from Debian to Ubuntu ?  I'm sure this is routine but I can't find the documentation ...
<Mithrandir> Diziet: what is your question, then?
<ogra> Diziet, you ping or mail elmo about it
* infinity sighs.
<Diziet> ogra: Right.
<ogra> Diziet, let me give you an example :)
<ogra> elmo, ping
<Kamion> Diziet: the canonical procedure is "if elmo's around on IRC, ask him there; otherwise send him e-mail"
<Kamion> no don't ping with no content
<infinity> pitti, ogra : lamont's already fixed that (king was running two buildd instances, YAY!)
<Kamion> that's just annoying and incurs round-trip times
<Mithrandir> Diziet: ask for syncing of $package with $version and whether it's ok to override ubuntu changes (those have to be verified first)
<ogra> elmo, (now Kamion fixed) please sync openafs from debian unstable
<Kamion> oh, for pity's sake, I can't do Rosetta exports by a simple URL any more?
<Kamion> that used to work
<elmo> ogra: nothing to sync
<ogra> huh ? 
* ogra looks
<elmo>    openafs |   1.4rc1-1 | breezy/universe | source
<siretart> iirc this is about openafs-docs
<siretart> which should be in sync with openafs, but seperate source package
<ogra> siretart, nope, its about openafs... 
<siretart> ok
<elmo> [maybe I should write a wiki page about this...] 
<elmo> [including documenting some sort of penalty system.. :P] 
<ogra> i get nagged about that since some time, but had no time to test before the weekend...
<Diziet> So, elmo, can you please sync foomatic-filters-ppds and foomatic-db ?
<sivang> elmo: did you get my email about additional files Emiko uploaded?
<sivang> elmo: they are needed in order to complete the certification..
<Diziet> Maybe I should make an email.
<ogra> gah, crimsun already snyced it...
<elmo> sivang: yes, breezy ate my mail tho - once I've recovered from that, I'll sort your stuff out
<sivang> elmo: gazillion thanks, I know how busy you might be these days.
<elmo> [Updating]  foomatic-db (20050705-1 [Ubuntu]  < 20050720-1 [Debian] )
<elmo> [NOT Updating - Modified]  foomatic-filters-ppds_20050720-1ubuntu1 (vs 20050913-1)
<Diziet> Trash that update in filters-ppds.
<Diziet> It's included in the Debian version.
<elmo> iwj: those both need UVF exception approval from kdz or mamion first, and I need to know if it's ok to override the ubuntu changes
<elmo> err, mdz or kamion.  that was special
<Kamion> WaterSevenUb: it's https://launchpad.net/distros/ubuntu/breezy/+sources/base-config/+pots/pkgconf-base-config/pt/+translate anyway - +pots/base-config is the program translations, but we need the debconf translations
<ogra> elmo, lol
<ogra> nice one
<Diziet> Um, UVF> Yes, but it's just printer data.  I think it's clear that it ought to be taken.
<WaterSevenUb> kamion, ok... I'll translate it and then you can import from rosetta.
<elmo> Diziet: sure - but I'm still not mdz or kamion, I don't get to make exceptions, even obvious ones
<Diziet> Right.
<Kamion> elmo: yes, that's fine
<Diziet> I'm hoping Kamion is watching.
<Diziet> Ah :-).
<Kamion> as infinity/diziet say, printer data's pretty much "take the newest" I think
<Diziet> Those two are the packages with data in; the other foomatic packages seem to have actual version numbers and appear to contain code.
<Diziet> Anyway, thanks.
<sivang> Diziet: what printer data are you chaning?
<sivang> s/chaning/changing/
<Diziet> The proximate cause is 7384, about LJ 6MP printable area.  But it seems silly to chase that kind of thing piecemeal.
<elmo> Diziet: done
<Diziet> elmo: Ta.
<elmo> ogra: why have you split out a 3rd package for xscreensaver?
<ogra> elmo, because i need xscreensaver-text and xscreensaver-getimage-* its used by some hacks... i dont think its appropriate to put it in the -data package
<elmo> ogra: why not?
<Kamion> as mdz said, the -data name hardly seemed appropriate in the first place
<elmo> yeah, I agree with  that too
<Kamion> xscreensaver-hacks?
<Kamion> *shrug*
<ogra> the -data name is the right name
<elmo> ogra: err, why?
<ogra> even if its binary data, its not installed in PATH and gets only executed by a screensaver daemon program
<infinity> Hacks are applications/programs, not data.
<ogra> so omho -data is the right name
<elmo> ogra: your definition of data is boken
<elmo> broken too
<infinity> -hacks would have made more sense to me.
<ogra> data isnt allowed to be binary ? 
<Kamion> data implies non-execution to me
<bddebian> elmo: Are you who I need to ask to revert my wesnoth fuckup?
<elmo> bddebian: I can't revert uploads
<Kamion> bddebian: you can't run version numbers backwards, ever
<bddebian> Isn't that what mdz meant?
<Kamion> if possible, fix ttf-dejavu
<infinity> -data is general arch-independent (though could be dependant, if it;s something like a BDB database, argh) junk that gets read by executables.
<bddebian> Kamion: It requires an updated fontforge
<Kamion> or tweak wesnoth not to need it
<infinity> bddebian : I gave you options.
<crafton> great argument infinity 
<infinity> bddebian : The most sever of which is reuploading the old wenoth under a new version like the ugly mozilla-firefox version in warty.
<infinity> s/sever/severe/
<dilinger> Kamion: --- Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )
<ogra> *sigh* ok, how do i change the package name without breaking everything now ? elmo is conflicts+replaces appropriate here ? 
<dilinger> er
<dilinger> s/Kamion/Keybuk/, rather
<infinity> bddebian : Less severe being to try to get a UVF exception for fontforge, after proving it's not going to hurt ANYTHING (has this been shot down), or fix the thing that wants a new fontforge to no longer need it.
<bddebian> infinity: Yes, it breaks ttf-freefont I think
<Kamion> ogra: conflicts/replaces would be normal, yes, possibly provides as well
<ogra> ok
<ogra> fixing it...
<infinity> Provides is overkill for a package that's existed for all of a few days.
<infinity> No one will be trying to install is manually anyway.
<infinity> s/is/it/
<Kamion> yeah, that's probably true
<elmo> ogra: please consider merging the third package intot his new package too
<elmo> I'm not going/can't veto it, but I'd sure as heck reject this 3rd package from Debian without best justification for it's existence
<infinity> In fact, the conflicts/replaces could probably go away again after a couple of weeks, if you're just trying to ease the pain of people wh otrack breezy daily.
<infinity> But don't bother with that. :)
<elmo> s/best/better/ - jesus
<ogra> elmo, ok
<Kamion> I'd prefer the utils package to be merged into -hacks too, yes
<Keybuk> dilinger: /msg nickserv register ...
<Keybuk> :)
<ogra> Kamion, elmo who am i to argue with you two ;) fixing ...
<Keybuk> dilinger or see the #12788 bug I just punted at you -- is there any way for ndiswrapper to build module alias table strings for the devices it can support?
<Kamion> ogra: thanks
<dilinger> Keybuk: /server irc.oftc.net :P
<ogra> Kamion, elmo but note it will be very weird once we have spliut the hacks into 4 packages as sabdfl wants it
<dilinger> Keybuk: anyways, yea, i saw the bug.  responding now..
<elmo> ... what?
<Kamion> oh, I'd forgotten about that madness, gar
<ogra> he wants to have separate packjages for shipped/non shippes screensavers, that will split -gl-extras and -hacks-extras
<ogra> so we'll have 4 (probably 6 if i have to split rss-glx too) packages with hacks
<elmo> umm, why?
<ogra> anyway, mdz made that a dapper goal, so i have tim to think about it 
<ogra> time even
<ogra> elmo, to only ship the selected screensavers and demote the rest to universe
<infinity> -hacks, -hacks-gl, -hacks-extra, -hacks-gl-extra?
* infinity shudders.
<ogra> yup, something like that... except i merge gl/non-gl extras
<WaterSevenUb> kamion, you can import https://launchpad.net/distros/ubuntu/breezy/+sources/base-config/+pots/pkgconf-base-config/pt/+translate if you want. Though, it doesn't have "Configuring..." ... "Preparing..." strings I think.
<Keybuk> mjg59: does my comment on #8575 seem reasonable?
<WaterSevenUb> kamion, maybe I just didn't notice those strings. Nevermind. IMport the pt.po if you can:)
<Kamion> WaterSevenUb: yeah, I'm just downloading that to have a look
<ogra> Mithrandir, any chances we'll se a fixed NX in universe for breezy ? i get a lot of requests from edubuntu people
<spacey> whats the purpose of /dev/shm / tmpfs thingy?
<spacey> that is substracted from your normal memory, no?
<spacey> its really huge and unused
<siretart> spacey: unused parts of that can be paged out to swapspace
<siretart> no need to worry, imo
<spacey> siretart, things is that i'm missing 1GB of memory
<spacey> so i wondered if that was the place it went
<spacey> its some sort of ramdisk i assume?
<spacey> siretart, can you tell what /dev/shm is used for?
<siretart> spacey: yes, tmpfs is comparable to a ramdisk
<siretart> spacey: no, but I find it quite handy from time to time
<spacey> siretart, so its reasonable to think that GB of lost memory is allocated to /dev/shm? since it has a size of 1.5GB
<bddebian> mdz: ping?
<Kamion> WaterSevenUb: ok, grabbed, will upload shortly
<siretart> spacey: why 1.5gb? over here, thats only 252mb
<spacey> siretart, i have no clue, but it is tmpfs                 1,5G     0  1,5G   0% /dev/shm
<bddebian> Is mozilla just broken?  I get all kinds of dep errors for it.
<siretart> spacey: strange
<spacey> siretart, you know where that size is configured?
<spacey> not sure if its ubuntu or edubuntu thing, on the server edubuntu preview release was installed
<ogra> Kamion, elmo, hmm, if i add the utils to -hacks, every package containing hacks has to depend on the -hacks package in the future, so you wont be able to only install GL based screensavers for example... i still think a -utils package would make more sense
<siretart> spacey: look in /etc/default/tmpfs
<ogra> this way it brings odd dependencys to xscreensaver...
<spacey> "by default kernel sets this upper limit to half of available memory." 
<Kamion> spacey: as siretart says, unless that's actually being used it's irrelevant to your actual physical memory use
<spacey> explains a bit i guess, since there is 4GB in the machine
<spacey> Kamion, will it get auto resized if more memory is used?
<Kamion> it's not relevant. it's a red herring. don't worry about it
<Kamion> you might need to turn on PAE to get the kernel to map the top gigabyte?
<Kamion> not absolutely sure there
<elmo> no, you only need PAE for > 4GB
<spacey> yeah that limit is 4GB
<spacey> already checked the kernel config file
<WaterSevenUb> kamion, thx.
<Mithrandir> ogra: I've not worked on it since it got deferred..
<ogra> Mithrandir, ok
<Mithrandir> mdz: if it's ok with you, I can devote some time to getting NX in reasonable shape.  It will take some days, but I think it may be worth it; see ogra's request for it above.
<spacey> aaah i still only have 3GB of mem :S thats wierd. and for sure its not /dev/shm now, because its 256M.
<spacey> i'm sure the bios said 4GB
<jordi> sivang: can't find the url. Can you ask mdke?
<jordi> gotta go
<ogra> Mithrandir, its not release critical, i just get requests about it and wanted to know if you work on it for universe even if it was deferred... there is no rush
<Mithrandir> ogra: I'm leaving for dinner at my father's place in a short while, but if you can talk with mdz about getting me to work on NX, I'm absolutely open towards it, but I'd like him to say "sure, go ahead"
<doko> Kamion: openoffice.org1-debian-files should stick in NEW, would be nice, if you could process this?
<Mithrandir> ogra: given that I have a bunch of bugs and there's still > 200 RC bugs left.
<ogra> Mithrandir, he wont, the release is more important :)
<ogra> Mithrandir, and i wont, its not that serious, i can point people to vnc
<ogra> was just a request for information ;)
<Mithrandir> ogra: ook
<Kamion> doko: elmo's around, no reason to ask me
<doko> Kamion: sorry
<doko> elmo: openoffice.org1-debian-files should stick in NEW, would be nice, if you could process this?
<Keybuk> can you correct Bugzilla quips? ... this Tolkien quotation is wrong
<Kamion> can we just *delete* most of those stupid Bugzilla quips?
<Keybuk> hmmm
<Keybuk> now this is interesting
<Keybuk> Aug 31 20:41:01 localhost udevd[2372] : udevd.c: seq 0 forked, pid 18491, 43576
<Keybuk> seconds old
<Keybuk> Aug 31 20:41:01 localhost udev[18491] : udev.c: action, subsystem or devpath missing
<Keybuk> Aug 31 20:41:01 localhost udevd[2372] : udevd.c: seq 0 exit, 43576 seconds old
<Keybuk> ... Mr Kernel is not giving /proc/sys/kernel/hotplug all the variables it's supposed to
<Keybuk> BENC!
<hunger> Keybuk: I told fabbione that it is a kernel bug!
<Keybuk> did he agree, or not?
<hunger> Keybuk: He did not.
<hunger> Keybuk: I never had the issue with a 2.6.13 kernel...
<Keybuk> this may be part of the general "input subsystem is snorting 2-year-old crack" problem
<Keybuk> (ie. hasn't been updated to the new world order yet)
<Keybuk> fabbione ?
<Keybuk> the kernel should _at_least_ be supplying ACTION=add though
<Keybuk> otherwise it's kinda going to userspace "yeah, some device thing just happened, dunno what or who though, sorry, will pay more attention next time"
<ogra> silbs, !
<ogra> silbs wb :)
<silbs> ogra: I'm not really here till tomorrow. This is just a mirage
<ogra> heh
<bob2> a psuedo-silbs
<ogra> silbs, a relaxed one i hope ;)
<bob2> also, someone did something to my laptop and now it beeps at random intervals
<elmo> grr, why _did_ we switch to gnome-screensaver anyways?
<ogra> elmo, what dont you like about it ? 
<ogra> its much better integrated
<elmo> well for starters my aliases and keyboard mappings that talk about 'xscreensaver-foo' are broken
<ogra> hmm, the lock shortcut from metacity works fine here...
<elmo> and 'gnome-screensaver-command -activate' doesn't appear to actually, err, work
<elmo> ogra: custom keyboard mappings
<ogra> elmo, its like xscreensaver, use gnome-screensaver-command --activate :)
<Diziet> I'm starting to wonder if I should feed the firefox source to glimpse.
<elmo> ogra: err, no
<elmo> xscreensaver-command takes '-activate'
<elmo> if g-s-c takes --activate, fine, but it shouldn't silently do nothing on '-activate'
<ogra> elmo, did you just upgrade right now ? you need to logout and in again to add gnome-screensaver to your session (or start it manually)
<ogra> oh
<ogra> its a -- vs - thing
<elmo> and g-screensaver just seems SLOW
<ogra> it is
<ogra> it uses xembed for the lock window, thats a bit solwer than direct x programming
<ogra> slower even
<elmo> also there's no way to disable it?
<ogra> in gconf
<ogra> err, and in the settings panel indeed
<Keybuk> dilinger: #12788, another reply for you <g>
<Treenaks> are there known problems with sound on via VT8233/A/8235/8237
<Treenaks> music is playing (according to ogg123), channels are not muted.. no sound can be heard
<ogra> Treenaks, switch on your speakers ? 
<Treenaks> ogra: ha. ha.
<Treenaks> ogra: they work fine :)
<ogra> :)
<Treenaks> ogra: (i.e. if I stick the plug in my mp3 player, music _does_ come out)
<dilinger> Keybuk: tag, yerit!
<Keybuk> dilinger: sounds perfect, if -m would write the modprobe.d files properly, hotplug would just work
<Keybuk> should I tickle upstream, or are you willing to do it yourself?
<dilinger> Keybuk: i dunno about tickling them, that sounds kind of scary
<Keybuk> "asking" :)
<dilinger> Keybuk: i'd suggest you do it, since i don't really do much w/ hotplug/udev atm
<Keybuk> ok
<Keybuk> got a url for their bts?
<Keybuk> or address for a mailing list?
<dilinger> they use sf
<dilinger> ndiswrapper.sf.net
<ogra> Keybuk, dilinger you are working on our ndiswrapper ? 
<Keybuk> ogra: mdz assigned me the "make ndiswrapper hotplugishnessable" bug
<dilinger> ogra: not specifically ubuntu's.. ndiswrapper is in universe, right?  at least, ndiswrapper-utils (i know fabbione was including the module in the stock kernel)
<jbailey> Kamion: dilinger just asked me to pick a less sucky directory than /etc/mkinitramfs.  He's suggesting /etc/initramfs-tools, which would make sense.
<ogra> Keybuk, dilinger, if you fiddle with it anyway could you add adm64 to the control file, so i dont need to compile it myself all the time ? 
<jbailey> Kamion: I generally think that it's too late in the cycle to change that, but I'm not entirely sure.  Does the installer poke its head in there at all?
<dilinger> ogra: you mean for breezy?  i believe that's already set in sid
<ogra> dilinger, the ndiswrapper module is in our default kernel
<Diziet> Gah !  The bookmarks.html that it seems to be using for new profiles claims to be an autogenerated file.  But it contains URL domain names in it that appear nowhere else in the entire firefox source tree.
<bddebian> Oh sure and I can't get a newer fontforge?? ;-P
* bddebian ducks
<ogra> dilinger, i doubt we just grab the sid settings since the module is in the kernel package
* maswan stops his ubuntu-5.10-preview bt seeder after 615 gigs
<Treenaks> ogra: it was a hardware thing I think...
<ogra> Treenaks, ??
<Treenaks> ogra: it's now outputting on line-in instead of line-out
<Treenaks> ogra: even on the old kernel#
<ogra> ah
<ogra> you talk about the sound issue :)
<Treenaks> but that's new afaik
<Treenaks> headphone and master controls are mixed up as well
<mdz> dilinger: ndiswrapper-utils is in ubuntu main and always has been (since Warty)
<mdz> Mithrandir: NX -> not for breezy
<Kamion> jbailey: yes, base-installer does
<Kamion> jbailey: it's easy to change and avoid breakage if you give me a bit of warning
<dilinger> mdz: ok
<Kamion> jbailey: you'd have to be sure to migrate the old config file from /etc/mkinitramfs/
<Keybuk> mdz: morning
<ogra> mdz, any opinion on the xscreensaver splitting story ? (i need some utils and wouldnt like to put them in the -hacks (future name of -data) package) 
<Keybuk> python*-musicbrainz can't be upgraded (hoary->breezy)
<Keybuk> known?
<jbailey> Kamion: 'k, thanks.
<mdz> ogra: story?
<ogra> mdz, some of the hacks need the xscreensaver text and image loaders, so i packaged them into a -utils package, Kamion and elmo oppsed that and asked me to put all hacks and utils into a -hacks package
<ogra> mdz, but then we would have to have *any* hacks depending on that package in the future, that disables users to only install GL screensavers for example
<mdz> ogra: just put them in the existing -data package
<ogra> mdz, so i'd like to keep the -utils package and rename -data to -hacks...
<ogra> ok
<mdz> now is not a good time for more package churn
<ogra> mdz, so i also keep the name for now, if i understand you right ? 
<mdz> ogra: yes
<ogra> ok :)
<mdz> I thought we discussed it already
<ogra> mdz, it came up due to my splitting out of the -utils package and elmo opposing to NEWing it 
<mdz> package splits/merges/etc. should be minimized this late in the release
<ogra> ok
<mdz> bddebian: argh, so doko's rrdtool update is also broken due to the same fontforge dependency chain
<Diziet> I reckon they should be minimised completely.  It's usually better to have a misnamed packages than to constantly be moving stuff around.
<Diziet> Or would we suggest renaming /usr now ? :-)
<elmo> err
<bddebian> mdz: Mwuhahah, it's a conspiracy ;-)
<elmo> that's a ridiculous comparison
<doko> mdz: please see my email
<bddebian> mdz: Sorry, that probably isn't funny.
<mdz> doko: yes, I just did
<Diziet> But perhaps this is rather a philosophical argument to be having at this point in the release.
<mjg59> elmo: Did you get a chance to check whether sleep had started working on your machine?
<mdz> doko: it looks like ttf-freefont is the only package in main which uses it
<elmo> mjg59: no, sorry - my powerbook is at home; I'll look tonight
<mdz> doko: but it needs to be tested
<mjg59> elmo: Thanks
<mjg59> elmo: Has cwd left?
<elmo> cvd?  no
<doko> mdz: looking at it
<mjg59> Uh, yes. Her.
<Kamion> phew, getting #15513 out of the way is nice
* mjg59 keeps getting confused by that
<bddebian> mdz: Anything I can do to help?
<mdz> doko,bddebian: if it doesn't break ttf-freefont, updating fontforge is a possibility
<Kamion> mdz: I'm thinking Colony 5 later this week, FYI
<mdz> bddebian: you could see what in universe uses fontforge and test it with the new version as well
<Kamion> hopefully Thursday
<elmo> oh, is this why cricket is uninstallable?
<mdz> Kamion: sounds good
<mdz> elmo: yes
<elmo> I'll not file a bug then ;)
<bddebian> mdz: I've already hit all the rdepends for fontforge and they all are fine afaict
<mdz> we are going to need to be more rigorous about checking dependencies before syncs
<elmo> doko: do you know about lm-sensors FTBFS?
<bddebian> mdz: Wesnoth was totally my fault, I will take complete blame for that one
<doko> elmo: yes, needs librrd2 -> ttf-dejavu
<mdz> bddebian: by "rdepends" do you mean "apt-cache rdepends" or "all reverse build-depends, build-depends-indep and depends"?
<elmo> doko: oh, for that too?  meh
<bddebian> mdz: Oh, I just hit apt-cache rdepends
<elmo> wah, out-of-date's exploded again
<bddebian> How can I get at reverse build-deps, etc?
<mdz> bddebian: grep-dctrl
* mvo goes and play hockey now. bbl
<bddebian> Hmm, apparenlty I don't know how to use grep-dctrl :-(
<Kamion> it has a good man page
<Kamion> and you can use /var/lib/apt/lists/*_Sources as input
<bddebian> Ughh, wine
<bddebian> Heya mbreit
<bddebian> OK, doko can test wine ;-P
<jdub> ogra: so, can we dump gnome-screensaver from breezy yet? reiterating: it's seriously not ready, and was added *way* too late. :-)
<jdub> it will definitely be on the agenda (a much bigger one) for dapper and gnome 2.14.
<ogra> jdub, *sigh* i even get PM asking why we changed it
<jdub> all reasons for changing it are good, it's just too early
<ogra> jdub, err, you arent serious, are you ? 
<jdub> i'm completely serious.
<jdub> would far prefer to stick with xscreensaver for breezy, and work on gnome-screensaver for dapper.
<ogra> jdub, so convince sabdfl i've put the last 3 days into integrating it
<jdub> ok
<ogra> i think its ok now, the only thing it really lacks is the option to change the settings for single screensavers
<jdub> btw, have you received "lock dialogue keeps crashing" bug yet?
<ogra> nope
<jdub> pipka was going to file it, dunno if she did
<ogra> not one about the lock dialog
<jdub> she couldn't unlock her session without killing the daemon
<ogra> and i just shrunk my screensaver buglist from 40 to 14 today
<mdz> jdub: can you give me some concrete data to support the case for swapping it back?
<ogra> jdub, are you sure pia just didnt run both screensaver daemons ? they clash badly ... it was solved with todays upload...
<jdub> mdz: could start with... days since feature/preview freeze that it was added? age of codebase? extreme lack of testing both within ubuntu and without? ;-)
<jdub> ogra: no, she was using my laptop
<ogra> ok
<mdz> jdub: is it a new codebase? I thought it was based on xscreensaver
<jdub> nup
<Kamion> "Ubuntu" in Macedonian == ""
<Kamion> cool
<\sh> mdz: which kernel version is used for breezy install iso boot kernel?
<ogra> 2.6.12
<Kamion> \sh: same as the regular system
<mdz> \sh: the same one used everywhere else in breezy; it only has one ;-)
<\sh> mdz: aehm..benc wrote in one of the bugzilla reports regarding marvel yukon2 drivers...that in rev 13 the sky2 driver is enabled..but not on the boot kernel for the latest daily i386 iso ;)
<ogra> jdub, i would say whats there runs stable but i agree that its lacking features
<jdub> ogra: i don't think we can say 'stable' with any serious credibility
<mdz> \sh: it's possible it's a rev behind, depending on when the builds happened
<jdub> mdz: it's certainly copied some code from xscreensaver, but it's by no means a fork or anything
<Kamion> \sh: it's also possible the kernel team forgot to put it in any udeb
<mdz> jbailey: this mean anything to you?
<mdz> jbailey: > > /init: 64: Syntax error: 0x
<\sh> mdz / Kamion : ok..so I have to tweak the initrd ;)
<\sh> thx...cu later...trying to install the portege again :(
<ogra> jdub, i ran it for some weeks on all machines here and had neither crashes nor any other probs and i think seb128 tested it too... indeed it didnt recieve a big field test
<mdz> jdub: it's going to be a hard sell sabdfl-wise to change it back
<jdub> ogra: dude, it's not even highly distributed among developers, let alone by another distributor
<Kamion> \sh_away: if my guess is correct, I'd prefer it if you could inform the kernel team that that driver needs to be added to some udeb
<mdz> jdub: we'll need to uncover actual bugs
<jdub> mdz: yeha
<jdub> mdz: did it go through security review?
<elmo> well I can't prove it (yet) but I'm pretty sure it's taking down my machine at home
<mdz> jdub: no, by virtue of the fact that I thought it used xscreensaver's basic stuff
<Keybuk> isn't the bulk of "screensaver" the programs being run by it, and those are from xscreensaver anyway, no?
<mdz> Keybuk: well, there's that, plus some incidental bits which do things like carry your password around ;-)
<elmo> and there's that -activate thing too
<ogra> Keybuk, yup
<mdz> elmo: -activate thing?
<jdub> Keybuk: those aren't the interesting bits
<Keybuk> hmm, the screensaver preferences I have here claim to be XScreensver
<elmo> mdz: gnome-screensaver-command -activate does nothing
<elmo> it wants --activate instead
<ogra> mdz, gnome-screensaver requires two dashes, xscreensaver only one for options
<elmo> which is fine, but it could be more useful than "do nothing"
<elmo> when passed the "wrong" thing
* jdub boggles at the "switch user" / "unlock" button behaviour
<Keybuk> elmo: System -> Preferences -> Keyboard Shortcuts -> Lock Screen
<Keybuk> and don't nih next time <g>
<elmo> Keybuk: don't be silly
<Keybuk> unless I'm missing something silly?
<elmo> I know there are alternatives, but changing command names at this point in the release is total and utter crack
<elmo> compound that with changing the option parsing...
<dilinger> Keybuk: nice!
<jdub> and you have crack brownies
<jdub> irresistable, delicious, and bad for babies
<elmo> Keybuk: the fact that there's a way to make it work, doesn't mean the way I've been using since before I even used Debian should suddenly stop working
<mdz> jdub: the buttons are totally reasonable; that was what attracted sabdfl
<ogra> and the userlist ...
<mdz> much better than what we have in xscreensaver presently
<jdub> mdz: the swappy switch/unlock stuff is nuts though
<jdub> i totally agree that gss is the right thing 'going forward'
<jdub> but not now
<Keybuk> elmo: it doesn't pretend to be xscreensaver, does it?
<mjg59> Nnngh.
<mjg59> I don't give a shit which screensaver we ship, but could you please MAKE YOUR MINDS UP
<ogra> jdub, mpt works on a redesign since friday afaik... sabdfl ordered that
* jdub cheerled the creation of gss
<mdz> mjg59: dude, calm down, we switched from one to another
<ogra> mjg59+++++++++++++
<ogra> and plus
<mjg59> mdz: Sure, which is a bit of a pain in terms of updating packages that interact with the system screensaver
<mdz> mjg59: yes, there are getting to be rather more of those...
<mjg59> But if there's a last minute change back from gss to xscreensaver, I'm going to kill people
<jdub> "lock screen when active" -> grr.
<ogra> mdz, for me it were 4 switches in complete and two attepmts to rewrite the lock screen it goes back and forth since we started that cycle... and in the end a hasty implementation ...
<Keybuk> it'd be so unlike jdub to suggest we remove some package right before release that he suggested in the first place
<ogra> which made us switch to gnome-scr.
<jdub> Keybuk: i did not suggest switching to gss in breezy.
<ogra> jdub, you did at guadec when i asked you
<mdz> blame whoever showed gss to mark
<mjg59> Can we please agree never to show anything to Mark after preview?
* bddebian only takes blame for wesnoth, not screen savers :-)
<mjg59> It just leads to crack
<jdub> ogra: "yes, we should switch to gss *now* or for breezy+1" most likely.
<ogra> jdub, yup
<jdub> not after *feature freeze and preview release*
<jdub> you have much better things to fix :)
<ogra> jdub, so i dropped my laock patch... and heard from seb it wouldnt be ready a week after UVF
<ogra> *lock
<ogra> and started working on it again... 
<ogra> i dont mind either one... but as you said, i have some edu distro to fix so i dont want to waste my time for something we dont ship
<Keybuk> isn't Mark on holiday?
<ogra> sabdfls word on friday seemed quite final...
<jdub> given mjg59's POV, it's unlikely that even common sense would convince mark otherwise now
<mdz> Keybuk: yes
<ogra> as i said, i dont mind either one, but mpt should be notified what he should beautify now, i'll implement whatever he sends me for whatever package we want
<jdub> ogra: i don't think there's much life in this discussion.
<jdub> so don't worry about it
<ogra> jdub, ok
<mdz> it's going to stay unless it can be shown to be a fuckup
<Keybuk> (was just wondering the timescale for someone to show Mark gss for him to get hooked on it)
<elmo> can we at least retroactively security check it?
<mdz> elmo: yes, we should.
<seb128> dunno if that matter but Suse did a security audit and said it's fine
<Keybuk> are SuSE shipping this too?
<jdub> they might be for 10
<Keybuk> isn't that coming out at the same time as us?
<seb128> I guess they are
<jdub> they're putting a lot of crazy shit in 10
<elmo> usr/bin/oo, ick                                             universe/devel/clc-intercal
<elmo> classy filename
<Keybuk> so it's not really any worse than anything else gnomey we shove in before release ... when it breaks, it breaks for other distros too and looks like a gnome bug
<seb128> yep
<elmo> except a broken screensaver is a good way to make any remotely security concious user run screaming in the opposite direction and never come back
<Keybuk> run where though, if the same thing breaks on other distros too?
<mjg59> Keybuk: MacOS X
<maswan> Keybuk: debian stable?
<mjg59> Windows
<mjg59> Christ knows
<elmo> Keybuk: what other distros will be shipping this thing on the same timescale as us?
<mjg59> Remember when MacOS had a buffer overflow in the screensaver?
<Keybuk> elmo: SuSE 10, apparently
<elmo> Suse 10 are coming out in October?
<elmo> s/are/is/
<mjg59> "Hey, we're no worse than Suse" is not really a good argument...
<Keybuk> mjg59: no...
<mjg59> It would be nice if someone could read the code and stress it
<Keybuk> sure, I'm not arguing against reading the code ;)
<mdz> elmo: suse is now mimicking our release schedule
<elmo> bwahahahaha
<jdub> night all
<bddebian> heh
<bddebian> Heya ivoks
<ivoks> hi
<mdz> elmo: there are very few things you need to get right to have a secure screen locker; they tend to fail safe leaving your screen even more secure by making it impossible to ever unlock
<mjg59> mdz: Providing that the daemon doesn't fall over
* sivang -> back
<mdz> mjg59: you mean, preventing the screen from locking after the timeout?
<mjg59> mdz: Yeah
<mdz> nobody seriously relies on the timeout to lock the screen, do they?
<mdz> ogra: why did you remove the xscreensaver conflict that I asked you to add?
<sivang> mjg59: your package is up already? I can now do through testing on the laptop
<ogra> mdz, you asked me to add a Replaces
<mdz> ogra: no, between gnome-screensaver and xscreensaver
<mjg59> sivang: No
<mjg59> sivang: Give me a moment
<mdz> ogra: oh, you were talking about a different one in your changelog
<ogra> mdz, i added that today ?
<sivang> mjg59: no pro, I will hang here, justping me when we're up with it
<ogra> mdz, ah, yes and youre looking at xscreensaver ;)
<mdz> ogra: reading breezy-changes, it looks like this:
<mdz>    * add a Conflicts: xscreensaver to avoid clashes and doubled
<mdz>      menu entrys
<mdz>    * remove the Conflicts again (not necessary)
<mdz> ;-)
<mdz> ogra: thanks
<ogra> heh... i'll make them more readable in the future :)
<doko> mdz: the ttf-freefont's generated by the new fontforge look ok, I cannot see visual differences
<mdz> Keybuk: are you sure about this pcmcia-cs change?
<mdz> Keybuk: things were as they were because probing hangs some desktops
<mdz> notably some very common Dells
<Keybuk> it only probes when it's a laptop
<ogra> it would also be nice if pcmcia could ask again before it shuts down the network on upgrades, thats very annoying...
<bddebian> doko: all the apt-cache rdepends work OK too.  I'm working on some of the build-deps now
<ogra> especially if you just run update-manager in the background during a IRC meeting :)
<doko> bddebian: what do you work on?
<Keybuk> btw, GNAHSR, packages which rewrite debian/control SHOULD BE FUCKING ILLEGAL
<bddebian> doko: I need a newer fontforge for ttf-defavu for my wesnoth fuckup ;-)
<doko> bddebian: but you did see to main inclusion reports?
<bddebian> doko: ??
<Keybuk> mdz: have_pcmcia=0 on desktops without hotplugged pcmcia cards (desktop ISA owners will have to go the /etc/modules route)
<doko> bddebian: what are you trying to do?
<Keybuk> but on laptops we try anyway, as there's a high probabilty it does have an old ISA socket
<Keybuk> mjg59 claims it won't hang them
<bddebian> doko: I need ttf-dejavu which needs an updated fontforge.  I already tested all the repends on fontforge in Universe.
<mjg59> Autoprobe i82365 on laptops. Don't do it on desktops.
<mjg59> Only attempt it if there isn't a cardbus bridge
<jbailey> mdz: That means that stat could find the major/minor of the swap device...  I've seen that where the device didn't exist yet for some reason. 
<jbailey> mdz: Are you using the current initramfs-tools in the archive, or the snapshot I had put up on p.u.c?
<jbailey> The one in the archive should have a check to not try the resume if the swap partition doesn't exist.
<doko> bddebian: ahh, ok. I don't care that much about universe at the moment, just did it for main
<jdub> oh man
<jdub> i comment on a story on drupal.org
<jdub> and guess who turns up?
<jdub> HostingGeek
<jdub> *insane*
<ogra> lol
<bddebian> doko: I know and I love you for this btw ;-)
<ogra> he wasnt in -motu for ages
<smurfix> jdub: ouch. Is he as bad there?
<bddebian> haha, hostinggeek
<ogra> i think tseng had a lot of fun with him in -motu ;)
<jdub> he just said "hi jdub!!!!!!!!!!"
<ogra> yes, tseng taught him a lot :)
<bddebian> Hey, tseng doesn't teach me anything :-)
<ogra> desrt, you rock !
<mdz> jbailey: that was from a report on -devel
<ogra> (14967)
<mdz> jbailey: and it caused the boot to fail
<mdz> jbailey: if it's as you describe, it's probably broken all thin clients
<jbailey> mdz: Ugh, thanks.
<ogra> jbailey, mdz, i'm just doing my daily burn and installation of edubuntu, wait 2h and you got a guineapig
<jbailey> mdz: The patch causing this is that USB and Ethernet don't like to be loaded before a resume, so the process has to be split up.
<Keybuk> biab; gonna try and duplicate this on laptop now
<\sh> BenC: ping
<\sh> BenC: I would say remove the sky2 driver before it annoyes more people ,-)
<\sh> mdz: on the installed kernel from todays daily iso, 2.6.12-8.14 is installed...but not as boot iso kernel
<Kamion> \sh: be patient, it takes a little while to propagate
<\sh> Kamion: no it's ok..the driver is useless
<\sh> i will file bugreports now 
<mjg59> sladen: Around?
<Kamion> because it requires a daily debian-installer build, which has to be BYHANDed into the archive, etc.
<ogra> mdz, err, looking at the initramfs report again, thats the one jbailey solved with me on the phone (a small quoting bug)... he must have a pre preview mkintitrams-tools
<Kamion> and somewhat unfortunate timing means that the byhand generally happens just after the daily CD image build
<ogra> jbailey, do you agree ? Syntax error: 0x ?
<\sh> Kamion: well..problem is, the driver is not usable right now..it will annoy more people then no driver
<Kamion> \sh: ok
<Kamion> (not my problem really, I don't do kernel)
<Kamion> (unless I have to)
<jbailey> ogra: Well, the three lines I've seen that on are basically: if [ -e ${resume} ] ; then major=$((0x$(stat -c%t ${resume})));  minor=$((0x$(stat -c%T ${resume})))
<jbailey> ogra: but the whole if -e bit is supposed to protect against stat not giving something useful in that spot.
<Kamion> doesn't that need to be $(( 0x(...) ))?
<Kamion> are you sure busybox parses the )) right?
<ogra> jbailey, thats a ltsp boot, there is no resume involved
<\sh> mjg59: would u agree, that it is a better solution to remove the driver from the kernel? sky2 driver
<Kamion> (I might be wrong)
<mjg59> \sh: I'm afraid I don't understand the question
<jbailey> Kamion: I'll double check it, thanks for the heads up.
<\sh> mjg59: right now the sky2 driver for marvel yukon2 hangs after a few seconds (bug report will be filed in a minute)
<\sh> mjg59: it's quite useless, and i think it annoyes more people to have this driver in the kernel, then no driver in the kernel
<ogra> jbailey, i talk about this one: http://lists.ubuntu.com/archives/ubuntu-devel/2005-September/011182.html
<jbailey> ogra: Right.  But in any event, resume not being defined to something useful would take care of that
<mjg59> \sh: Yes, it will be removed
<mjg59> I've already sent a patch
<ogra> jbailey, ah, k, sorry for the noise then
<jbailey> ogra: Don't be.  Any insight as to why it might be failing despite the safeguard is always welcome. =)
<ogra> :)
<bddebian> Hmm, wine might have a problem with fontforge LD_LIBRARY_PATH="../libs/unicode:$LD_LIBRARY_PATH" ../tools/sfnt2fnt wine_courier. 13 1252 96 128 8
<bddebian> Can't open face
<jbailey> Hmm.  In hex a leading zero is always insignificant, right?
<jbailey> I can work around this bug by placing a leading zero so that at least busybox would see 0x0
<jbailey> But I'd rather fix it so that the code isn't run there.
<thesaltydog> jbailey, not only in hex..
<thesaltydog> in decimal too
<thesaltydog> :-)
<jbailey> thesaltydog: Unless your interpretor assumes that you really mean octal.
<thesaltydog> yes!
<crimsun> mdz: would it be possible to apply the patch in bugzilla#14232 from Thomas Hood for alsa-utils?
<jbailey> ogra: I'd like to take you up on your guinea pig offer to figure out why it's failing there.  The only thing I can think of is that for some reason either [ -e "" ]  is matching true, or that the file that is in resume is a regular file and doesn't have a major,minor
<ogra> jbailey, since he says he runs preview, i certainly cant confirm it... i ran several install since then... its unlikely tht the one currently running here is broken for me... but i'll report
<jbailey> ogra: Oh, I had missed that he was running preview.
<jbailey> ogra: I assumed it was from the upload this weekend.  I've been worried over those lines of code.
<jbailey> But they were only added in the Saturday upload.
<ogra> ah, ok, i didnt do an install over the weekend, i played with screensavers :)
<jbailey> Ah!
<jbailey> Is that why my screensavers now all ask for a password? =)
<ogra> heh
<ogra> jbailey, xinerama should be fixed now btw
<jbailey> Ah, cool.  I saw a couple more xinerama things pop by, so I was thinking of dusting that machine off.
<sivang> ogra: as you did in Mataro, the images of your playing with the retro version of the screen saver still with me :)
<Kamion> mdz: please merge colin.watson@canonical.com--2005/casper--translations--0; does what it says on the tin
* Kamion runs off to karate, late as usual
<dilinger> Kamion: that's one thing i wouldn't show up late for, i'd be afraid of getting my ass handed to me :)
<ogra> sivang, :)
<sivang> dilinger: lol
<vrln> the freetype2 package in breezy is version-locked already I guess? It has issues with certain E17 themes (the fonts are cut off in themes that use a very small window border) - it's an issue with all freetype versions under 2.1.8
<crimsun> is there a simple fix for it, like a few one-liners, or is it more intrusive?
<sladen> mjg59: re: 12547.  r.
<sladen> mjg59: that guy was going to get back about his fan though
<mjg59> sladen: I'm rewriting cpufreq-detect.sh. There's various nicer ways of doing the logic
<mjg59> I'll send you a copy later on
<sivang> mjg59: send one to me as well, the hickups are killing my WOTW music :-)
<sladen> mjg59: ideally, rip the stuff out of x86info, or the kernel detect code.  They use the family/model/stepping bit mask for most of the work and only resort to the ID strings to tell apart idividual processors
<sladen> mjg59: no clue how to detect the chipset, currently it's hackish, but... working
* sivang thinks of attempting use lvresize to shrink a partition, wonder if there are any good reports about it
<sivang> mpt: ping
<elmo> doko: ?
<crimsun> mdz: please consider merging the patch referenced from http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324783 for xmms-flac
<doko> elmo: here
<sladen> sivang: edit cpufreq-detect and change 'Intel ICH' to 'Intel .*ICH' and then you can get rid of the hickups
<sivang> sladen: k, let me try that
<mpt> sivang: pong
<elmo> Rejected: ttf-opensymbol_1.1.4-7ubuntu2_all.deb: old version (1.9.125+2.0beta2-1ubuntu2) in breezy >= new version (1.1.4-7ubuntu2) targeted at breezy.
<elmo> doko: ^--
<elmo> from openoffice.org_1.1.4-7ubuntu2_i386.changes
<doko> elmo: ahh, ok. are the other binaries in the archive?
<elmo> amd64, powerpc?
<elmo> or what do you mean?
<doko> no, I think you accept the other binaries built from the source, even if one fails
<elmo> err, heck no
<elmo> an upload is an upload (or: everything associated with a .changes); if  one part fails, the whole thing fails
<bddebian> doko: How's fontforge coming? :-)
<doko> bddebian: see main inclusion queue ...
<bddebian> doko: And where is that?  I live in the Universe ;-)
<sivang> mpt: I'd like to leave lpi still for all of the alike panel behaving applets: showdesktop, notification area, workspace switcher. I still want to have the lpi items pop to the user if he right clicks those, to provide consistent behavior. What do you think?
<seb128> BenC: around?
<mpt> sivang: Consistent with what?
<crimsun> elmo: please sync openafs-doc from Sid
<crimsun> elmo: err, scratch that. Sorry.
<sivang> mpt: with the panel itself, for example, if someone right cliks the panel, he can see the lpi items, if we drop it from show desktop applets, the part of the panel with that "button" on it , when right clicked won't have the items. this is somewhat inconsistent since I don't think user distinct that from the rest of the panel. same goes for the workspace switcher status and notification area.
<sivang> mpt: so "regular" applets are excluded, but those will still tickle the user to open a launchpad browser window.
<mpt> sivang: They have context menus specific to the applet, so if they have LPI items as well, those items should also be specific to the applet.
<mpt> sivang: I thought the reason for removing them was that they were too much clutter, not that they were going to the wrong place.
<sivang> mpt: true, this is still the reason for the "regular" applets - clock , fish ,etc. But I am talking about hte applets which are essentialy a part of the gnome-panel, and that IMHO can still carry lpi since it would look as this is part of the panel.
<mpt> sivang: How they look isn't quite as important as what their context menu already contains
<mpt> e.g. the workspace switcher's context menu is all about the workspace switcher, so if it contained LPI items I'd expect those to be about the workspace switcher too.
<mpt> same for Show Desktop
<mpt> same for notification area
<sivang> mpt: they are, bare in mind that those all part of the gnome-panel package, so lpi items there is meaningful to their regard.
<sivang> mpt: (users clicking on the panle's get help, will reach the same url one cliking the get help of showdesktop)
<sivang> err, /me curses this laptop kbd
<vrln> I found a little aesthetic bug in the breezy bootup scripts: http://tolu.edu.hel.fi/~vrln/script.png
<vrln> the "Mounting local filesystems..." displays the [ok]  in a wrong location geometry-wise
<Keybuk> grr
<vrln> is this worth filing a bug about, or is this "normal"?
<Keybuk> fabbione: so, talk to me about the input subsystem ;)
<fabbione> Keybuk: it sucks?
<fabbione> what else do you need to know?
<mpt> sivang: Hmm, this is like whether "Back" and "Forward" should be in the menu when you right-click on a link :-)
<sivang> mpt: so do you agree? ;-)
<Keybuk> it seems to think it can get away with not passing all the environment to hotplug
<mpt> sivang: ok, I suppose so
<mpt> sivang: with the disclaimer that I think including LPI items in gnome-panel's context menu is not useful to begin with
<sivang> mpt: but then, how would you help people one-click to launchpad it? (btw - I am really not trying to push, just want to follow what you say to be ok with spec/intent)
<mpt> How would I help people what to what?
<ogra> fabbione, seen 14967 recently ? :-D
<sivang> mpt: to have them open gnome-panel in launchpad as they do for "regular" apps ;)
<vrln> anyone? Just a simple yes/no would be great and I'd be glad :)
<fabbione> ogra: no.. i am not following that bug...
<sivang> ogra: malone/bugzilla?
<vrln> (in regards to the 3 lines I said earlier)
<fabbione> ogra: and no.. i am not going to debug inotify anymore :)
<fabbione> ogra: i refuse :P
<seb128> fabbione: what shoud I do to rebuild a linux package with a patch? apt-get source linux-source-2.6.12, drop the patch somewhere or apply it and debuild?
<ogra> fabbione, we apparently have a patch 
<fabbione> seb128: we use dpatch
<fabbione> seb128: create a dpatch and stick it in the usual place
<fabbione> BUT
<fabbione> we don't use 00list directly
<fabbione> you need to add it to 00list-$version
<fabbione> so just look around there
<mpt> sivang: I wouldn't. I think the kind of people who need tech support with gnome-panel are unlikely to understand that it's a distinct item from the rest of the OS, and I don't think there are significant people who want to translate gnome-panel but not the rest of Ubuntu.
<fabbione> and you will easily understand
<fabbione> seb128: if you build on concordia (I STRONGLY SUGGET IT)
<fabbione> seb128: export CONCURRENCY_LEVEL=200
<fabbione> that will speed up things
<mpt> sivang: So I'd have a general "Help" menu for LPI with Ubuntu-in-general (including panel), but that's Dapper material.
<vrln> ok fine - I'll try #ubunty instead, thanks anyway
<fabbione> seb128: there is also another kind of speedup you can do
<fabbione> seb128: before building go into debian/config/$arch
<fabbione> and remove the flavours you don't need
<fabbione> so if you use 686, just kill 386 686-smp k7*
<fabbione> and use the binary-debs target
<seb128> fabbione: in fact that's to try the inotify patch ... maybe I should ping BenC to know if he can do 1 build and put here somewhere so people can try it and note if that fixes the issue?
<fabbione> it will build only the image you need
<fabbione> seb128: i just gave you everything you need.. really
<fabbione> it's few simple steps
<seb128> fabbione: thanks for the explanations, I'll give it a try now
<fabbione> seb128: use concordia
<seb128> and maybe using concordia is a good idea, right :)
<fabbione> it will save your life :)
<fabbione> but don
<sivang> lol
<fabbione> but don't export more than 200
<fabbione> otherwise it will crash under your feet
<seb128> k
<fabbione> and elmo will start yelling and screaming at me
<seb128> could be fun :p
<seb128> but then I need to start running from you which is not really that fun :)
<sivang> fabbione: concrodia will crash? ;-)
<sivang> mpt: agreed, what should I do for now? (want to "fix" this "bug")
<mpt> sivang: <mpt> sivang: ok, I suppose so
<mpt> so, include them if you like
<fabbione> seb128: ahahha
<mpt> I don't think it'll make any difference either way
<fabbione> sivang: if you export 500 yes
<fabbione> sivang: it will exhaust all the memoru
<fabbione> memory 
<fabbione> and become kind of unresponsive
<sivang> fabbione: how much RAM does it have?
<sivang> mpt: ok, if only to not annoy some people who have reported it to be annoying in the clock and other applets.
<fabbione> sivang: 2Gb + 2Gb swap
<fabbione> sivang: but running 500 instances of gcc is not exactly light
<sivang> fabbione: true :)
<WaterSevenUb> Kamion, installing everything in PT language and allowing connection to the network do download additional language packages as requested during install (doesn't give an error in the end), firefox in the end appears in plain English, do you know why?
<WaterSevenUb> kamion, if the download of language support doesn't give an error, the package mozilla-firefox-locale-pt should have been installed.
<mjg59> www.codon.org.uk/~mjg59/tmp/powernowd_0.96-1ubuntu3_i386.deb
<mjg59> If people could test that, I would love them forever
<sivang> mjg59: it it works, I will love you back with a beer on UBZ, if you're coming there
<mjg59> sivang: Grab it and install it
<mjg59> You may need to reboot
<Robot101> oh yes
<sivang> mjg59: trying now
<fabbione> Kamion: ping?
<fabbione> mehsorry
<fabbione> mdz: ping?
<fabbione> mdz: librrd2-dev needs promotion to main. It's a B-D of lm-sensors
<fabbione> i think something was done recently to these 2 pkgs..
<fabbione> because i don't recall them being part of main
<sivang> mjg59: how do I know if I have to reboot? if hickups are gone iz ok ;-)
<mjg59> sivang: Has it loaded speedstep-ich ?
<sivang> mjg59: should I check with lsmod again?
<mjg59> sivang: Yup
<sivang> mjg59: module list as the same as before, IIRC
<sivang> speedstep_smi           5680  0
<sivang> speedstep_lib           4228  1 speedstep_smi
<sivang> freq_table              4388  2 speedstep_smi,cpufreq_stats
<mjg59> sivang: Ok. Can you try rebooting, then?
<sivang> mjg59: sure, be back in a sec.
<sivang> er, have to wait for a package build. in a couple of minutes then.
<siretart> fabbione: around? your sparc is ready :)
<mjg59> sivang: No problem
<sivang> siretart: are you and fabionne starting to play with sparc? I have a new machine in the office, could try installing there.
<siretart> sivang: A friend of mine wants to provide hosting and hardware for use as buildd
<seb128> jbailey: around?
<sivang> siretart: whee cool
<jbailey> seb128: Yup
<seb128> jbailey: do you know something about http://bugzilla.ubuntu.com/show_bug.cgi?id=15826 ?
<jbailey> Only sort of.  I know the code that's crashing, but it's not obvious to me how it's doing so.
<jbailey> ogra: Did you get a failure with your LTSP install?
<seb128> jbailey: k, so no idea of that a linux or something else bug and what to do?
<ogra> jbailey, i burned the wrong iso :( still installing
<fabbione> siretart: great!
<fabbione> siretart: but i am about to go and crash in bad..
<fabbione> bed even
<ogra> seb128, thats the bug we just talked about
<seb128> jbailey: it happens to the gnome-vfs upstream and a friend to him on a clean install, and it doesn't crash with -7
<fabbione> siretart: mind if i take it over tomorrow?
<ogra> seb128, there is also a mail on -devel
<seb128> ogra: who, where, when?
<siretart> fabbione: 
<siretart> fabbione: I'll write you an encrypted and sign mail with credential, ok?
<ogra> seb128, this morning... it has ltsp in the title... exactly the same symptom
<siretart> fabbione: which mail do you prefer?
<fabbione> siretart: sure.. that works for me..
<seb128> ogra: did you figure what is wrong?
<jbailey> seb128: Any of them on IRC?
<fabbione> siretart: anything that's in my gpg keys is fine and known to work
<sivang> mjg59: rebooting now
<ogra> seb128, i'm just installing a edubuntu, i'll try to track it once its finished
<jbailey> seb128: I'd love to troubleshoot this interactively.  That's why I was waiting for ogra.
<fabbione> siretart: they all land in the same inbox :)
<siretart> fabbione: okay :)
<seb128> jbailey: gicmo is coming 
<jbailey> seb128: Thanks, just grabbing a drink.
<seb128> jbailey: he's one of the gnomevfs upstream and he opened the bug I just pointed
<gicmo> hey hey
<seb128> hi gicmo :)
<gicmo> jbailey, you wanna track the kernel stuff down?
<jbailey> gicmo: Please.
<jbailey> gicmo: Let's take it to a /msg so that you can paste things at me without annoying the neighbours. =)
<seb128> gicmo: dunno if you use freenode, but you need to be registred to /query now ...
<jbailey> seb128: I have that turned off on my nick.
<seb128> oh, cool
<jbailey> seb128: /msg nickserv set unfiltered on
<jbailey> IIRC
<seb128> jbailey: I just say it to people now because it's not easy to notice first 
<jbailey> Yup
<maswan> elmo: if you are around and feel like some dns changing, tutankhamon.acc.umu.se (130.239.18.137) is down with some undiagnosed hardware failure for now. fix eta anything from days to weeks.
<fabbione> maswan: yo
<fabbione> maswan: do you think i can get (tomorrow) buttercup online to grab the config files for the other buildd?
<fabbione> (tomorrow = when you can. not now ;))
<maswan> fabbione: ah, right, I'll see when we get around to doing that. probably not tomorrow, hopefully this week. :)
<fabbione> maswan: for now i will be glad to backup the config files
<fabbione> maswan: so i can just replicate them to another buildd
<fabbione> it looks like we will make it for breezy :)
<maswan> fabbione: :)
<fabbione> we only have one issue to solve
<fabbione> and test the install cd
<maswan> fabbione: well, it is booted in solaris now (other disks)
<fabbione> maswan: ah cool
<fabbione> did you put some load on it?
<fabbione> or is it just idling?
<mjg59> sivang: Any joy?
<sivang> mjg59: seems so :)
<sivang> mjg59: now let's try with some music, as there it was the worst hickups.
* fabbione waves goodnight
<sivang> nigh fabi
<maswan> fabbione: I don't remember if they put osme load on it on if we're going to do that tomorrow. I was thinking something like while(1) {compile gcc; rm -rf}
<sivang> grr, night fabbione 
<mjg59> sivang: Cool
<sivang> mjg59: you rock man, I will report back if I'll have more problems.
<mjg59> sivang: Is speedstep-ich loaded?
<sivang> mjg59: acutally, I didn't see any speedstepish loaded, is this okay?
<mjg59> sivang: Hmm.
<mjg59> sivang: Yes, that's a problem
<sivang> pooh@bluespace ~ $ lsmod | grep "speedstep"
<sivang> pooh@bluespace ~ $
<mjg59> sivang: Can you please do
<sivang> mjg59: sure, whatever you say
<mjg59> sivang: . /usr/share/powernowd/cpufreq-detect.sh; echo $MODULE $MODULE_FALLBACK
<mjg59> sivang: The first ". " is important
<wasabi> Oh this is weird.
<sivang> mjg59: what does it do? (the first "." ?)
<wasabi> Fakeroot breaks when using libnss-ldap in the way I am doing so
<mjg59> sivang: It sources the file into your current shell, rather than executing it in a new one
<dholbach>  good night
<sivang> dholbach: night d
<sivang> mjg59: ah k, do I need to run this as sudo'd since I get a permissions error
<mjg59> sivang: No, that should be fine
<mjg59> If it's just the /dev/mem error
<sivang> mjg59: yes, it is
<mjg59> Do you get any output?
<sivang> pooh@bluespace ~ $ . /usr/share/powernowd/cpufreq-detect.sh; echo $MODULE $MODULE_FALLBACK
<sivang> /dev/mem: Permission denied
<sivang> none acpi-cpufreq
<mjg59> Hm.
<mjg59> What CPU do you have?
<sivang> model name      : Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz
<sivang> flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
<sivang> currently operating in 1.20GHz
<mjg59> sivang: What does the cpu family line say?
<sivang> cpu family      : 15
<mjg59> sivang: Ok, hang on a moment
<sivang> mjg59: sure no prob
<sivang> mjg59: I'm getting much less hickups now, although spotted on or two since I booted
<mjg59> sivang: Can you download the package again and reinstal it?
<sivang> ofcourse
<sivang> you changed anything?
<mjg59> Yup
<sivang> mjg59: ok, installed, reboot again?
<mjg59> sivang: Please
<sivang> mjg59: ok, be back in a sec.
<sivang> mjg59: ok, back now
<sivang> mjg59: lsmod | grep "speedstep" again?
<mjg59> sivang: Please
<sivang> Huston, I think we have a take off :-)
<sivang> pooh@bluespace ~ $ lsmod | grep "speedstep"
<sivang> speedstep_ich           5164  0
<sivang> speedstep_lib           4228  1 speedstep_ich
<sivang> freq_table              4388  2 speedstep_ich,cpufreq_stats
<mjg59> Excellent
<mjg59> That seems more promising
<mjg59> Hmm. Is powernowd running?
<sivang> yes, it does
<mjg59> Rock
<sivang> so now I should be able to use the laptop witout hickups?
<mjg59> Yup
<sivang> (none spotted so far, even network seem faster)
<sivang> mjg59: how does it do that? what was the error?
<mjg59> sivang: I had some incorrect shell syntax
<sivang> mjg59: so you were loading  the incorrect modules due to that?
<sivang> mjg59: (hope you don't me asking)
<sivang> weird, gnome-terminal eats up 30MB, that normal?
<sivang> (with irssi in)
<seb128> jbailey, gicmo: have you figured what is wrong? I've the same issue now here with a linux rebuild I made with an inotify patch
<jbailey> seb128: We're working on multiple bugs at once. =)
<seb128> jbailey: oh, and the bugzilla I pointed 1 hour ago?
* jbailey reads the backscroll
<seb128> jbailey: the syntax error 0x0 stuff
<ogra> jbailey, same symptom...
<mjg59> sivang: Yup
<tseng> ogra: oh man
<tseng> ogra: hosting geek.
<ogra> tseng, lol
<bddebian> heh
<jbailey> seb128: Right.  We're fixing that.
<jbailey> We've also fixed update-initramfs to work right too in the case I hadn't tested.
<jbailey> *joy*
<seb128> jbailey: what is wrong for the syntax error? Something I can workaround? I would like to comment on this patch before going to sleep :p
<seb128> s/workaround/workaround now/, I"m sure I'll get it fixed by an upload anyway :)
<jbailey> seb128: As a workaround, edit /usr/share/initramfs-tools/scripts/functions
<jbailey> Go to line 231.
<mjg59> jbailey: Right. I'll be looking at the hibernate issue soon
<mjg59> It seems to be broken for everyone (hurrah hurrah hurrah)
<jbailey> Comment out that section for now, and regenerate the initramfs with mkinitramfs -o /boot/initrd.img-2.6.12-8-FOO 2.6.12-8-FOO
<seb128> thanks
<seb128> if that happens to everybody this bug is going to make some bad pub
<seb128> "my box doesn't box" is something most user will not fix
<jbailey> seb128: It'll be gone as soon as I figure out what it is.
<seb128> k, thanks
<gicmo> jbailey, so reboot now?
<jbailey> gicmo: Please.
<gicmo> ok brb
<sivang> night all
<bddebian> Later sivang
<jmg> hi all
<jmg> does ubuntu use the debian menu system for registering/deregistering
<elmo> ok, so yeah, gnome-screensaver is definitely entirely breaking my box
<ogra> elmo, ?
<elmo> every time it starts the load ramps up and up, with X spinning hard
<jmg> if not, how do i add a menu item. thanks
<ogra> elmo, bug please :)
<ogra> elmo, i havet heard such a case yet...
<ogra> what arch is that ? ppc ?
<elmo> i386
<ogra> hmm
#ubuntu-devel 2005-09-25
<elmo> ogra: if you don't use your box for anything else you might not notice - try locking your screen, switching to the console and running top
<robertj> is Ubuntu Express still on track from Breezy?
<tseng> no.
<ogra> elmo, it eats 2%, 90% idle
<elmo> ogra: ok, so it's not universal at least
<elmo> I wonder if it's fighting with workrave
<ogra> ah, that sounds reasonable
<ogra> i also have a weird bug from rossb... 
<ogra> elmo, #15817 
<ogra> it couls also be something like that...
<ogra> could
<ogra> i cant reproduce it on x86 and amd64 here
<seb128> jmg: you can have a Debian menu from the Application menu by installing menu-xdg
<seb128> jmg: other way you have to use a menu editor, the GNOME menu uses the freedesktop format and desktop files
<seb128> jmg: "smeg" by example of menu editor
<robertj> did the guadalinux folks just not hit their deadlines?
* ogra hugs seb128 for working on KDE issues with the kernel :)
<elmo> yeah, the problem is workrave
<elmo> or gss vs. workrave
<seb128> that's not a KDE issue but an inotify issue, I was saying it from the start :p
<ogra> seb128, but you also said you wouldnt work on KDE issues :) 
<ogra> seb128, thanks for doing it anyway...
<robitaille> ogra,   is it a bug or a feature that gnome-screensaver doesn't have a gui to select an amount of time before my laptop display totally turns off?
<seb128> np
<ogra> robitaille, hmm, not sure :) 
<robitaille> like with xscreensaver and its powermanager menu
<ogra> robitaille, i dont know whats planned for the UI in the future...
<ogra> so i'm not sure if its a bug or a feature
<robitaille> but the current UI is  the UI we'll ship?
<ogra> robitaille, with changes in the lock screen... but yes
<jmg> is there a way to monitor the filesystem for changes before and after installing from a
<jmg>   commercial installer and make a deb file out of the changes?
<jmg> not checkinstall, this POS doesnt use makefiles
<robitaille> ogra,  usually with my laptop and xscreensaver, I select blank the screen after 1min, turn off the screen after 5 mins to minimize battery usage. 
<ogra> robitaille, i think we can do something similar with laptop-mode or the acpi-support package for now, in dapper we'll surely have g-p-m ready
<robertj> jmg: fsdiff probably does the job
<robertj> jmg: but it's just going to give you the changes, not any of the packaging stuff
<robitaille> ogra,  that would be very useful to avoid reinstalling xscreensaver at the cost of removing ubuntu-dekstop;  should I fill something in bugzilla?
<ogra> robitaille, there is something already...
<robitaille> ogra,   oh...I didn't find it.
<elmo> ogra: #15831, enjoy
<ogra> elmo, thanks
<ogra> i'll have to use workrave now i guess :)
<ogra> robitaille, 15426 and 12003
<Nafallo> hmm
* Nafallo shuts down workrave :-P
<ogra> Nafallo, do you see that too ?
<Nafallo> ogra: I saw that bug. that was enough for me :-P
<Nafallo> ogra: atleast this evening ;-)
<Nafallo> ehm, night
<mdz> jbailey: did you track down that initramfs error?
<jbailey> mdz: Still chasing it with gicmo 
<jbailey> Figured out why my trap didn't work.
<\sh> grmpf
<jbailey> Apparently [ -e ${resume} ]  is true when resume is not defined.
<gicmo> jbailey, works
<jbailey> \o/
<gicmo> also for my friend
<ogra> oh, great, i just finished my install
<ogra> jbailey, whats the fix i can test it immediately
<jbailey> ogra: http://people.ubuntu.com/~jbailey/initramfs-tools_0.27_all.deb
<jmg> wow fsdiff isnt in debian
* jbailey wonders if he can wire a machine up here LTSP style for testing.
<ogra> jbailey, install edubuntu :)
<jbailey> ogra: What does it need on the server side?
<jbailey> Like, is it a package I can install on my main breezy box?
<ogra> jbailey, i run a pIII 900 with 256MB , but i only have one client available
<ogra> ah, k
<jbailey> Well, I was going to setup another machine anyway for watching DVDs in the other room.
<ogra> see ThinClientHowto on the ubuntu wiki
<jbailey> So it has no need of a local drive anyway.
<ogra> thats the core stuff, you wont need anything else... edubuntu is only the software selection and shiny artwork stuff...
<jbailey> Ooo shiny!
<ogra> heh
<ogra> the CD bootscreen looks cool, i just saw it the first time in action
<ogra> anyway, testing now
<mdz> crimsun: the change looks ok to me, though the patch is in "normal" format and so is unlikely to apply correctly
<mdz> crimsun: (regarding 14232)
<\sh> good night gentlemen
<martinhj> jbailey: looked anymor at #14316 ? (lilo not working when I boot with initramfs image)
<ogra_ltsp> jbailey, i can confirm the breakage and i can confirm the fix, works fine
<jbailey> ogra_ltsp: Lovely, thanks.
<ogra_ltsp> mdz, mousedev doesnt get loaded in ltsp :(
<jbailey> ogra_ltsp: I'll do two more tests on my machines and upload.
<ogra_ltsp> jbailey, great
<mdz> ogra_ltsp: if that were the case, X would never start
<mdz> yet it does
<ogra_ltsp> mdz, exactly, it doesnt start
<ogra_ltsp> i had to login on console and load mousedev, i will investigate further...
<mdz> ogra_ltsp: more likely you are encountering http://bugzilla.ubuntu.com/show_bug.cgi?id=12915
<jbailey> martinhj: Gimme a sec.  I'm just working on a different bug.
<jbailey> <song>Where oh where did my /dev/input go?</song>
<ogra_ltsp> mdz, yes, most likely
<ogra_ltsp> thanks
<mdz> ogra_ltsp: if you are able to reproduce it, please help Keybuk debug it
<mdz> because so far we have difficulty reproducing it
<mdz> and
<mdz> the thin client environment is nice and simple
<mdz> mousedev is the only module loaded in /etc/modules
<ogra_ltsp> yup, i know
<ogra_ltsp> i will try to find the cause
<Keybuk> I did 150 reboots today
<Keybuk> AND STILL CAN'T REPLICATE THAT MOTHER FUCKER
<Nafallo> Keybuk: wow! that's lots of fsck :-P
<mjg59> Nafallo: Rule 1 in debugging: tune2fs your filesystem to fsck less often
<Keybuk> Nafallo: I commented that stuff out
<Nafallo> :-)
<Keybuk> well, made it reboot before it got that far
<Nafallo> mjg59: btw, is that stuff supposed to run while on battery?
<mjg59> No, not really. But it probably is.
<Nafallo> mjg59: that's a post-breezybug I guess? ;-)
<mjg59> We'll see
<mjg59> Anyway, I'm off home
<Nafallo> oki
* Nafallo adds bugfiling on mjg59 to his todo-list :-)
<Keybuk> here's a nickel, kid; get a real filesystem
<Nafallo> I run ext3 everywhere ;-)
<Keybuk> it's not a real filesystem unless it scares the willies out of elmo
<jbailey> Keybuk: umsdos?
<Nafallo> HAHA
<Keybuk> reminds me of the LCA keynote where Andrew Morton gave away the USB key to the man who admitted to running jfs "to back up his files onto"
<HrdwrBoB> hahaha
<HrdwrBoB> I use XFS
<ogra_ltsp> Keybuk, seems i can reproduce it reliably
<tseng> have a cookie
<ogra_ltsp> Keybuk, so what info do you need...
<Keybuk> ogra_ltsp: check that mousedev *is* loaded, and /dev/input/mice is missing
<ogra_ltsp> Keybuk, mousedev isnt loaded
<Keybuk> it isn't?
<ogra_ltsp> i have to load it manually
<ogra_ltsp> afterwards everything works fine
<Keybuk> then it's not 12915
<ogra_ltsp> ok
<Keybuk> 12915 is when mousedev is loaded, but the udev event is dropped somewhere
<ogra_ltsp> so its something else
<Keybuk> sounds like it
<ogra_ltsp> funnily psmouse is loaded
<Keybuk> oh, now that's kinda amusing
<Keybuk> psmouse should generally drag mousedev in
<ogra_ltsp> heh
<ogra_ltsp> hmm, modinfo psmouse doesnt show a dependency on mousedev
<Keybuk> no, but mousedev declares its undying love for all things of class mouse
<Keybuk> so grepmap <anything mousey> will load it
<Keybuk> as will modprobe $MODALIAS for anything mousey
<ogra_ltsp> hmm
<Keybuk> actually, the second bit there may be a lie and a kernel bug
<Keybuk> but we're not using that anyway
<ogra_ltsp> the fun is, i have a /etc/modules with only the line mousedev in it... 
<ogra_ltsp> but it still doesnt get loaded
<Keybuk> hmm
<Keybuk> ltsp is ordinary breezy?
<Keybuk> in breezy those are loaded by S:S20module-init-tools (yay descriptive filename)
<ogra_ltsp> yup, but with a startscript for the client that loads the modules...
<Keybuk> hmm
<Keybuk> trace the script?
<ogra_ltsp> so there may be something wrong... but i wouldnt know what, since there was no change in ltsp since ma last install on friday
<ogra_ltsp>     for module in $(env | awk -F= '$1 ~ /^MODULE_/ { print $2 }'); do
<ogra_ltsp>         modprobe $module
<ogra_ltsp>     done
<Keybuk> hitting max environment size ?
<ogra_ltsp> hmm...
<mdz> jbailey: thoughts on letting initrd-tools pass into universe in breezy?
<ogra_ltsp> env looks ok here... on the client as well as on the server
<mdz> ogra_ltsp: that code isn't relevant
<mdz> that's used for loading additional modules via lts.conf
<mdz> mousedev is loaded in /etc/modules
<ogra_ltsp> mdz, so module-init-tools is my prob 
<mdz> ogra_ltsp: perhaps you modified /etc/modules in the chroot
<ogra_ltsp> mdz, i didnt touch it...
<mdz> ogra_ltsp: "stuff listed in /etc/modules doesn't get loaded anymore" is a bug someone else would have noticed...
<ogra_ltsp> its a fresh install the only thing i did was reconfiguring linux-image to use jbaileys fix
<mdz> ogra_ltsp: did you look at /etc/modules or no?
<ogra_ltsp> it contains mousedev as usual
<ogra_ltsp> module-init-tools is there as well... started by S20 in rcS.d
<Keybuk> is there an /etc/modules-* ?
<ogra_ltsp> nope
<jbailey> mdz: I'd be happy to see that.  The only case I've seen where I have no idea what's happening is the iBooks that refuse to load an initramfs at all.
<jbailey> mdz: But it has to happen right after breezy, anyway, since without devfs it won't work.
<Keybuk> did you really mean devfs?
<jbailey> Keybuk: Yes.  initrd-tools depends on devfs.
<ajmitch> jbailey: just to check, with initramfs, udevstart runs before the real init?
<jbailey> Keybuk: This was part of my incentive to start initramfs-tools after OLS of last year.  I tried ripping the devfs stuff out, and it just got uglier..
<jbailey> ajmitch: Yes, but only a limited subset of drivers has been loaded at that point.
<jbailey> ajmitch: g'morning, btw.
<ajmitch> jbailey: right, just checking for selinux stuff :)
<ajmitch> hi
<jbailey> Ooo, selinux.  shiny. =)
<ajmitch> jbailey: I'd really like to see some of it in dapper if possible, so I need to review all the bits I have now
<jbailey> Nice.  Hardening dapper would probably be lovely.
<ajmitch> yeah
<jbailey> It would also mean that anything that certifies to dapper isn't going to automatically suck on the next version if it grows selinux
<ajmitch> depends on how much support we can get in :)
<Keybuk> it'd be nice to get a real deployment of the dpkg selinux support to see whether it works <g>
<ajmitch> things are still moving a bit slow in debian with other packages :)
<ogra_ltsp> mdz, module-init-tools is broken, line 25 reads "log_end_msg 1" but should read "log_end_msg 1 || true" else it exits on readonly filesystems or if depmod cant get executed out of other reasons
<ogra_ltsp> in the init script that is indeed
<wftl> Can anyone provide me a link that can show me the release schedule and the feature plan for 5.10 and the next release?
<Burgundavia> wftl, 1st part, 5.10 releases Oct 13, 2005
<Burgundavia> wftl, features for 6.04 (the next release) are going to be decided at the next dev conference
<bddebian> https://wiki.ubuntu.com/Releases
<Burgundavia> wftl, features for 5.10 can be seen in the release notes https://wiki.ubuntu.com/BreezyReleaseNotes
<wftl> Thanks, Burgundavia and bddebian.
<bddebian> NP
<wftl> Are there any likely changes to the installer for Breezy Badger?
<Burgundavia> wftl, no
<Burgundavia> wftl, the uniifed live/install cd didn't make feature freeze
<Burgundavia> expect it for 6.04
<wftl> I actually meant the graphical installer.
<wftl> Burgundavia, where are you located?
<wftl> Just curious because of the shawcable address.
<Burgundavia> wftl, Victoria, BC Canada
<wftl> Ah, cool.  Nice place.
<Burgundavia> wftl, the unified live/installer cd is the graphical isntallers
<mjg59> So. As root, how do I determine a user's Dbus session address?
<Lathiat> you dont?
<mjg59> Ok. Let me rephrase that.
<mjg59> As root, how do I determine a user's DBus session address in order for it to be possible to control gnome-screensaver from acpi scripts and avoid the death of small kittens and destruction of the battle fleet?
<mjg59> mdz: Around?
<mdz> mjg59: yep
<mjg59> mdz: Something of a problem with gnome-screensaver integration
<mjg59> mdz: gnome-screensaver-command uses DBus to communicate. It's not just a drop-in replacement for xscreensaver-command
<mjg59> The ACPI scripts run as root, so somehow we need to mimic the user's DBus environment. I can't find any simple way of doing that
<mjg59> Which presents certain problems
<ogra> mjg59, probably mimic the user, not the dbus env ? (i know how ugly that is) sudo -u $user gnome-screensaver-command --whatever ?
<mjg59> ogra: No, that doesn't work
<mjg59> ogra: Because it doesn't know where the DBus session bus is
<ogra> works here ...
<ogra> root@honk:~ # gnome-screensaver-command --activate
<ogra> ** Message: Failed to connect to the D-BUS daemon: No reply within specified time
<ogra> root@honk:~ # sudo -u ogra gnome-screensaver-command --activate
<ogra> root@honk:~ #
<mjg59> ogra: + su mjg59 -c 'gnome-screensaver-command --unthrottle'
<mjg59> ** Message: Failed to connect to the D-BUS daemon: Unable to determine the address of the message bus
<ogra> hmm, yes, does only work in gnome-terminal...
<infinity> No, it only works if you have your environment preserved. :)
<mjg59> ogra: You've probably carried over your environment
<infinity> Hit a terminal, then "sudo su -", then try it.
<infinity> Breaks miserably.
<infinity> Is this seriously the first time we've run into the "hey, wait, how can root fiddle with aq user's DBUS session?" problem?
<infinity> It seems to me it would/should have come up much earlier. :)
<mjg59> < DrNick> mjg59: cat /proc/$(pgrep -U nicholas gnome-session)/environ |
<mjg59>                 xargs -0 -n 1 | grep -Po '(?<=DBUS_SESSION_BUS_ADDRESS=)(.*)'
<mjg59> I'm in awe of that one.
* infinity shudders.
<mjg59> I think I may have to use it.
<infinity> There must be a less obviously "I am root, so can do evil things" way to do it.
<ogra> argh
<mjg59> If anyone has a better suggestion within the next 4 minutes, I'll go with that
<mjg59> Otherwise you're getting crack
<mjg59> All of you
<mjg59> I've got an acpi-support upload that finally seems to fix the "My fans are broken after resume" thing
<infinity> Crack it is.  I can't be bothered to take the time out and search for something "better".
<Lathiat> mjg59: oh man
<Lathiat> mjg59: that is...
<Lathiat> thats impressive
<Lathiat> wont work on kde tho
<mjg59> Lathiat: If they're running gnome-screensaver under KDE, then, well...
<ajmitch> Lathiat: but this is for gnome-screensaver love.
<ajmitch> it's possible, but hardly going to be supported if they mix & match quite like that
<mjg59> Nnnngh.
<mjg59> Now it fails silently.
<mpt> ogra: ping
<Lathiat> mjg59: so what, this is to deactive the screensaver? can't you just run su <user> -c "dbus-send.." or whatever?
<mjg59> Lathiat: That would still need to know the user's DBus session address, no?
<Lathiat> mjg59: oh, yeh
<Lathiat> hrm
<jdub> GOOD MORNING FREEDOM LOVERS!
<whiprush> yay Mr. Dub!
<bddebian> Heya jbailey 
<bddebian> Err jdub 
<ajmitch> morning jdub 
<ajmitch> Lathiat: heard from ross about avahi debs? :)
<Lathiat> mjg59: mmm
<fabbione> morning
<fabbione> mdz: ping?
<fabbione> mdz: unping
<pitti> Good morning
<ajmitch> morning pitti 
<fabbione> hey pitti
<fabbione> hi ajmitch 
<pitti> moin ajmitch, fabbione 
<fabbione> hmmm weird
<fabbione> something is changed in in.tftpd recently that makes the init script useles
<fabbione> +s
<dholbach> good morning
<jsgotangco> hi daniel
<dholbach> hey jerome :)
<magnon> pitti: your pbbuttonsd package did not fix it :P
<pitti> magnon: but 0.7.1 works? http://people.ubuntu.com/~pitti/packages/pbbuttonsd_0.7.1-1ubuntu1_powerpc.deb
<dholbach> morning pitti
<magnon> yeah, 0.7.1 does owrk
<magnon> work
<magnon> I was entirely sure that I posted a comment to that bug on it
<magnon> but I didn't
<magnon> :/
<mdz> fabbione: unpong
<pitti> Hi mdz
<mdz> hi
<magnon> pitti: I'm not using the ubuntu 0.7.1 though. But, I'm not seeing any problems now
<magnon> I'd love to help finding what to backport
<magnon> but it's 7am and I need to go to bed ;)
<magnon> been up all night writing *sigh* business plans
<magnon> pitti: I'll be back at about 1300 CET, I'll see about it then :)
<magnon> have a nice day, folks
<pitti> magnon: sleep well
<pitti> thanks
<fabbione> mdz: well since you are around.. i am taking off a couple of hours from my ws today.. i need to go and SHARE THE LOVE!
<pitti> fabbione: distribute CDs?
<fabbione> mdz: give out some CDs and stuff.. but i will be back way before you will be awake ;)
<fabbione> pitti: yes
<whiprush> jdub: ping
<dholbach> whiprush: morning jorge :)
<whiprush> morning daniel!
<jsgotangco> hey whiprush 
<bob2> fridge me up
<whiprush> heh
<jsgotangco> whiprush, things that freeze?
<whiprush> soon dude.
<whiprush> soon.
<bob2> soon since april
<jsgotangco> 6.04
<ajmitch> jsgotangco: quite possibly :)
<whiprush> bob2: ph ye of little faith. :)
<jdub> whiprush: pong
<bob2> I thought I was ye of utter rudeness and the spawn of satan?
<ajmitch> bob2: that too
<whiprush> jdub: Just listened to asa's audio from oscon.
<jdub> bob2: it was never 'soon since april'
<fabbione> pitti: can you remind me again the URL to grab a raw main inclusion report?
<whiprush> jdub: ironically, I just got to the part where you got to talk.
<pitti> fabbione: view one and select "view raw" in the dropdown
<bob2> jdub: but harrassing whiprush is my hobby!
<whiprush> bob2: pfft.
<fabbione> pitti: danke
<jdub> bob2: you've chosen the wrong person to harrass
<whiprush> soon dude. soon.
* bob2 drops it
<pitti> fabbione: ?action=raw
<jdub> whiprush: meanwhile, still don't have a server yet ;)
<whiprush> jdub: I was going to ask what you thought of his speech, but now I get to hear you getting cut off.
<jdub> hopefully during tonight
<jdub> whiprush: i was hoping to do a response via zdnet, but my trip got in the way
<pitti> jdub: when will we see libmad0 and libxine1c2 in universe?
<whiprush> ... and so much for addressing his concerns.
<pitti> jdub: we should do that soon
<jdub> whiprush: the annoying bit was that straight after i got a chance to sit down with him for a useful amount of time and talk to him about it
<jdub> pitti: libmad yeah, xine - why bother?
<pitti> jdub: is it already cleaned?
<jdub> pitti: afaik, the debian/ubuntu builds don't have seriously naughty stuff
<pitti> jdub: so if it is patent-free (or, rather less patented) now, can we put totem-xine into main?
<jdub> it's tempting. i'd prefer if someone reviewed xine to make sure though.
<pitti> jdub: the description says that it supports mp3, mpeg, etc.
<jdub> * html b.bl {bottom:-2px}
<jdub> * html b.br {bottom:-2px}
<whiprush> jdub: man, kind of lame ... didn't even get a chance to follow it up in public.
<jdub> bah
<pitti> jdub: ?
<jdub> pitti: if you have libmad installed
<pitti> jdub: thou must not format IRC strings :-)
<pitti> jdub: ah, IC
<jdub> (that was css)
<pitti> jdub: I know :-)
<pitti> ok, cu later
<Mithrandir> ogra: gnome-screensaver seems unstable.  It has crashed for me here.
<Mithrandir> ogra: and it's not restarted even though I twiddled in the control panel (unlike g-v-m for instance)
<fabbione> morning Mith
<Mithrandir> hiya Fabio
<jdub> mdz: 128M req is fine for most cases, though perhaps we should say, "Some applications will have greater requirements."
<jdub> or something like that
<HrdwrBoB> like openoffice
<HiddenWolf> jdub, ever tried running gnome on 128?
<jdub> yeah
<HiddenWolf> Depends on what you're used to, but I wouldn't recommend it...
<jdub> works fine
<jdub> if you want to run useful apps, you need 256MB
<HiddenWolf> jdub, so what good it is to say 128 is minimum? save marketing?
* Burgundavia has tried the live cd on 128
<HiddenWolf> Burgundavia, i'm sure that kept you busy for a while. ;)
<jdub> mind you, now we've included all this crazy hplip stuff, we're chomping up huge gobs of useful memory on stuff the majority of our users won't care about (no, the majority do not have hp inkjets)
<HiddenWolf> jdub, ouch, it's that bad?
<jdub> HiddenWolf: if you just want to run a desktop and browser, 128MB isn't bad
<doko> pitti: please could you review ttf-dejavu (font) and libfont-ttf-perl
<jdub> USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
<jdub> hplip     6911  0.0  0.6   9636  4112 ?        S    Sep18   0:06 python /usr/sbin/hpssd
<Burgundavia> HiddenWolf, lets just say after 15 mins to the OO.o splace screen, I gave up
<jdub> it's not that bad
<jdub> but hopefully avoidable in the future
<HrdwrBoB> firefox can be very hungry though, but yes, 128mb is the bare minimum
<HiddenWolf> Burgundavia, you shouldn't known better than to try. ;)
<HiddenWolf> HrdwrBoB, I've had 200mb for firefox alone. ;)
<Burgundavia> HiddenWolf, didn't realize it had 128 until afterward
<HrdwrBoB> my 256mb laptop needs more desperately
<HiddenWolf> Burgundavia, :D
<HrdwrBoB> 128 is the barely usable minimum,  256mb is a workable minimum, 512 is perfect
<jdub> the two firefox sessions (two users) running on my laptop are 54M and 39M resident (130M and 128M virtual)
<dholbach> doko: pitti just went away
<HiddenWolf> jdub, well, if hplib is needed to get us on the desktop, it's a good price to pay.
<jdub> HiddenWolf: hplip running on every single machine is not required to "get us on the dfesktop"
<Mithrandir> jdub: I guess I love tabs; tfheen    8054  0.0  3.9 274588 81740 ?        Sl   Sep18   0:54 /usr/lib/mozilla-firefox/firefox-bin -a firefox
<HrdwrBoB> mine is 152mb but I have 16 tabs open
<jdub> HrdwrBoB: virtual or resident?
<Burgundavia> jdub, can the hplip stuff be better integrated into the existing cups/sane stuff we already run?
<HrdwrBoB> resident
<HrdwrBoB> 377mb virtual
<HiddenWolf> jdub, True, but it keeps HP friendly I presume. ;0
<jdub> (that's an unusual session for me, though)
<HrdwrBoB> I wouldn't bother using, building, or recommending a machine to anyone with 128mb ram
<jdub> Burgundavia: possibly, perhaps; ideally we could just activate it when required, yada
<doko> mdz: please process openoffice.org1-debian-files from NEW, and promote re-openoffice.org-debian-files to main 
<HiddenWolf> 11015 hidde     15   0  114m  50m  20m S  0.3  5.0   0:33.52 firefox-bin
<Mithrandir> I don't think I've got any machines running X with less than 1.5GB of memory.
<HiddenWolf> Mithrandir, why 1.5GB?
* ajmitch has no machines with more than 1GB RAM
* Lathiat has a 256M and a 512M machine
<Lathiat> and a 640M
<dholbach> ajmitch: me neither :)
<ajmitch> yet :)
<Lathiat> funnily enough the 640M machine is a server with no X etc and uses <100M :)
<Mithrandir> HiddenWolf: because my laptop comes with 512 and takes an extra 1GB stick, my other desktop started off with 512MB, but it was too little so I put another stick in it, and the one I'm on now was bought with 2G three weeks ago
<HiddenWolf> Mithrandir, ai. :)
<Mithrandir> HiddenWolf: since I'm developing stuff, it's kinda special, though, so I don't think that's necessarily a recommended situation.
<Mithrandir> HiddenWolf: but it really makes the live cd fly on the 2G machine. ;-)
<HiddenWolf> I can imagine
<HiddenWolf> Well, got to run. I'm up for 6 straight hours listening to lectures.
<Mithrandir> have fun
<HiddenWolf> Mithrandir, doubtful
<HiddenWolf> Mithrandir, but thanks
<doko> \msg `anthony you around? ok to checkin the locales patch (without the utf change) to the branch?
<HiddenWolf> I'll think of you guys while I'm sitting through a 2-hour lecture sponsored  by WIntel
<`anthony> doko: which one?
<doko> \msg `anthony the one I emailed you and martin v loewis
<doko> ohh, great, should execercise typing ...
<`anthony> doko: hm. when did you send the email? I don't see it.
<doko> `anthony: Martin did reply on Sep 14
<`anthony> nope - I don't see it.
* jdub hopes lenovo have some female designer/marketing people
<jdub> thinkpads do not turn the girls on
<Mithrandir> jdub: they're still hot, though.
<jdub> for us, yeah
<jdub> but attempting to convince pia that she wants a thinkpad is *hard*
<Mithrandir> what does she want, then?  Toshiba?
<jdub> atm she's looking at this flakey asus thing
<infinity> Really?... My girlfriend thinks our thinkpads are smokin' hot.
<jdub> which is more expensive
<infinity> Clearly, you need a new wife, not a new laptop design.
<jdub> "but it looks good!"
<jdub> "but it will fall apart!"
<whiprush> asuses are surprisingly linux-friendly
<whiprush> or, asii ...
<jdub> itym "arse"
<HrdwrBoB> my friends girlfirend has an asus
<HrdwrBoB> she thinks my X40 is cooler
<HrdwrBoB> her asus has a dead pixel
<jdub> yeah, and the T series just look like big X series
<jdub> not any uglier
<HrdwrBoB> yeah
<HrdwrBoB> I'll be getting a T series for my wife when we upgrade
<whiprush> that new lenovo widescreen X series look nice.
<jdub> yeah
<whiprush> people dig those new superbrite screens too
<whiprush> with the shiny coating on the screen
<HrdwrBoB> widescreen X series?
<whiprush> yeah they have one coming up
<HrdwrBoB> that would be very nice
<HrdwrBoB> jdub: http://www.engadget.com/entry/1234000527058629/
<HrdwrBoB> Z series will come out with titanium cover optionally
<jdub> hope the titanium is light
<infinity> The Z isn't a "widescreen X".
<jdub> 'cos ibm plastic is like kevlar
<HrdwrBoB> no it's not
<infinity> It's quite a bit thicker/heavier, and has more bells and whistles (ie: a CD/DVD drive)
<HrdwrBoB> but jdbu is looking at a T series anyway
<infinity> They should capture a market segment that the T and X doesn't currently, though, which is cool.
<infinity> I love my T.
<HrdwrBoB> yeah
<jdub> pipka needs combination of lightness and screen size, so T fits well
<jdub> R is like... crazy
<Mithrandir> R is a bit heavy
<infinity> The R is too heavy for me.
<infinity> S'why I spent the insane money on the T.
<whiprush> The R is too heavy for any human
<HrdwrBoB> my sister in law has an R40, she uses it for uni, it's not that bad
<HrdwrBoB> but a T series is the same only better
<infinity> A 2GHz laptop with all the bells and whistles, but still reasonably light and good battery life.  Nice, but at a price.
<jdub> dude, it's "R" like "ARGH!"
<Mithrandir> whiprush: I'm superhuman, then.
<infinity> (I'm actually a bit freaked out that I get 4 hours of battery out of this behemoth...)
<jdub> oh
<jdub> that reminds me
<jdub> i should turn off TLAPD on pgo
<whiprush> Mithrandir: you've got a X with 2 batteries iirc.
<whiprush> the wedge right?
<Mithrandir> whiprush: I used to have an R32
<infinity> I looked at the R a few times.  The really low prices are tempting.
<infinity> But, in the end, I wanted somehting I could carry from one room to the other wihtout hurting myself.
<Mithrandir> that was before the T series had its price cut in half.
<whiprush> if you're gonna lug an R, might as well slug an Xbox around. :D
<Mithrandir> and similarly for the X series.
<infinity> Yeah, the T and X used to be way out of my price range.  Now they're just uncomfortably in my price range.
<HrdwrBoB> second hand IBM laptops can be found cheaply, I paid ~$1000 for my X40
<HrdwrBoB> and thanks to their ruggedness, just as good as new
<infinity> I should find a second-hand X for my girlfriend, she really likes Daniel's X series.
<whiprush> infinity: X31's are cheap these days
<whiprush> Mithrandir's battery wedge for the X is the winner though. I need to pick one up.
<infinity> Yeah, that's pretty cool.
<HrdwrBoB> battery wedge?
<whiprush> it's like a half-dock kind of thing.
<infinity> I don't really need that much battery life, though.  As it is, this T series has more battery than I know what to do with.
<Mithrandir> HrdwrBoB: similar to the docking station, but pure battery goodness
<HrdwrBoB> independant X40 battery charger?
<HrdwrBoB> ooh, the long life battery
<infinity> (Okay, my last laptop didn't HAVE a battery, so the mobility is a bit confusing)
<HrdwrBoB> it's expensive though
<Mithrandir> infinity: it's useful when flying places.
<Mithrandir> infinity: which I've found myself doing a lot lately. :-P
<whiprush> Mithrandir: that puts you at about 10 hours with the wedge + extended battery?
<infinity> Mithrandir : Yeah, I fly very infrequently.
<Mithrandir> whiprush: yeah
<infinity> I wonder if I could cut my power useage by powering down some of my RAM!
* infinity giggles.
<HrdwrBoB> surely one day you will get power in a plane
<infinity> You can get power in most planes.
<infinity> I don't have the right adapter for my laptop right now, though.
<Mithrandir> but you have to fly business class, which is more than the price of the extended battery. :-P
<infinity> Some intercontinental carriers have power in cattle class now.
<Mithrandir> they do?
<HrdwrBoB> haha Mithrandir 
<jdub> yeah, who does that?
<infinity> Cathay has power in cattle class.
<infinity> Perhaps I should have booked with them for UBZ...
<infinity> Oh well.
* ajmitch wonders if air canada does, for the flight to UBZ..
* daniels blinks.
<daniels> qantas, thai, singapore, ba, most of the other oneworld people, virgin, easyjet, ryanair, certainly don't
<infinity> Yeah, I think Cathay is a special kinda... special.  They were the first intercontinental carrier I ever flew, and I've made the mistake of assuming others are like them.
<Treenaks> infinity: I hear lots of good stories about them, too
<infinity> Of course, that's the same carrier that upgraded me to business class on a whim, and the only carrier that ever served me filet mignon.  So, they rule.
<daniels> infinity: god*damnit*.
<daniels> i may have to review my choice of BA as bestest carrier evar.
<Treenaks> I'm flying BA to UBZ
<Mithrandir> I'm so far happy with KLM, but I guess I should get our booking guy to book me into something else once.
<Mithrandir> the stewardesses on the Malaysia airlines were exceedingly cute, though
<Mithrandir> and they have nice comfy pillows
<daniels> ba seriously lose out on that criteria (not the comfy-pillow one).
<infinity> The airline, or the stweardesses?
<infinity> (re: comfy pillows)
<daniels> i'm air canadia to UBZ
<Treenaks> infinity: comfy stewardesses? wtf? :)
<Burgundavia> daniels, AC isn't bad
<Mithrandir> infinity: they gave me the comfy pillows, I have no idea whether the crew had comfy pillows or not. :-P
<infinity> Air Canadia serves good food, and speaks recognisable English.  I've not (yet) flows them intercontinentally though, so I have no idea how comfy their pillows or stewardesses are.
<infinity> s/flows/flown/
<Lathiat> how comfy the stewardesses are? ;)
<dholbach> haha
<dholbach> you guys have problems
<infinity> My problem is that I've spent the morning banging my head against FTBFS bugs, and in an effort to relax am going horribly off-topic in a -devel channel.  Not sure what everyone else's is. :)
<dholbach> infinity: that's absolutely acceptable ;)
<Mithrandir> infinity: waiting for a 500-odd MB dist-upgrade to complete, so I can see if I can track down the "ia32-libs fails to unpack" bug.
* fabbione points the finger at libc6 upgrade for asking questions
<infinity> It doesn't ask questions if you export DEBIAN_FRONTEND=noninteractive
<infinity> If you don't, sucks to be you.
<fabbione> infinity: that's standard hoary -> breezy upgrade
<infinity> Oh, you mean during an interactive upgrade? :)
<infinity> Yeah, it asks questions, bugs are filed, people are wary of making glibc depend on debconf, not much else has been said about it, I think.
<infinity> s/glibc/libc6/
<fabbione> infinity: yes, but we do have that policy that says no questions between dist-upgrade, don't we?
<daniels> my problem is my raging headache
<infinity> fabbione : No unnecessary questions, certainly.  I guess it depends on how necessary we view the libc6 question.  If not, we can just fudge around it in breezy.
<fabbione> it's the one about restarting services
<Mithrandir> infinity: will people anytime say "no" to it?
<infinity> It's there under the assumption people may want to say no, but for us, we can probably just assume yes and carry on.
<fabbione> + all the daemons get upgraded too
<fabbione> so the restart is also in their maint scripts
<Mithrandir> infinity: in what case would people want to say no?
* Treenaks kills pcmcia-cs
<Treenaks> or actually, dist-upgrade did
* Mithrandir holds infinity's wrists to prevent him from handwaving
<Mithrandir> :-P
<infinity> ;)
<mitsuhiko> wb \sh
<infinity> In the case when you fear restarting something will hideously break the world, I guess.  I know I've answered "no" in the past, but I doubt I would do so very often.
<\sh> morning gentlemen
<infinity> And the average Ubuntu user isn't likely to.
<Treenaks> infinity: well, I would have loved to say "no" to pcmcia-cs restarting
<daniels> that could be our new slogan
<daniels> pcmcia-cs: just say no
<fabbione> ahah
<fabbione> daniels: +1
<Treenaks> daniels: well, I agree.. but still
<\sh> daniels: regarding #15846 do u have the XTerm in /etc/X11/app-defaults ?
<daniels> \sh: we had a patch to that in hoary that we probably dropped
<\sh> daniels: will fetch the hoary source :)
<daniels> http://people.ubuntu.com/~daniels/907_debian_xterm.diff
<\sh> daniels: what annoys me, is that in gnome I have this grey background in xterm..but in fluxbox everything is allright
<dholbach> morning mvo
<ajmitch> hi mvo 
<dholbach> LAOLA for mvo! YAY! :)
<daniels> \sh: probably xrdb not merging the default
<\sh> daniels: xrdb and gnome are merging all the stuff in /etc/gnome/config/
<mvo> hey dholbach, hey ajmitch
* ajmitch starts writing up a list of syncs to request :)
<\sh> daniels: but I don't see it merging (when it starts up the seesion) /etc/X11/app-defaults...and the default is normally bg: white fg:black 
<daniels> this is why you don't mix security updates and code updates, kids: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168752
<daniels> \sh: *shrug*
<Burgundavia> daniels, also why not to run fedora...
<Treenaks> Burgundavia: yeah, daniels wouldn't do anything like this during a development cycle
<daniels> hey man, that change was made to a *release*
* \sh patches xterm....there are no tickets 
<daniels> my hoary change was conservative as shit.  to the point where it possibly slightly broke some setups because of a bug in debconf that I didn't fix in the update.
<bob2> lilo's not the default in breezy, right?
<infinity> grub is the default i386 bootloader.
<ajmitch> bob2: it's not, unless you break things & go for a wholly LVM setup (no /boot partition)
<pitti> daniels: ouch
<daniels> pitti: with -10 that we shipped, the next update was always going to force sync ranges to be written out.  *shrug*
<sivang> morning all
<pitti> Hey sivang 
<ajmitch> morning sivang 
<doko> pitti: please could you review ttf-dejavu (font) and libfont-ttf-perl
<pitti> doko: yes, I will process the queue today
<sivang> morning pitti , ajmitch 
<Mithrandir> grrr, nvidia-glx-legacy needs to divert the libGL.so from mesa
<sivang> (and for the rest ofcourse)
<fabbione> Mithrandir: yeah it's buggy...
<fabbione> Mithrandir: do you actually have a machine where -legacy is required?
<pitti> Diziet: yay, ffox 1.0.7 and mozilla 1.7.12 this week
<fabbione> Mithrandir: because i think there is more than that, that needs fixing
<Mithrandir> fabbione: no, I'm trying to track down 15473
<fabbione> Mithrandir: if you don't mind to look at it, i will be very glad
<pitti> Diziet: that should be fine for breezy
<fabbione> Mithrandir: ah ok
<Mithrandir> fabbione: I could probably fix the obvious bugs, like "we don't care that we're stomping over half the world" and similar issues
<infinity> Shouldn't -legacy and -legacy-dev have pretty much identical maintainer scripts to nvidia-glx*? (and conflict with them)
<fabbione> Mithrandir: that would be nice, because i need to leave for a couple of hours now
<Mithrandir> infinity: I'd think so, yes.
<fabbione> gotta spread more love around
<daniels> if they don't have almost identical maintainer scripts, and conflict with them, then something went seriously wrong
* fabbione goes away for a while
<daniels> but I didn't get to finish that stuff off before I handed it off, only that all the diversions for the kernel modules were handled correctly
<Mithrandir> daniels: it doesn't divert the libGL stuff, it appears
<daniels> Mithrandir: rockin'
<Mithrandir> but I still can't reproduce 15473
<infinity> Mithrandir : Are you on it, or do you want me to fix it?
<Mithrandir> infinity: feel free to fix. :-)
<Mithrandir> nvidia-glx-legacy conflicts with the regular nvidia-glx
<infinity> And well it should.
<Mithrandir> dpkg: error processing /var/cache/apt/archives/nvidia-glx-legacy_1.0.7174-0ubuntu18_amd64.deb (--unpack): trying to overwrite `/usr/lib/libGL.so.1', which is also in package libgl1-mesa
<Mithrandir> though
<daniels> i can't remember whether d/r copies and seds, or whether I did it by hand
<infinity> Right, will fix that.
<infinity> I leave ia32-libs to you, however.
<Mithrandir> thanks. :-P
<infinity> No problem.
<infinity> :)
<\sh> who else as mdz can approve main uploads for bugfixes to main?
<infinity> Kamion.
<infinity> But if it's just a bugfix, not much approval is needed.  It's if you need to make very intrusive changes to fix the bug that you need to talk to someone about it.
<ajmitch> is main still in that freeze?
<infinity> We're thawing out, but will go hard freeze again really soon, so I suppose it's better to be safe than sorry. :)
<\sh> Kamion: can I upload xterm_203-0ubuntu3 to fix #15846?
<pvanhoof> openoffice.org: Depends: openoffice.org1-debian-files (> 1.1.3+1.1.4) but it is not installable
<pvanhoof> in breezy today
<Mithrandir> pvanhoof: it's stuck in NEW for now
<\sh> infinity: are universe packages running through the testbuilds now?
<pvanhoof> shouldn't that be openoffice.org1-ubuntu-files ?
<daniels> not really
<daniels> there's no point in diverging that far from debian
<pvanhoof> ok
<infinity> \sh : Yes.
<siretart> fabbione: around?
<infinity> Yeargh, l-r-m makes my eyes bleed.
<daniels> no shit
<infinity> Oh well, tidying up all the *legacy* mess as I go, should be ready tonight.
<chmj> is there a way to transfer a bug from bugzilla to malone ? 
<chmj> becouse that would be usefull 
* infinity ponders fixing #14250 along the way.
<infinity> daniels : Do you have an opinion on that bug?... nvidia recommends disabling those two modules, IIRC.
<daniels> infinity: it should disable them, yeah
<infinity> Man, nvidia-glx-config is kinda scary for what amounts to a single sed invocation.
<daniels> not my fault
<infinity> Didn't assume it was.
<daniels> that was before l-r-m got foisted upon me
<infinity> Does the pain still linger?
<daniels> dude, you know the horror freak show I'm maintaining in breezy
<daniels> that eclipses all possible pain l-r-m could cause
<infinity> ;)
<Kamion_> \sh: yes, please do
<Kamion_> (xterm)
<JaneW> is there a TB tonight... the agenda has not been updated...
<JaneW> ?
<Kamion> there ought to be
* Kamion checks last meeting logs
<Kamion> nothing obvious in the log about the schedule, so I'll put it at the same time
<JaneW> ok
<\sh> Kamion: thx :)
<sivang> so there's a TB tonight?
<\sh> xterm uploaded
<WaterSevenUb> Kamion, after installing breezy with network support during install, Answering yes to "Download language support" or similar, (no warnings), firefox in the end appears in english instead of the choosen language. Is this ok?
<pitti> WaterSevenUb: actually not, but it depends on your language
<pitti> WaterSevenUb: ffox does not have too many suported languages
<WaterSevenUb> pitti, portuguese should have I guess.
<WaterSevenUb> pitti, at least in hoary has.
<JaneW> does anybody know if there is an updated version of https://wiki.ubuntu.com/Installation/PowerPC ? Specifically if  "OldWorld" Power Macs (beige G3 and older) which will not boot from CD are yet supported by Ubuntu?
<pitti> WaterSevenUb: yes, that should work. mozilla-firefox-locale-pt-br
<Kamion> WaterSevenUb: no idea, I'm afraid
<WaterSevenUb> pitti, pt (PT)
<Kamion>  Package: language-support-pt
<Kamion>  Depends: mozilla-firefox-locale-pt-br, mozilla-firefox-locale-pt-pt, myspell-pt-br, aspell-pt, aspell-pt-br, openoffice.org2-l10n-pt-br
<Kamion> should work *shrug*
<pitti> WaterSevenUb: sorry, but yes, -pt-pt exists as well
<WaterSevenUb> well... after installation in a clean breezy install... no firefox in pt... :-)
<WaterSevenUb> tell me how to debug it.
<WaterSevenUb> I think the locale is not installed as it should.
<Kamion> JaneW: no, OldWorld PowerMacs still aren't supported. I've had reports of people managing to get them to work by the usual kinds of gross hacks one has to employ on OldWorld systems, but nothing supportable; booting those systems from CD currently requires proprietary Apple code that nobody's reverse-engineered.
<Kamion> I haven't updated any of those Installation/* pages yet
<JaneW> Kamion: oic, thanks for the info.
<WaterSevenUb> pitti, kamion, I'll bb in 30m 60m...
<pitti> mvo: did you find a solution for the "aptitude holds back packages" yet? it even breaks hoary security updates
<mvo> pitti: no, but I wasn't aware that it's that bad :/
<sivang> mvo: where is a good place to to learn about python-apt? 
<pitti> mvo: unfortunately it seems to be pretty bad
<mvo> sivang: depends what you want to do with it :) the python-interface from "import apt" might be a good start
<Treenaks> pydoc apt
<sivang> mvo: ok, I want to see if I can create an xml representation of the installed packages on a given system, to be able to apply this "changeset" to another unrelated system, if they are of the same release.
<sivang> mvo: what do you think?
<sivang> Treenaks: thanks
<mvo> Treenaks: yes, thanks
<Kamion> sivang: what's wrong with dpkg --get-selections and dpkg --set-selections?
<Treenaks> sivang: I used to do that with dpkg --get-selections + dpkg --set-selections ;)
<bob2> haha xml
<Treenaks> bob2: if it's XML, it must be good!
<sivang> lol
<sivang> why not xml? (or RDF )
<bob2> because it's pointless bloat
<bob2> if you want to transofmr dpkg --get-selections output to and from xml, go for it
<daniels> sometimes XML is useful
<daniels> this is not one of those times
<daniels> i did a little flat-file format for debbackup
<daniels> worked fine
* Treenaks rewrites the X config file parser to use XML
<daniels> please god no
<infinity> daniels : My chip isn't an RV370, by any chance, is it?...
<\sh> Treenaks: bah ;)
* sivang regrets he mentioned it
<daniels> infinity: it is
<daniels> infinity: you get full acceleration by default now
<infinity> \o/
<daniels> for better or worse
<infinity> I can move my windows again!
<daniels> you could do this with Option "FullAccel" anyway
<infinity> I can't wait.
* \sh wants to have full accell for his i915/i810 chipset ,-)
<infinity> Oh, now you tell me.
<daniels> you never asked
<infinity> "Daniel, why is my X so shit slow?"
<bob2> daniel, why is *my* X so shit slow?
<sivang> lol
<kamstrup> There is a profound confusion in the ArtTeam...
<Treenaks> kamstrup: why?
<kamstrup> Does anybody in here actually know what we are expected to do?
<infinity> Art!
<kamstrup> infinity: I knew it!
<Lathiat> daniels: my X login got so stupidly fast! yay!
<infinity> Hope that helps.
<Treenaks> kamstrup: isn't that the definition of art btw? :)
<mvo> sivang: you can use python-apt for this
<ogra> morning
<kamstrup> Well, if we submit a full theme, will it even be considered for inclusion?
<sivang> mvo: I will, thank you
<sivang> morning ogra , what's up?
<infinity> Argh, brain hurting, changed too many things at once, lost track, need break.
* infinity implodes.
<infinity> (ps: l-r-m is evil)
<ogra> Mithrandir, is that in your xinerama setup ? 
<kamstrup> We are afraid to invest to much time without knowing what will become of the result
<infinity> Mithrandir : My lrm upload may fix your ia32-libs thing.  I'll test on a chroot here and see when I'm done.
<bob2> kamstrup: any of the MOTUs can upload a theme for you
<Mithrandir> ogra: yes
<Mithrandir> infinity: can you reproduce the problem at all?
<infinity> Mithrandir : Haven't tried yet, but I can spot where the problem may be....
<pitti> ogra: /usr/share/man/man1/xscreensaver-getimage.1.gz bug is known, I suppose?
<infinity> Mithrandir : I'll play with it in a bit, when I'm done confusing myself with my current changes.
<kamstrup> Yeah, but what about the "Ubuntu Art Challenge" mentioned on https://wiki.ubuntu.com/DesktopArtwork
<ogra> pitti, nope ?
<Mithrandir> infinity: ok, since I can't.
<mvo> pitti: I added the aptitude problem as #15871 (severity: major)
<bob2> er
<pitti> mvo: thanks
<bob2> installing or upgrading anything that requires restarting dbus takes my network down
<mvo> pitti: feel free to add stuff that I have forgoten :)
<Treenaks> bob2: networkmanager coolness?
<pitti> bob2: hm, we don't restart dbus any more
<bob2> Treenaks: it rocks!
<bob2> pitti: gnome-power-manager did
<pitti> bob2: ouch, that should be fixed
<pitti> bob2: it should reload the config files, not more
<Treenaks> bob2: that would mean it actually works
<bob2> Treenaks: it seems to work ok
<Treenaks> bob2: it never did for me :(
<\sh> seb128_: evolution is crashing when I get a mail with this attachment style:
<\sh> Content-Type: text/calendar; name="www.open-xchange.org/task.ics"; charset=us-ascii
<\sh> Content-Transfer-Encoding: 7bit
<\sh> Content-Disposition: attachment; filename="www.open-xchange.org/task.ics"
<seb128_> \sh: backtrace ?
<\sh> seb128_: bugbuddy? ;) or should i file it in bugzilla for you?
<seb128> put it on pastebin.com to start
<seb128> maybe that's already known
<\sh> seb128: give me a short hint for debugging libs for gnome ;) 
<\sh> and especially for evolution calendar,-)
<Mithrandir> Kamion: can you reproduce 15549? (I'm just wondering if it's powerpc-specific)
<\sh> seb128: http://pastebin.com/368831
<seb128> \sh: get it crashing, click on the "send bug upstream", get a backtrace from bug-buddy :)
<\sh> seb128: did already :)
<\sh> seb128: I think it's because of the filename...cause it's not correct, is it?
<\sh> brb
<seb128> \sh: maybe
<seb128> \sh: could you rebuild evolution-data-server with DEB_BUILD_OPTIONS=nostrip set, the bug seems to be not known upstream
<dholbach> and be sure to install all the necessary -dbg packages :)
<seb128> dholbach: there is no for e-d-s :(
<dholbach> then at least for libgtk2.0-dev, libgnome2-dev, libgnomeui-dev, libsoup2.2-dev
<Kamion> Mithrandir: you'll have to wait a bit while I upgrade the relevant chroot
<doko> seb128: does gnome use /etc/mailcap?
<seb128> doko: no
<doko> seb128: where can I find the mimetypes and applications, which gnome uses?
<Mithrandir> Kamion: sure
<seb128> doko: /usr/share/mime/, that's the freedesktop shared-mime-info package
<seb128> doko: the "standard" list is /usr/share/mime/packages/freedesktop.org.xml but apps can install other definitions to /usr/share/mime/packages/
<doko> seb128: is there a debhelper/other utility, installing into this directory?
<dholbach> doko: usually the build systems themselves take care of it
<Kamion> elmo: please sync partman-partitioning 36 from Debian
<seb128> doko: dh_installmime
<siretart> is the kernel module sk98lin not beeing build in breezy kernel for a reason?
<mvo> siretart: it does not work very well for some people
<siretart> mvo: well, I have to make this hardware here work, and it happens to have a marvel chipset :/
<mvo> siretart: have you tried skge?
<siretart> skge?
<Lathiat> siretart: the marvel gigabit driver with no support?
<siretart> lets try
<siretart> Lathiat: dunno, never seen that
<siretart> mvo: skge does not say anythin, the hardware has pci id: 11ab:4362
<WaterSevenUb> pitti, just confirmed... mozilla-firefox-locale-pt-pt is not installed as it should in the breezy installation. Is it included in the CD right? 
<WaterSevenUb> pitti, In any case, even with network installation support, in the end is not installed.
<mvo> siretart: see #15299. it maybe a yukon2 that is not supported by skge (what does "dmesg" say after you inserted the module?)
<siretart> mvo: nothing :(
<pitti> WaterSevenUb: nope, it is not on the CD
<pitti> WaterSevenUb: so language-support-pt was not installed? although you agreed to, and network was functioning?
<WaterSevenUb> pitti, ok... so the problem then seems to be that the network was not functioning during install and no warning is issued in this case?
<Kamion> WaterSevenUb: good - we don't want to pester people who don't have a working network
<WaterSevenUb> pitti, the network is working in the end but the sources pt.archive.... are not.
<Kamion> Mithrandir: mysql-server doesn't start up properly here, although I'm not sure the symptoms are the same
<Mithrandir> Kamion: hmm, does mysql_install_db work correctly?
<Kamion> Mithrandir: ah, yes, pretty similar symptoms
<Kamion> Sep 20 11:29:52 cairhien mysqld_safe[21214] : ERROR: 3  Error writing file './mysql/db.frm' (Errcode: 22)
<Kamion> Mithrandir: no, mysql_install_db fails in the same way
<Kamion> should that really be ./mysql, rather than /var/lib/mysql or /var/lib/mysql/mysql or something?
<Mithrandir> Kamion: bingo, so it's ppc-specific.
<Mithrandir> Kamion: no idea, really.  I don't have a (working) ppc so it's a bit hard to track down.
<Mithrandir> Kamion: do you have time for it or should I throw it at infinity?  (He's got a ppc, doesn't he?)
<Kamion> [pid 21529]  pwrite64(5, "\376\1\7\t\3\0\0\20\1\0\0000\0\0\276\1\231\0\0\0\0\0\0"..., 64, 18446744073692708607) = -1 EINVAL (Invalid argument)
<Kamion> that's odd
<Kamion> Mithrandir: I'll have a quick look
<Mithrandir> Kamion: thanks a lot
<Keybuk> question for Mac OS X people from my sister (which I have no idea about) ... how do you add a dial-up internet connection to it?
<Mithrandir> Keybuk: "boot Ubuntu live cd [...] "
<Mithrandir> ;P
<Keybuk> other than that! 
<Zomb> what does the live CD use as the root filesystem, Ext2?
<sivang> mvo: I guess this is ok ? In [1] :import apt
<sivang> /usr/lib/python2.4/site-packages/apt/__init__.py:17: FutureWarning: apt API not stable yet
<Treenaks> Keybuk: you call apple, and buy the option?
<sivang>   warnings.warn("apt API not stable yet", FutureWarning)
<Mithrandir> Zomb: ext2, I think, yes.  On cloop.
<sivang> Keybuk: there's a dial up manager somewhere
<sivang> Keybuk: it also used to create dial in broadband connections
<sivang> Keybuk: I can't recall it's name though..
<mvo> sivang: yes, it warns you that the api (for the module "apt") is not stable yet :)
<sivang> mvo: I guess you put that warning there? ;-)
<mvo> sivang: yes, so that people don't complain too loudly if something breaks. and it won't break before breezy+1 opens :)
<sivang> mvo: nice, btw, so how can I achive the parallel to --get-selection , using the Cache module?
<sivang> mvo: oh cool I instantiated a Cach class and the keys are the pakcages, yay
<mvo> sivang: yes, then you can use "if cache[pkgname] .isInstalled: p"
<sivang> mvo: so cool :)
* sivang wonders what other goodies are there
<mvo> sivang: the apt module is not very complete. feel free to ask for stuff that is missing for you. the apt_pkg is more complete, but much less convenient
<sivang> mvo: is it hard to hack on it to extend it?
<Mithrandir> infinity: getting anywhere with the -legacy stuff?
<mvo> sivang: the apt module is very easy to extend, all python, basicly only wraping apt_pkg. apt_pkg OTOH is a hand-writen wraper around libapt. it's not overly complicated to work on, but more work
<sivang> mvo: I see, thx for that info - what about apt.Package, how do I make it reference a specific pkg?
<mvo> sivang: pkg = cache["apt"] 
<mvo> (I assume that is what you are looking for?
<sivang> mvo: yes, exactly. thanks
<mvo> sivang: cheers
<Keybuk> can anyone think of a bad reason to change the group of /dev/ttyUSB* of a known palm pilot from "dialout" to "plugdev" (or some other suggested group?)
<Mithrandir> elmo: please change PaS to allow valgrind to build on amd64.
<\sh> seb128: ok will do 
<seb128> thanks
* Diziet trips over http://people.debian.org/~nomeata/debian-game/.  ROTFL.
<sivang> Diziet: debian-w32 ?? ;)
<sivang> Diziet: (one of the squares)
<infinity> Mithrandir : Taking a break for a while, it'll be uploaded before I go to bed tonight (so, in the next 3 or 4 hours)
<Mithrandir> infinity: ok, sure
<infinity> Mithrandir : I'll close your bug while I'm at it, if I feel what I've done fixed it.
<Zomb> sivang: lame. We need a d-i port to CoLinux.
<infinity> Mithrandir : If not, I'll let you know.
<infinity> Kamion : Did you sort that mysql-on-ppc issue?
<infinity> Kamion : In the past, I've tripped over pread/pwrite being buggy on some arches (and ppc was one of them), so you may be running into that.
<Kamion> infinity: not yet, still trying to get it to build with debug on
<infinity> Kamion : Kay, if you give up, pass it off to me, just ping me in /msg to let me know.
<sivang> Zomb: sorry? 
<Kamion> infinity: look at the fourth arg to pwrite in that trace, though - it's clearly rubbish
<infinity> Kamion : I've joined The Debian MySQL group too, so it's sort of in my realm now.
<Kamion> infinity: so either strace is wrong or mysql has something that looks suspiciously like an endianness bug
<Zomb> sivang: ?? CoLinux is kinda UML running in win32 environment.
<infinity> I'd bet on the latter, though MySQL tends to be reasonably clean, so it'd be odd for it to crop up just now.
<Kamion> $ bc -lq
<Kamion> obase=16
<Kamion> 18446744073692708607
<Kamion> FFFFFFFFFEFEFEFF
<Kamion> hmm
<desrt> DBUS daemon
<desrt> Reboot recommended
<desrt> A new version of the DBUS daemon has just been installed. You should restart
<desrt> your machine soon so that the new version becomes effective.
<desrt> cute.
<ogra> bah
<fabbione> Mithrandir: ping?
<infinity> Kamion : Just wait until your debug build makes the bug go away.
<desrt> HAL daemon
<desrt> Reboot recommended
<desrt> A new version of the Hardware Abstraction Layer daemon has just been
<desrt> installed. You should restart your machine soon so that the new version
<desrt> becomes effective.
<desrt> very cute.
<bob2> yay dbus upstream
<Kamion> is it trying to do pwrite() to a negative offset?
<sladen> Zomb: coLinux for the LiveCD was an idea if you can find a fast+decent+easy X server for Windows
<sivang> Zomb: oh :)
<ogra> hww, we should rename them to dbus-w32 and hal-w32
<desrt> pitti; stop hurting me!
<desrt> y'all suck :p
<sivang> desrt: we have a BOF planned for that :-)
<pitti> desrt: sorry, I was asked to do that
<desrt> what the hell is a BOF?
* desrt keeps hearing about them
<pitti> ogra: hm?
<Mithrandir> fabbione: pong
<Kamion> birds of [a]  feather session - conference jargon
<ogra> pitti, rebbot after upgrade :)
<desrt> ahh
<sladen> Keybuk: a palm isn't really dial out...  but the assumption made by several programs is that all serial users -are- dialout
<pitti> Riddell: bah, libapt-front is not something I would like to put into main - you really want it, do you?
<ogra> pitti, thats a win32 feature :)
<desrt> sivang; good luck with upstream :)
<bob2> the canonical conference meaning of BOF is not really the same as the normal conference sense, tho
<ogra> sivang, no bof will change SuSEs decision...
<desrt> sivang; upstream libdbus is actively hostile toward the idea of bus-reconnection
<sivang> desrt: why so?
<desrt> sivang; 1) it exit()'s on disconnect
<bob2> sivang: because they upgrade in one go every year and are happy to reboot to do so
<desrt> 2) it keeps the system bus connection cached as an internal global variable
<sivang> bob2: lol :)
<bob2> (seriously)
<desrt> so if you want to  destroy the DBusConnection and recreate it... uhm... you basically can't
<ogra> bob2, its SuSE, they dont upgrade, they reinstall
<bob2> haha
<sivang> hehehe
<bob2> even better
<desrt> since all calls to get_system_bus() or whatever will see (and return) the cached value
<sivang> why don't we find a way to keep alive the daemon ?
<dilinger> my gf is forced to use suse for work
<sivang> as in, have one do-nothing connection that would keep it up
<desrt> sivang; we have a way -- don't restart it :)
<dilinger> it seems to constantly be broken :/
<Riddell> pitti: why do you not want it in main?
<ogra> dilinger, poor girl
<sivang> dilinger: me too :-(
<pitti> Riddell: it's an unversioned static library
<sivang> dilinger: I do hard regression and stress testing on that..
<fabbione> Mithrandir: did you have time to look at lrm ?
<pitti> Riddell: that means, bug fixes, security updates, and API changes are a PITA
<fabbione> for the nvidia-legacy?
<sivang> desrt: but then how you upgrade the in memory running code?
<desrt> sivang; anyway... if you plan to have this socalled 'bof' at ubz make sure i'm invited
<desrt> sivang; you reboot :)
<Mithrandir> fabbione: uhm, infty did that
<sivang> desrt: hey, it's not me ! :) I need to see who's does that, I'm just inrested, as you
<desrt> sivang; or you do it manually with the initscript under the understanding that stuff will break
<fabbione> Mithrandir: oh ok
<Riddell> pitti: the only programs which use it are made by the same author so far
<sivang> desrt: I would know better then claiming I Know about dbus other then it's somekind of gizmo to send objects as messages etc :)
<desrt> sivang; i filed the bug asking martin to not restart dbus... but i'm not happy about it.
<desrt> anyway.  i need to hop like a bunny to school.  cheers!
<sivang> desrt: cheers
<seb128> Riddell: kpdf uses poppler, right? Do you have some issues with cidtype fonts?
<pitti> Riddell: right, but it should be done properly nevertheless; building a shared lib can't be hard
<Riddell> seb128: it doesn't use poppler yet no
<seb128> Riddell: k
<ogra> has anybody investigated why firefox uses nimbus sans as default font in breezy ? 
<bob2> the monospace font is worse
<bob2> where worse = unreadable
<Riddell> pitti: it's not a shared lib yet because he does expect to make API changes 
<ogra> bob2, i cant see any changes in fontconfig that could cause it...
<pitti> Riddell: so a change in libapt-front would require to adapt and rebuild all reverse build-deps
<Riddell> pitti: yep, but since adept and libapt-front are made by the same person changes and releases are made at the same time
<\sh> seb128: ok http://pastebin.com/368899
<Riddell> pitti: and presumably it'll be a shared library by the time other projects start to pick it up, I can ask the author to make sure that's all correct
<mvo> Riddell: I'm pretty sure that is the case 
<Riddell> pitti: see, even mvo agrees :)
<seb128> \sh: that's not a debug build
<Riddell> the same thing goes for the debtags depends
<seb128> \sh: file /usr/lib/libecal-1.2.so.3.1.4
<\sh> seb128: I had to kill the data server i think
<seb128> \sh: gdb get the symboles without restart
<seb128> I mean no restart of the app
<\sh> strippt
<\sh> DEB_BUILD_OPTIONS := nostrip
<Keybuk> weird, why isn't a lot of my bugzilla traffic showing up on bugs-dist ?
<Riddell> what is the session dbus used for?
<seb128> \sh: what is that?
<ogra> Riddell, session IPC
<ogra> Riddell, its bound to the user
<seb128> \sh: DEB_BUILD_OPTIONS=nostrip apt-get source -b
<\sh> seb128: can't i set it in the rules file?
<Riddell> ogra: any examples of what will break if I don't use it?
<seb128> \sh: I've not tried it
<\sh> seb128: i rebuild again ;) np
<ogra> Riddell, apps that use the session bus indeed...
<seb128> \sh: don't both, you can cp the lib from the builddir to /usr/lib 
<ogra> Riddell, these should have a dependency on dbus...
<fabbione> seb128: yo
<Riddell> update-notifier for example
<seb128> fabbione: hi
<fabbione> seb128: how did your kernel test go?
<\sh> seb128: I want to be sure ;)
<seb128> fabbione: the inotify patch works but they have updated the patch since
<seb128> fabbione: the linux built went fine, thanks for the indications on how to do :)
<fabbione> seb128: ok, just remember that we have kernel full freeze in less than 9 days
<fabbione> so if there is any patch that must go in, it has to be asap
<seb128> fabbione: yeah, BenC said he'll put it with the next upload
<mvo> Riddell: update-notifier?
<Riddell> mvo: seems to be an rdepend of dbus-1-utils
<Riddell> dbus-1-utils brings in gtk so I'm wondering if I can either get rid of it for kubuntu or split out the bits that bring in gtk
<fabbione> seb128: perfect
<mvo> Riddell: it displays it's icon using libegg and that depends on gtk. there will be no way around that, sorry
<\sh> Riddell: we have to rewrite update-notifier for kubuntu
<\sh> Riddell: todo add "rewrite update-notifier for kubuntu" 
<crispin> mvo: I noticed that the latest hal upload adds an update-notifier hook, and deletes it in the init script, shouldn't it use the magic "DontShowAfterReboot" flag ?
<Riddell> mvo: it's dbus-1-utils I'm moaning about, update-notifier is just an example of something that uses it
<mvo> crispin: yes
<Riddell> \sh: adept already has an update program, adding a notifier will be pretty simple
<pitti> crispin, mvo: oh, there is a "DontShowAfterReboot" attribute now?
<pitti> Riddell: alright, but can you file a bug nevertheless?
<\sh> Riddell: it should be an applet...something really small...
<crispin> pitti: http://bugzilla.ubuntu.com/show_bug.cgi?id=13886
<pitti> mvo: is removing the notification in the init script bad?
<\sh> brb
<mvo> pitti: no, it's fine
<pitti> crispin: ah, pending upload - well, that flag makes sense for the kernel since it does not have its own init script
<crispin> pitti: the change for update-notifier is already in there
<Riddell> \sh: yes.  my point is that the hard part is done, the notifier is just a small thing :)
<Riddell> pitti: sure
<\sh> Riddell: yeah
<hunger> Anyone having problems with ssh lately?
<jdub> seb128: ping
<hunger> I can not log into my account with it anymore using keys (from user account to user@localhost).
<seb128> jdub: pong
<Mithrandir> mjg59: wasn't 9101 fixed by pcmcia-cs (3.2.5-11ubuntu2) ?
<mjg59> Probably, yes
<\sh> seb128: http://pastebin.com/368929 no...it's not stripped
<Mithrandir> mjg59: you close it or should ?
<Mithrandir> I, even
<mjg59> Feel free
<Kamion> fabbione: re kernel freeze, I have two kernel udeb changes I need before then
<mjg59> ahci needs to go in the sata udeb, sk98lin needs to go in the network device one
<fabbione> Kamion: ok!
<Kamion> #13506 is mjg59's ahci/sata-modules one; also #14736
<seb128> \sh: #5  0xb7abda4d in icalvalue_get_text (value=0x0)
<\sh> seb128: means?
<seb128> \sh: I guess it doesn't like the value=0x0
<fabbione> Kamion: gimme a few minutes and i will look at them
<Kamion> thanks
<seb128> \sh: do you have a bugzilla.gnome.org account to put that to a bugzilla?
<\sh> seb128: no..but I will get one ;)
<seb128> thanks
<\sh> seb128: kmail works btw
<seb128> \sh: and gimp too :)
<seb128> is that "name a working app" game? :p
<\sh> seb128: hmmm...how do i get evolution running again..i moved this stupid mail with kmail out of the way
<seb128> \sh: anyway that's and e-d-s bug anyway, it should not crash, even on incorrect files
<seb128> \sh: what do you mean?
<seb128> \sh: evolution -c mail?
<\sh> seb128: it's a mail which let evolution crashing ;) and it's in the summary files now...
<fabbione> Kamion: ok.. they are not too problematic..
<fabbione> Kamion: i will work on them as soon as BenC is around
<seb128> \sh: try asking on #evolution /gimpnet maybe
<\sh> seb128: which backend should I choose? calendar or mailer?  it happens in the mailer at least...or the mail frontend
<seb128> \sh: mailer, they will reassign if needed
<fabbione> jbailey: is / over NFS known to be broken?
<fabbione> ogra: does your ltsp client boot with today breezy?
<fabbione> ogra: like bootstrapping the client side from scratch?
<\sh> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=316777
<dholbach> bbl
<ogra> fabbione, it did with yesterdays breezy and a fixed initramfs-tools from jabiley
<\sh> seb128: can I remove this directory, it looks like it holds the summary infos for my imap account
<ogra> fabbione, does it complain about line 64 in init ?
<\sh> seb128: .evolution/mail/imap/src_0001@mail.kde-coder.de$
<fabbione> ogra: no
<fabbione> it seems it can't mount /
<fabbione> or something like that
<ogra> hmm
<Kamion> fabbione: great, thanks
<seb128> \sh: ask on #evolution rather, I don't want to make you trash some data ...
<ogra> fabbione, i'll have to rsync and burn first... havent tested todays build yet
<\sh> seb128: well...everything is on the server anyways...so lets try...
<fabbione> ogra: just kill the client side
<fabbione> ogra and run the ltsp-client-build whatever thingy
<\sh> seb128: it's the summary folder...so don't worry ;)
<fabbione> Kamion: no problem
<Riddell> jdub: is it possible/sane to separate dbus-launch from dbus-1-utils to stop dbus-1-utils bringing in gtk et al unnecessarily?
<jdub> Riddell: possibly, but that's going to be an ooky delta with debian, but doable. pitti is the man to talk to.
<Riddell> pitti is debian-dbus@fooishbar.org?
<fabbione> ogra it seems like nfsmount from initramfs is mounting / and return ok, but there is no FS mounted at all
<ogra> hmm
<jdub> Riddell: martin has done the most work on it in ubuntu
<fabbione> i can see the client and server are talking
<jbailey> fabbione: All I have is Ogra's report from yesterday.
<fabbione> jbailey: i bootstrapped the overall no more than 20 minutes ago 
<jbailey> fabbione: P'haps I will setup that other box as a thin client today for testing.
<fabbione> mirror is updated
<jbailey> fabbione: What arch?
<fabbione> i386
<Riddell> pitti: thoughts on separating dbus-launch from dbus-1-utils?
<mjg59> jbailey: Ok, that initramfs-tools update seems to have fixed things for various people
<mjg59> Now we just need to work out the LVM case
<pitti> Riddell: no, that's daniels
<fabbione> jbailey: the only thing i see from the client is "NFS over TCP not available from $serverip"
<fabbione> jbailey: if you can remember how to force TCP at server level, i can give it a shot
<Riddell> does anyone want to own up to owning dbus?? :)
<pitti> Riddell: splitting out should be possible, as long as dbus-1-utils can depend on dbus-launch
<Riddell> daniels: any objections to that?
<jbailey> fabbione: My tests before didn't go much beyong, install kernel-nfs-server, debootstrap, set mount points and go, and it Just Worked.
<pitti> Riddell: daniels has some experience in splitting packages :-P
<pitti> Riddell: I can do it, not a biggie, but daniels' opinion is appreciated
<seb128> before splitting dbus maybe speak with sjoerd?
<seb128> to be sure than Debian will split it the same way
<fabbione> jbailey: that's what ltsp does :)
<pitti> seb128: good call
<pitti> sjoerd: ping
<Keybuk> elmo: ping?
<infinity> Kamion : Did you and mysql come to an understanding?
<jbailey> fabbione: Mmm.  klibc hasn't changed since Ogra's snapshot, so if it's nfsmount having issues, it seems that it's likely a server setup. =(
<slomo> hm, does someone know a bit about the python webbrowser module? open(uri) should open the uri and not the default homepage, correct?
<mbreit> infinity: is there a problem with scons on the buildds? i now have two packages which do not build on the buildd but work find in pbuilder...
<Kamion> infinity: it fails to build with -O0 -g
<fabbione> jbailey: hmm i doubt.. that didn't change either :)
<Kamion> grrrrrrrrr
<fabbione> jbailey: well let me try some stuff
<Kamion> I've reproduced it under gdb, but without symbols or line numbers or anything it's kind of a pig
<jbailey> fabbione: Excellent!  Time to pull out the packet sniffer and see who's right. =)
<infinity> Kamion : NEAT!
<Kamion> missing destructor symbols or some similar C++ crap
<fabbione> jbailey: i think i got it
<fabbione> yeah there we go
<infinity> Kamion : Is there an open bug about this?
<fabbione> jbailey: ltsp nfs server for some odd reasons needs to be restarted...
<Kamion> infinity: can't see one in Debian at least
<infinity> That's cause it works in Debian.
<fabbione> jbailey: no worries :)
<infinity> I meant in Ubuntu, and I found the bug.
<infinity> Kamion : How loudly do you think I'd get yelled at for suggesting we promote mysql-4.1 to the default, and do a VERY quick transition?  (it was in my ServerRoadmap, but I never got around to it)
<jbailey> fabbione: Excellent! =)
<infinity> (Yeah, yeah, I should just find/fix the bug tomorrow)
<Surak> Hello. Is this my impression or latest breezy's openoffice are not working with cups anymore?
<infinity> Riddell : ping.
<ogra> fabbione, erm... thast done by ltsp-server-standalne's postinst normally
<Riddell> infinity: hi
<Kamion> infinity: my inclination's definitely no
<infinity> Riddell : Can you look at #14595 for me?... It has your name all over it (even in the changelog)
<infinity> Kamion : Yeah, I know.  It was a thinking out loud thing.
<Mithrandir> jbailey: 15779; _YU doesn't seem to be in i18n/SUPPORTED?
<infinity> Kamion : I'll add myself to the CC on this bug, and see if anyone (you?) has gotten anywhere before I wake up.  If not, I'll poke some more.
<Kamion> infinity: ok, sounds good
<Riddell> infinity: hmm, yes.  I'm testing daily CDs just now but poke me again if I don't get back to you in a couple of hours
<infinity> Riddell : KDE/QT and I don't get along much, so if you can reassign that one to you and fix it (pretty please), I'll say nice things about you for a WHOLE WEEK.
* infinity heads to bed.
<pitti> night infinity 
<fabbione> ogra: i think the root cause is that i added an interface after nfs server was restarted. 
<fabbione> infinity: good night
<sivang> night infinity 
<Surak> yes, it's my impression. hplip needs to be restarted some times.
<jbailey> Mithrandir: I need to do another locales pass shortly to catch all of those.
<ogra> fabbione, ah :)
<jbailey> Mithrandir: I'm trying to talk Jordi into generating all of the locales package from Rosetta and making it Not My Problem. =)
<Mithrandir> jbailey: ah. :-)
<pitti> Riddell: is sanekonsole deliberately a native package?
<ogra> pitti, where did gstreamer0.8-polypaudio go ? 
<ogra> any idea ?
<jonathan-fc> pitti: i need that package ogra mentioned quite badly ;)
<infinity> Riddell : Actually, I'll reassign it for you.  What's your bz ID?
<ogra> jonathan-fc, probably we have a new way to handle polyp and the package isnt needed anymore...
<pitti> ogra, jonathan-fc: we do not buuild it any more since polypaudio is not supported in breezy
<ogra> pitti, not even for universe ? 
<Diziet> There are _four_ copies of the code in netstat to truncate the address field.  One for TCP local end, one for TCP remote end, one for UDP local end, one for TCP local end.  They're all identical.  Bah!
<pitti> ogra: building it would mean to pull polypaudio into main
<Diziet> I think I'll grep the code for `22' to find any I missed.
<jbailey> Diziet: Refactoring is for wimps.
<jonathan-fc> ogra: can i use anything else as replacements for alsasink, osssink, etc in gnome multimedia systems selector?
<Diziet> Um, that last should be UDP remote end of course.  But you were all bored by that point, just like I was.
* Kamion wonders if elmo would mind if I processed my own sync request
<Kamion> of course that assumes I know how to drive josie
<jbailey> fab-ltsp: =0
<jbailey> =)
<fab-ltsp> ehhe
<ogra> yay
<infinity> Kamion : You can just cheat.  <cough>
<fab-ltsp> yeah i need to write some documentation on how to setup NAT/routing for ltsp clients on the server
<ogra> fab-ltsp, now get sound working on the thin client ;)
<pitti> seb128, dholbach: is g-keyring-manager something we want in main? I thought it crashes all over the place?
<seb128> does anybody knows why there is no build for valgrind amd64?
<fab-ltsp> ogra: hmm let me try
<seb128> apt-cache showsrc says it's i386 amd64
<fab-ltsp> seb128, PAS
<ogra> fab-ltsp, wont work :) dont waste time :)
<fab-ltsp> seb128, there is a file that needs manual editing on the buildds
<ogra> not without NAS at least
<seb128> fab-ltsp: we will have it for 5.10?
<fab-ltsp> ogra: yeah i was just thinking about it
<seb128> pitti: it's a part of the GNOME desktop so probably
<fab-ltsp> seb128, i think Mith did the request for it today already
<fabbione> ok
<seb128> pitti: I'm just too busy to make wiki pages for everything atm
<pitti> seb128: don't worry about that
<pitti> seb128: I'm just interested in its stability
<pitti> since I heard bad things about it recently
<seb128> pitti: it's an official part of the GNOME desktop, so it should be quite fine
<pitti> ok
<seb128> pitti: I don't use it a lot but I never had issue with it, do we any bug about that or bt ?
<seb128> pitti: or is that just random luser making noise again on the wrong list?
<seb128> :)
<seb128> pitti: I read some mails on the list yeah, but I don't give them any credit. Let's wait for a backtrace
<seb128> pitti: upstream bugzilla has a total of 15 bugs for it an nothing with a severity up to normal
<seb128> ie: no crasher
<pitti> ogra: what about mknbi? I can't approve it since it is FTBFS
<pitti> ogra: oh, wait, it is i386 only?
<bddebian> Hello
<pitti> Hi bddebian 
<Riddell> infinity: jriddell@ubuntu.com
<Riddell> pitti: how do you mean native?
<bddebian> pitti: Hi.  I'm back "attempting" pgtcl :-)
<pitti> Riddell: no orig.tar.gz and a huge tar.gz
<ogra> pitti, drop it, its only a Recommends now, mdz changed it immediately
<pitti> bddebian: cool; feel free to /msg me questions related to packaging
<pitti> ogra: ah, cool
<bddebian> pitti: Great thanks
<ogra> pitti, tuxpaint-stamps and mimetex would be more interesting for edubuntu :)
<pitti> ogra: I'm close to make the queue empty
<ogra> yay
<pitti> ogra: mimetex is the last item on it
<bob2> /var/lib/NetworkManager/
<ogra> pitti, did you recieve any answer about mediawiki from mdz ? 
<bob2> w. t. f.
<pitti> ogra: none I can remember
<ogra> bob2, whats wrong with that ? lets introduce wiki style for all directorys !
<ogra> :)
<bddebian> pitti: Well I'm almost there.  It builds libpgtcl1.5.so and puts it in /blah/blah/blah/debian/tmp/usr/lib...  But it never "installs" it to /usr/lib
<pitti> bddebian: I /msg you
<markuman> i hope i don t disturbed  and i am in the right channel. im trying to build a .deb from source. it creat only a .orig.tar.gz, .dsc, .diff   http://paste.debian.net/1978
<Riddell> pitti: yes, that's how he wants to do it and that's how it's going to be in debian so I didn't want to change it
<pitti> Riddell: ok
<bob2> markuman: that's what a Debian source package is...
<pitti> markuman: this source package is broken, so it can't be built in the first place
<pitti> ogra: hey - mimetex looks highly useful 
<ogra> doe it ? 
<ogra> does even
<pitti> ogra: at least I learn about the wealth of packages while doing these reviews
<ogra> heh
<pitti> ogra: yes, /me loves LaTeX :-)
<ogra> ah, yes, i forgot...
<sivang> pitti: what do you like it so much martin ?
<ogra> :)
<sivang> bob2: is it beneficial to install netowrk-manager ?
<pitti> sivang: mimetex - nice idea :-)
<bob2> sivang: it's shiney and uses dbus
<sivang> bob2: k ;)
<ogra> shiney == hilarious broken crack ? 
<bob2> sivang: it appears to be less unstable than netapplet, too
<Nafallo> lol @ ogra :-)
<sivang> bob2: hmm, interesting, none of them are installed over my breezy upgraded machine
<bob2> sivang: yes, it's in universe and not installed by default
<ogra> sivang, n-m stayed in universe for a reason :)
<pitti> bob2: well, anything is more stable than netapplet, given that it immediately generates a kernel oops :-/
<Nafallo> ogra: cause it's "shiney"? ;-)
<bob2> hahahah
<bob2> pitti: iz kernel bug ;p
<bob2> sivang: among other things, it runs it's own magic dhcp client and copy of bind9
<pitti> bob2: it worked quite fine in hoary, and I actually liked it :-(
<ogra> bob2, nahh, iz gtk boog
<Nafallo> the damn thing (NM) gave me an 169.* ip when it couldn't find a dhcp :-P
<sivang> bob2: is that a good thing? why mirror their functionality ?
<Mithrandir> Nafallo: aka link-local
<bob2> Nafallo: which is reasonable, so you can still talk to local machines
<ogra> bob2, since our compiler depends on gtk, everything is a gtk bug :)
<bob2> haha
<Nafallo> Mithrandir, bob2: I was debugging why I didn't get an IP from my ISP ;-).
<bob2> sivang: it uses bind9 as an ultra-heavy-duty programmable resolver
<bob2> pity broker.aarnet won't give me rdns for my /48
<Nafallo> it did _not_ help to get that microsoft-crap ;-)
<ogra> and it fiddles badly with resolv.conf 
<sivang> Nafallo: that's acutally a good thing - my gf could have used it on her uni library where they use this same method for their win32 clients. ("Private IP config")
<bob2> "fiddles badly" is too polite
<sivang> hehe
<bob2> it pillages it and tell you never to touch it again
<Nafallo> sivang: it's a bad thing for me :-P
<sivang> Nafallo: ;)
<bob2> oh man
<sivang> bob2: I guess it wants it all to itself :)
<bob2> finding the management UI for my AP somewhere in 10/8 is going to take a while
<ogra> elmo, please sync mediawiki from debian NEW
<bob2> haha
<bob2> what could possibly go wrong?
<elmo> ogra: NEW isn't public
<bddebian> heh
* bddebian doesn't comment
<ogra> elmo, err, you cant access it ? 
<elmo> ogra: not as an Ubuntu developer no
<Mithrandir> elmo: could you please allow valgrind to build on amd64 by editing PaS?
<ogra> hmmkay... then i'll wait until it passed ...
<elmo> Mithrandir: no - get it fixed in P-a-s upstream
<infinity> Mithrandir : I'll fix upstream P-a-s for you.
<Mithrandir> infinity: yay, thanks.
<infinity> Mithrandir : Do we want all of its deps too?
<infinity> alleyoop and callgrind.
* infinity waits.
<Mithrandir> infinity: those have valgrind as rdeps?
<Mithrandir> infinity: I don't know, I can test them
<infinity> Mithrandir : Yes, they both depend on valgrind, hence are in P-a-s as well.
<daniels> Riddell: i'm not sure I see the point, but whatever
<Mithrandir> infinity: yes please.
<daniels> Riddell: ask sjoerd, since he's the primary maintainer these days
<infinity> I'll let them in, they both look like frontends.  Should work.
<daniels> Riddell: if he's okay, go nuts
<daniels> Riddell: but I don't really see whyu
<Mithrandir> infinity: alleyoop doesn't like the valgrind version, but I'll track that down, hopefully
<infinity> Mithrandir : Right, well, if it's broken on i386, it won't be less broken on amd64.
<Mithrandir> infinity: mpe. :-)
<infinity> elmo : Done, can you sync P-a-s? :)
<elmo> infinity: at some stage it'd be nice if we could fix P-a-s instead of using n-f-u failed in w-b
<elmo> infinity: (btw, next time space not tab between architectures, pls)
<elmo> synced
<infinity> <blink>... I tabbed?
<Mithrandir> elmo: thanks
<elmo> +%calltree: i386        amd64                                                 # Valgrind 'skin'
<elmo> or multiple space or something, I dunno, looks funny anyway
<infinity> Oh, must have been vim messing with my head.  I used append mode, and it looked like a single space on my terminal.
<daniels> Riddell: (fwiw, the primary debian dbus maintainers are myself, kinnison and sjoerd, in ascending order of usefulness lately; myself and pitti do it in ubuntu, but mainly pitti.)
<Mithrandir> oh, go alleyoop.  Segfault.
<Kamion> elmo: please sync partman-partitioning from unstable; ok to override Ubuntu changes
<Mithrandir> ah, that was just because I forgot to forward X
<mjg59> Kamion: Ok to sync hotkey-setup from Debian? Fixes a failure to set up hotkeys on non-tablet HPs
<elmo> Kamion: done
<sjoerd> pitti: pong
<pitti> ah, hi sjoerd, how are you
<Kamion> thanks
<pitti> sjoerd: Riddel would like to have dbus-launch split out of the dbus-1-utils package to not pull in glib into Kubuntu
<pitti> sjoerd: is that something you are entirely opposed to?
<pitti> sjoerd: maintaining the split in Ubuntu is no big deal either, but it would be the only actual delta for now
<sjoerd> aren't the kubuntu guys using glib through gstreamer yet ? :).. But no no real reason to be against it
<Kamion> $ sh -n debian/init.d
<Kamion> debian/init.d: line 29: syntax error near unexpected token `;;'
<Kamion> debian/init.d: line 29: `    ;;'
<elmo> doko: did mdz ok the oo split?
<Kamion> mjg59: try working code next time kthxbye ;-)
<pitti> Riddell: ^ what sjoerd asked
<sjoerd> pitti: it's probably the best to put it in dbus anyway, so one doesn't need dbus-1-utils to startup the session bus
<infinity> ARGH, I WAS TYPING, AND MY SCREENSAVER KICKED IN; DIE, GNOME-SCREENSAVER, DIE!
<Kamion> mjg59: (I think you want the . hp.hk after the esac)
<ogra> infinity, :'/
<pitti> sjoerd: hum, you are absolutely right
<pitti> sjoerd: now that I think about it I wonder why it landed in utils in the first place
<jdub> infinity: http://bugzilla.gnome.org/show_bug.cgi?id=315969
<elmo> ogra: oh, yeah, dude, GREAT NEWS
<ogra> infinity, could you check the dpms settings in gconf-editor ? 
<elmo> ogra: killing workrave doesn't fix  my problem
<elmo> gnome-screensaver still DOSes my  box
<infinity> ogra : DPMS is enabled, I enabled it myself, and yes, it was DPMS that kicked in, not the screensaver.
<ogra> elmo, we'll discuss g-s-s in TB tonight...
<elmo> I LOVE LAST MINUTE CODEBASE SWITCHEROOS
<sjoerd> pitti: probably because nothing used the session bus at that time
<Kamion> elmo: but it's PWETTY
<Riddell> sjoerd: glib yes, but dbus-viewer is the killer, bringing in gtk/atk/cairo etc etc
<daniels> elmo: do you have anything else open with a global keyboard grab?
<sjoerd> Riddell: ah, that explains :)
<pitti> Riddell: I'll upload a new dbus that moves dbus-launch into dbus proper
<elmo> daniels: not that I can think of, but that seems the most likely culprit
<elmo> daniels: as I have to move the mouse to get g-s-s's dialog to appear
<elmo> pressing a key doesn't cut it
<daniels> sweet
<Riddell> pitti: great
<doko> elmo: no, not explicitely, but I cannot imagine, why not. openoffice.org-debian-files will be in main, the new openoffice.org1-debian-files in universe
<elmo> doko: ok, it's just we were discussing it, and the dicsussion stopped without conclusion
<Riddell> sjoerd: and other apps in dbus-1-utils bring in gobject and stuff that kubuntu doesn't need
<daniels> i think rigorously following freeze guidelines and our release schedule to not destabilise the tree with random shit at the last minute is what makes ubuntu truly great.
<elmo> well explicit conclusion, but hey what do I care
<jdub> ogra: http://bugzilla.gnome.org/show_bug.cgi?id=316558 <- hrm?
* ogra looks
<sjoerd> Riddell: that explains 
<ogra> jdub, hmm
<ogra> jdub, #15616
<jdub> ogra: in ours?
<ogra> yup
<ogra> tagged upstream
<jdub> as in, you're pointing to the same bug, or something else of interest?
<jdub> right
<jdub> waht's with the "doesn't use pam" bit?
<ogra> might be, i have to look into it...
<ogra> it uses lbpam as build dep...
<ogra> libpam even
<ogra> and configure has: --enable-pam            Enable PAM support [default=auto] 
<ogra> so i would expect pam to be in...
<ogra> its something else... xscreensaver has a special function to capture typeahead input... i dont think its a pam issue
<infinity> Great, it did it again.
<infinity> This hasn't happened to me at all since the upgrade, now I've had it twice in the last 10 mins.
<infinity> How do I make the stupid screensaver know I'm... Like... HERE...?
<mjg59> I think gnome-screensaver is the BEST THING EVER
<mjg59> I'm glad I spent so long last night integrating it into acpi-support
<ogra> infinity, what are the dpms settings in gconf for g-s-s ?
<pitti> ogra: do I need to do anything spethial to get g-s-s? I still have xscreensaver running
<ogra> pitti, install ubuntu-desktop ? 
<pitti> ogra: good point :-) I haven't
<mjg59> Bugzilla is currently broken. Please try again later. If the problem persists, please contact bugme-admin@osdl.org. The error you should quote is: Can't connect to MySQL server on 'nat.osdl.org' (111) at globals.pl line 140.
<mjg59> NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNGH.
<ogra> it depends on it... g-s-s conflicts with xss
<\sh> hmmm....
<infinity> ogra : dpms_enabled (checked), dpms_off (240), dpms_standby (120), dpms_suspend (10)
<\sh> no TB meeting tonight?
<infinity> ogra : I haven't changed any of those from the defaults, except to chekc the box.
<pitti> ogra: so I should install g-s-s to join the pestering^Wtesting team? :-)
<ogra> infinity, the 10mins are a leftover of the default settings that got shipped
<Keybuk> \\sh: should be, at 2000UTC
<ogra> infinity, it was fixed in my second upload
<infinity> ogra : How does that make a difference?... If I'm typing, none of these should kick in.
<\sh> Keybuk: why is nothing on the w.u.c/Calendar or on the TechnicalBoardAgenda *gnarf* and I thought I could test a lot of small features
<Keybuk> nobody's added anything to the Agenda
<Keybuk> it does say Tuesday 20 September 2005 at 2000 UTC though
<Keybuk> don't know who does /Calendar
<\sh> hahahaq
<\sh> not this morning
<\sh> last edited 2005-09-20 11:02:53 by ColinWatson
<pitti> Riddell, sjoerd: new dbus uploaded; I moved dbus-launch from dbus-1-utils to dbus
<pitti> Riddell: so please make sure to depend on dbus >= 0.36.2-0ubuntu5
<Riddell> thanks pitti 
<bob2> NM appears to like to break my network
<pitti> bob2: oh, does it anything else?
<pitti> (SCNR)
<bob2> hahaha
<sivang> lol
<pitti> Hey shackan, how are you
<shackan> apart from the fact that I had to drive my scooter under the rain this morning, fine
<jbailey> Hey cool, the software power button on my laptop now apparent means "go do software suspend"
<shackan> and I've started to see what the bluetooth stack in freebsd looks like, luckily the api is almost identical :)
<mvo> ogra_: will g-s-s come up even if some other app (like totem) is already in fullscreen mode? is that something that (assuming we release with g-s-s) should be fixed?
<ogra_> mvo, i guess totem looks if xss is running, so i guess we need to change something
<mvo> ogra_: I was wondering if we should teach g-s-s to look for fullscreen-state windows and not kick in when it finds one
<ogra_> mvo, yes, thats sounds better than leave it to the app
<bob2> fabbione: do you know/care if the ubuntu kernel would need a patch to host vmware?
<jdub> bob2: i would
<bob2> it oopses on breezy
<bob2> (oopses the host, that is)
<fabbione> bob2: i have no idea...
<bob2> hmmm
<bob2> the patch seems to be for the modules, not the kernel
<Yagisan> bob2 - what is the problem ? - I use vmware with hoary
<daniels> Yagisan: 'on breezy'
<sladen> I asked on #ubuntu-doc 4 hours ago, but no reply since.  Does anyone here have admin rights on the wiki to revert a page or does one have to do it by hand?
<sladen> (a LaptopTestingTeam Tester has trashed the Template with their own results)
<markuman>  i hope i don t disturbed again: but every time a try to build a deb file, the deb files are only a few kbs big. so the source code was not included. i ve paste here the 2 lines from output and the debian/rules http://paste.debian.net/1980
<Yagisan> dainels: I know he said breezy - but the kernel should not need a patch to run vmware.
<daniels> Yagisan: they have a custom kernel module
<sladen> markuman: you're using dpkg-genchanges...!
<bob2> markuman: .deb files do not include source code
<markuman> sladen, hm? i use dpkg-buildpackage -rfakeroot
<markuman> bob2, but why it is so small? 
<bob2> markuman: that debian/rules file by itself is pretty profoundly unuseful
<bob2> markuman: if you want help with your package, you need to put the full source somewhere
<markuman> bob2, the hole folder where everything is include?
<bob2> markuman: so
<Kamion> markuman: this isn't really appropriate for #ubuntu-devel; could you find somewhere else to discuss this, please?
<Yagisan> daniels: I know - I'm trying to make vmware into a .deb for my private use. It has vmmon and vmnet, but if they were patched with the vmware-any-any-XX patches it should work.
<Kamion> perhaps some Debian or Ubuntu help channel
<daniels> markuman: #ubuntu-motu might be useful for you
<ogra_> :)
<markuman> ok thx sry
<fabbione> ogra_: can you kindly paste to me the standard /etc/network/interfaces that comes out of a ltsp-server install?
<Kamion> Mithrandir: just out of random curiosity, have you played with oem-installer at all?
* Amaranth waves
<ivoks> wave
<mdz> chmj: no way to transfer from bugzilla to malone, but you can add a reference to bugzilla in  malone, which is similar
<ogra> morning mdz 
<mdz> morning
<\sh> chmj: hcid segfaults on my laptop when trying to gnokii --identify and entering my pin on the phone :(
<seb128> hi mdz
<\sh> evening mdz
<chmj> \sh: can you pleaes file that with bugzilla, and provide a backtrace is possible 
<chmj> morning mdz 
<\sh> chmj: i will...need to find the time to play around again
<\sh> charging cell right now
<ogra> fabbione, cool howto ! thanks
<chmj> \sh: ok, thanks 
<mvo> morning mdz 
<fabbione> how is the list admin for ubuntu-devel?
<fabbione> hey mdz
<jdub> fabbione: yo
<seb128> mdz: any objection to build gst-plugins0.8 with libcdio? It has been accepted for main by pitti. That will not change existant features or create a new package.
<fabbione> jdub: please unsubscribe Frans.Kool@FRSGlobal.com
<mdz> seb128: what is libcdio?
<jdub> oh, autoresponder guy?
<fabbione> jdub: out of office reply to people posting to ubuntu-devel
<fabbione> yes
<seb128> mdz: a better libcdparanoia
<mdz> seb128: we've been testing cdparanoia for a long time
<seb128> mdz: ross plan to use it for sj/GNOME 2.14, if we ship the plugin with the current package that will allow him to code using 5.10
<mdz> seb128: do you choose at runtime whether to use cdio or cdparanoia?
<seb128> mdz: it doesn't replace it, but if it's shipped people can use it
<mdz> seb128: can we keep cdpaarnoia as default?
<seb128> mdz: yep
<mdz> ok, no problem then
<seb128> sure
<seb128> thanks
<spayne> is daniel holback around?
<seb128> he's dholbach
<dholbach> hi spayne :)
<spayne> thanks seb128
<bddebian> spayne: No we locked him in a cage ;-)
<spayne> dholbach: right, problem with gnome-bluetooth
<bob2> mjg59: so, with dpms blanking off, it gets quite far into the resume
<doko> mdz: the OOo2 packages based on m129 are ready for upload
<bob2> mjg59: paste the little progress-o-meter that shows it reloading pages
<bob2> mjg59: but then the screen goes blank like it normally would when about to switch back to x, but all it switches to are brown and white vertical lines
<mjg59> bob2: Do you have latest initramfs-tools, and have you regenerated your initramfs?
<bob2> mjg59: which look a lot like a corrupted version of the usplash image
<mjg59> Yes, that's normal
<seb128> ogra: intested by upstream discussions about gnome-screensaver changes, I got a mail from upstream who wants to discuss changes on how to set the list of them, make it coherent with xscreensaver, etc
* bob2 tries
<seb128> ogra: he says to Cc people interested by the discussion
<ogra> seb128, yup go ahead
<ogra> i'm already discussing a bug with mccann
<\sh> spayne: come to #ubuntu-motu cause gnome-bluetooth is universe i think
<ogra> seb128, i wonder where he got this:  Does it still use setuid root for the gnome-screensaver-dialog
<ogra> process?  
<spayne> \sh: thanks but i'm in deep discussion with dholbach
<\sh> oh ok :)
<ogra> seb128, did this package ever use setuid stuff ?? 
<bob2> I do wonder why this xterm is black on white, tho
<seb128> ogra: no, it uses pam
<\sh> bob2: what? in gnome? i wonder with you
<ogra> seb128, yes, thats what i answered in the bug... i was just curious how he got that idea
<seb128> ogra: I read some bug saying it doesn't work without putting it setuid on debian/ubuntu
<seb128> ogra: that's because the upstream pam install doesn't work out of the box, I've patched it for the package
<ogra> ah
<bob2> mjg59: btw, should I touch MODULES in default/acpi=support at all, or is it all auto now?
<ogra> seb128, gnome #316558
<mjg59> bob2: You should never need to touch it
<mjg59> If you do, please file a bug
<bob2> mjg59: ok, the example could do with an update then :)
<bob2> mjg59: just mkinitramfs -o /boot/initrd...?
<mjg59> dpkg-reconfigure linux-image-`uname -r`
<Amaranth> seb128: Could you handle bug 15874 for me? Just make the suggested change.
* Amaranth kicks his broken HD
<\sh> bob2: something is strange....really with xterm
<siretart> fabbione: did you get the email with the credentials for igor? [my evo crashed, but according to logs, mail should have been sent] 
<seb128> Amaranth: sure
<\sh> bob2: because now it works as expected :)
<mdz> doko: ok
<bob2> mjg59: heh, I geuss I can get rid of acpi_sleep=23_bios kernel flag now too?
<mjg59> bob2: Yes...
<bob2> mjg59: hm, a bunch of "tr" errors on hibernate
<bob2> mjg59: and NM doesn't see my wired nic until I restart dbus
<bob2> mjg59: otherwise working great, tho, thanks again
<bob2> ahhhh. NM only sees it when it comes up afterwards.
<bob2> I wonder if that;s a bug or not
<mjg59> Ok, cool
<bob2> and it's like an order of magnitude faster to suspend than haory
<mjg59> Yeah
<ogra> bob2, dont worry, we'll slow it doen again with gnome-screensaver
<mjg59> I'm not sure where all the speedup comes from
<mjg59> But it's really quite usable
<pitti> *sniff* until the weeked, hibernate worked perfectly, now it's *entirely* broken
<pitti> mjg59, what did you do? :-/
<mjg59> pitti: Install initramfs-tools. Regenerate your ramdisk. Read the MANY MANY DUPLICATE BUGS.
<bob2> ogra: hah, you'll have to make me upgrade, first ;)
<pitti> mjg59: ir-t is installed for ages, but I'll try to reconfigure my kernel
<mjg59> pitti: Latest initramfs-tools
<mjg59> As in, the ones that I uploaded at midnight
<pitti> mjg59: 0.28 is not recent enough?
<ogra> bob2, its already a dependency of ubuntu-desktop :)
<ogra> bob2, and mjg59 just rewrites the acpi scripts for g-s-s
<mjg59> pitti: That's the one. Make sure your initramfs uses that.
<mjg59> And then make sure that you have a swap partitoin
<pitti> mjg59: I have two, could that lead to trouble?
<pitti> mjg59: in the first two attempts, it came back with "not enough space"
<mjg59> pitti: Plausibly, then
<mjg59> Check that you *do* actually have 2 at the moment
<pitti> mjg59: hmm, how could you know? the big one is really gone...
<pitti> mjg59: not that I touched it in any way, but thanks for the hint
<mjg59> pitti: Because initramfs-tools was broken
<mjg59> And you tried hibernating
<bob2> hah
<Riddell> Kamion: could you change the isolinux splash for kubuntu to this http://kubuntu.org/art/kubuntu-usplash-639x320-14.png
<pitti> mjg59: ah, ok; thank you very much
<bob2> suspend-to-ram is broken because gnome-session is not running
<mxpxpod> pitti: could you check something on your ppc?
<Kamion> Riddell: ok, will do after dinner
<pitti> mxpxpod: yes?
<mxpxpod> pitti: can you enable the composite extension in X and then run gdesklets?
<Diziet> kamion: lsb's init-functions:
<pitti> mxpxpod: ouch - that is so slow on my ppc that it is not actually usable...
<mxpxpod> pitti: suck :(
<pitti> mxpxpod: but I can test it; what is the exact option?
<Diziet> I'm about to upload a fix to 4367, which is a complaint that when an initscript prints errors to stderr between saying it's doing something and the the message saying it's failed, the screen is garbled.
<mxpxpod> pitti: whenever I run gdesklets with the composite extension enabled, it crashes X
<Diziet> This is a replacement of about 20-30 lines in the middle of log_begin_msg etc.
<Diziet> (a) Should I take care about anything in particular and (b) should I send my diff somewhere else too ?  (eg, Debian)
<mxpxpod> pitti: do you need the option for X?
<pitti> mxpxpod: well, how do I enable it again?
<mxpxpod> pitti: Section "Extensions"
<mxpxpod> Option "Composite" "On"
<mxpxpod> EndSection
<pitti> mxpxpod: I thought I have to change something in xorg.conf for that
<pitti> mxpxpod: ah, ok
<ogra> hmm, is it intended to be used ? 
<ogra> i thought thats only a proof of concept ...
<mxpxpod> ogra: composite?
<ogra> yup
<mxpxpod> not sure
<mxpxpod> I thought it worked
<ogra> sure, it works, but its only a proof of concept... and it clashes with GL
<ogra> (afaik)
<mxpxpod> ah
<Diziet> kamion: I have to go very soon; my parents are visiting this evening ...
<pitti> mxpxpod: do I need to install xcompmgr for your test?
<mxpxpod> pitti: no
<pitti> mxpxpod: ok, I started X with composite, what now?
<mxpxpod> pitti: launch a terminal and run gdesklets
<pitti> mxpxpod: no such command
* pitti installs
<mxpxpod> hehe
<pitti> mxpxpod: good grief - that pulls in half the world, including xmms
<mxpxpod> pitti: are you serious? jeesh
<pitti> mxpxpod: 28 additional packages
<mxpxpod> pitti: sorry :(
<pitti> mxpxpod: well, aptitude knows how to clean up :-)
<mxpxpod> :)
<mxpxpod> good deal
<pitti> mxpxpod: yep, confirmed, it crashes X
<mxpxpod> pitti: ok, thanks
<mxpxpod> pitti: must be something with composite because grdesktop does it too
<pitti> mxpxpod: entirely possible
<carstenh> debian + wmaker + xorg + composite + xclock crashes too
<mxpxpod> pitti: thanks for trying it
<carstenh> probably the same bug
<pitti> Hi carstenh, how are you
<carstenh> hi pitti, fine :)
<mxpxpod> carstenh: any clue what causes it?
<zyga> pitti: where can I learn/track the language-packs issue?
<zyga> pitti: BTW: hi :-)
<carstenh> mxpxpod: no, sorry. i have rebuilt wmaker and tried it on sarge and etch.
<mxpxpod> carstenh: ok
<carstenh> mxpxpod: it freezes
<mxpxpod> strange... I guess I'll just disable composite... no big deal
<carstenh> mxpxpod: it freezes the whole pc
<mxpxpod> pitti: what X options do you use for your video card?
<carstenh> mxpxpod: and icewm works fine. so i'm not sure what causes this bug
<mxpxpod> carstenh: that's wierd... it just crashes X for us
<carstenh> mxpxpod: i tried it on different architectures and with different graphic adapters
<pitti> mxpxpod: hey, I started gdesklets and now my keyboard went crazy
<mxpxpod> pitti: with composite?
<pitti> mxpxpod: no, just disabled it
<pitti> bah
<mxpxpod> ah, ok
<pitti> shift does not work any more and produces weird results
<mxpxpod> pitti: yeah, gdesklets is messed up
* pitti purges this scary stuff
<mxpxpod> pitti: I just wanted to see if you got that crash
<pitti> mxpxpod: any idea why it messes up the shift key?
<mxpxpod> pitti: heh, no clue
<Diziet> Oh, he's at dinner.  Oh well.
<mxpxpod> pitti: do you have a ppc laptop? or just a ppc
<mjg59> Hmm.
<pitti> mxpxpod: laptop - iBook G4
<mxpxpod> pitti: ah, cool
<mjg59> So, from power button to desktop is 90 seconds when resuming from hibernate
<mjg59> That could be better
<mjg59> It'll do, though
<mxpxpod> pitti: that's what I've got
<mxpxpod> pitti: what X settings do you use for your card?
<pitti> mxpxpod: the OOTB ones, I didn't touch them - just UseFBDev true
<mxpxpod> ah
<mxpxpod> pitti: have you had problems with pbbuttonsd not sleeping the laptop after booting?
<pitti> mxpxpod: no, that works fine for ages
<pitti> mxpxpod: I never shut down my iBook, i always use STR
<bob2> \sh: so, erasing my gnome config and starting from scratch means xterm is back to normal
<mxpxpod> pitti: with the new pbbuttonsd package, if I boot into linux, it no longer uses 100% cpu, but I can't get it to sleep either using the gnome logout, gdm-signal -s, or pbbcmd config TAG_GOTOSLEEP 1... I have to restart pbbuttonsd in order for it to sleep
<zyga> pitti: ping ping :)
<pitti> mxpxpod: oh, with 0-7.1? /me installs
<pitti> zyga: pong, sorry
<mxpxpod> pitti: no no
<\sh> bob2: i don't think so..I just implemented today the old hoary patch for some Xterm app defaults..and termcap/terminfo...but strangewise..now it's black/white...not like before black/grey
<zyga> pitti: I'm sorry for bothering you but I'd really like to learn about that issue
<mxpxpod> pitti: 0.6.6
<pitti> zyga: issue meaning, how to build language packs?
<mxpxpod> pitti: did you guys just upload 0.7.1?
<pitti> mxpxpod: I currently have the latest breezy version installed since that was the one I hacked on last; but 0.7.1 worked fine as well
<mxpxpod> pitti: I'm talking about the latest breezy
<pitti> mxpxpod: no, I still need to discuss this with mdz
<mxpxpod> pitti: try rebooting (I know, that may be hard for you ;) and after everything is up and running, try to sleep your ibook
* xTina shares some pictures http://tuxtina.de/tmp/ubuntu_lab1.jpg http://tuxtina.de/tmp/ubuntu_lab2.jpg
<zyga> pitti: no the issue of true language pack separation, main vs universe and so on
<bob2> \sh: well, it's working for me now
<\sh> bob2: grey?
<wasabi_> TRICKARY
<wasabi_> there are mirrors in the back!
<mxpxpod> pitti: also, check out #12198
<\sh> bob2: or white?
<xTina> wasabi: No, it's a glass wall. There's a total of 74 machines in that room.
<ogra> wasabi, then you would be able to see xTina there :)
<\sh> xTina: wonderful :)
<wasabi_> A glass wall?
<\sh> this project sounds as the project pylon mentioned last time
<xTina> wasabi_: It partitions the room in two halfs.
<\sh> wasabi_: big window :)
<bddebian> pitti: You back? :-)
<bddebian> pitti: Sorry, I got pulled away :-(
* zyga wonders how pitti manages to read everything and do his work *and* have a personal life....
<daniels> zyga: (he doesn't have a personal life.)
<\sh> zyga: time management :)
<mjg59> HURRAH.
* mjg59 fixes hibernation with inserted PCMCIA cards
<pitti> bddebian: yes, I had to go for a while
<\sh> mjg59: u rock man
<mjg59> You people all owe me so much
* ogra applauds mjg59 
<mjg59> RIGHT.
<mjg59> Now.
<mjg59> TWO MORE PATCHES.
<\sh> mjg59: ubz...
<pitti> mjg59: kudos!:-)
<mjg59> \sh: Probably not there
<ogra> mjg59, you will be sooo drunk
<mjg59> Sadly...
<ogra> mjg59, oh ? 
<ogra> :(
<mjg59> Too much work
<\sh> mjg59: what? 
<pitti> zyga: so you want to start to build universe language packs?
<zyga> \sh: time management is the magical skill of expanding 24 hour peroid  ;-)
<zyga> pitti: no... I want to make proper language packs
<mjg59> \sh: I have to get on with my real life work as well as Ubuntu :)
<pitti> zyga: the langpack-o-matic code is in a public arch repo, that's not the problem
<\sh> zyga: in the ubuntu world the day has 48 hours
<zyga> pitti: and a language pack management system ;-)
<pitti> zyga: you just need a computer with good bandwith to run it on :-)
<zyga> pitti: arch.ubuntu.com? I'll check it out :)
<bddebian> pitti: IF you get a sec, can you please just take a look at:  http://www2.bddebian.com:8000/packages/ubuntu/libpgtcl2/  And see how far off I am?
<bob2> UBZ+1 should be in Cambridge
<\sh> mjg59: oh..i see u are in uk...not far from us..ogra...lets book a 19cent flight to london ;)
<pitti> zyga: nope, that's something different
<bob2> so everyone can repay mjg59 
<daniels> bob2: UCH
<daniels> or UCP, rather
<zyga> pitti: hehe, I want to think of something that might be used by ubuntu and everyone else in the end :)
<daniels> Ubuntu at Colin's Place
<Diziet> kamion: I uploaded that new lsb (see scrool) and I hope it's all right.  Let me know if not.
<pitti> zyga: http://people.ubuntu.com/~pitti/arch/martin.pitt@canonical.com--2005/langpack-o-matic--main--1/
<ogra> \sh, 19cent ? i think i'd rather walk :)
<\sh> ogra: + taxes and a nice journey with the train from stansted
<\sh> (sp?)
<pitti> bddebian: no orig.tar.gz?
<zyga> pitti: I'll flood you with draft specs and sample code if I ever manage to write anything, thanks :)
<pitti> zyga: feel free to ask me things about the code, the existing doc is not very good
<daniels> arguably all development to within four standard deviations of the normal happens there anyway, so it'll be no different
<bob2> mjg59: I get "/usr/share/acpi-support/power-funcs: line 11: /proc//environ: No such file or directory" when trying to sleep now, since gnome-session isn't running
<mjg59> bob2: Don't do that, then
<bob2> I made a new gnome session from scratch 15 minutes ago
<mxpxpod> pitti: if you could test that behavior I told you about and check out #12198, that'd be awesome
<mxpxpod> I gotta get back to work
<mjg59> bob2: More seriously - just /dev/null that
<pitti> mx|away: I reassigned the bug to me
<mx|away> pitti: sweet
<bob2> mjg59: aside from that, it just prints "declare -x FOO=bar" for each env var I have, then exists cleanly
<daniels> heh
<bob2> tho, it occurs to me that it's my fault for not running gnome-screensaver
<mjg59> "fault"
<bob2> and that I'm being punished for having a screensaver that reliably locks ;)
<mjg59> I have a feeling that I'm going to have to carry out my threat to kill people
<daniels> start with motu
<zyga> pitti: just a side question, how do you feel about separating translations from everything else
<ogra> daniels, HEY !
<daniels> ogra: just checking to see if you're still awake :)
<zyga> (separate management system)
<ogra> :)
<dholbach> daniels: tststs
<pitti> zyga: what do you mean? langpacks contain nothing but translations
<daniels> clearly this means you're all spending too much time looking at IRC instead of working
<zyga> pitti: yes but they have many flaws
<\sh> daniels: what's up with motu? motu rocks..
<zyga> pitti: I'm talking about a complementary translation pagage management system
<bob2> on the plus side, suspend-to-disk is fast enough that I'll wait for *screensaver to unbreak before whinging about sleep
<zyga> s/pagage/package/
<daniels> \sh: kidding, dude
<pitti> zyga: not sure what you mean
<\sh> daniels: wait until I finished my design for the new motu shirt ... u will be jealous ,)
<daniels> heh
<zyga> pitti: I'm not sure how to tie this into existing tools yet but what I gnerally mean and think about is a system that keeps track of what translations are needed - this is not related to any language-xxx.debs it's a different, better (hopefuly) system
<zyga> actually - not better - specialized
<pitti> zyga: langpack-o-matic is currently a system to pull translations from buildds, mangle them a bit, and generate language pack source packages; not sure what you want to add
<daniels> mdz: duuuuuuude.
<\sh> From: root <mdz@ubuntu.com>
<\sh> i just wanted to say something...
<mdz> yes, I noticed that as well
<mdz> the lirc debian/rules is EVIL
<mdz> it modifies changelog and config.* during the build
<mdz> which was run under fakeroot
<\sh> oh well...sounds like libhid
<daniels> obviously it should use yada
<daniels> --disable-manage-devices
<daniels> er
* bob2 vomits at daniels 
<\sh> get the libversion number from debian/changelog and fails when the version is x.z.y-XubuntuY
<daniels> --with-port=0x3f8 --with-irq=4
<daniels> --with-moduledir="/lib/modules/$(shell uname -r)/misc"
<daniels> isn't it an IRC client?
<bob2> it's drivers for IR devices
<\sh> lirc is remote control stuff
<Kamion> Diziet: should be fine to just fix it. Debian also has roughly the same set of functions (imported from Ubuntu), but they've been developing and fixing them since after our upstream version freeze so I don't know whether your patch will apply there. It may do.
<Mithrandir> Kamion: re oem-installer: no, I haven't had the time. :-(
<pkern> Should one download the whole breezy ISO to reinstall or is it possible to install it with a warty image? (aka were they many changes in d-i since warty?)
<shackan> where's the source for update-notifier? It hoped to find it in gnome cvs but maybe it's ubuntu-specific so I have to look somewhere else ?
<pkern> shackan: Try apt-get source when you have deb-src in your /etc/apt/sources.list
<Kamion> pkern: loads of changes, but you can certainly install warty and upgrade from that
<mdz> pkern: Ubuntu 5.04 (hoary) is the current stable release; breezy is the current development release
<Kamion> pkern: you can't use a warty ISO to install breezy directly, but upgrades from the warty system it will install are fine
<shackan> pkern, yes, I know, I was looking for the upstream repository
<bob2> fabbione: have you found 2.6.12's ipv6 stack to be slightly shit?
<mdz> pkern: there's no reason to install warty except in the unlikely event that it works while hoary doesn't
<pkern> mdz: I know, but I have warty shipit here, because I got that shortly before hoary was released. |:
<pkern> mdz: Ok, then I have to download the 700Mb download. Isn't there any netinst image?
<Kamion> there's a netboot image, which isn't quite the same
<mdz> (-> #ubuntu)
<Kamion> (downloads all of d-i over the network)
<jdub> mdz: the google search box in firefox is fascism.
<mdz> jdub: pardon?
<mdz> oh, summerfield
<mdz> undercover as "John"
<jdub> mdz: just in case you thought you were being reasonable.
<pitti> Morning mdz
<daniels> gar admin@highlinewebwhateveritis.com
<daniels> possibly the most useless reply ever: http://lists.ubuntu.com/archives/ubuntu-users/2005-September/049464.html
<Treenaks> daniels: yay forum gateway>
<daniels> wow, he's got an arseload of stuff.  just when I thought -users couldn't possibly get worse.
<daniels> Treenaks: that's not actually coming from the forums, believe it or not.
<bob2> sadly that wasn't gatewayed
<Treenaks> What was the way to make grub try a certain kernel only once?
<bob2> wtf
<Treenaks> bob2: it is possible
<bob2> there's a whole thread about some guy whinging he didn't get an answer on the forums
<Nafallo> lol
* bob2 shudders then sleeps
<dholbach> bob2: good night :)
<fabbione> bob2: works fine here.. define shitty
<Keybuk> heh, Debian have DDoS'd their security server
<lathiat> eh?
<pitti> Keybuk: yeah, the new flamewar is annoying
<Keybuk> uploaded security updates to X --> saturated outgoing bandwidth
<Keybuk> there's a flamewar?
<lathiat> ah, heh
<Kamion> Riddell: done, thanks
<Riddell> Kamion: thank you
<ogra> Riddell, so tell me about kscreensaver
<Treenaks> skreensaver?
<ogra> Riddell, does it hae a own daemon ? 
<ogra> have even
<Riddell> ogra: it's screensavers for KDE.  kscreensaver-xsavers brings in xscreensavers and is a frontend to them
<Riddell> it uses kded I think
<pitti> mdz: do you have an idea why mozilla-browser is still in main and does not show up in anastacia?
<Kamion> Riddell: let me know if it's working right with tomorrow's images; there was no colour close enough to white in the image for use for text, so I took advantage of the fact that the palette wasn't full and told ppmtolss16 to use white as colour 7 anyway
<Kamion> I'm not absolutely certain that'll work; we'll see
<ogra> Riddell, so you only need the hacks, not the daeon, right ? 
<ogra> deamon
<ogra> ARGH
<ogra> d a e m o n 
<pitti> ogra: tpying scuks :-)
<Riddell> ogra: hacks?
<ogra> Riddell, the single screensavers in /usr/lib/xscreensaver
<ogra> Riddell, they all moved to xscreensaver-data
<ogra> depend on that and you should be fine
<ogra> (as long as you dont need the daemon, then we'd have a problem)
<Riddell> ogra: nice, I'll give that a try
<ogra> Riddell, sabdfl wants them even more split, so we'll end up with at least 5 packages with hacks in dapper
<Riddell> webcollage doesn't want to work :(
<ogra> Riddell, webcollage wil get dropped
<ogra> Riddell, #15847
<Riddell> aww, I liked the danger it posed
<elmo> pitti:    * debian/control: Add appropriate conflict.
<elmo> pitti: is that a typo?
<pitti> elmo: no, why?
<elmo> why conflicts and not replaces?
<pitti> elmo: since I moved dbus-launch from dbus-1-utils to dbus, the dbus needs to conflict with older dbus-1-utils
<pitti> elmo: that's my usual approach, at least
<pitti> elmo: replaces is better?
<elmo> yes, much better
<elmo> Conflicts << forces dpkg to remove the old version of what you're conflicting against
<Kamion> pitti: because librsvg2 build-dep mozilla dep mozilla-browser
<pitti> Kamion: OMG, -browser is a build-dep? crazy; I thought just mozilla-dev was
<Kamion> sorry, librsvg2 build-dep mozilla-dev dep mozilla-browser
<pitti> elmo: apt doesn't install the newer version first? 
<Kamion> pitti: what elmo said, conflicts << is evil for that
<pitti> Kamion, elmo: alright, I fix that
<Kamion> replaces has the proper semantics
<daniels> (finally)
<pitti> Package: dbus
<pitti> Replaces: dbus-1-utils (<< 0.36.2-0ubuntu5)
<Kamion> pitti: apt will probably try, but might not always be able to. conflicts imposes an extra constraint on the upgrade ordering that doesn't need to be there
<Kamion> and the fewer constraints the better
<pitti> alright
<jdong> hey guys, what's up?
<jdong> lol
<mdz> pitti: either it is seeded, or it is a dependency or build-depenency, direct or indirect, of a seeded package
<mdz> pitti: germinate rdepends will tell you which
<seb128> Kamion, pitti: I can fix librsvg2, that's for the mozilla svg plugin but we can probably change it to firefox
<pitti> mdz: yes, Kamion already found it; m-dev depends on mozilla-browser *grumpf*
<seb128> dholbach did that with 2.12.0
<mdz> elmo: how can I reproduce your workrave/gnome-screensaver bug?
<elmo> mdz: I don't know
<elmo> is there anyway to tell what has a global key grab going on?
<elmo> 'cos I reckon daniels was on the right track
<Kamion> pitti: also enigmail, openoffice.org2, openoffice.org2-l10n build-dep on mozilla-dev
<Kamion> that looks like the lot
<daniels> elmo: not really, no
<pitti> Kamion: right, m-dev is fine for main; it's the m-dev depends: m-browser dep that's evil
<Kamion> ah
<daniels> elmo: i mean, you can enable whatever crazy-arse serverflag it is, and ctrl-alt-kpdivide it
<pitti> seb128: see above, don't bother
<daniels> elmo: that's the massive-rubber-mallet approach to grabs
<seb128> pitti: l
<seb128> s/l/k/
<Kamion> you could enable AllowClosedownGrabs, ctrl-alt-kpmultiply, and see which processes die
<daniels> right
<daniels> the other option just kills the grabs
<daniels> not slays the processes holding them
<elmo> what the heck is kp?  numeric keypad?
<daniels> (kills the client, whatever.)
<daniels> elmo: yeah
<elmo> ok
<Kamion> I figure he wants to know which clients are at fault
<daniels> Kamion: true dat
<Kamion> unless X logs it
<daniels> i'm going to laugh really hard if it's core gnome
<daniels> and elmo's session dies
<elmo> oh, I wonder if it's unclutter
<Kamion> (logging which clients would be nice, actually, if it can)
<elmo> we have a winner
<elmo> it's unclutter
<daniels> Kamion: it doesn't log, no
<daniels> it probably should
<daniels> (the sensible logging layer -- with levels of verbosity -- is up in the xfree86 ddx because that totally makes sense, so nothing down lower in the dix can do verbosity-dependent logging.  WHOOHOOHOO.)
<phlaegel> ok, this whole dbus-upgrade-recommends-reboot thing isn't going to last forever, is it? maybe fixed in dapper, when dbus is a bit more grown up?
<ogra> phlaegel, its an upstream decision...
<Kamion> unclutter> don't use -grab?
<phlaegel> ogra: ouch. a permanent one?
<ogra> phlaegel, as long as the dbus authors decide its necessary, its hard to work around that
<phlaegel> yeah
<ogra> phlaegel, aks them :)
<lathiat> phlaegel: you can get dbus to reload its configs, if thats what your concerned about
<daniels> or just don't use unclutter at al
<elmo> Kamion: I'm not
<elmo> just 'unclutter'
<Kamion> huh, the source seems to say it won't XGrabPointer() unless -grab
<daniels> OH MY GOD
<phlaegel> lathiat: I just don't want to see linux become reboot-happy. I don't like rebooting my desktop :-)
<daniels> THIS IS A HORROR SHOW
<daniels>                      * send a pseudo EnterNotify event to the parent window
<daniels>                      * to try to convince application that we didnt really leave it
<daniels> what could POSSIBLY go wrong
<elmo> <ignorant>why's that so bad?
<ogra> lets just morguify unclutter, who uses that anyway :P
<daniels> so the alternative to using the grab method, is to have it create a tiny little window under the cursor
<daniels> then it sends an event to the parent window and says 'hey, know how you lost focus to me?  it's all yours again!'
<daniels> and does this awful event-mangling
<elmo> ogra: the whole GSS situation's made so much more fun by comments like that, FYI
<lathiat> gss?
<daniels> elmo: seriously though, unclutter is completely pathological
<daniels> elmo: -grab may actually be *better*
<daniels> lathiat: gnome-screen-saver
<Kamion> ogra: (what's wrong with the word "remove", anyway?)
<lathiat> ah
<ogra> elmo, belive me i get thrown cluebats after me all the day, no matter where i go...
<ogra> Kamion, it just doesnt sound that cool with geran accent :)
<ogra> *german
<elmo> well -noevents does "fix" it
<daniels> elmo: -root could also be vastly less shit
<daniels> elmo: noevents> right, that's the pathological branch I was talking about
<elmo> yeah, sorry I know I'm being dense, but I'm not clear on why it's pathological to send the fake event?
<elmo> and why it's only GSS that gets upset
<elmo> I mean, seriously, this code hasn't been modified since before some of you were born
<elmo> (well, okay, not quite, but close)
<daniels> eh, at the time, my workstation was running NT 4 Server with MSSQL and IIS
<bddebian> w00t
<ogra> elmo, xss lock screen was 15 years untouched when i started working on it...
<daniels> so GSS could be more robust in handling this particular behaviour
<daniels> but it's ... it's not something anyone should ever attempt to do
<daniels> you know how you see people driving roofing nails through their testicles?
<daniels> and they're all like 'don't try this at home, kids'
<Kamion> not personally, no
<daniels> this is that
<bddebian> hahaha
<daniels> Kamion: you need more bmevideo.com in your life
<daniels> (MASSIVELY NSFW.)
* lathiat ughs
<daniels> if I could figlet NSFW, I would.  i don't think I can quite stress the point enough.
<daniels> also, not safe for just-had-lunch
<lathiat> "not safe at all"? ;)
* sivang is back
<Keybuk> what's worrying is that daniels probably has an account at that site
<lathiat> daniels is a continual source of amusement
<Keybuk> I'd go for "worry"
<lathiat> Well either way amusement still stands
<daniels> what's worrying is that you all went and looked
<ogra> Keybuk, depends if as user or as committer...
<ivoks> argh...
<lathiat> daniels: no whats more worrying is that i already knew what it was
<ivoks> gnome-screensaver is really broken
<Keybuk> daniels: *shrug* nothing on there shocks me
<Keybuk> I've seen worse from my friends <g>
<lathiat> *by* your friends or *from* your friends
<lathiat> the internet is a wonderous place
<Keybuk> both
<tseng> Robot101: ref me baby one more time
<tseng> Robot101: PASS THE PIPE
<Robot101> tseng: >:)
<bddebian> Pipe?  Who's got the pipe?
<sivang> Robot101: any new stuff on the design you showed me that other day? (re: clientlib etc)
<tritium> Kamion, is there still a yaboot/os-prober problem in current daily install images?
<Kamion> tritium: yes; the kernel issue that's blocking me fixing that is being fixed now
<tritium> Kamion, oh, sounds close to resolution?
<Kamion> tritium: well, the current images don't hang, at least, if that's what you're asking, but they don't detect OS X
<Kamion> yes
<Kamion> if you don't have OS X, current images should work fine for you
<tritium> Great, thanks for the info.  I'll be glad to test on G5 iMac soon
<tritium> I still do have OS X
<Robot101> sivang: python prototype has got channel support now
<sivang> Robot101: channel?
<Robot101> sivang: our abstraction for all different services over IM/VOIP connections
<sivang> Robot101: ah cool, you have it online somewhere?
<Robot101> textchannel specifically
<Robot101> floopily.org/darcs/ipcf-python
* Robot101 is hacking on cheddar.py (the jabber connection manager) and clienttest.py
<mdz> tech board meeting in #ubuntu-meeting
<paines> hi
<jdub> heh. lock dialogue in swap.
<\sh> bmonty_laptop: ping ubuntu-meeting fast
<kikidonk> hi there !
<kikidonk> i'm planning to do an install party for the upcoming breezy version
<jdub> rad!
<kikidonk> but i was wondering, does the breezy install cd come with a way to repartition windows disks ?
<jdub> yes
<kikidonk> read: most likely ntfs stuff
<paines> cedega stopped working with breezy pre install. i think due to nptl missing in glibc. is that possible ?
<kikidonk> rad!
<kikidonk> in the install process ? 
<jdub> yes
<kikidonk> that rock
<kikidonk> thanks :)
<Robot101> kikidonk: it did in hoary :)
<kikidonk> i didn't look to be honest
<kikidonk> but it's very nice
<Robot101> kikidonk: choose the ntfs partition off the partition manager menu, then you can choose a new size
<kikidonk> cause i'm going to convert windows users of course, and they will very likely have a windows-only disk which must be resized to make room for linux
<Robot101> it lacks feedback, but you can see parted's output on Alt+F3
<kikidonk> cool
<Robot101> I dunno if breezy added a progress bar for that
<kikidonk> i can do without, a longs as it's happening under the hood
<shackan> kikidonk, weren't you a gentoo guy ? :)
<kikidonk> yes
<kikidonk> but gentoo is broken
<torkel> mjg59: ping?
<Kamion> Robot101: no
<Kamion> (sorry)
<mjg59> torkel: Hi
<torkel> mjg59: hi
<mjg59> torkel: What's up?
<torkel> mjg59: re #15582. It works for me with 0.34 if I change user=`finger| grep -m1 ":0" | awk '{print $1}'`
<torkel> to user=`finger| grep -m1 ":0 " | awk '{print $1}'`
<torkel> in getXuser
<torkel> otherwise it matches root
<mjg59> Ok
<mjg59> Please file a bug
<torkel> mjg59: ok. I do a followup
<daniels> screw that
<ogra> mjg59, did you follow the meeting decision for g-s-s ?
<daniels> just search the server's memory space looking for MIT-MAGIC-COOKIE (or XDM-AUTHORIZATION-1 or whatever), get the auth key
<mjg59> ogra: No
<daniels> then search everyone's home directory looking for that key in .Xauthority
<ogra> mjg59, seems we switch back
<mjg59> ogra: Right.
<ogra> :)
<daniels> mjg59: back me up here
<torkel> would be nice if acpi-support works with g-s-s anyway...
<mjg59> torkel: REWAREWAFDS:OIUREWAFDSAREAREWAFDREW
<ogra> that was loud
<mjg59> (ahem)
<torkel> daniels: it's not about Xauth, it's about dbus
<daniels> torkel: if getXuser is wrong, then it's about xauth
<daniels> my solution is simultaneously more foolproof and more elegant
<torkel> mjg59: huh? 
<daniels> alternately, we could write a small script to gdb into the server, break on the first line of WaitForSomething or something equally well-known, and use that to drill down into the auth structures.
<daniels> saves brute-forcing the memory space with strstr()
<Kamion> mjg59,ogra: we switch back providing sabdfl accepts the TB's consensus
<Kamion> which is not the same as "seems we switch back"
<ogra> yes
<torkel> daniels: no. becasue the only way to speek to g-s-s is through dbus, so you have to find DBUS_SESSION_BUS_ADDRESS, which getXuser does in 0.34
<mjg59> torkel: Currently I wish every screensaver to die
<mjg59> I would quite happily have acpi-support conflict with every one of them
<ogra> Kamion, thus the careful "seems" in front
<daniels> torkel: okay, so you didn't mean what you said about needing to change the line so it didn't match root
<mjg59> When there's a decision, I'll fix xscreensaver support
<mjg59> daniels: No, it does mean that
<spayne> i got realplayer from marillat
<daniels> spayne: bad idea
<spayne> wrong channel :-)
<mjg59> We need to find out which user owns the X session so we can find his gnome-session and then find the DBUS_SESSION_BUS_ADDRESS variable in /proc
<spayne> what could you suggest daniels
<torkel> mjg59: I can understand that. They are a mess...
<daniels> mjg59: right
<daniels> spayne: *shrug*
<daniels> mjg59: hence my suggestion of gdb'ing the X server with a small script that prints out the currently active auth keys
<daniels> mjg59: and looks through everyone's Xauthorities looking for that key
* lathiat thinks the proper solution would be to run a daemon as the user that listens on the system bus
<spayne> it is out of hoary extras
<spayne> daniels: it is out of hoary extras
<lathiat> spayne: that has nothing to do with us
<spayne> i know
<spayne> sigh
<lathiat> it seems approximately 3000x less hackish
<lathiat> any reason we are not doing that?
<Riddell> seb128: would it be possible to separate libgstgdkpixbuf.so from the rest of gstreamer0.8-misc, is adds a lot of depends
<seb128> Riddell: I don't want to divert from Debian
<seb128> Riddell: I'll ping the Debian maintainer
<Riddell> seb128: can you CC please if it's e-mail
<seb128> nop, that's IRC
<seb128> is that the only file of this package to be an issue?
<pkern> Any clue what happens when lilo fails to install with LVM as root partition like that? "lookup_dev: number=FD00" "device-mapper ioctl cmd 12 failed: No such device or address" "Fatal: device-mapper: dm_task_run(DM_DEVICE_TABLE) failed"
<mdz> Kamion: I've updated the seeds; please push an update to ~cjwatson and roll new metapackages
<Riddell> seb128: seems to be just that file yes
<pkern> Mailinglist suggests a problem in udev |:
<mdz> Kamion: else I'll do it after lunch, but sooner is better
<jlj> simple C# command line audio player: http://nanocrew.net/2005/09/20/snd123/
<shackan> wow, john lech johansen :)
<jlj> :-)
<shackan> uhm wait, 12 megs of source code for a 'simple command line audio player' ?
<dholbach> shackan: maybe it has some .oggs to test it with ;)
<jlj> the command line interface source code is 1488 bytes, the rest is codecs :-)
<jlj> all the supported codecs are included, there are no external deps besides mono and libesd
<ogra> jlj, what kind of codecs does it support ? 
<jlj> MP2, MP3, AAC, Ogg Vorbis, Speex, FLAC, Apple Lossless, AC3, CDDA, WMA 1 and 2. MOD formats: MOD, XM, IT, S3M, 669, MTM, STM.
<mjg59> jlj: What license is this under?
<jlj> mjg59: GPL
<shackan> seems something which would look pretty good with some frontend
<ogra> jlj, how does that work with included proprietary codecs ? 
<jlj> proprietary? all the decoders are open source, most of the GPL'ed
<jlj> *them
<ogra> MP3 is patented and you have to pay for it
<ogra> i think AAC is nonfree either
<jlj> proprietary != patented
<ogra> yes, sorry, wrong term
<jlj> Ubunu ships libmad in main
<mjr> correct; patented is a form of proprietary
<jlj> err, Ubuntu
<jdub> jlj: (which is an error that we'll be fixing before breezy goes out... finally...)
<ogra> jdub, :)
<shackan> jdub, so it'll be in universe ?
<jdub> yes
<shackan> will it come on the cd ?
<ogra> universe ? 
<ogra> nope
<shackan> people using the live cd won't be able to play their music, that's bad :(
<Keybuk> sure they can
<Keybuk> they can apt-get install the codec to play it
<shackan> yes but it's not the same thing
<Keybuk> no different than people using the install cd though
<ogra> shackan, there was never a mp3 supporting player on the live CD you always had to install the codec
<Keybuk> we can't put the codecs in main because people in suits will take all our money away and put jdub in jail
<jdub> with elmo
<Keybuk> and he refuses to be elmo's bitch
<jdub> *REFUSE*
<jdub> watch me
* jdub works it.
<shackan> hahaha
<shackan> why did elmo go to jail ? :D
<jdub> he hasn't yet
<jdub> but you are suggesting he should
<shackan> !
<jdub> YOU WOULD PUT ELMO IN JAIL FOR A LITTLE MUSIC?
<shackan> argh, what have I done!
<sivang> Keybuk: LOLOL
<dholbach> good night everybody, i'll see you tomorrow
<mdz> Keybuk: I reproduced the mice bug
<mdz> Keybuk: with uber debugging enabled
<Keybuk> oooh, how reproducible?
<mdz> oh, not at all
<mdz> just happened once
<Keybuk> send your syslog :p
<mdz> but I had that extra udev logging of yours enabled, if that helps
<Keybuk> though I doubt it'll be interesting because I forgot to ask you to move syslog earlier into the boot sequence <g
* ogra apt-cache searhes uber-debugging
<mdz> Keybuk: sent
<\sh> who is iwj@ubuntu.com? 
<mdz> Keybuk: how much earlier?
<mdz> \sh: Diziet
<\sh> AH OK
<\sh> grmpf...caps lock
<mdz> heh
<Keybuk> mdz: from rc2.d/S20 to rcS.d/S20
<sivang> does anybody know how I can use my ubuntu.com email addres now being an approved memeber in launchpad having signed the CoC ?
<\sh> small keyboards...
<\sh> lpname@ubuntu.com..u have to wait until the cron job rund
<\sh> -d+s
<elmo> sivang: it should work already
<mdz> Keybuk: it's at rc2.d/S10 right now
* bddebian doesn't have a working @ubuntu.com address.. :-(
<mdz> anyhow, moved 
<mdz> I'll do some more rebooting
<Kamion> mdz: sorry, I was away having my evening ;-)
<Keybuk> right, but needs to be rcS.d so it's before /etc/modules is processed
<Kamion> mdz: and I'm off to bed now
<mdz> Kamion: night
<Kamion> I imagine the seed mirrors have updated by now
<\sh> how do i get a working pdf now from a ps output of firefox..
<mdz> Kamion: yeah, I uploaded -meta already 
<Kamion> ok
<\sh> ps2pdf doesn't work
<mdz> \sh: that works for most pages
<mdz> though not all
* Keybuk grabs some tea to drink while reading mdz's syslog
<\sh> mdz: but not bugzilla printer formatted pages
<mdz> Keybuk: it doesn't look very enlightening
<\sh> mdz: #15916
<\sh> mdz: and it's confusing, because in evolution e.g. u have the possibilty to print directly to pdf
<\sh> next to .ps
<ogra> mdz, eek
<ogra> mdz, removed xscreensaver-data ?
<mirak> honestly, does anyone manage to build packages with apt-build ?
<mdz> ogra: xscreensaver depends: xscreensaver-data
<mdz> ogra: or if it doesn't, I'd consider that a bug...
<mdz> I just put it back the way it was before
<ogra> i does phew
<ogra> soryy
<mirak> just wondering
<mirak> does apt-build is adapated to ubuntu or not ?
<mirak> I mean does the package management and naming in ubuntu can be a problem for apt-build ?
<\sh> ok..going to bed...
<\sh> good night gentlemen
<bddebian> Later \sh
<sivang> elmo: should it be like my irc name registered in launchapd? or what account does it use?
<ogra> night \sh
<elmo> sivang: what \sh said
<Keybuk> mdz: were the devices missing after the boot, or after the suspend/resume ?
<mdz> Keybuk: after the boot
<mdz> it may even have been the next-to-last boot actually
<tseng> mdz: bwar @ 6108
<tseng> mdz: i was about to give into you being a seperate bug, too.
<Keybuk> yeah there's not much there other than confirmation of the pattern of failure
<Keybuk> moving syslog to /etc/rcS.d/S20sysklogd would help for next time
<sivang> mdz: email sent, hope it's ok
<mdz> Keybuk: ok, just got it again
<mdz> Keybuk: was trying to replicate the conditions
<mdz> it was a boot-instead-of-resume after hibernating, so the filesystem was unclean etc.
<mdz> it just happened to be after a reboot -f into single-user
<mdz> which is what I did befor etoo
<Keybuk> wow, that was quick ;)
<Keybuk> randomly, you don't have a /dev/input/mice, but do have mousedev loaded?
<Keybuk> do you have a /dev/psaux ?
<mdz> Keybuk: sent new syslog
<mdz> and have the system in the broken state
<mdz> I am missing psaux as well, yes
<mdz> mousedev and psmouse are both loaded
<Keybuk> what is in /dev/input ?
<mdz> event[0-3] , mouse[01] , ts[01] 
<Keybuk> and in /sys/class/input ?
<mdz> same, but also with mice
<Keybuk> and cat /sys/class/input/mice/dev ?
<mdz> 13:63
<mdz> OUCH
<mdz> I thought it would be clever of me to tar up sysfs for further examination
<Keybuk> can you confirm that there's _not_ a /dev/.udevdb/class@input@mice file?
<mdz> that causes a nice kernel panic
<Keybuk> yeah, uh, don't do that
<mdz> no, I cannot confirm that
<Keybuk> kernel gets upset if you try and tar up its core state
<mdz> I killed it
<Keybuk> there's the memory maps of modules and shit in there (/sys/module/*/sections/*)
<dieman> hah
<dieman> nice
<mdz> I'd done that before without ill effects
<mdz> not for a while though
<Keybuk> it's at that kind of point I like to say "BENC!"
<mdz> Keybuk: has anyone checked to see if it's present in the initramfs /dev?
<Keybuk> mdz: the /dev is moved over these days, isn't it?
<mdz> Keybuk: yes
<Keybuk> if you gunzip|cpio -t your initrd.img, you shouldn't find mousedev in it
<mdz> I meant the "live" initramfs
<mdz> where udevstart has been run
<Keybuk> nope, didn't realise that you could still access that
<mdz> Keybuk: passing 'break' as a kernel parameter should give you a shell at precisely the right place
<Keybuk> interesting, worth a try
<mdz> ok, it's not there
<mdz> oh, mousedev isn't loaded there either
<mdz> only hci, storage and core
<mdz> nothing in /sys/class/input at all in initramfs
<Keybuk> yeah
<mdz> so by all indications rcS.d/S04udev sucks
<Keybuk> it shouldn't even be possible for those kernel modules to end up in your initramfs image, so if they got loaded there, strange things would be afoot
<Keybuk> actually, I don't think it's S:S04udev at all
<Keybuk> that's just supposed to copy over the initramfs /dev and fix it up
<mdz> should be plenty possible, by adding mousedev to mkinitramfs/modules
<Keybuk> it's when the first udevsend event occurs as a result of S:S20modules-init-tools that we have problems
<mdz> Keybuk: it doesn't copy it; initramfs does a mount -o move
<mdz> and then S04udev is supposed to just run udevstart
<Keybuk> right
<Keybuk> the second udevstart should just return having done nothing, and acts as a safety measure
<mdz> ah, right, so mice should be created by a hotplug/udevsend event
<mdz> as with all other random udev races, the obvious solution is to run udevstart in more places :-P
<Keybuk> just in case anything turned up in between initramfs and userspace
<Keybuk> Sep 20 14:42:53 (none) udev[5460] : udev.c: action, subsystem or devpath missing
<Keybuk> SCORE!
<mdz> oooh
<mdz> is that udevd or kernel's fault?
<Keybuk> the kernel's input subsystem doesn't do hotplug properly
<Keybuk> it's a known bug
#ubuntu-devel 2006-09-18
<jdub> tseng: apparently it's not in the desktop suite
<tseng> jdub: well, I know the reason its not there
<tseng> jdub: on that level.. any reason it shouldnt be promoted and in -desktop?
<jdub> not that i know of
<tseng> hm
<jdub> it's a pretty widely distributed chipset now
<tseng> its quite a pain getting networking up sometimes to install it
<tseng> depending on where you are
<tseng> for some reason dhclient isnt acking dchp offers for me atm
<tseng> (on the wire)
<tseng> gotta put in my long ass wepkey
<pygi> ho hi Keybuk 
<Keybuk> oh, that's good, firefox don't work *cry*
* Keybuk makes a mental note to kill iwj in the morning :p
<Keybuk> or at least hurt
<LaserJock> yeah, you want him to be able to recover and fix it ;-)
<Keybuk> yes, but I don't necessarily want him to live much longer afterwards
<Keybuk> lynx just isn't that useful for porn
<bddebian> Howdy folks
<Chipzz> Keybuk: my eyes bleed when I start firefox :(
<Keybuk> why?
<Keybuk> I just get a XUL/XML error
<Chipzz> some really sucky ui regressions
<Chipzz> remember the go button?
<Chipzz> not only is it a part of the url bar now, so it cannot be removed
<Chipzz> either you have both the url bar and the go button, or neither
<Chipzz> but it is also way to big
<Chipzz> the url bar takes less than 50% of the width now
<Chipzz> http://apocalypse.realroot.be/~chipzz/ff2beta.png
<Chipzz> which would be usefull to you if firefox actually worked for you ;)
<HrdwrBoB> you're right, it's massively large
<Keybuk> tried the usual crap like removing the profile and that didn't help either
<Chipzz> the search bar is also a big regression imo
<Keybuk> that looks more like a busted theme
<Chipzz> I only removed some buttons from the toolbar actually
<Chipzz> the rest is whatever ubuntu ships
<Chipzz> the backspace -> pageup instead of back is also very annoying
<Keybuk> did you update it?
<geser> Chipzz: are you using a theme from firefox-ubuntu-themes?
<Chipzz> chipzz@Reel:~$ dpkg --get-selections | grep firefox
<Chipzz> firefox                                         install
<Chipzz> firefox-gnome-support                           install
<Chipzz> firefox-themes-ubuntu                           install
<Chipzz> and I'm using whatever ubuntu has the user use as a theme for firefox with those packages installed
<geser> the problem with the themes is known as bug 60643
<Ubugtu> Malone bug 60643 in firefox-themes-ubuntu "[Edgy]  The "Go" button is much to wide when using Firefox 2.0b2" [Untriaged,Confirmed]  http://launchpad.net/bugs/60643
<Chipzz> at the rate this is going I'm considering downgrading firefox to the 1.5 version and putting it on hold permanently
<Keybuk> oh, that's weird
<Keybuk> it's not just evo doing the "folder display|..." thing
<Keybuk> totem is doing "short time format|..."
<bddebian> Keybuk!!
<bddebian> You probably know
<bddebian> Are we supposed to be including .la files any longer or not?
<Keybuk> yes
<bddebian> Crap.  I swore I heard that we were not
<Keybuk> there are differing opinions on this
<Keybuk> some people are wrong
<bddebian> Gah
* bddebian just turns in his "badge"
<Keybuk> lol
<Keybuk> why?
<bddebian> Because I suck?
<Keybuk> why do you suck?
<bddebian> Because I'm stupid?
<Keybuk> why are you stupid?
<Keybuk> you seem perfectly able to me
<LaserJock> mhm
<bddebian> Keybuk: Well now obviously you are now uninformed ;-)
<Keybuk> I'm sure the person who told you was someone like seb128
<Keybuk> who is firmly in the anti-libtool brigade
<jdub> heh
<Keybuk> the basic problem is that they cause bugs to show up
<Keybuk> which seb would rather sweep under the carpet and pretend were somebody else's problem
<Keybuk> :p
<jdub> like, say, YOURS
<bddebian> By including them or not including them?
<Keybuk> including them
<Keybuk> mine?
<jdub> your problem!
<Keybuk> what's my problem?
<jdub> seb's under-carpet mess
<Keybuk> I haven't maintained Libtool for a couple of years
<Keybuk> seb's mess shows up in other places
* ajmitch starts hating initramfs again
<Keybuk> like the other day when symbols mysteriously vanished from a library without a SONAME bump
<Keybuk> which he still claims wasn't an ABI change :p
<bddebian> You folks keep confusing my dumb ass :-)
<lifeless> thats so an ABI change
<tseng> bddebian: oh stop
<bod> any ubuntu sysadmins about?
<jdub> sure
<bod> need to see what's wrong with optus@syncproxy.ubuntu.com, the password no longer seems to work
<zul> isit just me or is the wiki slow?
<zul> hey spaz
<jdong> zul: yeah, the wiki's been slow recently
<Seveas> bod, #ubuntu-mirrors (usually they're there at non-insane UTC+1 hours)
<jdong> why is gnome-power-manager all of a sudden pulling numbers out of its ass?
<Seveas> because it can find no useful numbers?
<jdong> well, it used to do everything right
<jdong> now, it's pulling percentages and times out of it ass
<jdong> look! I have 18 hours of battery life left!
<jdong> 75%
<jdub> bod: ah, i was thinking "admins of ubuntu-based systems" ;-)
<jdong> while acpi -V tells me I have 35 minutes / 15% left
<jdub> bod: you can use the mailing list too
<jdong> now, I consider that pulling numbers out of its ass
<Seveas> jdub, shouldn't you be on your way to brussels? 
<Seveas> jdong, woah, I want a battery with 18h lifetime!
<Seveas> preferably if it weighs less than a metric shitload
<jdong> Seveas: yeah, gnome-power-manager is really trying to tease me on this one :)
<jdub> Seveas: unfortunately for various reasons, i won't be there
<Seveas> jdub, dang!
* jdong files bug on launchpad
<bddebian> We need an all doko all the time channel :-)
<Seveas> heh
<jdong> aha! the bullshit originates from HAL :)
<Seveas> jdong, excellent quote to take out of context
<jdong> Seveas: hehe....
<fabbione> slomo: ping?
<fabbione> jdub: ping?
<jdub> fabbione: pong
<fabbione> jdub: can you test a fixed mdadm for me?
<jdub> sure
<fabbione> ok
<fabbione> one sec that i am building it
<keescook> fabbione: what's been fixed in mdadm?
<HrdwrBoB> keescook: it wanted to stop arrays on upgrade
<fabbione> and it needs to kick an initramfs update
<keescook> ah-ha, cool.
<fabbione> jdub: people.u.c/~fabbione/mdadm_2.4.1-6ubuntu3_i386.deb
<jdub> man, initramfs build takes ages these days
<jdub> fabbione: !!!1111
<jdub> fabbione: it installed! :)
* ajmitch needs to test this..
<jdub> also, i'm getting this during initramfs builds atm:
<jdub> cpio: ./sbin/vgchange: No such file or directory
<jdub> i'll file
<fabbione> i didn't get that
<fabbione> Setting up mdadm (2.4.1-6ubuntu3) ...
<fabbione> update-initramfs: Generating /boot/initrd.img-2.6.17-7-generic
<fabbione>  * Starting RAID monitoring service mdadm --monitor                                                                                 [ ok ]  
<fabbione> that's about it
<fabbione> can you check if that symlink actually exists on your system
<fabbione> bah feh
<fabbione> that comes from lvm
<infinity> Yeah.
<fabbione> do you have lvm2 installed?
<jdub> fabbione: you probably have lvm installed
<jdub> no
<fabbione> iz not a buf
<fabbione> bug
<jdub> it is a minor issue ;)
<fabbione> and it's not an md issue
<infinity> jdub: Can you trace through and find what's trying to copy it?
<jdub> yeah
<infinity> jdub: That was specifically hacked around in dapper, I'm trying to find if someone dropped my change.
<jdub> it's now #60996
<infinity> jdub: initramfs-tools itself doesn't copy vgchange anywhere anymore.
<infinity> jdub: So, can you rgrep through /usr/share/initramfs-tools and /etc/initramfs-tools for the offending string?
<jdub> oh
<jdub> i was just sh -x ing it
<jdub> $ grep -rl vgchange /usr/share/initramfs-tools /etc/initramfs-tools
<jdub> /usr/share/initramfs-tools/scripts/local-top/lvm
<jdub> /usr/share/initramfs-tools/hooks/lvm
<infinity> jdub: Right, and we don't ship either of those.
<fabbione> so you have lvm partially installed
<fabbione> infinity: we do in lvm
<infinity> Oh, lvm-common ships those.
<jdub> it's the latter
<infinity> if [ ! -x /sbin/vgchange -a ! -d /lib/lvm-200 ] ; then
<jdub> which is installed!
<infinity>         exit 0
<infinity> fi
<infinity> Clearly, that's not tripping.
<jdub> and i can remove it
<infinity> Yeah, I don't want you to remove it.
<infinity> This should work.
<fabbione> infinity: want to take care of it?
<fabbione> or should i?
<fabbione> but for me removing lvm is not an option
<infinity> I'm removing lvm right now. :)
<fabbione>  /dev/mapper/gordian-root on / type ext3 (rw,data=ordered)
<fabbione> thanks :)
<jdub> yeah, i'll only remove it after testing this
<infinity> jdub: What's responsible for /lib/lvm-200 existing on your system?
<infinity> jdub: When I remove lvm2, it's completely gone.
<jdub> it's not
<jdub> but
<jdub> this is interesting
<jdub> $ ls /sbin/vgchange
<jdub> lrwxrwxrwx 1 root root 13 2005-09-17 08:17 /sbin/vgchange -> lvmiopversion
<infinity> Yeah, that's correct.
<jdub> alternatives?
<fabbione> no
<fabbione> all lvm calls are calling the same binary
<infinity> No, not an alternative.
<jdub> ah
<infinity> lvm is thpethial.
<fabbione> lvm decides how it has been called from $0
<fabbione> lvm binary is like a shell
<infinity> And lvm-common ships a wrapper binary to auto-select lvm10 versus lvm2
<jdub> $ if [ ! -x /sbin/vgchange -a ! -d /lib/lvm-200 ] ; then echo pants; fi; echo $?
<fabbione> try to invoke lvm alone and you get the same set of commands
<jdub> 0
<infinity> jdub: Err, wait.  No pants?
<jdub> no pants man. the way it ought to be. except in this case.
<infinity> jdub: Oh, crap.  Yes, I can reproduce.
<infinity> jdub: I'll dig.
<fabbione> dash'ism?
<fabbione> bashism?
<infinity> Oh, duh.
<infinity> '-a' is a bashism.
<infinity> Thanks, Fabio.
* infinity fixes.
<jdub> ]  && {
<jdub> well
<jdub> without the typo
<jdub> rad
* infinity needs to change his login shell to dash for this reason.
* jdub updates bug
<infinity> Also, that was always wrong anyway..
<infinity> That should be an OR, not an AND...
<pitti> Good morning
<ajmitch> hi pitti 
<fabbione> hey pitti
<Hobbsee> hey pitti!
<pitti> hey ajmitch
* pitti hugs Hobbsee, fabbione, and ajmitch 
<Hobbsee> ooh, group hug.  dont let me get squished :P
* Hobbsee pictures herself being hugged by giants
<fabbione> Hobbsee: did you ever file a bug for that ubuntulog thingy?
* pitti is 1.86m, hardly a giant :)
<fabbione> pitti: that's because you are skinny :)
<Hobbsee> fabbione: no, it's on my mental to-do list, or just to bug you when you had stopped talking
<Hobbsee> hah
<fabbione> pitti: take my 1.82 and add the power of the size :P
<keescook> hiya pitti
<pitti> hi keescook, how are you?
* pitti waves to slomo 
<keescook> great! you?  I was just digging around in malone, and thought I'd build a fix for the clamav cve...
<keescook> the control file reverted the Standards-Version from 3.7.0 to 3.6.2, and I don't know why... :P
<Burgundavia> whiprush: http://ubuntuforums.org/showthread.php?t=259210
* ajmitch was reading that one just a few minutes ago
<whiprush> looking
<Burgundavia> ajmitch: you had better be at Mountainview
<ajmitch> Burgundavia: unlikely, it'd require sponsorship
<whiprush> wasabi left a good comment on my blog post yesterday about this stuff.
* ajmitch rereads the blog
<pitti> keescook: some buglet introduced by merging; feel free to revert
<keescook> pitti: yeah, sorta dropped that part of the debdiff (see bug 59915)
<Ubugtu> Malone bug 59915 in clamav "clamav in dapper vulnerable to critical heap overflow" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59915
<ajmitch> whiprush: yeah, I should make some notes on that stuff..
<pitti> keescook: apart from the version number, this looks good
<ajmitch> like I have the code for getting the info from SRV records, etc
<keescook> pitti: what should the version number be? 1.1 instead of 2?
<pitti> keescook: exactly
<Burgundavia> whiprush: holy crap "In order to address this gap, Red Hat, Novell, Ubuntu and others must work together. It will require a concentrated combined effort that draws together expertise from a wide variety of sources. That way, Linux application developers could work with a standardardized but modularized tool.," Ted Haeger
<whiprush> ajmitch: I am going to start speccing some of the other stuff
<pitti> keescook: also, can you please state the origin of the patch in the changelog?
<Burgundavia> ok, ted is bloody brilliant
<keescook> pitti: okay, adjusting
<pitti> keescook: (upstream cvs, other distro, some other bug report, etc)
<ajmitch> whiprush: yeah, I'd love to sit down with you & some beers :)
<whiprush> put in for sponsorship, you never know. *shrug*
<ajmitch> whiprush: written my name down
<whiprush> sweet
<pitti> keescook: building coreutils now, btw
<keescook> pitti: okay, cool.  FYI, I needed to give debuild -e SHELL to pass the weird dircolors test.
<keescook> pitti: is "Patch from upstream version 0.88.4." sufficient, or should I be even more explicit?
<pitti> keescook: that's fine
<pitti> keescook: just that we can track whether we invented it ourselves, or where it came from
<ajmitch> whiprush: I'd love to spec out some of the desktop love that's needed soon
<pitti> keescook: e. g. sometimes we take them from fedora bug report attachments, etc
<ajmitch> pitti: we'll probably want new libpam-{krb5,heimdal} to go along with krb5, I'll file for syncs later tonight
<pitti> ajmitch: I only requested a sync for the security update, it shouldn't change any API/ABI?
<ajmitch> it shouldn't, but I still want them :)
<ajmitch> seeing the bug just reminded me of it
<pitti> ok, so it doesn't need coordination
<ajmitch> oh, and I uploaded libgphoto2 without libhal-dev change, in case you get a flood of bugs :)
<keescook> pitti: okay, 59915 has been updated with a better debdiff.
* ajmitch hasn't seen any new gphoto-related bugs so far though
<pitti> keescook: thanks; will upload today
<Burgundavia> whiprush: another interesting piece for today, via planet gentoo: http://blog.stuartherbert.com/gentoo.php/2006/09/17/are_we_on_the_rpath
<keescook> pitti: I emailed you a "details" section for clamav, I'm off to bed.  :)  
<pitti> keescook: thanks; sleep well!
<pitti> keescook: oh, a minute please
<keescook> yup, still here
<dholbach> good morning
<poningru> dholbach: saw your hackergotchi in a magazine couple of days ago
<pitti> hey dholbach 
<dholbach> heya pitti - hey poningru
<dholbach> poningru: which one was that?
<dholbach> poningru: linux format something?
<dholbach> hey slomo
<poningru> yeah linux format
<poningru> http://www.flickr.com/photos/puggles/244944977/
<poningru> that shows the magazine cover
<dholbach> they wrote "dan holbach"
<dholbach> nobody on earth calls me "dan", but anyway - i got my "best bits" coverd - LOL! :)
<dholbach> (it said "dan's best bits" above a tiny piece of text they quoted me on)
<dholbach> btw. Happy REVU day!
* jdub hugs marilize 
* dholbach hugs jdub and marilize
* marilize hugs jdub and dholbach!
* desrt pushes jdub to hug dholbach 
* desrt stays away from the whole mess
<ajmitch> desrt: you know you want a group hug
<ajmitch> hi Kamion 
<Kamion> morning
<pitti> Hi Kamion 
<dholbach> hi Kamion
<carlos> pitti: morning
<pitti> hi carlos 
<carlos> pitti: so, what should I do with dapper lang packs? touch those .po files?
<carlos> or will you use the tarball I gave you?
<pitti> carlos: if you can, yes; as I said, otherwise I need to hack my scripts to incorporate them at every build, but that's not going to be very robust
<carlos> ok, I will do it then
<pitti> carlos: don't you have access to the db to touch the timestamps of the affected packages with a script?
<carlos> did you upload a new lang pack for dapper already?
<pitti> carlos: I must not upload to *-updates ATM
<carlos> pitti: yeah, but that changes some metadata, that's why I tried to find another solution
<carlos> pitti: ok
<fabbione> ok.. let's give a shot to d-i on sparc
<pitti> fabbione: (I don't know what you are up to, but I did not release the new kernel to the official archive yet)
<fabbione> pitti: yes i am aware of that. the problem arise once we delete the old ABI kernel from the archive
<fabbione> pitti: at that point d-i netboot/netinstall won't be able to fetch the udeb
<fabbione> and so it needs to be updated
<pitti> yes
<fabbione> for the old releases we didn't really care
<fabbione> but now we do support a netboot/netinstall only machine
<fabbione> and we care
<fabbione> anyway there is no hurry
<fabbione> untill there is the old kernel everything is good
<dholbach> weird, LP says that pilot-link 0.12.1-3 has built on all arches (2 days ago), it has no new binary packges, but is not in the archive yet
<infinity> dholbach: Let me look around.
<dholbach> infinity: thank you
<infinity> It was accepted...
<infinity>          | N libpisock9/0.12.1-3/i386 Component: main Section: libs Priority: OPTIONAL
<infinity> SONAME bump?
<infinity> Indeed.
<infinity> dholbach: It was binary NEW.  SONAME bump.
<infinity> dholbach: Check "apt-cache rdepends libpisock8"... Are you ready to upload to rebuild all of those after I pass this through NEW?
<dholbach> oh?
<dholbach> happy to do so
<infinity> Alright.  I'll process it now, then.
<dholbach> thank a lot!
<dholbach> gnome-pilot{,-conduits} should be done soon, I'll look after the others
<infinity> Alright.  Processed and accepted.
<infinity> Thank you for shopping at #ubuntu-devel.  Please, come again.
* dholbach hugs infinity
<dholbach> woohoo, knot-3 in the news: http://www.golem.de/0609/47851.html
<seb128> rock :)
<HiddenWolf> dholbach: nice article. :)
<cbx33> hi sladen 
<sladen> seems NickServ ate my instructions to sivang for finding my house!
<StevenK> sladen: Hopefully, you can remember how to get to your house.
<popey> lo cbx33 
<cbx33> hi popey 
<cbx33> how are you?
<slomo> fabbione: pong
<fabbione> slomo: do I remember right that you were pinging me for mono on sparc?
<fabbione> mvo: hey dude
<fabbione> mvo: could you be so kind to fix bug 59403 ?
<Ubugtu> Malone bug 59403 in gnome-app-install "g-a-i postinst fails if X is not running" [Critical,Needs info]  http://launchpad.net/bugs/59403
<slomo> fabbione: yes... but the build failure happened only the first time... the 3 uploads afterwards worked fine although nothing sparc specific was changed ;)
<fabbione> slomo: ok perfect. it was probably a kernel/toolchain issue that has been fixed
<slomo> fabbione: maybe... but the second upload was only a few hours later :) well, let's hope it never shows up again
<fabbione> hmm ok
<mvo> fabbione: having a look now
<fabbione> mvo: thanks
<pitti> aah, mvo, good morning
<mvo> hey pitti
<dholbach> heya mvo
<jordi> mvo: AHA
<jordi> mvo: finally!
<jordi> mvo: where doyou get the po files for the "Package Descriptions" product?
<mvo> jordi: hello!
<mvo> jordi: https://launchpad.net/products/ddtp-ubuntu/+translations
<jordi> mvo: okay
<jordi> mvo: where did a "go.po" come from then?
<mvo> jordi: probably from debian, I importet the current state of the debian translations
<mvo> jordi: (from ddtp.debian.net)
<jordi> what is "go"? There are several broken files in there: km_KH, pl_PL, go
<jordi> mvo: oh I see.
<jordi> I'll ping bubulle then
<mvo> jordi: where is this go.po? I can't find it now
<jordi> https://launchpad.net/rosetta/imports?target=products&status=NEEDS_REVIEW&type=all
<jordi> heh
<jordi> empty fil
<jordi> +e
<mvo> jordi: uh, I see. what will rosetta do with them? it looks like my script can produce them
<mvo> jordi: if this is a problem, I can fix it
<jordi> mvo: rosetta doesn't know what to do
<jordi> so I can either delete them or block them
<mvo> jordi: just delete them, I will add more logic to my script to make sure it does not produce empty files
<jordi> ok
<mvo> fabbione: in bug #59403, do you have DISPLAY set at all?
<Ubugtu> Malone bug 59403 in gnome-app-install "g-a-i postinst fails if X is not running" [Critical,Needs info]  http://launchpad.net/bugs/59403
<fabbione> mvo: no, it's not set..
<fabbione> mvo: no more no less like when you login as root on console
<fabbione> DISPLAY=""
<jordi> mvo: what about the dupes? pl_PL vs pl
<jordi> oh, empty files as well
<mvo> fabbione: at least the later version of gtk can deal with this and won't die
<fabbione> mvo: ok..
<mvo> jordi: I guess that comes from inconsitency between rosetta and ddtp.d.o. rosetta always uses the full name and ddtp almost always the short language code
<mvo> jordi: I have seen this for other translations as well (people translating pl and pl_PL independently)
<mvo> jordi: (in the past)
<kagou> iwj, i'v always bug in fontconfig-config
<Tonio__> hi
<jordi> mvo: it's bad
<mvo> jordi: I totally agree. so what can we do :) ?
<jordi> mvo: rosetta did, in the past. Not anymore
<jordi> or it shouldn't.
<jordi> that's why I'm nagging here :P
<mvo> jordi: so what can I do? rename them all from pl -> pl_PL (etc) ?
<jordi> if it's safe, yeah: ie, not both of them exist
<jordi> if there's a conflict like sv vs sv_SE, I guess we need bubulle
<kagou> iwj, i talk about Bug #56682
<Ubugtu> Malone bug 56682 in fontconfig "Raster fonts appear in Edgy" [Medium,In progress]  http://launchpad.net/bugs/56682
<mvo> jordi: some of the conflicts are probably due to the fact that I imported them as they where (e.g. sv) and that then some people started to translate them in rosetta and created sv_SE along the way). does that make sense?
<jordi> not really
<jordi> because the sv_SE file was uploaded by you, ie, it's one of the initial files
<jordi> sv_SE.po in Package Descriptions for Ubuntu Series: ubuntu   	 	 [Edit] 
<jordi> Uploaded by Michael Vogt on 2006-08-08 18:33:23 CEST
<iwj> kagou: Hi.
<mvo> jordi: its not on ddtp.debian.net though, so probably my bad somehow
<jordi> mvo: weird
<jordi> mvo: killing it
<kagou> hey iwj :)
<mvo> jordi: thanks, I will investigate
<iwj> kagou: Can you say   echo 'get fontconfig/enable_bitmaps' |debconf-communicate
<iwj> and tell me what it says ?
<kagou> iwj, one minut, i power on my notebook, cause i'v do some hacking on fontconfig here ;)
<iwj> Right ...
<kagou> iwj,  said : 0 true
<iwj> And you did dpkg-reconfigure after installing 2.3.2-7ubuntu2 ?
<kagou> iwj, i think not
<kagou> but i'm not sure now, cause i'v did many things since
<iwj> Hmm.
<iwj> Well, you have 2.3.2-7ubuntu2 (or something later) now, right ?  And does dpkg-reconfigure --default-priority fontconfig-config  fix it ?
<iwj> You'll have to reinstall the .deb too.
<iwj> (Maybe.)
<iwj> Morning sabdfl.
<sabdfl> hi folks
<ajmitch> hi sabdfl 
<sabdfl> evening ajmitch
<kagou> iwj, no. doing dpkg-reconfig --default-priority create 30-debconf-yes ... in all case
<pitti> hey sabdfl
<kagou> hi sabdfl 
<fabbione> hey sabdfl 
<kagou> iwj, by "in all cases" i mean that if i already have a "30-debconf-yes..." OR NOT doing reconfigure create it
<iwj> For me, it always recreates 30-debconf-no-...
<iwj> Can you email me copies of your /var/lib/dpkg/info/fontconfig-config.config and .postinst ?
<iwj> iwj@ubuntu.com
<iwj> This is very mysterious.
* pitti wonders why his built source packages suddenly get wrong .dsc md5sums all over the place
<iwj> Oh, I'm misunderstanding what dpkg-reconfigure does.
<iwj> pitti: Freaky.  You must have a virus.
<pitti> iwj: sometimes it works, sometimes not. Smells like a race condition
<kagou> iwj, done
<kagou> iwj, have "db_input mpw fontconfig/enable_bitmaps || true" in .config may be it's the problem ?!
<kagou> sorry -> have "db_input low fontconfig/enable_bitmaps || true" in .config may be it's the problem ?!
<imbrandon> moins sabdfl and Keybuk 
<iwj> kagou: No, that's normal and just causes the question to (perhaps) be asked.
<Tonio_> imbrandon: gwenview builds, I'm writing main inclusion report now
<imbrandon> umm a UVFe you mean ;)
<Keybuk> mvo: do you have ubuntu-minimal installed?
<Tonio_> imbrandon: just woke up, forget this ;)
<mvo> Keybuk: yes
<Tonio_> Keybuk: yep
<seb128> carlos: around?
<mvo> Keybuk: everything up-to-date etc
<mvo> Keybuk: how can I turn it into debug mode? 
<carlos> seb128: hi
<seb128> hey carlos
<Keybuk> mvo: boot with --debug
<seb128> carlos: how do I know when the template for a package has been imported to rosetta, from what version of the source package it's coming?
<mvo> Keybuk: I also did not get any checkrootfs messages on a different machine
<Keybuk> mvo: that's a different bug
<carlos> seb128: I don't have that information stored, but I can give you the date when the POT was generated
<mvo> Keybuk: init=/sbin/init --debug? 
<seb128> carlos: I'm wondering what version of gtk+2.0 src package for gtk20
<carlos> seb128: and once I fix some permissions issues, you should be able to see it tooo
<Keybuk> mvo: yes
<seb128> carlos: would be nice, thank you
<carlos> seb128: we are a bit behind on those, I'm approving them atm, we still don't support paths with the version of the release
<carlos> so we need to approve them manually
<seb128> carlos: it's about https://launchpad.net/distros/ubuntu/+source/gtk+2.0/+bug/60614 in fact
<Ubugtu> Malone bug 60614 in gtk+2.0 "Wrong string in gtk20 po file" [Untriaged,Needs info]  
<mvo> Keybuk: ok, thanks! I do this now and let you know the results
<Keybuk> mvo: ok, I've got to pop out for a quick bit -- will be back soon
<mvo> Keybuk: ok
* mvo reboots to have a word with upstart
<jsgotangco> its fast for sure
<iwj> kagou: Well, I have done a lot of experiments and I have concluded: 1. purging fontconfig-config and reinstalling it restores everything to normality as expected (dpkg --purge --force-depends; dpkg -i);  2. It is possible to fix it with  echo PURGE | debconf-communicate fontconfig-config   and then   dpkg-reconfigure --default-priority fontconfig-config   3. I don't understand debconf properly.
<iwj> Nevertheless I'm convinced that new installs will be correct.
<iwj> And upgrades from dapper should be good too.
<seb128> carlos: thank you for updating the bug and reassigning
<carlos> seb128: you are welcome
<kagou> iwj, i will do fresh install with the daily iso tommorrow
<seb128> carlos: did you figure from when is the current template? just curious about it :p
<iwj> Thanks.
<kagou> iwj, your welcome
<iwj> If you want your own install fixed, I suggest the purge/reinstall.
<kagou> iwj, i test this. thanks
<iwj> If that doesn't work please let me know :-).
<kagou> =)
<carlos> seb128: well, when you pinged me, I think a new .pot file was imported already
<carlos> what's current version?
<carlos> in edgy
<seb128> 2.10.3
<carlos> seb128: ok, then I think it was 2.10.0 (same problem with glib)
<seb128> carlos: ok, that explains the mismatch with upstream then, it has been changed for 2.10.2
<kagou> iwj, it's working
<thom> hrm, firefox beta2 seems much less stable for me :(
<jsgotangco> yeah
<iwj> kagou: *phew*  Thanks for your help and sorry for the run-around.
<Tonio_> pitti: ping ?
<mvo> Keybuk: sorry for the noise, it seems my laptop problem was just a "can't see messages from fsck" problem. 
* StevenK would be interested to find out how much quicker upstart makes startup and shutdown.
<Treenaks> I think I might have set a new record..
<Treenaks> 13784 mstreek   22   5 1804m 1.6g  536 D    0 80.7   0:09.45 objcopy                                
<ajmitch> Treenaks: not bad
<Treenaks> ajmitch: that's firefox + java + crash
<ajmitch> yeah, I had firefox using 1.0GB RSS
<kagou> iwj, in fact i will test fresh daily iso installation, when they will be available again ;)
<ajmitch> so you have me beaten
<ajmitch> I didn't get to use java though :)
<StevenK> My firefox is a wimpy 300Mb
<giftnudel> hmm, i had eclipse with 8xx ... ;)
<Treenaks> ajmitch: this is apport's objcopy...
<StevenK> However, Quod Libet is 400.
<Treenaks> and now I ahve to reboot (OOPS)
<Treenaks> brb
<ajmitch> ouch
<Fujitsu> ajmitch, it has a habit of doing that.
<iwj> kagou: *snort*
<iwj> IBM updated the bios in my laptop and now usplash works.  Oh well, so much for that prospective bug report.
<kagou> sorry iwj , what is *snort* :)
<iwj> It's a short nasal kind of laugh.  gnrgkl or some such.
<kagou> ok :p
<iwj> nasal/guttural.
<jdub> it's what iwj does when your joke isn't funny enough for a laugh
<iwj> ROTFL
<jdub> unlike that one! score!
<Fujitsu> Hey jdub :)
<crispin> pitti: any thoughts on where to do with my tracking down of the race in bug #55809 ?
<Ubugtu> Malone bug 55809 in hal "HAL changes wireless interface (net.80211) to wired (net.80203) in info.category after suspend" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/55809
<Kamion> kagou: (I just turned the cron jobs back on)
<Kamion> (for cdimage)
<kagou> Kamion, nice ! thanks
<Treenaks> ok.. my Nvidia + usplash = broken output; that + fsck = 'WTF isn't my machine booting?!?'
<Fujitsu> Treenaks, you can't see fsck output anyway, with upstart.
<HiddenWolf> Treenaks: +1 on that one
<Keybuk> mvo: ah ok
<mvo> Keybuk: what needs to be done to get the checkfs messages to the terminal?
<Keybuk> mvo: need to modify the checkfs script somehow
<Keybuk> it should also send them to uslash, you see
<Fujitsu> Keybuk, that'd be good.
* StevenK peers at python-gtk2
<fabbione> Treenaks: same reason i was offline 3 hours yesterday
<fabbione> Treenaks: couldn't figure out why my machine did hang at boot (HI SCOTT!)
<Keybuk> hmm?
<Fujitsu> fabbione, that's got me a few times, but then I noticed the HDD access.
<fabbione> Keybuk: no fsck output to usplash or no output at all...
<Fujitsu> Keybuk, fsck isn't visible at boot any more. Confuses everybody.
<seb128> StevenK: ?
<Keybuk> fabbione: blah blah blah
<fabbione> Fujitsu: i don't have such luxury.. the 700GB raid was on another controller with no led
<fabbione> Keybuk: ;)
<StevenK> seb128: Ahh ha, someone to help.
<Fujitsu> Hahahah.
<fabbione> Keybuk: i didn't yell at you.. come on.. it was sunday ;)
* fabbione hugs Keybuk 
<StevenK> seb128: http://librarian.launchpad.net/4295062/buildlog_ubuntu-edgy-amd64.diacanvas2_0.14.4-3_FAILEDTOBUILD.txt.gz
<seb128> StevenK: https://launchpad.net/distros/ubuntu/+source/pygobject/+bug/57182
<Ubugtu> Malone bug 57182 in pygobject "Problem importing codegen from desextras" [Medium,Confirmed]  
<StevenK> Ah ha!
<seb128> StevenK: thank you for working on it ;)
<ajmitch> great to have willing volunteers, isn't it?
<seb128> exactly!
<seb128> :)
* StevenK notices he has something more pressing to do.
<StevenK> :-P
<Fujitsu> Hey, there are a few bugs blocked on that.
<StevenK> Fujitsu: Feel free to help.
<Fujitsu> I've got no idea about it :P
<ajmitch> wasn't bddebian looking into that?
<StevenK> Fujitsu: You mean you don't know Python? :-P
<Fujitsu> StevenK, I know Python quite well.
<StevenK> Right. There's a problem in pygobject, and another in diacanvas2
<pitti> Tonio_: pong
<pitti> crispin: not yet, sorry
<Fujitsu> diacanvas2's is easy to fix, but I'm not sure about pygobject's.
<StevenK> Yes, diacanvas2's is fix the override file
<StevenK> Hah, and now that I fix the override file.
<StevenK> ERROR: Could not find a recent version of pygtk.
<StevenK> Oh wait, for python2.5
<Fujitsu> Yes, it does that.
<StevenK> Right, fixed it.
<StevenK> Do we care that we don't have a 2.5 version of diacanvas2?
<Fujitsu> The whole thing?
<Fujitsu> Until we get pygtk for 2.5, I don't think so.
<StevenK> With a bit of work, I can produce a patch for diacanvas2, and also one for pygobject
<seb128> Fujitsu, StevenK: somebody should probably forward the pygobject issue upstream
<Fujitsu> Probably, yes...
* Fujitsu looks for upstream.
<Fujitsu> Ah.
<Fujitsu> Part of pyGTK, of course.
* StevenK nods.
<StevenK> seb128: Sure, but we should be selfish and fix our version first?
<mvo> Keybuk: one more question about upstart. I just switched to my terminal from X with C-A-F1 and did some stuff in the shell, then loged out (CTRL-D) again. now I can't type anything anymore and ALT-Fn is no longer working. could this be releated to upstart?
<StevenK> s/\(we\) \(should\)/\2 \1/
<Fujitsu> StevenK, we've got universe freeze shortly, so I presume so.
<seb128> StevenK: why not working with upstream, they might be useful and fix it faster the we do :p
<StevenK> Fujitsu: pygobject is in man
<StevenK> Um
<StevenK> main
<Fujitsu> Hm.
<Fujitsu> So it is.
<StevenK> seb128: Oh, I know why.
<seb128> why what?
<StevenK> seb128: Because that involves touching bugzilla.
<Fujitsu> StevenK, urgh.
<StevenK> And dun wanna, icky
<seb128> StevenK: such comment are not really useful ...
<Fujitsu> I'd say bug #60583 was a dupe...
<Ubugtu> Malone bug 60583 in gst-python "FTBFS: RuntimeError: Function gst_pad_get_negotiated_caps is being overridden more than once" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60583
<seb128> no
<seb128> that one looks a python2.5 being stricter
<StevenK> seb128: True, but I like whinging.
* StevenK creates a Gnome bugzilla account.
<Keybuk> mvo: I don't think so ...
<Keybuk> Alt-Fn not working implies the kernel has panic'd ?
<Fujitsu> Of course, Launchpad was designed to prevent this sort of business.
<StevenK> I can't see Launchpad logging into Gnome's bugzilla and creating a report for me. :-P
<mvo> Keybuk: no, I just can't use ALT-F1,2,3 etc. strnage enough, CTRL-ALT-F7 brings me back to X (and C-A-Fn works as well)
<ajmitch> StevenK: magic
<mvo> Keybuk: and only after I logout of one terminal with CTRL-D
<StevenK> ajmitch: Heh
<Keybuk> mvo: does that getty not respawn?
<mvo> Keybuk: it does. maybe just something entirely different.
<Keybuk> hmm?
<zul> hello
<ajmitch> hey zul 
<Keybuk> so after the getty dies, the new one spawns, but you can't type into it?
<mvo> Keybuk: yes. but apparently I can not reproduce it all the time :( 
<hunger> How do I configure my console keymap to use a layout available in my X setup but which is not part of ubuntu?
<pitti> fabbione: do you have an idea why so many packages still depend on libgnutls12 on sparc? all other main arches don't have any dependency on it any more in main
<Keybuk> mvo: odd, let me see here
<Keybuk> the fact your keyboard goes away is a little strange
<fabbione> pitti: no i don't check these kind of things...
<fabbione> pitti: do you know what pkgs are?
<mvo> Keybuk: I had this two time now, since the weekend (when I upgraded this machine), but it might as well be some X problem or something
<pitti> fabbione: yes, a minute
<hunger> Is console-setup known to crash the X server by the way?
<fabbione> pitti: also.. when we did switch version, did you also add a versione B-D ?
<fabbione> versioned even
<pitti> fabbione: http://pastebin.ca/174992
<fabbione> if not, you might have uploaded the other packages in a limbo state when gnutls13 was not yet available for sparc
<Keybuk> mvo: yeah, I would suspect X or console-setup to be likely ... as they actually do things with the keyboard
<Keybuk> I took the "reset the console" code out of upstart
<pitti> fabbione: hm, we switched version almost two months ago
<mvo> Keybuk: ok, thanks!
<fabbione> pitti: have been these pkgs rebuilt since? are the binaries in the archive?.
<pitti> fabbione: for most packages I didn't bother to actively transition them, it just happened over time
<pitti> fabbione: I just cleared the last four some days ago
<fabbione> pitti:  i don't know.. this is something you need to clear with infinity and LP.
<pitti> fabbione: libgnutls-dev_1.4.0-3_sparc.deb     04-Jul-2006 21:18  359K
<pitti> fabbione: ok, I'll ask infinity 
<fabbione> pitti: it's much easier for infinity to check what went wrong than for me
<fabbione> he has access to all infrastructure
<fabbione> while i would have to do everything manually
<pitti> fabbione: ok, I just wanted to know whether there was a specific issue with 13 I didn't know about
<pitti> fabbione: thanks
<fabbione> i only heard about the transition a few days back at the meeting
<fabbione> and wasn't able to check much for the past weeks
<pitti> fabbione: do we have a sparc developer box in the DC with a current edgy chroot?
<fabbione> faure.ubuntu.com
<pitti> ah, nice
<fabbione> it's always been there since.. dapper
<pitti> fabbione: yeah, sorry, I don't deal with it much, so I forgot
<fabbione> pitti: you lazy boy :P
<pitti> fabbione: feh, it seems that just the sparc mirror on rookery is out of date
* fabbione will stay silent
<pitti> fabbione: ah, it appears in anastacia as it should be
<fabbione> #!@!!!!!!
<pitti> fabbione: sorry, dude, up to a few weeks ago the mirror was just fine
<administrator> how do you undone /ignore?
<fabbione> don't worry
<administrator> undo*
* pitti RTs
<pitti> Keybuk: can you please demote gnutls12, just to be sure no main package will pick it up again?
<Keybuk> done
* pitti hugs Keybuk 
<Keybuk> odd, X crashed
<Mithrandir> Kamion: https://launchpad.net/distros/ubuntu/+source/xorg-server/+bug/58016 ; this looks like a bad xkeyboard-config default, but is it correct that live keys would be preferred in the UK?
<Ubug2> Malone bug 58016 in xorg-server "Edgy choice of UK Dead Keys Layout in Gnome" [Low,Confirmed]  
* Keybuk blinks at ubuntu-devel
<Keybuk> did mdz flush an old mail out of his queue or something?
* pitti recently got a lot of May mail from BenC, too
<pitti> probably mailman administration
<Fujitsu> Burgundavia cleaned the spam filter 48 hours ago...
<Hobbsee> yes.  unfortunately :P
<Kamion> Mithrandir: I have the fix for that in hand, although I don't know how to deal with upgrades
<Kamion>     uk) XMAP="gb"; VARIANT="intl";;
<Kamion> ^-- retarded
<Mithrandir> so UK people don't want dead keys?
<Kamion> hell no
<Mithrandir> heh, 'k
<Kamion> I'll upload the fix for fresh installs now
<Kamion> dead keys produce a "WTF" reaction here
<abattoir> Kamion: hi, are you aware of http://paste.ubuntu-nl.org/23877 ?
* jdong kicks archive.ubuntu.com
<jdong> bad archive! stop your md5sum mismatching!
<Kamion> abattoir: oops, yes, I have a fix for that pending upload
* Kamion will upload it now
<abattoir> Kamion: i also noticed that /usr/sbin/oem-config doesnt have the option for kde-ui, could you add that too?
<Kamion> abattoir: sure
<abattoir> Kamion: and i have fixed the indenting too
<jdong> Kamion: was ubiquity supposed to work in knot3?
<Mithrandir> jdong: no, we just released it for the heck of it.
<Kamion> what he said
<jdong> Mithrandir: seriously or sarcastically?
<Mithrandir> (what do you think?  Yes, of course it was supposed to work)
<Mithrandir> we spent resources on testing, we don't tend to do that just for the heck of it.
<jdong> well, the installation didn't launch at all on my amd64
<jdong> it would backtrace on launch
<Mithrandir> worked for me
<jdong> so I forced it to dist-upgrade on the livecd....
<Kamion> file a bug please
<jdong> then it would launch
<Kamion> with the traceback and the logs
<Kamion> like the error message tells you to
<jdong> k, when I get a chance to, I'll regenerate the error
<Kamion> asking on IRC at random intervals is about the least productive way to draw my attention to a ubiquity problem. :)
<jdong> sorry, I was just making sure it wasn't a known issue
<Kamion> I'd rather you filed a potential duplicate
<jdong> k, duly noted for the future
<Kamion> *much* rather
<Hobbsee> Mithrandir: *g* @ the response
<carlos> Riddell: hi, around?
<Riddell> hi carlos 
<carlos> Riddell: hi
<carlos> Riddell: I would like to know what should I do about https://launchpad.net/bugs/58579
<Ubug2> Malone bug 58579 in kopete "no kopete translations in edgy" [Untriaged,Confirmed]  
<carlos> Riddell: should I wait until new KDE to import the new .pot file?
<carlos> or import it right now and move it from the old package to the new kopete one?
<Riddell> carlos: I would say so yes, else we'll have more duplication than normal
<Riddell> carlos: wait that is
<carlos> Riddell: ok
* Hobbsee watches carefully
<Riddell> Hobbsee: what for?
<Hobbsee> the kopete stuff
<carlos> Riddell: thanks for the input
<Hobbsee> seeing as i'm usually the one who changes it
<Hobbsee> and we're keeping the source split, right?
<jdong> Kamion: can I ask you about when/if #58139 is to be decided upon?
<Riddell> Hobbsee: yes
<jdong> *ahem* bug 57139
<Ubug2> Malone bug 57139 in linux-source-2.6.17 "Add lm-sensors support for nForce 410 and 430" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/57139
<jdong> not that one
<Hobbsee> Riddell: good
<jdong> bug 58139
<Ubug2> Malone bug 58139 in ktorrent "UVF exception request ktorrent 2.0.1 -> 2.0.2" [Low,Unconfirmed]  http://launchpad.net/bugs/58139
<jdong> that one
<Kamion> jdong: I hadn't seen the new information on the bug yet because I'm very behind on my bugs folder; I've queued it up for my review now
<jdong> Kamion: ok, thanks. The bug it fixes is quite irritating.. large downloads just stop going after a while
<infinity> mvo: Around?
<mvo> infinity: yes, hello
<dholbach> Riddell: I'll do a no-changes rebuild upload for kdepim (libpisock8 -> libpisock9), is that ok with you?
<Riddell> dholbach: sure
<infinity> mvo: It's been brought up in #debian-release that app-install-data probably contains non-free data (acrobat icon and such), and our own app-install-data-commercial would obviously suffer similar issues.  We ship both in main, and Debian's is in main as well, of course.
<dholbach> Riddell: excellent
<infinity> mvo: Can you think of any clever way to resolve that?
<infinity> mvo: (In Debian, the easiest solution is probably just to replace the icons with free alternatives, not sure what you want to do for Ubuntu)
<mvo> infinity: I never uploaded it to debian and I very much doubt that whoever uploaded it re-ran it over the debian archive (also I may be wrong here of course). my advice for debian would be to remove it because it is likely to contain incorrect data (for debian) anyway
<infinity> mvo: We do commit to main being free, but since you want g-a-i to depend on app-install-data-commercial, that gets tricky.
<infinity> mvo: Ahh, that wasn't your doing.  Check.
<mvo> infinity: ubuntu is more tricky :/
<mvo> infinity: we could make app-install-data-commercial a recommends of ubuntu-desktop. this way people can easily get rid of it at least
<infinity> mvo: But where do we ship it?
<infinity> mvo: We don't enable -commercial by default, so that's out, and we've committed to restricted being for hardware support only, though perhaps mdz would be willing to bend that rule for this case.
<mvo> infinity: right. either -restricted or we remove all non-free icons 
<mvo> infinity: as for app-install-data, I will have a look at the sutff from multiverse and remove the icons
<mvo> (or check for free alternatives)
<infinity> mvo: Awesome.  You rule.
<mvo> messy problem :(
<infinity> mvo: Can you file a placeholder bug for this and subscribe me to it?
<infinity> mvo: Most things (like acroread for sure) should have free icons that would suffice.
<infinity> mvo: For -commercial, I assume the vendors would be miffed if we didn't use their logos, so we'd have no choice but to ship them in a nonf-ree component, I suspect.
<jdub> there's nothing wildly wrong about shipping trademarks that refer to a product
<jdub> i mean, we ship apache after all
<jdub> and gnome
<Mithrandir> jdub: this isn't about trademarks, but copyright.
<jdub> what's the copyright issue?
<Mithrandir> jdub: they're probably not free (in the DFSG sense) so can't go to main.
<infinity> Shipping vendors' unmodifiable logos?
<jdub> we ship quite a few trademarks
<infinity> One could make an argument that shipping a logo that is also a trademark is a sketchy grey area, but I'd prefer not to go there.
<Mithrandir> (the copyright issue being "they're unmodifiable due to copyright")
<jdub> including projects that, if modified, you're required to change the name
<jdub> Mithrandir: how is that different to "apache"?
<Mithrandir> jdub: requiring name changes is ok wrt the DFSG.
<jdub> (red hat ship "httpd")
<infinity> jdub: You can't modify the Acrobat logo at all.  You can modify the word "apache" all you want.
<jdub> ok, the gnome foot
<infinity> jdub: The GNOME foot is unmodifiable?
<jdub> infinity: it's a trademark
<infinity> Yes, so?
<infinity> That doesn't make in unmodifiable.
<infinity> It makes it a trademark.
<infinity> You're mixing and matching laws here.
<jdub> no, i'm not
<infinity> s/make in/make it/
<jdub> there are very few trademarks you can modify without a license
<jdub> to do so
<infinity> You can easily license the foot to be freely modifiable and still say "the foot is a trademark of the GNOME foundation".
<jdub> no you can't
<jdub> because you are not protecting your trademark
<infinity> Erm, no.  Really.  A mark can be modified for non-competitive use and not violate the mark.
<jdub> there are lots of things shipped in ubuntu that are not modifyable per trademark or copyright; the GPL is a good example
<Mithrandir> jdub: a modified work might not look anything like the gnome foot.  If it's derived from the gnome foot, it's still covered by copyright "taintedness" from the foot.  However, if it doesn't look like the foot, it's not covered by the trademark.
<jdub> infinity: that is not correct.
<Burgundavia> Keybuk: see my mail to -devel about it
<infinity> If it's competitive use, it becomes a trademark issue, not a copyright issue.  And copyright law plays no part in that.
<jdub> infinity: that is not correct.
<jdub> Mithrandir: if it's nothing like the gnome foot, it's not a trademark issue.
<infinity> jdub: But could still be a copyright issue.
<infinity> jdub: That's the point.
<Mithrandir> jdub: it can easily be a trademark issue without being a copyright issue too.
<jdub> Mithrandir: absolutely
<dholbach> rodarvus: ROCK ON! :)
<jdub> Mithrandir: that's roughly my point
<rodarvus> dholbach, heh :)
<rodarvus> hey, on an unrelated subject. I noticed you like drum'n bass
<dholbach> hehe, yeah, you could say that :-)
<rodarvus> there is a drum'n bass "specialization" in brazil, which I think you might like (or maybe you already know)
<rodarvus> called 'sambarock'
<dholbach> I need to get more into it, but I know there's a lot of very good brazilian dnb DJs
<Riddell> Mithrandir: are you going to upload casper sometime with the accessibility changes?
<Mithrandir> Riddell: yeah, I have a bunch of other changes I need to get in too, for upstart.
<rodarvus> we have some really good stuff on this genre here
<dholbach> rodarvus: I didn't know you were into drum'n'bass music
<mvo> jdub: so you say shiping those icons maybe unproblematic?
<jdub> Mithrandir: you're basically arguing that shipping trademarked icons in reference to a product is not DFSG compliant. that's pretty hairy - should the DFSG cover trademarks? *highly* problematic. in DFSG terms, you can replace these icons with whatever you want.
<jdub> mvo: i think it comes down to a trademark issue, not a DFSG issue.
<jdub> mvo: because getting trademarks caught up in DFSG stuff is extraordinarily problematic.
<Mithrandir> jdub: the DFSG traditionally isn't interpreted to cover trademarks, but if we were to make it cover trademarked icons too, we'd need to only ship non-trademarked (or with trademarks which allows modification) bits.
<infinity> jdub: And if we take a step back and say the icons aren't trademarks (the ones in question may be, but may not be), but they're still unmodifiable?
<rodarvus> dholbach, I'm into electronic music, generally. just happen to enjoy some of dnb as it has strong roots in brazil
<dholbach> rodarvus: I'll send you a link to some mixtapes, then ;-)
<infinity> jdub: You're giving trademark logos the same blanket "turn a blind eye" stance that we give to license texts, and I can see the argument for that, but we hadn't actually established that these icons were all registered marks in the first place, just that they were non-free images. :)
<rodarvus> dholbach, if I knew you like it, I could have brought you some brazilian dnb (can do it next time too, if you want)
<jdub> infinity: ends up being a different issue.
<rodarvus> nice, appreciated :)
<ogra> rodarvus, ping
<rodarvus> ogra, pong
<jdub> Mithrandir: then you have the firefox issue impact everything. eek. ;)
<dholbach> rodarvus: that sounds super
<ogra> rodarvus, whats the reason for patching all the upstream tarballs of the X drivers instead of using debian/patches ? 
<rodarvus> none, really
<Mithrandir> jdub: the DFSG _does_ cover copyright bits though so we need to make sure whatever we include at least is modifiable, even if the trademark licence forbids it.
<Kamion> infinity: non-free data probably falls in the region where we diverge from the DFSG on a case-by-case basis anyway
<infinity> ogra: When Daniel first packages all the modular stuff, he only added debian/patches and a dpatch build-dep as things needed patching.  So some packages have them, and some never did.
<ogra> rodarvus, we had quite an hard time here at the ltsp hackfest because the via driver doesnt work on *anything* anymore with the GIT patch you added
<rodarvus> wanted to rush them for Knot 3, but using quilt would be better, of course
<rodarvus> ogra, oh?
<infinity> ogra: I suspect others (like rodarvus) have just maintained the status quo. :)
<ogra> could you please revert that ? 
<Kamion> "Ubuntu contains licensed and copyrighted works that are not application software. For example, the default Ubuntu installation includes documentation, images, sounds, video clips and firmware. The Ubuntu community will make decisions on the inclusion of these works on a case-by-case basis, ensuring that these works do not restrict our ability to make Ubuntu available free of charge, and that Ubuntu remains redistributa
<Kamion> http://www.ubuntu.com/ubuntu/licensing
<rodarvus> ogra, that patch is actually meant to make it work. it wouldn' work without that patch
<ogra> none of the disklessworkstations.com terminals work anymore and it took me some time to figure that out
<infinity> Kamion: Fair enough.  If that's the case, then mvo can just yell at Debian for being slack about this, and we can pretend we don't care? :)
<jdub> Mithrandir: i think you end up with a sticky ball of confusion if you try to separate those too much
<rodarvus> ogra, can you send me the Xorg.0.log so I can take a look at it?
<rodarvus> and inspect the exact cause of the problem
<ogra> if i compile the package with the plain upstream source tarball from freedesktop.org it works fine everywhere
* mvo likes this solution
<Mithrandir> jdub: why?  They're totally separate issues.
<jdub> Mithrandir: almost totally - in theory.
<ogra> rodarvus, ok, will do
<rodarvus> thanks, appreciated
<ogra> err
<jdub> Mithrandir: in practice, they're often intimiately wed. how many images do you think we ship that are unmodifiable, but not due to trademark restrictions?
<ogra> rodarvus, err, well, it will be a bit hard to get them since the terminal hardlocks as soon as X starts ...
<ogra> but i'll try my best 
<Mithrandir> jdub: I have no idea; I did actually assume we didn't ship non-free data apart from GFDL-ed docs.
<ogra> the fedore guys actually had the same prob, was quite funny that i fixed their package alongside ;)
<jdub> Mithrandir: and licenses. and trademarks. ;-)
<rodarvus> ogra, it was a problem on the upstream release, actually
<rodarvus> which my patch is supposed to fix (usage of assert())
<infinity> jdub: Well, without licesnes we can't ship anything (except a few MB of public domain stuff) at all, so we pretty much have to hand-wave that one past.
<ogra> rodarvus, well, when they reverted to the upstream tarball it worked for them as well ... apart from the fact that they also have a DRI problem that still needs fixing (the forcefully enable DRI everywhere ;) )
<infinity> jdub: I'd prefer not to see "license texts are non-free!" be someone's toehold to argue for more such exceptions, cause that just makes no sense.
<rodarvus> ogra, haha, I fixed that too! :)
<ogra> rodarvus, i dont think its the assret stuff that breaks it, but rather the GIT commit to the source
<ogra> *assert
<jdub> infinity: the point being that trademarks should be regarded as legitimately non-modifiable.
<rodarvus> ogra, the strange thing is I don't have any other complain with the current version of this driver :/
<ogra> (isnt the assert change only one line ?)
<rodarvus> yes
<ogra> right
<Mithrandir> jdub: modification doesn't make sense in the context of a trademark.  If you create something from scratch it can still violate a trademark.  You _can't_ violate copyright by creating from scratch.
<ogra> well, i have at least three thin clients here where it works fine with dapper and with the plain upstream source but not with the patched one
<rodarvus> ogra, oh, so you want me to revert the OpenChrome changesets?
<ogra> right
<rodarvus> *glup*
<rodarvus> ok :)
<jdub> Mithrandir: well, you can, but for different reasons. but yes, i know what you mean, and that is accurate.
<ogra> we should rather get unichrome fixed and to main at some point :)
<rodarvus> ogra, do you think its possible for you to try a locally built version, and then, if it works we can later upload it?
<ogra> yep, i'll talk to jim if i can borrow one of the clients where it breaks until mountain view 
<Mithrandir> jdub: oh yes, s/copyright/the licence/ if that makes you happier.  By cleanrooming something you avoid any restrictions the licence used imposes on you.
<ogra> luckily i can return it in november :)
<rodarvus> ogra, anyhow, the OpenChrome changesets are exactly meant to fix DRI
<jdub> Mithrandir: doesn't help with a book, though. :-)
<ogra> rodarvus, aha
<rodarvus> without them, we'll be in the same situation as Fedora
<ogra> well, not really 
<ogra> seems the binary i built just worked on the fedore system they have here ;)
<ogra> they only replaced their module with mine and it started to magically work *g*
* ogra still laughs about the fact that he fixes fedora bugs 
<rodarvus> O_O
<jsgotangco> haha
<HiddenWolf> ubuntu doesn't have enough bugs to keep awesome ogra busy all day and night. ;)
<ogra> heh
<jdong|laptop> there, posted my two grips to KubuntuKDEMedia
* jdong|laptop feels great to get that off my chest
<jdong|laptop> oops, wrong channel
* jdong|laptop smacks himself
<rodarvus> ogra, http://people.ubuntu.com/~rodarvus/packages/xserver-xorg-video-via/
<ogra> whoops ... gdebi kicked in *g*
* ogra now downloads properly to install on the client instead of breaking his server ...
<rodarvus> nice, please report here when youu have results :)
<ogra> rodarvus, looks fine 
<rodarvus> good
<rodarvus> a working driver is always good news
<rodarvus> ogra, and wrt DRI, I suppose its not rocking?
* Keybuk decides to have a "three days until Beta Freeze" panic
<pitti> Keybuk: good idea, given that we are just out of knot-3 freeze; it becomes cold in here
<rodarvus> on a semi-related subject ("three days until Beta Freeze"). about two weeks ago I requested UVF exception for Mesa (which was at version 6.5.1rc2 at the time). mdz asked me to wait for 6.5.1 final, due to the rather intrusive changes applied to Mesa since the last package update (~20 days before the UVF exception request)
<rodarvus> well, Mesa 6.5.1 was released this weekend.
<carlos> Keybuk: hi, around?
<Keybuk> carlos: yeah, what's up?
<carlos> Keybuk: hi
<ogra> rodarvus, dri doesnt work on thin clients anyway ...
* jdub spanks ogra 
<rodarvus> ogra, I'm not worried about (only) the thin clients, but via driver users in general
* ogra cries
<rodarvus> :)
<ogra> evil jdub 
<ogra> rodarvus, i dont have any other via HW to test it 
<rodarvus> ogra, hey, do you have a spare thin client you could test the new and shinning 'unichrome' driver on?
<carlos> Keybuk: would be possible to fix upstart's source to stop mixing '\r' and '\r\n' in the same gettext messages? 
<ogra> rodarvus, i tried that one when we had the probelm ... it didnt work, xorg fell back to vesa
<carlos> Keybuk: https://lists.ubuntu.com/archives/rosetta-users/2006-September/001805.html
<ogra> and when i forced it, it didnt start
<rodarvus> its an alternate driver for via boards - it (knowingly) doesn't works on all via boards, but it is said to be better than the 'official' driver for the ones it supports
<Keybuk> carlos: err, what's the problem?
<Keybuk> that string is correct
<rodarvus> oh
<ogra> but i'll get the client where the via driver broke to take it home, i'll be able to test more by the end of the week 
<ogra> so i can provide logs etc then 
<carlos> Keybuk: why do you mix them? is any technical need? 
<Keybuk> carlos: because \r and \n are different characters?
<ogra> i just dont have more time i can waste with general bugfixing here, i'm here to finish off the ltsp upstream erge
<Keybuk> and do different things?
<carlos> Keybuk: I don't mind if you use '\r' or '\n'
<Keybuk> carlos: eh?
<carlos> Keybuk: What I'm asking is to not mix both in the same sentence
<Keybuk> why not?
<Keybuk> what's wrong with mixing them?
<carlos> either us '\r' or '\n' or '\r\n'
<Keybuk> no
<Keybuk> BZZT
<carlos> well, from the translation point of view
<ogra> rodarvus, (flying back tomorrow night, so i'll have time from thursday on to hunt that for you)
<carlos> you drive our translators crazy
<Keybuk> what has this got to do with translations ?!
<Keybuk> you are making no sense
<carlos> from the Rosetta point of view... upstart will be rejected 
<Keybuk> why?
<Keybuk> is there a bug in Rosetta?
<carlos> Keybuk: that allows you to import such strings, yes
<Keybuk> eh?
<Keybuk> dude, please start from the beginning
<Keybuk> what is the problem with that string?
<Keybuk> it is correct
<rodarvus> ogra, thanks, appreciated!
<carlos> technically is correct, right
<carlos> but, from the translator point of view
<Keybuk> what have translations got to do with it?
<Keybuk> the french shutdown message still needs to return to the beggining of the line before writing over a terminal
<carlos> Keybuk: what happens if a translator translates '\r foo \r\n' with '\n foo \n' ?
<Keybuk> then they will get the wrong thing
<Keybuk> and that translator should be slapped
<Keybuk> it should be \r foo \r\n
<carlos> Keybuk: so technically you need exactly that information?
<Keybuk> or, at least, \r f \r\n
<Keybuk> yes
<carlos> ok
<Keybuk> \r and \n are different characters
<Keybuk> they do different things
<Keybuk> anyone thinking they are the same needs re-education
<carlos> I know
<Keybuk> so what's the problem?!
<Keybuk> I am utterly confused here
<carlos> but most of the time (always since we started with Rosetta) people used '\r' when they were thinking on '\n' so I was just checking if that's the case here
<Keybuk> no
<giftnudel> Keybuk: I think it was not clear, that you need both \r and \n exactly
<Keybuk> it's definitely not the case
<carlos> Keybuk: ok
<carlos> next question
<Keybuk> the \r at the start is required to reset the cursor position
<Keybuk> as that message is written over whatever is on any terminal already
<Keybuk> the \r\n at the end are needed because you don't know the settings of the terminals you are writing to
<Keybuk> so need to explicitly return and advance the carriage
<carlos> Keybuk: would be possible to move out those tags from the gettext string?
<Keybuk> no, because it needs to be done in a single write
<carlos> this will break a lot of translations because many translators don't even know about that difference
<carlos> I see
<carlos> ok
<Keybuk> otherwise you'll end up with a shtudown message broken up across a terminal running anything that attempts to actively update the display
<carlos> then we will need to figure a way to help translators to handle that without breaking upstart
<giftnudel> carlos: maybe some education will help?
<Keybuk> it wouldn't break upstart, they'd just get jumbled up shutdown messages
<carlos> and fix also Rosetta now that we found the first case that actually need that mix of chars
<Keybuk> seriously, translators should at least know some fundamentals about C strings, no?
<Kamion> Keybuk: you could still assemble the string in memory first and then write it in one go
<Keybuk> Kamion: perhaps
<Kamion> I think that would be a good idea - it's somewhat analogous to security vulnerabilities due to incorrect format string translations
<carlos> Keybuk: no, that's not why Rosetta is being developed. It's something good that they know about it, but we shouldn't need to teach them about it
<Kamion> I've been trying to improve d-i to rely less on translator knowledge
<Keybuk> that's already an ugly piece of code just for dealing with translations
<carlos> Keybuk: thanks for your time
<Keybuk> it was one of those where I almost did a Jane over translation <g>
<ogra> Keybuk, ping
<Keybuk> ogra: I'm not here, I've been away for the past hour, and am not returning for another three
<Keybuk> I'm not even here now
<Nafallo> lol
<ogra> udevinfo -qenv -n fd0 (or /bock/fd0) retunr nothing here 
<ivoks> jee... Keybuk has a bot :)
<Keybuk> ogra: what did you expect it to return?
<ogra> Keybuk, something ? 
<jdub> the messiah.
<Keybuk> ogra: such as?
<Kamion> ogra: last time I asked a similar question, Scott's answer was "if udev doesn't change anything versus what the kernel recommended for that device, then udevinfo won't print anything"
<ogra> ID_BUS, ID_TYPE
<Kamion> or words to that effect
<thom> i don't think block devices can be very naughty boys
<Keybuk> ogra: we don't record that information for floppy devices
<Keybuk> users get annoyed at the *chuggggchunkwhrrr* on boot :p
<ogra> sbalneav say ok, thats fine ... we'll make up a name ...
<Keybuk> and for a floppy, that's pretty much hard-codable anyway, no?
<Keybuk> bus=floppy
<ogra> *says
<Keybuk> type=floppy
<Keybuk> :p
<ogra> will work, at least for one 
<Keybuk> for one?
<Keybuk> why not for two?
<ogra> dunno if that'll work with multiple floppes though
<Keybuk> fd0, iirc, is only ever XT floppy devices
<ogra> ok
<Keybuk> sure, the id is just the 0, 1, 2, etc. bit on the end
<ogra> ok, thanks for now :)
<ogra> iwj, i have some weird problems with flash on ltsp here ... seems if i use a dapper chroot (thus the dapper X server) it works fine, as soon as i switch to edgy (even with vesa) firefox just crashes 
<ogra> (on flash sites)
<iwj> ogra: I blame flash.   Err.
<ogra> hmm
<ogra> but the only thing i change is the X server ... i'm tempted to blame X
<ogra> or ssh ...
<iwj> Sorry, but Flash is not free software so I can't help.  Debugging it would involve reverse-engineering, which is forbidden by Macromedia, even if I were prepared and motivated to attempt it without the source.
<ogra> but thats the only thing thats different
<ivoks> ogra: it's compositing manager
<ivoks> ogra: turn it off
<iwj> ivoks is probably right.
<Keybuk> iwj: talking of Firefox ... mine doesn't work
<ogra> how ? i didnt turn it on deliberately ...
<iwj> Keybuk: Oh ?
<ivoks> i was smashing my head for days cause of this :/
<Keybuk> I get an XML Parsing Error when it starts
<Keybuk> edgy, current
<iwj> Yay!
<Keybuk> tried a fresh profile
<iwj> That's crazy.
<iwj> And this apparently only happens to you.  How weird.
<iwj> Does it mention the filename that has the problem ?
<Keybuk> "undefined entity" is on <toolbarbutton id="go-button"  and <menuitem id="menu_HelpPopup_reportPhisingtoolmenu"
<Nafallo> there are bugs about that
<ogra> ivoks, thanks thats a good hint, thanks a million
<Keybuk> chrome://browser/content/browser.xul
<ivoks> ogra: np
<Keybuk> iwj: is there any super-debugging-power thing I can do to help?
<Keybuk> obviously there's not enough info for a bug report here yet
<giftnudel> Keybuk: can confirm this bug
<iwj> Keybuk: Can you try running it with LANG=C and no other locale variables ?
<Keybuk> iwj: "LANG=C firefox" works
<iwj> Right.
<iwj> The problem will be fixed when the langpacks are updated.
<Keybuk> iwj: "LANG=en_GB.UTF-8 firefox" doesn't (my default lang)
<Keybuk> ah, I see an updated langpack thing
<Keybuk> I'll try installing that
<iwj> Yes, do :-).
<iwj> Hey, that was too easy.  Ask me another one.
<Keybuk> iwj: Would you like any toast?
<Nafallo> iwj, Keybuk: I have seen a bug-report about that already where Kamion suggested using LANG=C etc...
<Nafallo> I'm trying to find it now
<iwj> Nafallo: Never mind, we know what the answer is.  Although we should express this in dependencies somehow.
<Keybuk> iwj: yes, that fixed it
<Nafallo> well, that answer is in the bugreport aswell, and have been the whole weekend ;-)
<iwj> m-f-l-thing Breaks: firefox (!= the one it's intended for)
<iwj> Nafallo: I often find that rediscovering the answer to easy questions is faster and more reliable than looking at what people say in bug reports :-).
<Nafallo> hehe, with the amount of bugreports against the said package I understand you :-P
<mvo> Kamion: does my suggestion to fix #52718 sound ok? If so, I wil implement it now. note that I would like to rename the environment used for this
<Keybuk> bah, greasemonkey not available
<seb128> mvo: are you sure those are different options?
<seb128> mvo: that looks like "make GST_NO_INSTALL_NTP does what it used to do and mask the ntp setting too"
<Kamion> mvo: sure, no opinion on the environment variable, just let me know what you decide
<azeem> dholbach: if you manage to fix the multisync build WRT libpisock, please let me know :)
<mvo> seb128: well, I think when we just hide the checkbutton/button complettely that should be enough, no? 
<seb128> mvo: which one?
<seb128> oh, the ntp and ntpdate options you mean (ie: everything between the timezone and the buttons bar)?
<iwj> pitti: BTW, my latest attempt at ff 1.5 for breezy is building.
<pitti> ah, nice
<pitti> iwj: I am off for a bit now, and when I return later this evening I'll chat with mdz about tbird 1.5
<mvo> seb128: the old patch did remove the button "install ntp now". but when the installer runs time-admin, it does not need the ntp stuff. so the checkbox "sync system clock with the net" and the button "choose server". ntpdate is installed so the "sync now" button can probably stay
<seb128> mvo: ok, works for me :)
<dholbach> azeem: dlp_ReadRecordById dropped one argument
<FliesLikeALap> mvo you around?
<dholbach> azeem: I did a small patch for evolution too
<mvo> seb128: ok, I will do that then
<mvo> FliesLikeALap: yes
<FliesLikeALap> mvo, may I strike up a private query with you?
<mvo> FliesLikeALap: sure
<bddebian> Heya folks
<bluefoxicy> who is generally in charge of Ubuntu/Canonical finances?
<bluefoxicy> sabdfl?
<azeem> dholbach: oh, ok.  I only had a very superficial look at it so far and it looked non-trivial to me :)
<bluefoxicy> Someone is asking me about getting financial support for something so I figure I'll send him towards the proper channels
<Seveas> bluefoxicy, jane.silber at c.com
<bluefoxicy> Seveas:  nods.  I'll send him that way then.
<bluefoxicy> c == canonical?
<Seveas> yes
<bluefoxicy> kay.
<tkamppeter> Who is responsible for merges.ubuntu.com?
<pitti> tkamppeter: Keybuk 
<tkamppeter> There are missing: foomatic-filters, foomatic-db, foomatic-db-hpijs
<tkamppeter> Keybuk, I these packages need to be updated for Edgy to fix several bugs and to update hardware support.
<tkamppeter> Thanks, pitti.
<pitti> tkamppeter: usually they are missing because we have a newer version than Debian
<StevenK> pitti: Not in this case.
<Kamion> in this case I imagine they're missing because we never made Ubuntu-specific modifications
<Kamion> foomatic-filters | 3.0.2-20060530-1 |          edgy | source, all
<tkamppeter> So I directly update such packages, as I usually did with Mandriva.
<Kamion> tkamppeter: shouldn't we sync them from Debian?
<pitti> tkamppeter: oh, in that case a sync is better
<Kamion> foomatic-filters | 3.0.2-20060712-3 |      unstable | source, all
<Kamion> for instance
<Keybuk> that's weird
<Kamion> we're generally happier with syncs where possible, because it broadens the base of people we can expect to have tested the packags
<Kamion> packages
<Kamion> unless of course newer versions still are required, over what Debian has
<tkamppeter> Perhaps we need even newer, to fix several bugs which I have recently fixed upstream, as
<pitti> tkamppeter: if that's the case, please apply modifications on top of sid's package instead of our's
<pitti> tkamppeter: so that we don't run into merge troubles later
<crispin> Keybuk: thanks for the info on /proc/bus/usb - the VMware guys are apparently aware of the situation with it
<tkamppeter> bug 36532 (wrong recommended driver gimp-print)
<Ubugtu> Malone bug 36532 in cupsys "Unable to print text or ps/pdf to gutenprint printer" [Unknown,Unconfirmed]  http://launchpad.net/bugs/36532
<tkamppeter> bug 16703
<Ubugtu> Malone bug 16703 in foomatic-db "hpijs is recommended for hp laserjet 1100A but ljet4 prints better" [Medium,Confirmed]  http://launchpad.net/bugs/16703
<tkamppeter> bug 23461
<Ubugtu> Malone bug 23461 in cupsys "gs-esp dies when it is called by cups" [Medium,Needs info]  http://launchpad.net/bugs/23461
<tkamppeter> pitti, so you think, I should generate a patch out of the current snapshot of each Foomatic package and add this to the appropriate Debian unstable package to get a Ubuntu package making up the current snapshot of Foomatic?
<pitti> tkamppeter: yes
<tkamppeter> Is it not easier to simply take today's upstream snapshots?
<tkamppeter> And also bug 39465 and 41789, and probably many others which I found by myself or by reports to other distros or to the linuxprinting.org mailing lists ...
<Ubugtu> Malone bug 39465 in foomatic-db "Samsung ML-1740 Not Listed" [Medium,Confirmed]  http://launchpad.net/bugs/39465
<Ubugtu> Malone bug 41789 in foomatic-db "the Samsung ML-1610 printer works with ML-1510 driver" [Medium,Confirmed]  http://launchpad.net/bugs/41789
<pitti> tkamppeter: no, I mean use 'uupdate' in Debian sid's version, not our's
<pitti> tkamppeter: so that the next automatic merge will be easier
<pitti> tkamppeter: you can still use today's upstream snapshot (all under the assumption that mdz approves, of course)
<carlos> Riddell: hi, do you have time to debug a problem with Edgy's kdelibs.pot file?
<Riddell> carlos: I can try
<Riddell> I know we're missing the stock strings
<carlos> Riddell: we got an email from a user related to some strings being set as obsolete (let me look for the thread...)
<carlos> oh, I see
<carlos> so that's the problem
<carlos> Riddell: is there any bug report open so we can point our users to it?
<Riddell> carlos: not that I know of
<Riddell> I'll try and look at that today
<carlos> do you want that I file a bug?
<carlos> if you think today it would be fixed, that's enough for me
<Riddell> sure, do file a bug
<carlos> ok
<carlos> Riddell: https://launchpad.net/distros/ubuntu/+source/kdelibs/+bug/61107
<Ubugtu> Malone bug 61107 in kdelibs "Some stock strings are not extracted to be translated" [Untriaged,Confirmed]  
<iwj> pitti: The problem you had before with the new ff was   gtk_stock_lookup: assertion `stock_id != NULL' failed   I take it ?  (Followed by glibc detected free invalid pointer)
<ogra> mdz, ping
<mdz> ogra: pong
<ogra> mdz, sorry for bug 57329 i added an explanation ...
<Ubugtu> Malone bug 57329 in xorg-server "upgrade to latest xorg has stopped my CLE266 from working" [Medium,Fix released]  http://launchpad.net/bugs/57329
<ogra> mdz, but that wasnt the reason for my ping ... sbalneav has made a proper upstream package of ltspfs now, and we merged the source into one sourcepacke, would it be ok for an UVF exception ?
<mdz> ogra: what would be the benefit in edgy?
<ogra> (i'll file a request etc, but wanted to ask you first)
<ogra> we'd have only one ltspfs package and sbalneav actually would maintain it (with me sponsoring)
<ogra> s/package/sourcepackage/
<ogra> and the fixes we worked out here wouldnt have to be backported to my packages
<ogra> (floppy handling improvements, path improvements for the mounting etc)
<ogra> ltspfs upstream is completely maintained on LP and in bzr now btw :)
<iwj> mvo: Is there a way to turn off the crash reporter so I can have a corefile for my debugger ?
<iwj> I can't remember what it's called so I can't find the corefile in /var/whereever either.
<Mithrandir> iwj: apport-unpack /var/crash/$whatever /tmp/unpack-foo
<iwj> Uh.  Excuse me, I have no brain.  I would have found that if it had existed.  But I'm using _breezy_ which doesn't have it.  duh.
<iwj> But that leaves the question, where's my corefile and what put up a dialogue box about the crash ?
<gnomefreak> mjg59: ping
<jdong> mother of god... how long does it take for apport to prepare a crash report about firefox?
<gnomefreak> jdong: they are large
<gnomefreak> jdong: like 20+ mb
<jdong> there, done
<iwj> pitti: Hmm.  I'm rebuilding ff unoptimised so my gdb works.  No doubt the bug will vanish.
<pitti> iwj: I'm not sure about the particular crash, sorry
<pitti> iwj: I just know that ffox itself worked flawlessly and most gtkmozembed apps (yelp, epiphany, etc.) broke
<mvo> iwj: apport and apport-gtk are responsible for this
<iwj> Right.  I'm working with yelp atm because it's relatively small :-).
<iwj> I'll leave this debug build running and pick it up tomorrow morning.
<mind> hi, where i can find the ubuntu's build log? i'm looking for something similar to buildd.debian.org
<bddebian> mind: Launcpad
<Keybuk> 21308 root      25   0 72144  68m 1072 R  100  3.4   0:39.98 ld
<Keybuk> *blink*
<Keybuk> what in gods name is it linking?!
<bddebian> mind: More specificially:  https://launchpad.net/distros/ubuntu  and put in your package name
<pitti> iwj: sudo /etc/init.d/apport stop, btw
<pitti> iwj: (edgy+1 will have a more user friendly method)
<gnomefreak> init.d still works in edgy?
<Keybuk> yes
<gnomefreak> is it changing in edgy+1 or later in edgy?
<mind> bddebian: thanks
<Keybuk> we'll begin changing to upstart jobs in +1 and finish in +2 or so I guess
<iwj> pitti: Right, thanks, but it turned out to be me being stupid.
<mind> bye
<gnomefreak> ah cool ty Keybuk 
<iwj> Keybuk: How easy would it be to have a little stub init.d which talks to upstart, for the ease of compatibility (cron jobs, finger macros, etc.)
<Keybuk> for edgy we're just using upstart to drive init.d
<iwj> Right.
<Keybuk> iwj: easy; though it's easier and less error-prone just to keep /etc/init.d/rc around
<Keybuk> unless I'm wildly missing something?
<iwj> Err, well, yes, but it would be nicer in the end to have daemons that live as direct children of upstart.
<Keybuk> yes, this is true
<pitti> however, in the interest of legacy and Debian compatiblity (and not to the least, merging), wouldn't it be better to just replace the symlinks with upstart scripts, and have the upstart jobs call the existing init scripts?
<Keybuk> pitti: wouldn't work
<Keybuk> upstart jobs and init scripts behave differently, remember
<Keybuk> you could call the init script with "start" as the argument, and then treat it as a daemon that forked into the background, and hunt for a process -- but it's manual configuration per-package then
<iwj> I think this needs some serious thought and design.
<pitti> well, right now upstart scripts call rc, so there must be a way to write adapters for them
<Keybuk> (to name the daemon you're looking for, or the pid file to read)
<iwj> Ie, more than random wibblings on IRC :-).
<Keybuk> I'm not sure we need those adapters?
<pitti> Keybuk: hm, right
<pitti> well, if we have to touch all packages with an init script anyway, we can as well do it properly
<Chipzz> pitti: and upstart calling rc gains us what, exactly?
<Keybuk> Chipzz: existing init scripts run without modification
<Chipzz> pitti: daemons won't start in parallel
<pitti> Chipzz: if we could use Debian's init scripts unmodified, a lot less merge work
<pitti> Chipzz: why not?
<pitti> Chipzz: I'm not talking about using the rc?.d symlinks
<Keybuk> pitti: tbh, I doubt it will be an increase in merge work -- we've touched most things in main with an init script already
<pitti> Chipzz: just about using the init scripts to do the footwork
<Chipzz> because rc is just a simple for loop?
<Keybuk> Chipzz: fsvo simple
<pitti> Keybuk: well, many, if not the majority of lsb init scripts have been adopted in Debian
<pitti> Keybuk: I never had a rejected Debian bug report about it
<pitti> and most were applied within a reasonable time
<Keybuk> I was thinking about teardown
<Chipzz> Keybuk: fsvo?
<Keybuk> Chipzz: for some value of
<Nafallo> hmm
<Chipzz> Keybuk: you know what I meant ;)
<Keybuk> pitti: we've adjusted many update-rc.d calls, wouldn't be much extra to just drop them
<pitti> Keybuk: right
<Nafallo> I can't open upstarts sv.po (extracted from Rosetta) in gtranslator :-P
<Chipzz> Keybuk: "it boils down to a for-loop calling the scripts sequentially"
<pitti> Keybuk: but I thought you want to not use init scripts at all any more and instead provide an upstart-ish script to every package
<Chipzz> pitti: allow me to rephrase: why do we need compatibility with something we had in the first place?
<pitti> Chipzz: I don't know what you mean
<Chipzz> we had init calling rc (being a for-loop)
<pitti> Chipzz: I mean, 'Debian' -> using most of Debian's packaging with just a few bits modified
<Chipzz> now we have upstart calling rc (also being a for-loop)
<pitti> Chipzz: and 'legacy' -> scripts and users being used to run /etc/init.d/foo
<pitti> Chipzz: yeah, but upstart calling rc is just a transitional solution for edgy
<Chipzz> yes I know why upstart is good
<Chipzz> and I'm all in favor of it too :)
<Chipzz> pitti: but the transitional solution gains us very little
<pitti> Chipzz: right, just testing of upstart itself and the possiblity to play with it
<pitti> and one release is just too short to do everything
<Chipzz> the real value of upstart would be to be able to dump the rc script :)
* pitti agrees
<pitti> I never questioned that either
<pitti> Chipzz: I was talking about init scripts, not rc
<pitti> i. e. /etc/init.d/postgresql start -> bring up my damn database and do whatever is necessary
<Keybuk> pitti: eventually. sure; but I'd vaguely envisioned Debian being onboard too by that point
<pitti> Keybuk: I truly hope so :)
<Nafallo> hehe, #ubuntu-worlddomination :-P
<desrt> lmanul; hello
<Chipzz> Keybuk: can we have a mix of the old and new system?
<Chipzz> or would that break?
<Keybuk> Chipzz: sure, we do now, technically
<desrt> lmanul; i have some questions about your SoC work
<Chipzz> I meant something else ;)
<Keybuk> what did you mean?
<Chipzz> I meant some daemons being started with their /etc/init.d scripts
<Chipzz> and some the upstart way
<Chipzz> or is it a one-shot thing?
<Keybuk> how do you mean?
<Chipzz> well
<Chipzz> obviously you can't start a daemon twice
<Chipzz> (once the upstart way, and once using the symlink to /etc/init.d/foo)
<Keybuk> you can gradually convert daemons to be run by upstart jobs by removing their symlinks from rc?.d so rc doesn't run them
<Chipzz> well maybe you could, but for some daemons madness would ensue
<Chipzz> yes
<Keybuk> while still having upstart run rc
<Chipzz> but removing the symlinks would break backwards compatibility
<Chipzz> ie you couldn't go back to a pure sysvinit system if upstart breaks?
<Keybuk> that's not backwards compatibility
<Keybuk> but yes, that's correct; you can't ship both sysvinit and upstart handling
<lmanul> desrt: Sure
<Keybuk> well, you can, but you'd have to make upstart not run rc
<lmanul> desrt: I'm listening :)
<Keybuk> at which point you force yourself to convert everything at that point
<Chipzz> Keybuk: that's part of what I was thinking
<Chipzz> Keybuk: and removing the symlinks would break for people not having installed upstart
<Keybuk> heh, people may not be able to install sysvinit anyway
<Chipzz> so you would be forcing everyone to upgrade to upstart
<Keybuk> yes
<desrt> lmanul; i need to know about the stop-the-cursor-blinking stuff you did
<desrt> lmanul; did you add an XSetting for it?
<Keybuk> (to fix the upgrade problems, we may be forced to replace sysvinit with an empty package that depends on upstart, upstart-compat-sysv, etc.)
<desrt> or mark upstart-compat-sysv as depending on upstart and as replaces/conflicts sysvinit?
<bluefoxicy> fuck mplayer, it crashes X.
<desrt> (disclaimer: that was actually a question)
* bluefoxicy slightly frustrated.
<lmanul> desrt: Yes, I did add an XSetting
<desrt> oh.  that sick!
<desrt> is your code in gtk?
<lmanul> desrt: See http://www.manucornet.net/code/2006_GTK_cursor_blink_lifetime.diff
<Keybuk> desrt: that doesn't cause upstart-compat-sysv to get installed in the first place
<Keybuk> which is our problem
<Keybuk> people have lost ubuntu-minimal in the past
<lmanul> desrt: Not sure it's been forwarded upstream, but I do think so
<desrt> Keybuk; oh.  people who don't have ubuntu-...
<desrt> right
<Keybuk> sysvinit becomes non-essential and nothing depends on it, so apt cheerfully removes that for them
<desrt> lmanul; can you please make sure?
<Keybuk> but nothing causaes them to get upstart and upstart-compat-sysv in its place
<desrt> lmanul; i want to use that code asap :p
<lmanul> desrt: Matthias Clasen (among others) did some minor tweaking, and probably put it into GTK
<lmanul> desrt: Hmm there's a bug about this I think
<lmanul> desrt: Let me see
<desrt> lemme look at gtk CVS
<desrt> since it's a string API i could always just make the call and watch it fail if the user has old GTK
<pitti> mvo: btw, we have a problem in edgy: as soon as ubuntu-desktop vanishes, apt wants to uninstall 2348234 package
<pitti> s
<Keybuk> of course, if everybody used dselect, this wouldn't be a problem
<pitti> mvo: how did we solve that problem with aptitude?
<Keybuk> because dselect ensures everything with a high priority is installed anyway
<Keybuk> <g>
<pitti> mvo: (same for ubuntu-standard and -minimal)
<Keybuk> dselect: 1 - apt: 0
<pitti> mvo: i. e. if I try to remove wpasupplicant, I break my complete system
<mvo> pitti: is this on a upgraded system? or a fresh install?
<pitti> mvo: fresh knot-3
<imbrandon> mvo: same with kubuntu-desktop FWIW
<pitti> mvo: maybe the installation should mark the direct -meta dependencies as 'wanted'
<desrt> lmanul; i don't see your xsettings changes here
<Keybuk> pitti: which defeats the spec -- the point was to cause -meta changes to result in packages being removed
<mvo> pitti: I think we "just" need change the way that packages are installed on the livecd, I talk to infinity about it
<pitti> Keybuk: but *all* of them?
<Keybuk> apt really needs first-class tasks
* mvo agrees
<Keybuk> so you can say that you want ubuntu-desktop installed without wpasupplicant
<pitti> Keybuk: forcing people to use *-meta can hardly be the right answer
<lmanul> desrt: Thanks to Arjan at Intel and Matthias and Manu's patch the next version
<lmanul> of gtk we have in rawhide will include the cursor blinking patches.  You
<lmanul> can set the timeout in the gtkrc with this:
<lmanul> desrt: 11:14 <@mclasen> gtk-cursor-blink-timeout = <n seconds>
<lmanul> 11:14 <@mclasen> in your gtkrc
<lmanul> desrt: the two limit cases are
<lmanul> gtk-cursor-blink-timeout = 0 --> no blinking (we already had a boolean
<lmanul>                                 setting for that)
<lmanul> gtk-cursor-blink-timeout = MAXINT --> blinks forever (the current
<lmanul>                                      behaviour)
<lmanul> Any user interaction (button press, key press, focus change) restarts
<lmanul> the blinking.
<desrt> lmanul; all nice and good, but...... where's the code?
<imbrandon> well if they were marked as wanted durring installation and say you replaced oo.o with koffice it woudlent want to remove ALL the other stuff only kubuntu-meta
<lmanul> desrt: See   http://bugzilla.gnome.org/show_bug.cgi?id=352442
<Ubugtu> Gnome bug 352442 in GtkTextView "Support for cursor blinking timeout" [Enhancement,Unconfirmed]  
<desrt> http://cvs.gnome.org/viewcvs/gtk%2B/gdk/x11/gdksettings.c?rev=1.2&view=markup
<desrt> no "lifetime" yet :(
<imbrandon> but would kinda defeat the pourpouse of the spec too
<imbrandon> but forcing *-desktop to stay installed sucks also ....... /me gos back to lurking
* mvo is off for ~1h
<mvo> imbrandon: no worries, we find a solution that will not involve removing a gazillion things
<imbrandon> ;)
<desrt> ah.  some patches later down in this bug address this problem
<desrt> ok
<desrt> lmanul; k.  thanks.
<lmanul> desrt: http://cvs.gnome.org/viewcvs/gtk%2B/gtk/gtktextview.c?rev=1.322&view=log   (see also GtkEntry)
<lmanul> desrt: No problem :)
* desrt adds support to gnome-terminal
<lmanul> desrt: Oh, really? nice :)
<desrt> time given in seconds is annoying :p
<Riddell> carlos: ping?
<carlos> Riddell: pong
<Riddell> carlos: about importing the upstream .desktop translations into rosetta, is it sane to create a new package with those in it?
<carlos> Riddell: didn't we agreed on doing that using different packages?
<carlos> Riddell: for Rosetta is not an issue at all, just warn me when you do that and give me the list of translation domain affected (usually the .pot filename) so I move the ones we already have to the new sourcepackage
<carlos> from the language pack point of view, nothing changes
<Riddell> carlos: so we'd end up with teh .pots in the KDE source packages, but the upstream .pos in a special source package
<Riddell> of course that's a source package with no binary packages, which may not be sane
<carlos> Riddell: oh, so you are talking about just moving the .po files to a new package instead of adding them to kde-l10n?
<carlos> Riddell: that requires some changes in our side
<Riddell> I'll look at doing some automated fetching in kde-i18n-xx
<carlos> Riddell: I would prefer it...
<mjg59> gnomefreak: Hi
<gnomefreak> mjg59: for bug number 60621 should that be on usplash or usplash-theme-ubuntu
<mjg59> gnomefreak: No idea
<mjg59> Kamion: Any clue about the right way of doing #60621?
<gnomefreak> hmmmm
<Rathann> hi
<Rathann> slomo: are you around?
<slomo> Rathann: yes
<Rathann> great
<Rathann> I'd like to have a word with you about mplayer packaging
<Rathann> you did great, but there are still some issues
<slomo> thanks, tell me which ones (apart from it being broken in edgy because of ffmpeg) :)
<Rathann> you disabled mp3lib because of some audio decoding problems
<Rathann> but this hasn't been reported to us...
<Rathann> I didn't even know about this
<Rathann> 'till I read the report in ubuntu bugtracker
<Rathann> please, push the reports upstream whenever you can
<slomo> oh but can you reproduce it? and no, it wasn't reported... probably forgotten at some point :(
<Rathann> ok
<Rathann> next, why did you patch ve_lavc to disable those two options?
<slomo> because we build against our own ffmpeg which was (is) too old and does not have this two options
<Rathann> slomo: and yes, I can reproduce the mp3lib issue with my RPMs ;)
<slomo> and which is currently the reason why mplayer is somewhat broken in edgy... but that's on my todo list
<Rathann> I see
<Rathann> ok
<Rathann> why do you add config.sub and config.guess?
<Rathann> they are completely useless for non-autoconf configure
<Kamion> mjg59: usplash-theme-ubuntu should be fixed to ship a 640x480 (and/or 640x400?) theme
<slomo> Rathann: oh they're added because of a boilerplate in debian/rules that updates it at build time... right, it's not needed for mplayer because it doesn't use autoconf but it doesn't hurt ;) i'll remove that part later... thanks for noticing
<Rathann> :)
<Rathann> makes the diff smaller
<Rathann> ok
<slomo> Rathann: but as you're mplayer upstream... can you tell me something about the bundled liba52? would it be somehow possible to use an external liba52? last time i tried some private parts of liba52 were used and after fixing those it simply segfaulted ;)
<Rathann> oh, just noticed: you install codecs.conf? that's bad
<Rathann> mplayer has a built-in codecs.conf
<Rathann> the file is only for adding support for new codecs/testing
<Rathann> users shouldn't mess with it
<slomo> yep, i know... but the file was already in the versions that we had ages ago and removing config files it not that easy
<slomo> especially when all versions are slightly different... and we can't know whether a user changed the file or not
<slomo> so we decided to keep that file
<Rathann> we've had many weird bugreports we couldn't reproduce
<Rathann> which were caused by an obsolete codecs.conf laying around
<Rathann> well mplayer now checks this
<Rathann> but still
<slomo> the only way how a obsolete one could lie around is when the user changes the file
<slomo> and then he is notified at install time about it
<Rathann> well they can copy it to ~/.mplayer/
<Rathann> that's why we want packagers NOT to ship it at all
<slomo> sure... but we can't just unconditionally delete /etc/mplayer/codecs.conf as the user could loose his settings...
<Rathann> I see
<_ion> You could rename it to codecs.conf.old and print a warning in postinst.
<Keybuk> slomo: use the standard recipie?
<slomo> _ion: yes, that would work
<slomo> Keybuk: md5sum etc? impossible because we had many different versions of the file and they're not in the archive anymore
<Keybuk> slomo: compare the md5sum against status
<slomo> Rathann: anything else that you don't want to have shipped?
<slomo> Keybuk: right... thanks :)
<Rathann> no, codecs.conf was the only one ;)
<slomo> Rathann: ok, so what about liba52? :)
<Rathann> my fellow developer tells me it's possible
<Rathann> but we don't support it
<Rathann> anyway, our liba52 is pretty much synced to current upstream
<Rathann> or rather, upstream has accepted our patches ;)
<Rathann> though I agree that it should be possible to use external liba52
<Rathann> patches are welcome ;)
<Rathann> ah, I see you have gui/nogui version
<slomo> ok, i'll try to get it done then ;) what's the liba52 version that contains all your stuff?
<Rathann> but they're conflicting...
<Rathann> hm
<Rathann> the latest cvs probably
<Rathann> in liba52/ there are diffs 
<Rathann> between upstream and our version
<Rathann> and liba52 syncs to upstream are mentioned in changelog, let me check
<slomo> yep, i saw them... hm, this needs to be fixed anyway... otherwise it's impossible to use an external ffmpeg
<Rathann> how so?
<Rathann> mplayer supports external libav*
<Rathann> i.e. shared
<Rathann> oh, BTW
<ogra> mdz, ?? any word about ltspfs ? 
<Rathann> I think you have an old version of libavcodec...
<mdz> ogra: your response didn't mention my name and I missed it
<ogra> oh
<slomo> Rathann: we have? why?
<Rathann> slomo: I think the a52 version in 1.0pre8 is 0.7.3 but I'm not sure
<ogra> mdz, 
<ogra> <ogra> (i'll file a request etc, but wanted to ask you first)
<ogra> <ogra> we'd have only one ltspfs package and sbalneav actually would maintain it (with me sponsoring)
<ogra> * raphink hat die Verbindung getrennt (Read error: 104 (Connection reset by peer))
<ogra> <ogra> s/package/sourcepackage/
<ogra> <ogra> and the fixes we worked out here wouldnt have to be backported to my packages
<ogra> <ogra> (floppy handling improvements, path improvements for the mounting etc)
<ogra> <ogra> ltspfs upstream is completely maintained on LP and in bzr now btw :)
<mdz> ogra: I'm interested in what's changed from our package, and justification for a feature freeze exception
<Rathann> slomo: because one of the recent bugreports contained a gdb trace
<slomo> Rathann: and it breaks because libavcodec export liba52 symbols and you then link your own liba52 to the same binary... and boom
<ogra> i'd really really like to have it in ... its improved a lot 
<Rathann> and it showed mplayer linked to /usr/lib/libavcodec.so.0d
<Rathann> there's never been such version
<Rathann> it should be something like libavcodec.so.49
<Rathann> slomo: I see, then it should be fixed
<slomo> Rathann: that's the debian version... debian soname because the ffmpeg guys didn't use it right in the past from what i heard
<Rathann> is there anything preventing you from packaging the latest SVN snapshot?
<ogra> mdz, right, that will go into the request ayway, but some of the foppy stuff wasnt tested well in our packages and sbalneav did a really great job with his first package and the fixes, he deserves to get it in even if its only for his motu application ;)
<ogra> *floppy
<slomo> Rathann: time :) the version we have is from 2006-08-23
<ogra> s/and the fixes/and the fixes for floppy handling/
<Rathann> slomo: it's true that in the past ffmpeg didn't care about shared versions
<mdz> ogra: it's about the release, not giving someone a reward
<Rathann> but that's no longer true
<Rathann> slomo: ah, ok
<slomo> cool... that's good news :)
<Rathann> which reminds me
<Rathann> why 0.99?
<mdz> ogra: I'll look for your email
<dholbach> Riddell: do you know a package using cmake to build offhand?
<ogra> mdz, i know ... our floppy handling is simply broken ... but the new package will need some changes to ldm thats something i'd like to have done before beta freeze ...
<slomo> Rathann: because 0.99+1.0pre8 < 1.0 < 1.0pre8 for dpkg :)
<ogra> ok, i'll mail as soo as i'm home then ... 
<Rathann> don't you have something like epochs in rpm?
<ogra> *soon
<Rathann> i.e. 1:0.1 > 0:5.0
<ogra> (have to look at the initramfs-tools as well ..
<Mithrandir> Rathann: we do, but we try not to use them unless we have to.
<Rathann> ?
<ogra> )
<Rathann> ah
<Rathann> well that's one of those cases I think
<_ion> 1.0~pre8 could be used.
<slomo> Rathann: we have... also with a colon... but if we used them always we would have 1234:1.0 for some packages probably ;)
<Rathann> I'd prefer it if you used the same version as we do
<Rathann> well good news
<Rathann> we're going to do 1.0rc1 soon
<Rathann> probably rc2 too
<Rathann> and then 1.0
<slomo> _ion: yes but at that time ~ was not recommended
<Rathann> and then 1.1. and so on
<slomo> cool :)
<Rathann> so no more weird preN ;)
<Rathann> ok, next issue
<_ion> rathann: 1.0rc1 would also be 0.99+1.0rc1 under the old recommendation. :-)
<Rathann> why do you have so many --enable-*?
<Rathann> most of the stuff is autodetectable
<Rathann> provided you have the appropriate -dev package installed
<Rathann> in fact, we discourage the use of --enable
<dholbach> imbrandon, raphink: does anbody of you know a package using cmake to build?
<_ion> rathann: Perhaps to make it complain if a packager has forgot a dependency that should be there.
<slomo> Rathann: i know... it's there to keep track of what we want to have enabled
<Rathann> because it's known to break things
<slomo> how could it break things?
<Rathann> if you don't provide --extra-libs and --extra-includes
<imbrandon> dholbach: and kde4 stuff
<Rathann> because it may fail to link
<imbrandon> s/and/any
<slomo> Rathann: well it but then it would be a build failure which we would notice and fix then :)
<dholbach> imbrandon: ok, got an example package?
<Rathann> slomo: keeping track of builddeps should be enough
<Rathann> --enable are evil
<imbrandon> i THINK speedcrunch , i will have to check one sec
<Rathann> ;)
<slomo> Rathann: imho it's easier this way ;) and until now we always had a mplayer that was buildable ;)
<dholbach> imbrandon: doesn't look like it
<imbrandon> dholbach: i just pinged Riddell  he will know for sure
<imbrandon> not much outside kde4 does atm
<dholbach> imbrandon, Riddell: i'm trying to help the telepathy-qt upstream author to package it and get it into ubuntu
<Rathann> ok, that's your choice
<Rathann> slomo: but if you didn't use --enable then you wouldn't have to patch configure for aalib, fontconfig and faac detection
<imbrandon> dholbach: check kde4base
<dholbach> imbrandon: rock and roll - checking
<Rathann> slomo: ok, next issue
<slomo> Rathann: probably, i'll consider it with the next release
<Rathann> AFAIK libmpdvdkit2 (libdvdcss) doesn't contain decss
<dholbach> imbrandon: thanks a lot
<imbrandon> dholbach: np
<slomo> Rathann: at least in the past it did
<Riddell> dholbach: strigi probably an easier starting point
<Rathann> it never did AFAIK
<Riddell> dholbach: there's a cmake.mk cdbs file in there
<dholbach> Riddell: neat - that should be in our cdbs too, no?
<Rathann> well, that doesn't really matter if you link with libdvdread
<Rathann> next issue
<Riddell> dholbach: no, it's just included within the package for now
<dholbach> hm
<slomo> Rathann: it's still in there... just look in your tarball ;)
<imbrandon> dholbach: tell him/her they are welcome to pop in #kubuntu-devel anytime also , we'll try to help
<Rathann> slomo: what is in there?
<Rathann> and which tarball do you mean?
<slomo> Rathann: libdvdcss (and the tarball from mplayerhq.hu
<Rathann> yes and?
<Rathann> it doesn't contain the illegally obtained CSS keys
<Rathann> which was what the fuss was about mainly
<Rathann> it's still illegal according to DMCA, probably, though
<Rathann> but that's another discussion ;)
<slomo> yes... and we simply don't want to ship it but this was already discussed a million times everywhere ;)
<Rathann> ok
<Rathann> what else... ah
<Rathann> mplayer and mplayer with GUI (gmplayer) can be installed simultaneously
<Rathann> just rename the binary with gui to gmplayer
<slomo> i know... currently the guy package has gmplayer as link to mplayer
<slomo> but what sense would it make to have almost the same binary installed twice?
<Rathann> well, gmplayer is more broken than  mplayer ;)
<Rathann> but some people insist on using it
<Rathann> so when something doesn't work with gui
<slomo> Rathann: even when using it as "mplayer", i.e. without gui?
<Rathann> we can tell people to try without gui
<Rathann> yes
<Rathann> because some codepaths are different then
<Rathann> well, it's your choice, really
<Rathann> I package mplayer and mplayer-gui in such way that they can be installed simultaneously
<Rathann> ah, good thing you don't have Depends: w32codecs
<Rathann> and good thing you use scalable font by default
<slomo> that won't work anyway as we don't have it packaged anywhere ;)
<Rathann> although instead of linking it to usr/share/mplayer/subfont.ttf
<Rathann> you can add fontconfig=yes and font="font name" to mplayer.conf
<Rathann> since you already link with fontconfig
<Rathann> just a tip to consider
<slomo> sounds sane ;)
<Rathann> that's about it
<Rathann> oh, did you read the packaging guidelines?
<Rathann> in DOCS/tech/ ?
<slomo> ages ago, yes
<Rathann> ok
<Rathann> slomo: next time, please forward the bugreports to us, ok?
<Rathann> thanks for packaging mplayer :)
<Rathann> and keep up the good work
<Rathann> also, please have a word with ffmpeg pkg maintainer
<Rathann> about updating it
<slomo> Rathann: sure :) i guess he will update it soon in debian
<Rathann> good
<Rathann> see you around then (come to #mplayer/#mplayerdev sometimes, we don't bite... much) ;)
<slomo> here on freenode?
<Rathann> yes
<slomo> ok, perfect :)
* Rathann waves
<slomo> thanks for your time :)
<Rathann> np.
<Kamion> hmm, a dilemma
<_ion> The answer is 42.
<Kamion> I'd like to add something to ubiquity to say "make sure you've done a CD integrity check before reporting this crash"
<Kamion> but if I do that, a sizeable number of people will reboot to do that check before saving the log files
<Kamion> and some problems will certainly be lost forever
<Kamion> it would be better if there were actually a useful way to report such errors - the problem is that they can and do manifest in practically every imaginable way
<Kamion> from failures to read certain files, to corrupted code running in the live session
<Kamion> I can't even trust debconf to work reliably in that environment, small though it is
<Kamion> at least with the alternate install CD, most of the running code is found close to the centre of the CD, and seems to be less prone to random corruption - MD5 checks on Packages files catch the rest
<mjg59> Kamion: People seem to be running out of RAM on ubiquity even on 256MB systems
<mjg59> Kamion: I think we're going to need to consider a pure-ubiquity (ie, non-Gnome) option
<Kamion> Mithrandir: how insane do you think it would be to put an md5sum.txt somewhere and have all the files in the squashfs checked on startup?
<Kamion> I mean, would it actually work out insanely slow, given that we have to read big chunks of it anyway?
<Kamion> mjg59: patches welcome. (seriously. I hate that kind of code.)
<Kamion> I hate writing it, anyway
<mjg59> Kamion: Right
<Mithrandir> Kamion: I could just make the cdrom-checker bit non-optional and non-rebooting.
<Kamion> also I'm not sure we've exhausted our "just make it use less memory" options
<mjg59> Kamion: This is cheap and can be implemented fairly fast
<mjg59> But obviously general resource usage improvement would be better :)
<Kamion> sure, but it also has heavy UI implications
<mjg59> Do you have time allocated for that before release?
<Kamion> at present, I'm entirely bug-fixing, and memory use counts
<Kamion> well, pretty much entirely
<mjg59> Kamion: Ok
<Kamion> currently I'm trying to get the ubiquity bug list under control, and fixing stuff along the way
<shackan> xfce is not an option ?
<Kamion> not here
<Kamion> the Ubuntu desktop CD also serves as a demonstration of the Ubuntu desktop, which is GNOME
<Kamion> we do not have room to put XFCE on the disk as well
<dholbach> Riddell, slomo: is libdbus-qt4-1-dev meant to be used?
<slomo> dholbach: no... something from qt4-x11-kdecopy should be used
<dholbach> aha
<slomo> dholbach: libdbus-qt4-1* will disappear soon after openoffice is finally rebuild against new dbus
<slomo> dholbach: but better talk to Riddell about qt stuff... i try to touch c++ as less as possible ;)
<dholbach> libqt4-core-kdecopy? maybe?
<slomo> yes
<dholbach> good night everybody
<Riddell> dholbach: you need qt 4 dbus?
<dholbach> Riddell: telepathy-qt does
<Riddell> dholbach: unless it's using qt 4.2 use libdbus-qt4-1-dev
<dholbach> Riddell: hum, that's not installable
<Riddell> uh oh
<slomo> BenC: ping?
<Kamion> bug 54787> you know I'd never really considered the notion of putting /var on NTFS ...
<Ubugtu> Malone bug 54787 in ubiquity "Installer crashes" [Untriaged,Needs info]  http://launchpad.net/bugs/54787
<Kamion> though I did add a check for it, but only along with a bunch of other stuff :)
<dieman> Kamion: heh
<dieman> Kamion: i could see putting /boot on NTFS though
<dieman> alltho i'd just use fat32 at that point
<dieman> makes it easier to edit grub's config from windows if you want to automate boot changes
<Kamion> dieman: I don't think I'd want to put /boot on a filesystem that Linux can't write to reliably
<Kamion> bug 55106 wins some kind of descriptive bug subject prize
* Kamion ponders replying "!" and seeing if the reporter gets the allusion
<desrt> bug 55106
<Ubugtu> Malone bug 55106 in ubiquity "?" [Untriaged,Needs info]  http://launchpad.net/bugs/55106
<shining> lol
<shining> found this quite funny, but I've to admit I generally don't find it obvious how to correctly report a bug, what information is relevant
<Kamion> shining: a clue is that if a dialog pops up asking you to report a bug and attach certain pieces of information, then you should follow its instructions ;)
<shining> oh :) it's worse than I thought then
<Kamion> mjg59: could you have a look at bug 46853?
<Ubugtu> Malone bug 46853 in ubiquity "grub install fails on Macbook Pro" [Medium,Confirmed]  http://launchpad.net/bugs/46853
<Kamion> suggestions of grub patches in there
#ubuntu-devel 2006-09-19
<DonDiego> siretart: hi
<DonDiego> siretart: we talked at linuxtag..
<mjg59> Kamion: The failure is because we've written a gpt partition table and grub wants to install into the mbr
<mjg59> So those patches on their own won't fix that
<gnomefreak> anyone know why libgmime before tomboy upgrade is libgmime2.1 and after is libgmime-2.0-2. that seems its going down in version number
<DonDiego> slomo: Rathann tells me that you are working on the debian package for ubuntu?
<mjg59> Kamion: We need to decide what to do about the partition table trouble
<DonDiego> siretart: weren't you working on the mplayer package as well?
<DonDiego> siretart: or other multimedia packages?
<slomo> DonDiego: mplayer? yes, we both work on it
<DonDiego> ah
<slomo> and both on other multimedia related packages too ;)
<slomo> why?
<DonDiego> i'm an mplayer developer
<DonDiego> i was looking over your package
<mjg59> Kamion: On the other hand, we probably need the grub patch anyway, so feel free to throw that in
<zul> mjg59: i could have swore that grub patch made it in to the grub merge from debian
<DonDiego> wait, i'll paste you the log of my conversation with Rathann in private..
<siretart> DonDiego: hi
<DonDiego> hi
<slomo> DonDiego: did you already paste it?
<siretart> DonDiego: I touched the mplayer package, yes. currenlty, I'm more focusing on the xine-lib pacakge, though
<mjg59> zul: Quite possible
<DonDiego> just a sec
<slomo> siretart: could you update liba52 from cvs in the next days? it has many fixes from mplayer... at least that's what i was told
<DonDiego> oh, they merged our patches?
<Fujitsu> mjg59, can you please tell me what happened with bug #54188? You set it to Fix Released, but the fix never appeared.
<siretart> slomo: okay, I'll add it to my todo list
<slomo> DonDiego: Rathann said it
<Rathann> I thought they did...
<DonDiego> slomo, siretart, please /join #mplayer-packaging
<geser> Fujitsu: I assume it's because mjg59 set distribution to unstable
<Rathann> I think someone wrote it in our mailing list...
<Fujitsu> Ah, so he did.
<Fujitsu> That would do it.
<geser> at least the changelog entry in the bug mentions unstable instead of edgy
<Fujitsu> geser, yeah, I noticed...
<mjg59> Oh, that would be why
<mjg59> I suck
<Fujitsu> I made that mistake once... Hobbsee attacked me with her long stick of DOOM for it.
<Fujitsu> SOmebody just noted in the incorrect resolution bug that it no longer worked.
<Fujitsu> It'd be really nice if Soyuz actually informed people if they uploaded stuff like that, I hear it just silently drops it.
<Kamion> Fujitsu: I believe that's been fixed (possibly not deployed yet), with the exception that invalid signatures still don't trigger a mail
<Kamion> I think they're being paranoid about only mailing people once they have an authenticated reason to do so
<Fujitsu> OK...
<Fujitsu> 'cause I had an upload once that had unstable as the distribution, and I was most mystified when it ceased to appear anywhere.
<Kamion> zul: if you want to check, that'd be good
<Fujitsu> mjg59, have you still got the source for that upload?
<mjg59> Fujitsu: No
<Fujitsu> mjg59, shall I redo it?
<mjg59> Sure
<Fujitsu> I was in the middle of doing it anyway when I discovered that bug.
<LaserJock> Kamion: would doing chmod 640 after dh_fixperms in edubuntu-menus make you happy enough?
<Kamion> sure
<bddebian> Howdy folks
<nictuku> bddebian, hi
<bddebian> Hello nictuku
<Fujitsu> :(
<ogra> :(
<Fujitsu> A week later...
<ogra> yeah
* ajmitch wonders if he'd even be involved if it weren't for freenode being round those years ago
<whiprush> ogra: how's your head?
<Fujitsu> D:
<ogra> whiprush, fine 
<ajmitch> hey whiprush 
<whiprush> hey aj
<ogra> whiprush, i had only 3 beers down there
<whiprush> I didn't drink, my head is mostly ringing from the sonic sweetness of it all
<whiprush> mdz: Wish You Were Here
<ogra> well, my ears are :)
<ajmitch> whiprush: you going to the ohio linuxfest?
<whiprush> ajmitch: yessir.
<ajmitch> nice
<whiprush> ajmitch: talking about all this integration stuff that's suddenly popular.
<ajmitch> what a surprise
<whiprush> ajmitch: in fact I got a mail today from a proprietary company asking if I would pimp their integration products.
<whiprush> I'm like ... "uhhh ... no."
<ajmitch> whiprush the superstar
<whiprush> ajmitch: I'm mostly here for the partying, not the superstardom. :p
<ajmitch> heheh :)
<ogra> whiprush, see ... i told you so ;)
<ogra> your a celebrity
<ogra> *you're
* ajmitch has more some ideas of where to improve things now.. :)
<bddebian> HMM
<whiprush> heh
<fabbione> morning
<Hobbsee> hey fabbione 
<Capt_Blood_Ponin> arrr
<Fujitsu> Yar.
<jdub> hey fabbione 
<jdub> fabbione: i forgot to ask - should i reboot to test the md/uuid stuff, or hasn't a fix landed?
<fabbione> yo yo
<fabbione> jdub: yes the fix is there. 
<fabbione> you can reboot if you want
<jdub> rock!
<jdub> ok
<jdub> maybe now is an ok time ;)
<fabbione> jdub: did it work?
<jdub> fabbione: haven't rebooted :)
<fabbione> tsk
<jdub> fabbione: (my irc client is on the machine to be rebooted, for reference)
<jdub> :)
<fabbione> ah ok
<mdz> whiprush: had a great time I hope?
<fabbione> hey mdz
<mdz> morning fabio
<whiprush> mdz: there are no words.
<fabbione> how you doing?
<mdz> fabbione: sweaty
<mdz> I just played volleyball for 2 hours
<fabbione> ehe
<fabbione> mdz: we still have a pending phone call.. what about in 10/12 hours when you wake up?
<mdz> fabbione: or now
<fabbione> mdz: it's better later..
<mdz> my brain works better at night anyway
<fabbione> if you don't mind
<fabbione> i am not awake enough yet..
<mdz> ok
<mdz> one of us will always be off our rhythm :-)
<fabbione> hmm we can also make it even later.. i don't mind
<Kagou> hi
<jdub> Fujitsu: yay! thanks for the 915 fixage
<jdub> now we just have to get the sucker in the desktop seed
<Fujitsu> jdub, that'd be nice.
<Fujitsu> jdub, I noticed it myself when I installed edgy a while back, but thought little of it.
<Fujitsu> Then I realised that it should have automatically configured, after somebody commented on that bug.
<Fujitsu> It'd be really nice if it'd get promoted at least :(
* Fujitsu looks for other things to fix.
<ph8`> Mithrandir:  ping?
<jdub> ever since i started using edgy from a non-upgrade edgy install
<jdub> vim has been bollocks
<jdub> and that's with 'vim'
<jdub> not vim-tiny
<jdub> my alternatives seem to be correct
<jdub> but it doesn't automagically detect gzip files
<jdub> and it doesn't do syntax highlighting correctly
<Fujitsu> jdub, mine works fine.
<Mithrandir> ph8`: hiya
<jdub> Fujitsu: did you upgrade?
<ph8`> n/m now mate, the amd64 iso appeared ;)
<Fujitsu> jdub, no.
<ph8`> did the kernel build in the end?
<Hobbsee> hey Mithrandir 
<Mithrandir> hiya Hobbsee 
<jdub> Fujitsu: dpkg -l | awk '/vim/ {print $2}' ... ?
<jdub> $ dpkg -l | awk '/vim/ {print $2}'
<jdub> vim
<jdub> vim-common
<jdub> vim-runtime
<jdub> vim-tiny
<jdub> 
<Fujitsu> I've got those + vim-gnome, vim-gui-common and vim-latexsuite, but they won't matter.
<fabbione> jdub: what about dpkg -l vim* ?
<fabbione> jdub: you awk lover
<jdub> fabbione: too much noise for irc pastage
<matiu> How can I install libglib2.0-dev ?
<dholbach> good morning
<matiu> It seems to be depending on a non-existant package... is it the same for others ?
<Fujitsu> Heya dholbach.
<dholbach> hey Fujitsu
<Kamion> epends: libglib2.0-0 (= 2.12.3-1ubuntu1), libc6-dev | libc-dev, pkg-config (>= 0.14.0)
<Kamion> looks ok ...
<dholbach> matiu: do you have any other apt sources in your sources.list?
<Kamion> (morning)
<matiu> just dapper standard...
<Mithrandir> ph8`: the new kernel was just uploaded, so no, there's not a new kernel on the ISOs
<matiu> I had other before, but I've done lots of apt-get update's since removing them
<Kamion> what error message do you get when you try to install it?
<matiu> libglib2.0-dev: Depends: libglib2.0-0 (= 2.10.2-1ubuntu3) but 2.10.3-0ubuntu1 is to be installed
<matiu> but 2.10.2-1ubuntu3 seems to not exist
<jdub> hrm, this is interesting
<jdub> when doing :syntax on once vim is loaded, i get:
<jdub> Error detected while processing /usr/share/vim/vim70/syntax/syntax.vim:
<jdub> line   42:
<jdub> E216: No such group or event: filetypedetect BufRead
<jdub> 
<Fujitsu> Er, that's odd!
* jdub tries a cleaner .vimrc
<Fujitsu> Good idea.
<Hobbsee> matiu: did you install something like xgl?
<Kamion> matiu: 2.10.2-1ubuntu3 is the version in dapper; 2.10.3-0ubuntu1 is the version in dapper-updates
<jdub> same thing with no vimrc!
<Kamion> matiu: you'll probably get a better error message if you now try 'apt-get install libglib2.0-dev libglib2.0-0' to see why it doesn't want to upgrade libglib2.0-0
<Kamion> and then iterate until it tells you the actual problem :)
<matiu> Kamion: same message
<matiu> Perhaps i don't have dapper-updates in my sources
<matiu> I have dapper-updates main restricted
<Kamion> BenC_: next kernel upload, could you please build nvram in on powerpc? (I filed a bug about that - it stops ybin working on fresh installs)
<matiu> ah! dapper-updates, is only in there with deb-src
<matiu> thanks Kamion
<Kamion> yup, that would do it - np
<ph8`> Mithrandir: eep? :/ The one ben uploaded yesterday (that was broken) isn't there then? How about tomorrow?
<Mithrandir> ph8`: the one uploaded yesterday failed to build.
<ph8`> right - but today's was ok?
<Mithrandir> I don't know, it hasn't been built yet.
<ph8`> ah ok
<ph8`> if it builds ok, it will go into tomorrow's isos?
<Mithrandir> yes
<ph8`> fantastic
<ph8`> cheers
<Kamion> yeah, that happens automatically
<jdub> $ ls /etc/vim/
<jdub> total 8.0K
<jdub> -rw-r--r-- 1 root root 2.3K 2006-07-23 04:05 vimrc
<jdub> -rw-r--r-- 1 root root  774 2006-07-23 04:05 vimrc.tiny
<jdub> 
<jdub> doesn't appear to be upgrade related issues as noted by numerous posts on google
<matiu> I have a package, that I'd like to get into ubuntu
<matiu> How do I do it?
<Kamion> start at #ubuntu-motu
<dholbach> matiu: join #ubuntu-motu
<Kamion> infinity: is the stacked-filesystems stuff ready for deployment?
<carlos> Riddell: hi, would be possible that the changes to kdebase to extract the .pot files that you did for Dapper are not applied to Edgy?
<carlos> Riddell: https://devpad.canonical.com/~andrew/paste/fileTECbIl.html
<carlos> Riddell: that's a list of templates that weren't imported last night because had some msgid that are not using ASCII encoding but with the encoding field doesn't say that is UTF-8
<pitti> Good morning
<carlos> Riddell: would be possible to set all KDE .pot files as being UTF-8 by default so we don't get this error anymore?
<Riddell> carlos: you'll need to /msg me the password for that
<carlos> Riddell: ASCII is a subset of UTF-8 so it should not be a problem
<carlos> Riddell: same as chinstrap's website
<Riddell> I have no idea what that is :)
<carlos> Riddell: I see ;-)
<Riddell> carlos: I've added that to my ToDo list for the day
<carlos> Riddell: ok, thanks
<Riddell> although it should all be the same as in dapper, buy maybe I missed the UTF8 conversion out
<carlos> Riddell: just extract all them as UTF-8 so you don't need to maintain the list of .pot files that need it
<Riddell> yes
<seb128> iwj: hi. Do you know about bug #61160?
<Ubugtu> Malone bug 61160 in totem "totem cannot be build (xpidl compiler not found)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61160
<seb128> Riddell: do you have any objection to build poppler with splash again?
<Riddell> seb128: remind me again what that is
<seb128> Riddell: there is a splash and a cairo backend, but I think it's glib specific, the qt backend always use splash or something like that
<seb128> Riddell: just checking with you before making the change in case that would be an issue for kubuntu but it's probably not ;)
<Riddell> seb128: so long as it doesn't touch the qt side I don't mind at all
<seb128> Riddell: ok, good
<Riddell> seb128: just make sure it doesn't add new dependencies to the qt package I guess
<seb128> Riddell: will do
<seb128> Riddell: 
<seb128> configure: error: Qt4 development libraries not found
<seb128> See `config.log' for more details.
<seb128> Riddell: you didn't add a Build-Depends to poppler for qt4 apparently, is that on purpose?
<Riddell> hmm, I'm sure I did
<seb128> Riddell: maybe you modified debian/control instead of debian/control.in?
<Riddell> oh, control.in evilness
<seb128> Riddell: I'll fix that, what Build-Depends are required?
<Riddell> libqt4-dev should be the one
<seb128> ok, thank you
<fabbione> hey mvo 
<mvo> hey fabbione, thanks for your bugreport
<fabbione> mvo: when you get a minute could you look at bug 61225 please?
<Ubugtu> Malone bug 61225 in gnome-app-install "[EDGY]  fails to upgrade" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61225
<fabbione> ah perfect.. you already did :)
<fabbione> no problem at all
<mvo> fabbione: I already uploaded a new version that may fix the issue. i'm not 100% sure though
<mvo> the trouble is that I seem to be unable to reproduce it on my upgrade testing machine
<fabbione> mvo: that was on a normal desktop
<mvo> how do you test this?
<fabbione> oh ok
<fabbione> mvo: just normal apt-get upgrade..
<fabbione> running as root
<fabbione> no DISPLAY set
<mvo> thanks, I will test this myself then. I have a non-interactive dist-upgrader here but it apparently gets the ordering right :/
<fabbione> mvo: i don't think it's an ordering problem
<fabbione> the error appears even if it is the last thing to upgrade
<mvo> fabbione: interessting. can you run "/usr/sbin/update-app-install" on the (mostely upgraded) system? does that give you the same error
<fabbione> mvo: yes.. same error
<fabbione> machine updated 1 hour ago
<fabbione> i can try another upgrade.. assuming there is anything
<mvo> fabbione: what versions of python-xdg, python-gtk2, python-gobject are installed?
<mvo> fabbione: that looks like its a problem with the system somehow. does python -c 'import gobject' work?
* mvo wonders if maybe something is wrong with python on sparc
<fabbione> python-xdg: 0.15-1.1ubuntu1, python-gtk2_2.10.1-0ubuntu1_i386.deb, python-gobject_2.12.1-0ubuntu2_i386.deb
<fabbione> all installed
<fabbione> python -c 'import gobject'
<fabbione> Traceback (most recent call last):
<fabbione>   File "<string>", line 1, in ?
<fabbione>   File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 30, in ?
<fabbione> 
<fabbione> ImportError: No module named _gobject
<mvo> fabbione: right, so something with python is not working ... could you please try removing "python2.4-imaging"?
<fabbione> Note, selecting python-imaging for regex python2.4-imaging
* fabbione does
<fabbione> mvo: same error
<mvo> fabbione: in the same file?
<fabbione> python -c 'import gobject'
<fabbione> Traceback (most recent call last):
<fabbione>   File "<string>", line 1, in ?
<fabbione>   File "/usr/lib/python2.4/site-packages/cairo/__init__.py", line 30, in ?
<fabbione> ImportError: No module named _gobject
<ajmitch> hm, there are a few bugs filed that looked similar but aren't 
<mvo> fabbione: do you have *.so files under /usr/lib/python-support/python-gobject ?
<fabbione> python-gobject# ls
<fabbione> python2.4  python2.5
<fabbione> there is a so for each dir
<fabbione> |-- python2.4
<fabbione> |   `-- gtk-2.0
<fabbione> |       `-- gobject
<fabbione> |           `-- _gobject.so
<mvo> hm, looks good 
<ajmitch> and /var/lib/python-support/python2.4/gtk-2.0/gobject/_gobject.so
<ajmitch> ?
<fabbione> i guess ajmitch just found the problem
<fabbione>  4 lrwxrwxrwx 1 root root    76 2006-09-17 10:46 _gobject.so -> p????Y???u?c?Ts?k???Nf??????EK?F??j??.?b?U???t?2??W??U???Jj???>U1Fm??{?F??"?j?JL????^??g`W?U?m?{???^?VcC???????ne?G?????w?Gc??kp??O????y?%?.?Q?t??C:}?P?am???vCi?t?Ri?????*?:???_???????9??????P?I???~c??L?d:??z???7w???????q+??g????? ?] =??|z?$*?P?U??????????',}B?=jU??????????oJ??w??*?dxU??? ??
<mvo> I suspect its something related to the new python-central and that this one is upgraded too late. could you please try reinstalling python-gobject. if that fixes the issue, its a ordering porblem
<mvo> fabbione: what is that?
<fabbione> this is FS corruption
<ajmitch> fabbione: that doesn't quite look right :)
<mvo> aha
<azeem> fabbione tries to exploit my irssi
<fabbione> ok.. later
* fabbione does a reboot of death for super fsck
<seb128> Riddell: obviously you added a binary package to debian/control too, do you still have that change locally? could you put it somewhere online?
<Riddell> oh crivvens, that will have been wiped too, hang on
<Riddell> seb128: http://kubuntu.org/~jriddell/tmp/control
<Riddell> hopefully libpoppler1-qt4.install and libpoppler-qt4-dev.install won't have been killed by control.in
<Riddell> seb128: by the way I heard there may be a new poppler release today
<seb128> Riddell: that control doesn't list a -qt4 package
<Riddell> seb128: reload
<fabbione> mvo: ping?
<mvo> fabbione: pong
<fabbione> mvo: it looks like that /var/lib... etc is not shipped in packages.. how can i regerate it's contents?
<fabbione> regenerate
<dholbach> fabbione: /var/lib/ what is that? something with python-support?
<fabbione> yes
<mvo> fabbione: try reinstalling the python-gobject package
<fabbione> dholbach: see above..
<fabbione> mvo: that was not the only package corrupted
<fabbione> mvo: there were several 
<dholbach> seb128, doko: is this part of the python-support problem we talked about some days ago?
<seb128> Riddell: ok, looks correct now, ta
<seb128> dholbach: I doubt of it
<dholbach> hmh mh
<mvo> fabbione: doko will know how to mass re-generate that
<fabbione> found it
<fabbione> mvo: thanks.. you can close the bug :)
<fabbione> update-python-modules -v -b -i -a -f <-
<mvo> fabbione: thanks
<Hobbsee> mvo: thanks for your recent bugfix of gtk2-engines :)
<Hobbsee> mvo: x2
<mvo> Hobbsee: cheers
<Hobbsee> mvo: took me ages to figure out what on earth was going on :P
<seb128> what was the bug about?
<dholbach> missing conflicts replaces
<seb128> those errors are pretty obvious usually no?
<dholbach> you only noticed it from upgrades from dapper to now
<dholbach> because they reintroduced dummy packages etc
<seb128> I mean the message is clear about file existing to the different packages no?
<dholbach> and I merged them without noticing
<seb128> and I thought mvo did fix that one on friday ;)
<mvo> seb128: I did, but I was fooled by control vs. control.in
<seb128> ah, yet another one
<seb128> mvo: you should document to changelog what files you are modifying :p
<seb128> would make easier to spot errors like that ;)
<mvo> seb128: I usually do (unless the changes are trivial *cough*)
<seb128> hehe
* seb128 hugs mv
* seb128 hugs mvo
<mvo> seb128: the vmware-modules package has a nice #THIS FILE IS AUTOGENERATED" header in the control ....
* mvo thinks that this would be cool for the gnome team as well :P
* mvo hugs seb128
<seb128> mvo: oh, we can use comments to debian/control?
<seb128> I didn't know
<seb128> could be an idea, right ;)
<simira> mvo: u-m just seems to just load "list of changes" forever... 
<mvo> simira: it may have crashed :( can you see something in .xmessages?
<mvo> seb128: well, when auto-generating debian/control on the buildds they remove the comment again :)
<seb128> ah, k
<simira> I have no .xmessages, .xsession-errors says nothing
<simira> mvo: I'm lying
<mvo> simira: don't do that :)
<mvo> its a sin!
<janimo> Gloubiboulga: hi
<iwj> seb128: bug 61160> I'm afraid I don't know anything about that.  It wasn't a change we made; I could check to see if it was something Debian did but I doubt it.
<Ubugtu> Malone bug 61160 in totem "totem cannot be build (xpidl compiler not found)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61160
<iwj> So I think it's a decision by upstream.
<seb128> iwj: if that's upstream it puts us in a delicate position
<seb128> iwj: it means we have to start using xulrunner and promote it to main
<iwj> Let me look at the build tree.  I assume it must built it.
<seb128> ok, thank you
<seb128> iwj: 
<seb128> "  * debian/firefox.install: Don't install xpt_link, xpt_dump, xpidl,
<seb128>     xpicleanup, xpcshell nor regxpcom. They are of no use to firefox users and
<seb128>     are provided with xulrunner anyway. (Closes: #362190)
<seb128>  -- Mike Hommey <glandium@debian.org>  Sun, 20 Aug 2006 19:49:25 +0200"
<seb128> iwj: from the package changelog
<iwj> Ah.
<iwj> OK, well I can undo that.
<seb128> iwj: we probably want that reverted for Ubuntu
<seb128> thank you
<iwj> NP.
<iwj> I should have read that changelog really.
<Mithrandir> mvo: is there a way to tell the tool which pops up when you insert a cd with debs on that you would like to never ever be annoyed by it again?
<bluto> Mithrandir: System --> Preferences --> Removable drives and media --> Multimedia --> untick "Play audio CD discs when inserted" or choose a different command from the drop-down.
<bluto> ?
<Mithrandir> bluto: it's a) not a CD I'm putting in, and b) it's not an audio CD.
<bluto> yeah, sorry
<mvo> Mithrandir: it should not nag you once the cd was added via apt-cdrom/synaptic etc
<mvo> Mithrandir: I could add a preference to never act on CDs though (if you insert a lot of different CDs)
<Mithrandir> mvo: well, I have this habit of making live cds, you see..
<Mithrandir> mvo: I never ever use the graphical tools for managing my packages or sources anyway, so it would be good if I could tell it to go away.
<mvo> Mithrandir: if you never ever use a graphical tool you may just remove update-notifier from your session
<Mithrandir> mvo: I tried, but it came back, iirc.  And I lost the "reboot required" notifications that way.
<mvo> right
<mvo> I make a note to add a preference for you
<Mithrandir> thanks.
<seb128> looks like a gconf-key option candidate ;)
* mvo looks at his TODO and cries
<mvo> rigth
<bluto> heh
<Mithrandir> sure, I'm happy with putting it into my list of commands I run when I create a new account.
<Kamion> argh, the gtkmm documentation is so hopelessly incomplete
<Kamion> http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1OptionGroup.html <-- yeah, thanks for all the details :-/
<dholbach> Kamion: file:///usr/share/doc/libglibmm-2.4-dev/reference/html/classGlib_1_1OptionContext.html might help
<dholbach> oh no sorry
<dholbach> it's the same
<Kamion> using the glib documentation helps, but I shouldn't have to; pygtk gets this right
<dholbach> *nod* :-/
<Kamion> it isn't just a missing build option somewhere? I never quite understood how the pygtk documentation was produced
<pitti> slomo: what was the bug again where apport picked the wrong package? (mono instead of the app)
<slomo> pitti: pick a random bug that was assigned to mono first :P https://launchpad.net/distros/ubuntu/+source/tomboy/+bug/61238
<pitti> slomo: ah, thanks
<ajmitch> pitti: like anything that uses mono :)
<slomo> someone please make LP faster again :P
<ajmitch> where /proc/$pid/exe is a symlink to /usr/bin/mono
<Fujitsu> slomo, it's not just me?
<pitti> ajmitch: hm, 0.20 should have already fixed that actually
<pitti> ajmitch: at least it fixed it for shell and python
<pitti> will try it out here with tomboy
<ajmitch> I haven't had a recent creash to try it on
<slomo> pitti: it definitely isn't for mono :(
<slomo> ajmitch, pitti: tomboy as panel applet is a good candidate ;)
<ajmitch> I have to find some clear panel space first :)
<pitti> slomo, ajmitch: ah, I know the reason
<slomo> pitti: you might also want to look at banshee... at does evil magic with setting the process name (and some other mono applications do this too now) but exe is still a symlink to /usr/bin/mono
<pitti> slomo, ajmitch: /proc/pid/status Name: says 'tomboy', but it executes Tomboy.exe
<slomo> pitti: same for banshee then... "Name: banshee" which is executed via /usr/bin/banshee and calls mono with /usr/lib/banshee/banshee.exe
<pitti> slomo: yeah, the problem is that it is exec'ed by a shell script
<ajmitch> which is cli policy
<pitti> so it's hard to find out what the name actually is
<pitti> maybe I should just special-case mono
<ajmitch> mono is pretty special :)
<slomo> pitti: dpkg -S /usr/bin/`grep ^Name /proc/$pid/status | cut -d: -f2` or something like that maybe? :)
<pitti> hm, I'll think about it
<ajmitch> slomo: that'd slow down apport even more :)
<slomo> ajmitch: it calls dpkg -S or something similar anyway
<pitti> yeah, that part is not the problem
<ajmitch> ah right
<pitti> I'll probably check for $Name in /bin, /sbin, /usr/bin, /usr/sbin
<slomo> pitti: which $name is probably better
<slomo> and if it starts /usr/local break
<pitti> slomo: I don't have an environment in apport
<slomo> oh
<slomo> ok :)
<pitti> it's called directly by the kernel
<pitti> right now I check if /proc/status' Name matches the basename of the second command line arg
<ajmitch> slomo: you saw that bug 60114 had /usr/local/lib/banshee/banshee.exe ? :)
<Ubugtu> Malone bug 60114 in banshee "Banshee crashes" [Untriaged,Needs info]  http://launchpad.net/bugs/60114
<ajmitch> I think that could warrant a reject :)
<slomo> ajmitch: done, thansk for spotting :)
<Fujitsu> They filed a bug about a locally compiled one... That's most impressive.
<ajmitch> Fujitsu: it's common, especially if they forgot they had an old version lying round
<Fujitsu> How silly.
<infinity> Happens all the time.
<slomo> and this bug was assigned to "mono" so the guy probably thought it was a bug in mono that his own banshee crashed *shrug*
<infinity> More fun is tracing crashes in packaged binaries to them being linked with hand-installed libraries.
<infinity> Which also happens all the time.
<Fujitsu> Fun fun fun.
<bluto> any chance someone could triage bug #58469
<Ubugtu> Malone bug 58469 in linux-source-2.6.17 "via-rhine net card stopped working in 2.6.17" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58469
<bluto> (please)
<gnomefreak> bluto: did you try 2.6.17-7 kernel?
<pitti> hi tkamppeter 
<Seveas> Kamion, elmo, CC meeting in T minus 3 minutes
<elmo> doh
* Hobbsee waves to elmo 
<tkamppeter> pitti, hi
<bluto> gnomefreak: yes, latest kernel
<bluto> gnomefreak: did a tcpdump and can see the bootp requets going from the client but nothing arrives at the server
<doko_> tkamppeter: ping
<mvo> Mithrandir: I have working task support for apt-get, the only problem now what to do if two conflicting packages are in the same task (e.g. libgl1-mesa-glx and libgl1-mesa-swx11)
* mvo goes for food
<mvo> infinity: same question for you. what should apt-get installtask do if  two conflicting packages are in the same task (e.g. libgl1-mesa-glx and libgl1-mesa-swx11)
<BenC> Kamion: re: nvram/ppc, will do
<tkamppeter> hi doko_
<doko_> tkamppeter: did you see my query?
<doko_> Kamion: please approve openoffice.org for dapper-proposed
<tkamppeter> No, doko_, probably I entered the channel too late.
<tkamppeter> doko_, I have seen it now.
<Mithrandir> mvo: blowing up would be fine.
<Mithrandir> hmm, upstart doesn't seem to reread its files from event.d?
<mvo> Mithrandir: blowing up is what it is doing now. if that is fine I will do some more testing and merge then
<infinity> mvo: Fail.
<Mithrandir> mvo: yeah, I'm happy with that.  It's just like an uninstallable package, really.
<mvo> infinity, Mithrandir: cool, thanks
<TomB|> .
<infinity> mplayer: symbol lookup error: mplayer: undefined symbol: a52_resample
* infinity puts on a grumpy look.
<elmo> what's a good wirelss PCMCIA/cardbus card that works with free drivers in Ubuntu?
<jdub> infinity: damn. puts a damper on pr0n time.
<slomo> infinity: known problem... i'll work on it this night
<elmo> I use to use Cisco aeronet stuff, but that became atheros under the hood
<jdub> really? man. slackers.
<tseng> intel really needs to expand their wifi business into other form factors
<Kamion> elmo: I tend to use netgate.com
<Kamion> who still do prism 2.5 stuff
<infinity> elmo: All things netgate, as Kamion says.
<infinity> Great for building home APs too.
<slomo> infinity: i guess i'll just switch back to the bundled ffmpeg, i don't have the time to port parts of mplayer to the public API of liba52
<infinity> slomo: I can get by with totem for now, if you want to fix it right...
<infinity> slomo: It would appear that my pr0n and totem get along, more or less.
<slomo> infinity: lately everything except some streams worked fine with totem-gst for me ;)
<infinity> slomo: Yeah, it seems much improved.  Still behaves a bit sketchier than mplayer at times, though (well, when mplayer works at all)
<elmo> man their website is slummy
<Mithrandir> mjg59: I'm probably incompetent or something, but I'm unable to get usplash on the live cd to do anything useful when run by hand from the command line.  It never updates the display.
<fatalerror> elmo: ping
<elmo> fatalerror: ?
<fatalerror> elmo: may I /msg you for a server-related "thing"?
<ajmitch> infinity: would you be able to arrange a test build of universe in the future & supply build results so we can clean up failures?
<elmo> fatalerror: sure?
<mjg59> Mithrandir: Uh. How so?
<infinity> elmo: Yeah, their site is sketchy, but I assure you they're above board and have always shipped me quality products.
<infinity> ajmitch: We're going to have to work out how we plan to do that this time around, since the soyuz spec we originally wrote up for this doesn't appear as though it'll make it on time. :/
<ajmitch> right
<infinity> elmo: Will we be able to abuse wanna-build one last time for the mass-rebuild mess?
<Mithrandir> mjg59: I run usplash -c & sleep 3 ; usplash_write PROGRESS 50 ; sleep 1; usplash_write PROGRESS 70 and it doesn't change the progress bar at all.
<Kamion> infinity: oh, how's stacked-filesystems deployment coming along?
<elmo> infinity: -ECONTEXT
<Kamion> Mithrandir: usplash_write's argument syntax sucks
<infinity> Kamion: Should have it fully tested on the buildds tomorrow.
<Kamion> Mithrandir: you need to do usplash_write 'PROGRESS 50'
<Kamion> etc.
<Mithrandir> Kamion: gah, I suck, then
<Kamion> I ran into that last week
<infinity> elmo: mass test rebuilds of edgy.  Was meant to happen in soyuz, that spec's delayed.  We'll need to do it in wanna-build. :/
<Mithrandir> Kamion: hooray, that works.
<Mithrandir> I should fix that.
<fabbione> infinity: what arches are you going to fireup?
<elmo> infinity: with the one buildd per arch?  rock on.  erm, so yeah, that's a little problematic
<infinity> fabbione: The primary arches, at least.  If you want to to sparc privately again, that won't hurt my feelings.
<elmo> infinity: the machine that was running the test archive, became archive.canonical.com \o/
<infinity> elmo: Hah.  Awesome.
<fabbione> infinity: hem.. sparc is primary last i checked.. :)
<fabbione> infinity: i was only wondering if you want to offload your machines, then i can do it here
<Kamion> archive.canonical.com is not exactly that busy though ...?
<infinity> fabbione: Well, for -server anyway. :)
<fabbione> infinity: yeps.. 
<Kamion> (I'd have thought. It has hardly anything in it.)
<fabbione> infinity: but try to explain that (easily) to w-b :)
<elmo> Kamion: yeah, but dak installs don't play nice together, or they do, but it's too easy to break things and/or use the wrong one
<infinity> fabbione: But, yeah, we need to do the test on i386 at least, but if you want to fire up sparc and spare my buildd, I won't complain.
<Kamion> ah
<elmo> it's been done obviously (klecker), but I'd prefer to avoid it
<elmo> so i need to find another .5Tb capable machine to put it on
<fabbione> infinity: ok, i can do that tomorrow probably.
<mjg59> desrt: Ok, so this is very likely not going to work, but:
<infinity> fabbione: That'd rock.
<mjg59> desrt: Can you try putting a call to acpi_early_init in init/main.c above calibrate_delay()?
<fabbione> infinity: i think i still have the old setup on the SAN :)
<infinity> fabbione: If you could make the IMAP folder directly available to ajmitch, so he can filter out universe results at his leisure, that would be even cooler.
<fabbione> infinity: i just need to update it
<mjg59> desrt: Or alternatively, for now, just a hack that sets SCI_EN (like your ICH7 quirk)
<fabbione> infinity: yeah i can do that too
<fabbione> infinity: the imap setup didn't change a bit
<fabbione> infinity: it has only been collecting spam over the past months
<Mithrandir> mjg59: would you be unhappy if I made usplash_write concatenate any arguments it got so it can only be used for one command per invocation?
<mjg59> Mithrandir: I don't have any great objection
<matthewrevell> Hello - anyone seen keybuck today?
<ajmitch> fabbione: any access is fine, we'll have a lot to do anyway :)
<fabbione> ajmitch: it's a very shared imap folder :) nothing more
<ajmitch> fine by me, procmail can sort through it all
<imbrandon> matthewrevell: my /lastlog shows the last time keybuk was talking awas yesterday at 1400 CST
<imbrandon> but it might not be 1000000% acurate ;)
<matthewrevell> imbrandon: Thanks :) It's the best I've got to go on.
<matthewrevell> imbrandon: Supposed to be meeting him tonight, so if anyone spots him, can you prod him to mail me :)
<imbrandon> matthewrevell: sure
<matthewrevell> thanks!
* Nafallo sits and wait for Keybuk, it's his Archive-day today :-)
<Nafallo> Keybuk: morning, o archive admin :-)
<Keybuk> heyhey
<Hobbsee> hi Keybuk 
<bddebian> Howdy folks
<bddebian> doko: ping?
<finalbeta> Perhaps not the place, but would like confirmation. Any person with a laptop running ubuntu edgy (gnome). When closing the laptop screen the setting, do nothing/blanck screen both blanck the screen and end the current session for me.
<fabbione> Keybuk, mjg59: ping?
<mjg59> fabbione: Yes?
<fabbione> guys do you have any idea when we will get text output in usplash?
<Keybuk> fabbione: the plan is for no next output?
<Keybuk> boot without "quiet"
<mjg59> Keybuk: We still need fsck output
<fabbione> Keybuk: what happens when there is an fsck for huge disks?
<fabbione> yeah exactly
<Keybuk> fabbione: that will be fixed before beta freeze
<Keybuk> I have it working here, I think, but want to give it some more testing
<fabbione> Keybuk: ok.. i was just wondering what was the plane..
<fabbione> Keybuk: i also found a couple of things that would be nice to have in upstart, but i will file bugs either later or tomorrow
<fabbione> Keybuk: like the option to force fsck on the next reboot. IIRC sysvinit had it.
<finalbeta> I hope the file check will be diffrend then in dapper, forcing you to wait on houre with no progress bar looking at a blinking _
<fabbione> mjg59, Keybuk: thanks for the info tho.
<Keybuk> fabbione: it never worked in sysvinit
<Keybuk> which is why I never copied the code
<Keybuk> somebody forgot the root filesystem wasn't writable, etc.
<Keybuk> fabbione: the plan is easy, just output messages to /dev/console and with an "URGENT" text to usplash
<fabbione> Keybuk: i also have a strange behaviour on normal installations.. ctrl+alt+del on text brings "nowhere"
<Keybuk> "nowhere" ?
<fabbione> it brings me to a # prompt
<mjg59> Keybuk: So I think I worked out why there was that "clear" in usplash
<fabbione> type exit to go out but it doesn't really do anything
<Keybuk> mjg59: oh?
<Keybuk> fabbione: hmm, you have /etc/event.d/control-alt-delete ?
<fabbione> Keybuk: standard install
<mjg59> Keybuk: We switch away from usplash so we can change the console font
<fabbione> Keybuk: so it should be there
<mjg59> Keybuk: That looks ugly if there's anything on the screen, so we cleared the screen before doing so
<Keybuk> mjg59: right, but the console font is now changed correctly even if usplash is running
<mjg59> Keybuk: Yeah
<fabbione> Keybuk: anyway, nothing urgent or important..  i will file proper bugs for that
<Kamion> mjg59: which reminds me, I had a theory for why that sleep 1 was there; I think it's waiting for usplash to open the fifo for reading
<mjg59> Kamion: Ah
<mjg59> Entirely possible
<Keybuk> fabbione: if you could run "sudo initctl events" on the console and then press ctrl-alt-del that'd be helpful
<Kamion> Keybuk: not really
<Kamion> Keybuk: I had to make it call setupcon afterwards; it didn't work while usplash was running, for no reason I could determine
<Kamion> the normal setupcon during boot isn't enough
<Kamion> but yes, changing the console font doesn't need to switch vt any more
<Mithrandir> Keybuk: on the live cd, upstart doesn't seem to notice when files in /etc/event.d are changed.  As in, I stop tty6, change the tty6 file, start tty6 and the old one is started.
<fabbione> Keybuk: ok. i will do that. i can't reboot right now
<infinity> mvo: Does apt-ftparchive re-order fields when it generates Packages.gz?
* mvo wonders why gcc-3.3-base has a ubuntu-desktop task
<infinity> mvo: (I'm pretty sure the answer is yes, but it leads to the next question...)
<mvo> infinity: IIRC yes
<Kamion> mvo: libstdc++5
<mvo> aha
<infinity> mvo: If so, can we hack it to place X-Original-Maintainer: immediately after Maintainer:, instead of putting it after the description?
<Kamion> desktop: * libstdc++5 [i386]     # doko: requested from some closed source applications
<Kamion> why does that field have the X-?
<Keybuk> Mithrandir: that doesn't surprise me, actually -- I guess the same's true for udev?
<mvo> Kamion: thanks
<Keybuk> inotify and unionfs are known to be unfriendly
<Mithrandir> Keybuk: no idea about udev.
<infinity> Kamion: Because it's a non-standard field?  If we want to define it as a standard field, I guess we could drop the X-
<Kamion> there's already an XB- syntax in control files to produce an unofficially-defined field
<Mithrandir> Keybuk: well, shouldn't it reload it when I stop and start it?
<Kamion> but the result of that in the binary control file drops the XB-
<Kamion> and nobody ever does XB-X-
<Keybuk> the inotify events would be coming for entirely different files
<infinity> Kamion: Err, it's meant to be XB-?  See I had that spec up for ages, and no one corrected that.
<Kamion> infinity: XB- is what you put in debian/control
<Kamion> infinity: in DEBIAN/control, the XB- gets dropped
<Kamion> (and XS- for source, XC- for changes)
<Kamion> for examples, see Installer-Menu-Item, Python-Provides
<Keybuk> Mithrandir: reloading job files on stop may make some amount of sense
<Mithrandir> Keybuk: and since it's init, I can't just tell it "reload the files, you fool" by hammering it with a signal and restarting it..
<infinity> Kamion: Yeah, I just read that bit of policy.  Argh.  I'm not sure if I specced it as X- or if mdz did, but blame one or both of us, since I don't think anyone else ever read that spec closely.
<mvo> infinity: I can add the reqruired reodering, no problem, just let me know the final name :p
<Hobbsee> Keybuk: you're on the CC, arent you?
<Hobbsee> Keybuk: or is it only Kamion?
<infinity> Kamion: So, I suppose I should change pkgbinarymangler to use XB-, and we'll have a mix in the Packges file of X-O-M and O-M... :/
<jdong> slomo: ping
* infinity could just force rebuilds of everything with X-O-M at some point to purge the oops.
<Kamion> Hobbsee: Keybuk is not
<Kamion> infinity: yeah
<infinity> Kamion: Thanks for the heads-up.
<Hobbsee> Kamion: ah right. 
<Kamion> sorry, I should have mentioned this earlier, but never remembered to
<imbrandon> mvo ping , dholbach  said i should show you soemthing ..... http://pastebin.ca/176190
<infinity> Kamion: S'ok, I should have known, being the policy nazi that I am, I just skipped right past that bit, apparently.
<Kamion> I only really know because the installer uses that feature quite a lot.
<Keybuk> Mithrandir: actually, you could do that -- but sending HUP to init seems wrong
<Keybuk> which is why I used inotify in the first place
<dholbach> mvo: Hehe, I told him to ask you if his apt was not behaving.
<Keybuk> but yes, I can see how that might not work with unionfs :p
<Mithrandir> Keybuk: it rereads everything on HUP?
<Keybuk> Mithrandir: no, doesn't do anything on HUP
<Keybuk> but it oculd
<Mithrandir> it'd be useful.
<mvo> imbrandon: fresh knot3 install? known problem
<infinity> Kamion: So, when does the XB- get stripped?  By dpkg-deb, or by apt-ftparchive?
<imbrandon> mvo: yea fresh knot 3
<Kamion> dpkg-gencontrol
<mvo> imbrandon: the trouble is that if you remove kubuntu-desktop it thinks all dependencies can be freed as well
<infinity> Kamion: Ahh, according to policy, I'd assume by dpkg-deb (since it claims the binary has the stripped version)
<jdong> mvo: does autoremove REALLY need to bug you every time you do anything in apt?
<imbrandon> mvo: okies, just thought i would poke you dholbach  thought you might like to see it
<jdong> mvo: I personally think autoremove should only tell you about those packages when you invoke apt-get autoremove
<Kamion> infinity: it does - dpkg-gencontrol is responsible for generating DEBIAN/control which dpkg-deb tars up into the .deb
<imbrandon> mvo: yea things like xserver-xorg i'd rather not remove
<imbrandon> ;)
<infinity> Kamion: Oh, then I should use the unstripped variety completely, if we don't want the XB-...
<mvo> jdong: it is important to show it for now so that people test it and we get reports like the one from imbrandon :)
<infinity> Kamion: Cause I'm editing it right before dpkg-deb is called.
<infinity> Kamion: In the dpkg-deb wrapper.
<Kamion> infinity: right, sounds sensible
<mvo> imbrandon: we are working on it currently (and it should be fixed soon)
<jdong> mvo: ah, ok, but when edgy releases, autoremove will stop nagging me, right? ;-)
<imbrandon> mvo: ok cool, thanks
<infinity> Kamion: Err, use the stripped variety even.  Gar.  Brain.  Not working.
<imbrandon> mvo: wnt me to stick that paste somewhere more perminate ( like in a txt file on my websever ) or you guys got in under wraps ? 
<mvo> jdong: I'm not decided yet, I personally find it very useful. 
<Kamion> infinity: I parsed it as "stripped" anyway :)
<mvo> imbrandon: thanks, no need for this. we are aware of the problem
<imbrandon> ok
<jdong> mvo: it can be bothersome, especially if you build up a big list...
<mvo> jdong: how big is the list for you?
<jdong> mvo: around 15 or so packages
<infinity> Kamion: Right, so there's no valid reason to have the X*- syntax at all, it's just for debian/control, so it's obvious in the source?
<jdong> some of which are indeed legitimate
<infinity> Kamion: (ie: we don't want X- stuff in the archive for any reason?)
<Keybuk> Mithrandir: that would be a worthy bug (inotify and unionfs not friends) though :)
<jdong> mvo: like autoclean doesn't give a huge list of packages you can purge from /var/cache every time you run apt-get install.... why should autoremove? ;-)
<jdong> mvo: maybe just saying the number of packages that can be autoremoved is a good compromise?
<Kamion> infinity: it's just that no other unofficial fields have X-, so it looks weird
<mvo> jdong: the difference is that (assuming autoremove works correctly) there is no reason to keep any package around that is listed there
<Kamion> I think the X*- syntax is to prevent typoes in standard field names
<jdong> mvo: the same can be said about autoclean, right?
<infinity> Kamion: http://cerberus.0c3.net/~adconrad/argh.diff
<infinity> Kamion: Sane?
<infinity> Kamion: (don't comment on the sed line if it makes you cry)
<Kamion> infinity: nothing wrong with that sed line, except that I always have to look up exactly what \ does inside "" so I tend to use \\ there
<Kamion> (but it's obviously already working, so)
<Kamion> infinity: yeah, seems fine
* infinity builds one test package to make sure it comes out as expected before uploading.
<Kamion> infinity: as a bonus, it's now possible to write XB-Original-Maintainer in debian/control to override pkgbinarymangler, instead of XB-X-Original-Maintainer
<Keybuk> somebody left a "set -x" in the initramfs ;)
<infinity> Kamion: That would cause a build failure currently, actually, but that was for my own paranoia's sake (making sure I don't run the thing twice in a row somewhow)
<infinity> Kamion: Once I'm sure it's workin fine (and it certainly seems to be), being able to override it from the source may be kinda cool, yeah.
<Keybuk> mjg59: local-premount/suspend ... one of yours?
<mvo> jdong: valid point. still, I think we need it at least for another couple of weeks
<mvo> to get debugging feedback
<jdong> mvo: yeah, that sounds good :)
<infinity> Kamion: Hrm.  I could make that change now.  Do you see any value in it, other than the "hey, cool" factor?
<mvo> jdong: please nag me then again :) I could add a "apt-mark unmarkauto --all" or something like this if you think there is room for this
<Kamion> infinity: not really
<jdong> mvo: will do
<infinity> Kamion: Figured. :)
* infinity just uploads what's tested and known-working for now.
<mvo> infinity: I'm preparing a new apt upload right now anyway, so if you need that rewrite ordering thing, I can quickly add it for you
<infinity> mvo: Right, what we want then is to have "Original-Maintainer" sort directly after "Maintainer"
<infinity> mvo: I can worry about getting that backported for drescher later.
<mvo> infinity: added, I'm doing some basic testing now
<infinity> mvo: Danke.
<infinity> Kamion: new kernel and lrm accepted, BTW, if you want to do a d-i ABI bump.
<infinity> Kamion: I can do the seeds, if you like.
<infinity> seb128: Around?
<infinity> seb128: Any idea why poppler just grew two new binary packages?
<slomo> infinity: Riddell activated the qt4 bindings iirc
<infinity> slomo: So now we have "qt" bindings and "qt4" bindings?.. That seems a bit odd.
<slomo> qt3 and qt4... what's odd about this? :)
<infinity> The part where I'm not sure why we care about qt3?  But alright.
<slomo> kpdf iirc
<Keybuk> infinity: we only care about qt3 at the moment
<Keybuk> qt4 is the crackful one, no?
<tseng> i thought almost all of our stuff was qt3
<jdong> infinity: qt3 is more important than qt4 right now
<infinity> Oh, we haven't switched yet.  Check.
* infinity tosses these bindings in universe.
* Hobbsee looks at the time and wonders why infinity is still up
<infinity> Hobbsee: I could ask the same of you.
<Hobbsee> infinity: true that.
<Hobbsee> but i'm not actually doing any work
* Fujitsu snoooores.
<infinity> I do my best work when I'm not supposed to be doing any.,
<infinity> There, no more binaries in NEW.
<Nafallo> infinity: you are away with reason: gone for the evening :-)
<infinity> Nafallo: Yeah, I lied.
<infinity> Nafallo: That was hours ago.  I came back.
* Fujitsu wishes his source packages would get out of NEW as well.. :P
<Nafallo> workaholic! :-)
<Hobbsee> infinity: true that
<Nafallo> Keybuk: when do you plan to start doing the syncs? :-)
<mvo> infinity: new apt uploaded, we need to change the livecd build script then to use apt-get installtask 
<Keybuk> Nafallo: currently doing them
<infinity> mvo: Will do.
<infinity> mvo: Does it work? :)
<Nafallo> Keybuk: nice, I think there is some new binaries in erlang for infinity to get in ;-).
<infinity> mvo: Actually, wait.
<infinity> mvo: Why a new action, instead of a syntax addition to "install"?
<infinity> mvo: That means I can't install both a package and a task in the same run. :/
<Keybuk> Nafallo: there are no NEW binaries
<Nafallo> Keybuk: oki. I thought erlang-nox would be new, since the package has never actually built with them added :-).
<Nafallo> AFAICS
<Nafallo> s/package/source/ above of course.
<mvo> infinity: this simplies the implementation quite a bit. but I could look at this again
<Keybuk> Nafallo: syncs often result in new, yes
<keescook> mornin'
<pitti> hey keescook 
<keescook> hiya pitti
<infinity> mvo: Well, we were really hoping to be able to do the same thing we do with either apt+metapackages or aptitude+tasks, which is to install "package package package {metapackage|task}" all in one run.
<infinity> mvo: It becomes somewhat more interesting when you realise that we sometimes hack around dependency resolution issues by specifying explicit packages before the metapackage/task to make sure we get what we want. :)
<mvo> infinity: what would the synatx look like? apt-get install pkg --task task --task task2? 
<infinity> mvo: Hence why Mithrandir originally suggested an aptitude-like "apt-get install package1 package2 ~ttask1 ~ttask2" syntax (or similar)
<infinity> mvo: Syntaz isn't so important to me, so long as it's doable.
<infinity> mvo: Syntax, even.
<Keybuk> From: Alana <martin.pitt@ubuntu.com>
<Keybuk> pitti: and I thought you were joking about wearing dresses
* pitti hides his pink skirt
<mvo> infinity: ok, I have another look at this then (if the current stuff is not good enough)
<infinity> Kamion: Kernel ABI bump committed and merged to all seeds, BTW.  Nothing left but the d-i bump, which I know you like to do yourself. :)
<dholbach> pitti: HAHAHA
<Kamion> infinity: go ahead, if you like - this CC meeting is draining my attention
<infinity> mvo: Well, I'm not sure about "not good enough" without rewriting some bits and testing it, but I think we'd be happier if we could do it on an "install" line.
<infinity> mvo: I know the install line already has some sketchy parsing to deal with the "package-" and "package+" syntax, so stapling this on might not be TOO painful.
<mvo> infinity: yeah, I could consider "apt-get install task*" or some similar obscource char
<infinity> mvo: Something that's not a shell metacharacter might be nice. :)
<infinity> mvo: task^ maybe.
<mvo> infinity: sounds ok to me
* mvo starts pondering again
<mvo> does anyone why the emacs font looks so bad with latest edgy?
<infinity> It's a plot by the disciples of vi.
<zul> infinity: yes...yes it is
<mvo> don't talk about vi, my vim folds changelogs now by default and won't tell me how to unfold them
<thom> mvo: { or }
<infinity> mvo: What thom said, or just smack space on a folded bit.
<infinity> (or pretty much any key, actually)
<thom> i do hate folds though
<thom> must work out if i can turn them off globally
<Kamion> mvo: set foldlevel=1000
<seb128> infinity: what slomo said, I just fixed the previous upload for that
<thom> Kamion: thanks
<mvo> thanks
<infinity> seb128: Yeah, got it sorted.
<Spads> zul: ping
<zul> Spads: pong
<lastnode> imbrandon, ping?
<Spads> zul: got time to chat about xen?
<zul> sure..
<Keybuk> crimsun: ping?
<Keybuk> unping
<imbrandon> lastnode: pong
<icecrash> hi
<mvo> infinity: ok, tasks with "taskname^" done
<desrt> mjg59; arf.  what are you thinking?
<carlos> Riddell: hi, I think all kde-i18n-XX packages failed to build, are you aware of that?
<Riddell> carlos: erk
<carlos> Can't open perl script "admin/am_edit": No such file or directory
<carlos> make[1] : *** [Makefile.in]  Error 1
<carlos> make[1] : Leaving directory `/build/buildd/kde-i18n-es-3.5.4'
<carlos> make: *** [build-stamp]  Error 2
<carlos> http://librarian.launchpad.net/4308142/buildlog_ubuntu-edgy-i386.kde-i18n-es_4%3A3.5.4-0ubuntu2_FAILEDTOBUILD.txt.gz
<Riddell> they built for me damnit
<carlos> Riddell: I didn't get any translation so I checked German and Spanish ones
<carlos> and both failed, so I guess that's the reason for the lack of translations
<Kamion> doko: sorry, I forgot about openoffice.org - done now
<doko_> Kamion: thanks
<doko_> anybody seen "Input/output error"'s after the last upgrade? installed the new gzip, then every other command/action fails ...
<elmo> doko: err, for stable?
<desrt> mjg59; SCI_EN is disabled when the system boots
<desrt> mjg59; setting it results in an immediately hard lock
<doko_> elmo: the errors? no for edgy
<elmo> doko: ok - was just worried, there's just been a gzip USN ;)
<slomo> Keybuk: does syncing from debian/testing or syncing an older version than what is in debian/unstable work or is a "fakesync" needed?
<Keybuk> slomo: it can work, provided you can find the source somewhere
<Keybuk> if you want to sync from testing, say so explicitly
<Keybuk> if you want an older version, find it on snapshot.debian.net, and request a sync from there
<slomo> Keybuk: ok, perfect :) the version i want is in testing
<slomo> Keybuk: what about the debian-multimedia syncs? any ETA for them?
<doko_> great, dpkg segfaults now after a reboot :-/
<Keybuk> slomo: NEVER
<Keybuk> actually, seriously, it's a sync from a random FTP location that we don't (yet) trust
<Keybuk> it needs someone like me or Kamion to sit down and read every line of code there, etc. and decide whether it's a trustable place
<slomo> Keybuk: it's in no way worse than marillat (and he is involved with that project) before and we synced stuff on request from there too. and for all the stuff i requested syncs we already had a version by marillat
<imbrandon> marillat runs debian-mm doesnt he
<slomo> afaik together with others, yes
<Keybuk> slomo: right, but it needs someone to get out from behind the sofa and check it
-CIA-7:#ubuntu-devel- [GLOBAL]  USE #FREENET TO DOWNLOAD CHILD PORN ANONYMOUSLY!
-CIA-7:#ubuntu-devel- Beu and Rez, Sitting in a tree, K.I.S.S.I.N.G.!
* mode/#ubuntu-devel [+o Keybuk]  by ChanServ
* mode/#ubuntu-devel [+b *!*@gateway/tor/x-51d786df81861028]  by Keybuk
* CIA-7 was kicked off #ubuntu-devel by Keybuk (No.)
* mode/#ubuntu-devel [-o Keybuk]  by Keybuk
<imbrandon> thanks Keybuk  i was just aobut to /op
<imbrandon> was looking away
<Keybuk> anyhoo, off to jono's for a bit -- back later
<imbrandon> wow backport bug fixed, woot, thanks for processing those Keybuk ( curious are you gonna do the NEW queue for dapper/edgy today ? )
<imbrandon> okies guess not ;) thanks
<imbrandon> ;P
<Keybuk> imbrandon: yes, when I get back
<Keybuk> already did some of it
<imbrandon> ok cool, you rock ;)
<mjg59> Keybuk: #30335 - erm?
<desrt> mjg59; should i try initialising acpi or is it the same as setting sci_en?
<mjg59> One case is the mmc subsystem loading mmc_block, the other is a card needing to load the driver that corresponds to the sd slot
<mjg59> Keybuk: they're two different (though similar) problems
<mjg59> desrt: The bit I'm interested in is setting sci_en
<desrt> mjg59; look up ^^
<desrt> flipping SCI_EN on before delay loop calibration -> hard lock
<mjg59> desrt: Oh, sorry, I see
<desrt> at that point in the boot that register is all-zero
<mjg59> Try doing acpi_early_init (or whatever) then
<desrt> i hope that function doesn't mind being called twice :)
<mjg59> Oh, it probably will
<mjg59> But it'll be interesting debugging
<desrt> not if it crashes before i get a dmesg :p
<mjg59> I'm wondering whether getting into SCI mode earlier will avoid the timing problem
<Keybuk> mjg59: they're the same -- kernel doesn't export a modalias for mmc, so drivers can't be autoloaded
<Keybuk> anyway, gone
<desrt> mjg59; calling acpi_early_init from calibrate_delay -> panic
<mjg59> desrt: Ok
<desrt> mjg59; i tried to find the SMRAM
<desrt> to see if i could get inside of it and figure out how its twisted little mind works
<desrt> thus far i've failed
<desrt> on 'rsm' the processor loads a bunch of data from a table at a location that is stored at a fixed offset from the SMBASE register
<desrt> one of those table elements is the new value for the SMBASE register
<desrt> so unless the SMRAM region moves around all the time, you should see there's a word in the system memory which points at the physical address 0xf7[something]  less than itself
<desrt> i found one such word... but it wasn't even aligned
<desrt> so it seems unlikely
<desrt> i wish apple documented their products as well as intel did :(
<desrt> mjg59; wrote writes the code that runs on SMI?  is it part of apple's BIOS or part of the ICH7?
<mjg59> The BIOS, I believe
<desrt> its functionality seems like it would be pretty extremely tightly coupled to the ICH7
<desrt> like all of these 'legacy usb' modes that it would have to support, etc
<jdong> Rejected:
<jdong> k3b: Version newer than that in BACKPORTS. 0.12.17-1ubuntu3~dapper1 >= 0.12.16-1ubuntu3~dapper1
<jdong> imbrandon: soyuz is fixed, huh?
<imbrandon> it accepted amarok and konvo, and keybuck and cprov say so 
<Kamion> no, the fix was committed but hasn't yet been deployed
<Kamion> 'bzr revno' on the soyuz codeline on drescher is older than the fix; I think Keybuk was wrong to set it to Fix Released
<Kamion> could also be that the fix was incorrect I guess
* Kamion -> off for a bit
<jdong> imbrandon: so it accepted amarok and konvo?
<imbrandon> https://launchpad.net/distros/ubuntu/dapper/+source/amarok/2:1.4.3-0ubuntu6~dapper1
<imbrandon> ^^ look , yup
<imbrandon> and -0ubuntu2~dapper1 was already there
<jdong> imbrandon: yeah, I see it under dapper-changes
<jdong> imbrandon: then why didn't k3b go through? :P
<imbrandon> lemme look
<imbrandon> dunno , dpkg --compare-versions says its fine , but the error you pasted thinks 16 is bigger than 17 ( nat the same error as before )
<imbrandon> not*'
<jdong> imbrandon: huh? it clearly says 17 is greater than 16
* imbrandon is afk a while
<jdong> 0.12.17-1ubuntu3~dapper1 >= 0.12.16-1ubuntu3~dapper1
<imbrandon> Version newer than that in BACKPORTS  <-- states 16 is bigger than 17
<jdong> imbrandon: no, that says 17 is newer than that (16) in backports
<imbrandon> anyhow, i dunno, it is marked fixed , accepted all but that one
<jdong> it is identical to the error last time
<jdong> I reopened the bug ticket
<jdong> maybe give it another shot and hope we get lucky :P
<imbrandon> ...
<jdong> argh, both archive guys left, didn't they?
<Nafallo> jdong: yes :-P
<imbrandon> its not an archive problem , soyuz
<jdong> imbrandon: i know, i was gonna ask them to try the backport again, see if it was just a timing issue
<Nafallo> soyuz might be better discussed in #launchpad then? :-)
<imbrandon> Nafallo: yes , kinda my point ;)
<imbrandon> i'm thinking its something wrong with THAT one backport thoughas the others seem to go though
<carlospc> There will be much hardware that will work in edgy but won't work on dapper? I'm looking "hardware support" around LTS definition but i'm not sure... any clues?
<jdong> carlospc: there's certainly going to be some new drivers in Edgy not currently in dapper, sure
<jdong> tifm21xx for one
<cprov> jdong: imbrandon: bug fix for bug #58144 wan't released
<Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,Fix committed]  http://launchpad.net/bugs/58144
<jdong> cprov: ah, ok, keybuk's fault then.... :)
<jdong> cprov: then how did imbrandon's amarok package get through?
<cprov> jdong: did the amarok failed before ?
<carlospc> jdong: well, supose that the distro it's for a government, would you choose dapper or edgy? I'm worry about the new hardware that the government would buy...
<jdong> cprov: amarok succeeded before; k3b failed before
<jdong> carlospc: well, what kind of hardware are you looking at? Dapper's hardware support is fairly comprehensive
<jdong> carlospc: personally, I'd feel more comfortable deploying dapper...
<cprov> jdong: I see, amarok_1.4.2-0ubuntu2~dapper1 got in before and now amarok_1.4.3-0ubuntu6~dapper1 worked too
<carlospc> jdong: that's the problem, i don't know. But the last year we have a huge problem, we was basing our distro on breezy, and some intel chipset weren't supported...
<carlospc> jdong: and we had to buy 2000 computers... but there weren't any seller that sold 2000 computers of a chipset that worked on breezy
<carlospc> that was a huge problem
<jdong> carlospc: well, for now, if you are looking at Core 2 Duo's or Intel 965 chipset, you're gonna have trouble with dapper
<jdong> carlospc: in fact, I don't think Edgy supports 965 fully yet either... lots of those changes are in 2.6.18
<carlospc> ouch
<jdong> carlospc: but if you can figure out what types of hardware you need support for, the kernel guys are usually quite flexible about adding support in
<jdong> (both dapper and edgy)
<jdong> carlospc: http://kerneltrap.org/node/7020
<jdong> that kernel trap thread has some of the changesets needed for 965 support
<carlospc> that would be the way
<jdong> I did a quick git tree search for dapper and edgy, not all of those are in ubuntu kernels
<jdong> carlospc: I'd recommend launchpadding linux-source-2.6.17 and linux-source-2.6.15 and link that kerneltrap thread
<jdong> I don't see anything that'd prevent ubuntu from getting those patches backported
<jdong> and i965 support is quite important for both releases, IMO
<carlospc> Ok, thanks a lot
<desrt> mjg59; btw.   about the xorg crashing thing
<desrt> mjg59; the real kick in the pants about that bug is i diff'd the file in which the crash occurs to its equivalent version from dapper
<desrt> mjg59; no changes.
<carlospc> We have a developer team, may be our efforts should go in that direction
<desrt> mjg59; (cept an extra #include, probably to fix a warning)
<jdong> carlospc: if you do file the report, subscribe me to it... I'm interested in buying some core 2 duos in the future, so I'd want to know too :)
<carlospc> jdong: thanks a lot!
<mjg59> desrt: Yeah, it'll be the reinit code that's called on VT switches
<mjg59> There's something there that tries to soft-boot the card under certain circumstances
<carlospc> jdong: ok
<desrt> and the soft-boot disables the ring buffer
<mjg59> No, the soft-boot probably just fucks shit up
<desrt> the problem is caused by a software timer noticing that the hardware hasn't advanced the ringbuffer in the past little while
<desrt> (and panicking)
<zyga> hi everyone
<popey> mjg59: if you have a moment, any chance you could triage bug 58469 or otherwise smack me with a cluebat?
<Ubugtu> Malone bug 58469 in linux-source-2.6.17 "via-rhine net card stopped working in 2.6.17" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/58469
* zyga has such network card
<mjg59> popey: Looks like an interrupt problem
<mjg59> It's probably the VIA interrupt quirks madness
<mjg59> Can you try the latest 2.6.17?
<popey> mjg59: I am on 2.6.17-7-386 and have tried -generic also
<jdong> mjg59: the 2.6.17-8 upload that was supposed to fix via quirks hasn't landed on download mirrors yet
<LaserJock> Kamion: I uploaded a new and improved edubuntu-menus to NEW for our reviewing pleasure ;-)
<crimsun> jdong: yes it has.
<popey> ah, ok, I'll be patient for that then
<LaserJock> s/our/your/
<popey> if that is a suspect
<jdong> crimsun: I haven't been able to pull it from archive.ubuntu.com
<crimsun> jdong: considering I've been running it for roughly 15 minutes, I'd say it's available.
<mjg59> popey: Yeah, wait for -8
<jdong> crimsun: hmm, you're right, they're in there, but dist-upgrade doesn't pull them in
<popey> shall I update the bug mjg59 ? 
<popey> is it a duplicate of something else?
<mjg59> Once you've tried -8, yeah
<mjg59> Not sure if it's a dupe
<popey> ok
<crimsun> jdong: -meta isn't updated.
<mjg59> I don't follow most of the kernel bugs too closely
<jdong> crimsun: ah, ok
<popey> thanks for your time, appreciated
* jdong manually pulls in 2.6.17-8
<Treenaks> mjg59: what is used for mode switching nowadays?
<mjg59> What sort of mode switching?
<Treenaks> mjg59: graphics mode, on boot (before X does it)
<mjg59> I don't really understand the question
<Treenaks> mjg59: I have 2 machines that display garbage on boot, instead of a nice flashy usplash. I think it's because [the thing that switches video modes]  doesn't do it correctly.
<jdong> Treenaks: you mean the workaround for intel chipsets, or more like what usplash does?
<Treenaks> (one has an ATi builtin chip, the other is an NVidia 6600)
<mjg59> Treenaks: It's your video BIOS
<Treenaks> mjg59: hm. suck. any way to force usplash to use a sane mode?
<mjg59> It uses sane modes
<Treenaks> (saner?)
<Treenaks> mjg59: how do I know which mode it's trying to set?
<mjg59> Check /etc/usplash.conf
<Treenaks> 1280x800
<Treenaks> (native flat panel resolution)
<_ion> Here usplash tries to use 1024x768 and then just dies because screen initialization fails for some reason. It'd be nice if it had a fallback to 640x480 or 640x400.
<Treenaks> _ion: how does it look when it dies? because it looks almost the same on my Ati and my nvidia..
<_ion> It just exits.
<Treenaks> _ion: no garbledness?
<_ion> There's a blank tty with the normal virtual console resolution. Alt-F1 etc. work as expected.
<_ion> Not at all.
<Treenaks> hmm
<popey> mjg59: perhaps further evidence - if I leave network cable out mouse is okay, if I plug it in the usb mouse goes sluggish, but trackpad is fine
<Treenaks> popey: that sounds _bizarre_
<popey> definately sounds interrupty
* Treenaks is scared of rebooting... as I have a VIA mainboard, and VIA fixes were removed from 2.6.15-27.48
<tseng> Treenaks: might have meant via cpus
<Treenaks> tseng: I have those too
<Treenaks> tseng: (epia boards)++
<HiddenWolf> Treenaks is our resident via groupie
<Treenaks> nah
<jdong> how do I temporarily deactivate apport?
<jdong> like I KNOW a web page I'm going to will make firefox segfault
<tseng> stop the service
<jdong> tseng: oh, that's easy :)
<jdong> heh
<zul> heh the via patch was reversed
<Mithrandir> or echo /bin/true > /proc/sys/kernel/crashdump-helper
<ScreaminIke> uhm. can i make a feature request in this room?
<cprov> imbrandon: ping
<jdong> ScreaminIke: I typically try that... and get yelled at for it :)
<jdong> ScreaminIke: YMMV
<LaserJock> ScreaminIke: it would kinda depend on the feature, most feature requests should be turned into specifications, I believe
<LaserJock> others are bugs and should go to Launchpad
<popey> zul: the via interrupt wierdness patch?
<zul> yep..
<zul> afaik
<Kamion> LaserJock: specifications should be used when the feature is complicated and/or affects several different bits of the system
<Kamion> i.e. requires design
<Kamion> just because it's a feature request as such doesn't mean it needs a specification - nor necessarily vice versa, even
<Kamion> there are some specs that are there to fix complicated bugs
<popey> zul: any clues why?
<zul> popey: well it broke alot of peoples computers i believe
<popey> :(
<popey> mine is broke :(
<carlos> Riddell: about the .pot files missing the UTF-8 encoding tag, would you fix also other templates from kdeaccesibility and kdelibs?
<Riddell> carlos: sure
<carlos> Riddell: thanks
<LaserJock> Kamion: good point
<AndrewLee> mdz: Hi, could you please take a look on bug #57081? A lot of users are waitting for this update.
<Ubugtu> Malone bug 57081 in scim-chewing "scim-chewing cannot enter any Chinese character" [Untriaged,Confirmed]  http://launchpad.net/bugs/57081
<mdz> AndrewLee: freeflying and I have an ongoing email conversation about this, but it is difficult to understand his explanation of the problem
<mdz> AndrewLee: whatever the approach we take, it must be implemented and tested in development before we even consider an update for dapper
<mdz> and that doesn't seem to have happened yet
<AndrewLee> mdz: It's broken in dapper now.
<mdz> AndrewLee: that is what the two of you have said, though I'm surprised this wasn't noticed in the months prior to dapper's release
<AndrewLee> mdz: It's well tested in Debian for a long time.
<AndrewLee> mdz: I did noticed the ubuntu member in Taiwan. but seems he didn't do anything on it.
<Kamion> AndrewLee: for dapper, the relevant fix needs to be isolated and backported (all the conversation on the bug is about dropping a new upstream version into dapper, which we generally try very hard to avoid)
<AndrewLee> mdz: I am the maintainer of the package in Debian, and ubuntu also list my name and email as the package maintainer, so I got a lot of users's complains
<Kamion> much like stable release updates in Debian; you'd get a "no" answer to a request to drop in a new upstream version there too, generally
<mdz> AndrewLee: I apologize for that; the maintainer field will be fixed automatically the next time the package is built
<AndrewLee> Kamion: I know, but how to make me away from the bug reports? Ubuntu listed my name on that....
<Kamion> AndrewLee: as mdz says
<Kamion> with the next build, it'll be Maintainer: ubuntu-devel@lists.ubuntu.com, Original-Maintainer: you
<Kamion> if you know the package well, is there any chance you could identify the patch needed?
<AndrewLee> Kamion: Users cannot use it is a big problem, hope you can solve it and use your way.
<Kamion> we realise that broken packages are a big problem, but (particularly due to recent events) we are being extremely cautious about stable release updates
<AndrewLee> Kamion: I felt so sad to hear this kind of shit, I notice ubuntu member before dapper released, but the bug is still there until now.
<mdz> AndrewLee: I've added some information to the bug explaining how to proceed
<Kamion> I haven't seen the conversation between mdz and freeflying (and mdz, feel free to tell me to shut up if I've missed something relevant), but nobody's saying "we shouldn't fix this"; we just want to know how to fix it in the least risky way for us.
<Kamion> note that Ubuntu membership just recognises significant and sustained contributions to the project; it doesn't guarantee that a particular bug will get fixed
<Kamion> (in time for a particular release)
<AndrewLee> mdz: Users cannot use for typing Chinese, it's big problem just like you cannot type your mother language...
<mdz> the best thing to do with a bug is to file it in launchpad, that way it is recorded
<mdz> AndrewLee: thank you for that information.  is there a problem with the information I added to the bug?
<AndrewLee> Kamion: if it's really a Linux for human beings...how could you make users cannot type their mother language...
<mdz> AndrewLee: scim-chewing in Ubuntu was last changed in April, two months before the release.  it was freeflying himself who made the change, and is now saying that it is broken
<AndrewLee> mdz: I did, but I didn't get ant answer since 2006-09-08 20:03:52 CST
<AndrewLee> mdz: I did notice them before dapper released.
<mdz> AndrewLee: in April, freeflying changed the configuration in scim-chewing in Ubuntu.  5 months later in September, I received an email saying that this configuration is wrong and needs to be reverted.  It was not until 15 minutes ago that the bug report was brought to my attention.  I've now added instructions to the bug explaining how to work toward a solution.
<mdz> AndrewLee: is there anything further I can offer to help?
<AndrewLee> mdz: It's too complicated to explain such mess, I think ubuntu was wrong since the im-switch integration.
<AndrewLee> mdz: And for scim-chewing 0.2.1 was a known bug in upstream, they got the problem solved on 0.3.x
<AndrewLee> mdz: And dapper took the buggy 0.2.1 with a messed im-switch configuration
<AndrewLee> mdz: So that become two problems and both made users cannot type Chinese.
<imbrandon> cprov: pong
<cprov> imbrandon: hi, did you requested sync-source from amarok in backports or did you uploaded it ?
<imbrandon> cprov: what do you mean? i requested the backport AND uploaded the edgy version
<imbrandon> cprov: keybuk did the actual backport though afaik
* imbrandon isnt sure about sync-source
<jdong> cprov: ubuntu-archive does the actual backporting; imbrandon and I are the human filters deciding what gets sent to them for backporting
<cprov> imbrandon: right, so that's why is was accepted, it didn't pass throught the buggy code we refered before (and is fixed in RF4066)
<imbrandon> hrm i'm not following 
<jdong> cprov: I don't think imbrandon did a manual upload backport for amarok
<jdong> it should've passed through the buggy code just like the k3b backport
<cprov> jdong: imbrandon: ok, I was just curious how the amarok version was accepted in backports (code is really broken as I described)
<imbrandon> no i uploaded it to edgy normaly, then keybuk did sync-source when i "approved" the backport
<imbrandon> hrm i dunno how it got through heh it went through the same process as k3b afaik
<jdong> cprov: yeah, that makes me scratch my head, too
<cprov> jdong, imbrandon: can't you do the same procedure for k3b ? it sounds like a good & safe workaround
<jdong> cprov: it's the same procedure to our knowledge though
<imbrandon> cprov: they were / are done the same way
<jdong> cprov: we didn't do anything different
<imbrandon> right
<Kamion> s/sync-source/backport-source/
<Kamion> sync-source doesn't do backports
<Kamion> I need to send backport-source to the Soyuz guys, I know
<cprov> Kamion: do you have this variation of the script ? 
<Kamion> cprov: it's not a "variation", it's more or less completely different
<imbrandon> hrm it might be k3b is the only thing holding up, i was about to file one for konversation ( thats already there also ) Kamion you wannt backport-source it and see if its just k3b ?
<Kamion> backporting generates a new source package
<Kamion> it's in ~lp_archive/bin/ on drescher
<Kamion> it's just a port of elmo's old mia.py tool to Soyuz
<cprov> Kamion: uhmm, it makes me curious ;)
<Kamion> sure, that's why I say I've been meaning to send it to you
<jdong> imbrandon: the only difference I see between k3b and amarok is that k3b ftbfs'ed while amarok had binaries in dapper-backports
<Kamion> but it doesn't affect this bug - backport-source generates a source package which we dump into the sync queue, just like syncs
<Kamion> jdong: that's highly relevant
<jdong> imbrandon: IIRC konvo also failed build, so I predict it'll get rejected, too :)
<Kamion> at least to binary accepts
<jdong> Kamion: interesting... we might be getting somewhere :)
<imbrandon> jdong: that probably should have been in the bug report heh
<Mez> I presume this is a backports discussion ?
<jdong> Mez: yep
<Kamion> although actually wasn't the amarok reject a source reject?
<imbrandon> mez yea
<cprov> uhm, the same bug exists in binary world
<Kamion> in which case never mind me
<Kamion> cprov: yeah, I know
<imbrandon> Kamion: no amarok went through
<Kamion> oh
<imbrandon> thats the puzzling part
<cprov> see https://launchpad.net/+builds/+build/247050, succesfully build, but no binaries
<cprov> built, too
<imbrandon> Kamion: can you try to backport the new konv ( it needs it anyhow and i was about to file ) and we'll see if its becouse the old backage ftbs
<Kamion> right, that's why I wasn't backporting amarok
<Kamion> imbrandon: no, I'm not going to attempt any backports until the fix for this bug is rolled out
<Kamion> if Keybuk had asked I would have suggested the same thing
<imbrandon> cprov: no binarys ?
<Kamion> imbrandon: for amarok
<jdong> imbrandon: the binaries get sucked into a black hole :)
<cprov> when we roll the fix we can recover them 
<Kamion> 18:13:54 INFO    amarok: Version newer than that in BACKPORTS. 2:1.4.3-0ubuntu6~
<imbrandon> ok , sounds like a plan , man this gets more intersting by the minute ;)
<Kamion> dapper1 >= 2:1.4.2-0ubuntu2~dapper1
<Kamion> ^-- binary reject
<jdong> ooh, binary reject
<jdong> so it accepted a newer source if no binaries exist
<jdong> no, sorry, meant reject
<Kamion> oh I don't know, I'm not investigating this tonight
<jdong> but if binaries exist, it accepts a source but rejects newly built binaries
<imbrandon> theres a fix in the works thats all that matters
<jdong> fascinating, confusing, and definitely calls for aspirin :)
<jdong> cprov: what's the ETA on rollout?
<cprov> the code line in drescher is really messy, let try to cherrypick the fix experimentally in another codeline, if it works we can request kiko/mdz permission to roll it out
<imbrandon> kk
<cprov> jdong: we are working to rool major feature til the end of this week, but not promises ...
<jdong> k
<jdong> whoa, hey cool, mplayer is completely not working now
<jdong> yay!
<_ion> jdong: Yeah. There's a bug report about it.
<jdong> _ion: yeah, I see it now
* jdong wonders if it just needs a rebuild after the ffmpeg upload?
* jdong hopes for the best... else his core duo will have to retire from today's transcoding queue
<Nafallo> jdong: AFAIK slomo said it was harder than that.
<jdong> Nafallo: I was afraid of that :)
<slomo> jdong: a rebuild will make it work again partially but won't fix it completely
<jdong> ever since I moved from gentoo this whole recompiling thing isn't as magical anymore :)
<slomo> Nafallo: feel free to fix it yourself if you have some free time today, i have to care about something else now ;)
<jdong> slomo: what exactly is a partially working mplayer? ;)
<jdong> as long as mencoder can use the xvid and lavc codecs I'm happy
<slomo> jdong: exploding on ac3 decoding... other than that it should work fine
<Nafallo> slomo: new banshee? :-)
<slomo> Nafallo: yes
<jdong> slomo: k, works for me :)
<Nafallo> slomo: hehe, prio ;-)
<pitti> yay python 2.5
<Burgwork> Kamion, you around to chat quickly about evand?
<Kamion> Burgwork: sure
<slomo> infinity: iirc you care about apache2... apache2-dev is uninstallable on the buildds for some reason: http://librarian.launchpad.net/4316188/buildlog_ubuntu-edgy-i386.mod-mono_1.1.17-1_FAILEDTOBUILD.txt.gz
<cprov> Kamion: imbrandon: jdong: fix for bug #58144 rolled out experimentally, can you submit a backport candidate ?
<Ubugtu> Malone bug 58144 in soyuz "Backport is rejected if an older backport is already there" [Critical,Fix committed]  http://launchpad.net/bugs/58144
<imbrandon> Kamion: is the only one with the privlages to actualy pipe it though
<imbrandon> cprov: ^
<cprov> imbrandon: upload, it will seat in unapproved queue, which is already a big win 
<Kamion> ! no it's not
<Kamion> I don't want dapper-backports hitting unapproved - that's just extra work
<cprov> Kamion: uhm, ok ...
<imbrandon> no we dont upload to dapper backports
<Kamion> and distro policy is not to have people uploading backports by hand in general
<imbrandon> yea
<Kamion> cprov: I mean, I don't want sync-queue backports to hit unapproved
<Kamion> cprov: if anyone uploads to it by hand, that should hit unapproved, definitely
<imbrandon> we just file the reports and test them
<Kamion> but when we punt it through the sync queue, it should go straight to new/accepted
<ajmitch> Kamion: want any more info added to bug 59001 ?
<imbrandon> right ... well if you want one to test i can file a request for konversation or we can retry amarok
<Ubugtu> Malone bug 59001 in Ubuntu "sync zope packages" [Untriaged,Needs info]  http://launchpad.net/bugs/59001
<cprov> Kamion: fine by me, fix is rolled, let me know if it works as expected or not.
<Kamion> I'll do amarok
<imbrandon> Kamion: kk
<Kamion> hmm, no, amarok source worked
<Kamion> was it k3b that got source-rejected?
<imbrandon> yea
<imbrandon> amarok on the binarys got rejected
<imbrandon> k3b source
<kmon_> Hi. Can someone be kind enough to tell me the login details of knot cd 3. I can't login in console mode and X doesn't start.... I'm trying to get some info to squash a bug.
<Kamion> ajmitch: that's great, thanks
<imbrandon> kmon_: ubuntu / ubuntu
<Kamion> kmon_: whatever you entered during installation - there's no default user/password
<Kamion> kmon_: unless you mean the live CD, in which case what imbrandon said
<imbrandon> Kamion: livefs
<kmon_> imbrandon: It doesn't work
<Kamion> it's supposed to start with the ttys already logged in though
<Kamion> then you're hosed :)
<imbrandon> hrm true
<kmon_> Kamion: ubuntu/ubuntu doesn't work
<Kamion> I expect that the CD or the drive is a bit buggered
<Kamion> kmon_: the image or the drive is faulty beyond reasonable repair, then, I think
<kmon_> I've tried on both the x86 and amd64 live cds
<Kamion> this is sadly quite common
<imbrandon> kmon_: username : ubuntu password: ubuntu not ubuntu/ubutnu
<Kamion> drive lenses often get dirty
<imbrandon> yea
<kmon_> imbrandon: typo, sorry
<imbrandon> bad cdrom drive likely
<imbrandon> err dirty
<Kamion> kmon_: sorry if that seems overly quick to jump to conclusions, but I've dealt with several dozen such bugs lately
<kmon_> with both isos?
<kmon_> Kamion: ok
<kmon_> I'll see if I can get another cd to test
<Kamion> kmon_: it's possible for the *drive* to be unable to read CDs in general
<Kamion> not a matter of the CD
<imbrandon> kmon_: drive
<Kamion> another CD is worth trying of course
<kmon_> ...
<Kamion> but this has happened to me, I'm not making it up - a drive cleaning kit bought from an electronics shop worked wonders
<kmon_> I'll try with another computer I have
<Kamion> yes, that's worth trying
<kmon_> I'll tell you in a few seconds....
<imbrandon> specialy the livecd as it wont mess anything up
<imbrandon> only out some uptime ;)
<Kamion> doko: I'd still like you to add information about the Ubuntu changes being overridden in those ada syncs to the bug
<Kamion> doko: I don't know if you told me on IRC, but if you do that, I'll lose it
<kmon_> Kamion: same problem on my other computer
<kmon_> now, the only chance is that *both* cd's I've used to burn the x86 and amd64 isos are broken...
<imbrandon> strange, are you sure the cd burner burned it correctly ? md5s matched
<kmon_> imbrandon: haven't tested, that's on my next test
<Kamion> do a CD integrity check from the boot menu
<Kamion> we did test the knot-3 images before release - if it were a daily build I'd be more inclined to suspect breakage in the image itself
<Kamion> of course it could still be that, but need to eliminate hardware first
<kmon_> ok
<Kamion> then, try sticking 'single' on the end of the boot options (F6 from the boot menu)
<kmon_> I'm trying yet another cd drive
<Kamion> can't remember what that does on the live CD but with any luck it'll get you to a root prompt you can use to debug stuff
<kmon_> Kamion: thanks
<imbrandon> Kamion: it does , i had to use it when i borked a upstart install ( without upstart-sysv-compat ) reciently
<imbrandon> heh
<imbrandon> or should say it /should/
<Kamion> ok, k3b worked this time, I think
<Kamion> anyway, bed
<imbrandon> Kamion: gnight
<imbrandon> thanks ;)
<kmon_> bye
<imbrandon> cprov: ping
<cprov> imbrandon: pong
<imbrandon> heh looks like k3b worked he said, is there a way to recover the amarok, or does it need to be redone
<cprov> imbrandon: there is a way, I think you can ask infinity to do so.
<imbrandon> ko , sounds great, thanks for pushing the fix, you rock
<cprov> imbrandon: thanks, it was already too late ;)
<kmon_> imbrandon: the check cd test has finished but didn't tell me anything at all, instead it booted into gnome
<imbrandon> kmon_: looks like a good thing
<kmon_> then if the cd shows the login problem on both drives and the check cd didn't report any problem....
<kmon_> I think I have a bug
<kmon_> :)
<imbrandon> possibly, this is a knot 3 cd right, i thought you said you couldent start X
<kmon_> I have 2 machines
<kmon_> X doesn't boot on my laptop
<kmon_> I'm using my desktop now
<kmon_> anyway
<kmon_> if single mode works
<imbrandon> hrm ok i'm missing the problem , sorry i've tired, whats the root issue ?
<kmon_> Ill use it to get the bug details
<kmon_> there are different issues here
<kmon_> one is that on both amd64, x86 knot cd 3 login through the console doesn't work
<kmon_> I mean, ubuntu / ubuntu doesn't work
<kmon_> then, the other issues are things I'm trying to debug in my laptop
<imbrandon> you did check caps lock etc correct ? sorry i must ask
<kmon_> errrr
<kmon_> I think so ;)
<imbrandon> heh
<kmon_> arrrg
<kmon_> another boot
<kmon_> now
<kmon_> wait
<kmon_> yes, NO caps lock
<imbrandon> ok kmon_ i'm sorry to cut this in the middle there might be someone awake still in here or better in #ubuntu , if not meet us back in here in about ~12 hours
<imbrandon> ok , just checking
<imbrandon> sometimes we all make booboo's ;)
<kmon_> I don't care much about the login issue if single mode works
<kmon_> I should have thought about it, but here is also late....
<imbrandon> yea single should drop you to a root console
<kmon_> I think it's a common practice to debug things late at night
<kmon_> :)
<imbrandon> ;)
<kmon_> anyway...
<kmon_> thanks for your help
<kmon_> I'm off to try the single mode
<imbrandon> yea collect a bit of info i'll be glad ( or someone ) to help out when i wake
<imbrandon> ciao
<kmon_> bye
<siretart> gnarf. why don't we have ffmpeg in main :/
<dholbach> see you tomorrow
#ubuntu-devel 2006-09-20
<terlmann> Is Michael Vogt(michael.vogt@ubuntu.com) here ?
<jdong> terlmann: that's nickname mvo, and he is not here right now
<terlmann> yea,what would you guys think about a new package managment system(frontend+core) for debian ubuntu 6+1? and how about naming it "Stymie"?
<terlmann> What would you guys think about a new package managment system(frontend+core) for debian ubuntu 6+1? and how about naming it "Stymie"?
<Chipzz> terlmann: there allready is talk about using smart
<Chipzz> terlmann: and michael vogt is here during the day
<terlmann> could it be named Stymie?
<terlmann> It is the "day" here.
<Chipzz> no?
<Chipzz> why would you get to name something other people created?
<Chipzz> it's 0:46 here; he will be here in aproximately little over 8 hours
<Chipzz> and his nick is mvo
<terlmann> No,just it would be a better name than spmngr or spmanager or spm. stymie update && stymie dist-update .... it starts with s ... like spm ... and like synaptic... but better name ,don't you think? I did ask vogt to take a look at it.
<terlmann> I have created a launchpad page.
<terlmann> Apt & it's Gui frontend,Synaptic, were GREEEAATT for their time,but no more.with the size of files & the number of downloads worldwide,a new system needs to be used.something that can pause& resume updating.
<terlmann> something that more efficiently handles the need for servers to be nearby,decreasing download times.something that might be called Stymie .
<shackan> people don't care about names
<Chipzz> terlmann: you DO realize apt can pause and resume updating?
<Chipzz> and you DO realize that you can use <country-code>.archive.ubuntu.com ?
<Chipzz> apt-get update ; apt-get upgrade -y ... ctrl-c ... apt-get upgrade -y
<Chipzz> I know that's a poor mans solution to pausing
<terlmann> it is.and it is command line only.
<Chipzz> but there is really fundamentally little that does prevent apt pausing
<Chipzz> 00:51 < terlmann> Apt & it's Gui frontend,Synaptic
<Chipzz> 00:55 < terlmann> it is.and it is command line only.
<Chipzz> ? :P
<Chipzz> no matter
<Chipzz> you also do realize that you can have apt download the files in the background?
<Chipzz> and that when you disconnect, it is possible to resume that download?
<Chipzz> (well actually update-manager does that)
<terlmann> <chipzz> apt-get update ; apt-get upgrade -y ... ctrl-c ... apt-get upgrade -y 
<terlmann> ?
<Chipzz> mvo would probably have a few reasons why apt is bad
<Chipzz> but I can't see your arguments being good ones
<theine> Hi, which wiki engine does http://wiki.ubuntu.com actually use? And would that engine be in main?
<Mithrandir> theine: moin and yes.
<theine> Mithrandir: What package is this?
<Chipzz> python-moinmoin - Python clone of WikiWiki - dummy library package
<Chipzz> ?
<Chipzz> just a wild guess
<Mithrandir> soudns right
<Mithrandir> anyway, I'm off to bed.
<theine> the "dummy library part" irritated me a bit
<Chipzz> theine: try apt-cache search moin ?
<Nafallo> s/search/show/
<theine> yes, it seems there are pretty much only library packages related to moin in main
<Chipzz> Nafallo: no, search
<Chipzz> root@Reel:~# apt-cache show moin
<Chipzz> root@Reel:~#
<Nafallo> ah. python2.4-moinmoin
<Nafallo> and moinmoin-common ;-)
<terlmann> apt is only a native command line app,like yum. the .deb spec is what makes it better.
<Chipzz> terlmann: heh?
<Chipzz> I would say rather the contrary, that deb as a package format is inferior to rpm
<HrdwrBoB> Chipzz: that's a pointless thing to say
<HrdwrBoB> and not on topic for this channel anyway
<Chipzz> HrdwrBoB: maybe I understood him incorrectly, but he seemed to be arguing for .deb as a package format:
<Chipzz> 01:11 < terlmann> apt is only a native command line app,like yum. the .deb spec is what makes it better.
<terlmann> hah.chipz,.deb beats .rpm hands down. and yum itself sucks compared to apt.but you just want to argue.not promote creative thinking.Am I right? (of course I am right |his kind always says that "it really can""but there is really fundamentally little that does prevent"and "you also do realize".this argument is over.we need a new revolution to keep the thoughts going around and around.so you do it.and I wont complain.only if it is n
<Chipzz> terlmann: no, you are just plain clueless
<terlmann> you are clueless.
<HrdwrBoB> rpm is a very good format, it's POLICY that makes deb packages good
<Chipzz> terlmann: I did over 2 years of packaging rpm's. go fuck yourself or something
<ajmitch> Chipzz, terlmann: stop the bickering now
<Chipzz> I do know what I am talking about
<Chipzz> ajmitch: yeah, probably should do that
<terlmann> so do i. I have rpm'd. It is policy. I AM NOT DENYING THAT! .deb DOES that,rpm doesnt.period.so go code.or something.
<zul> mind taking it to offtopic
<terlmann> sure.
<terlmann> whats the name?
<terlmann> ubuntu-offtopic?
<terlmann> (and this problem is ubuntu development orientated,mind you.)
<zul> not directly
<Chipzz> what is the component to look for bugs for the rebuilding of a package?
<Chipzz> "archive" or something?
<Chipzz> rebuilding -> syncing
<infinity> sync bugs should be filed against the package in question, and ubuntu-archive should be subscribed to the bug.
<infinity> Chipzz: https://wiki.ubuntu.com/DeveloperResources <-- See the "Syncs" section.
<Chipzz> infinity: I'm not a developer myself; I guess I can't subscribe ubuntu-archive?
<infinity> Anyone can.
<infinity> But if you aren't going to check the package thoroughly (ie: if you're not prepared to go through the process listed on DeveloperResources), you should get a developer to poke through it and then do the sync request.
<Chipzz> infinity: I'm not 100% sure a sync request is what's needed, but quite sure though
<infinity> If not 100% sure, then don't subscribe us, file the bug and get someone else to look at it first.
<Chipzz> infinity: mythtv got synced to version 0.20, while mythplugins is still at 0.18
<Chipzz> I think that would qualify, no?>
<infinity> That would need a UVF exception as well.  Best to talk to #ubuntu-motu about it.
<infinity> But it's probably a no-brainer.
<Chipzz> mythplugins is useless as is now
<tseng> you're appealing to the wrong guy
<Chipzz> should I just go ahead and subscribe ubuntu-archive?
<tseng> no.
<tseng> you need dholbach, slomo, or siretart (pick 2) to approve it
<crimsun> please complete bug 61332
<Ubugtu> Malone bug 61332 in mythplugins "Needs a sync for mythtv 0.20" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61332
<Chipzz> crimsun: that's exactly the bug I just filed, and which I'm arguing about weither I should subscribe ubuntu-archive or not
<Chipzz> crimsun: what additional info is needed?
<crimsun> see https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-August/000181.html
<Chipzz> crimsun: I lack the needed information, though I guess I can find it by digging around a bit; shall I do that, or let the maintainer complete it?
<crimsun> Chipzz: generally it's quite helpful to provide all the relevant information up front.
<infinity> crimsun: Tell me that you know the ruby codebase inside out and backwards.
<infinity> crimsun: Even if it's a lie, tell me that anyway, so I can offload something on you. :P
<Chipzz> crimsun: I would agree; but the reason I filed this bug is more as a reminder to the maintainer, as I'm sure he is aware that mythtv needs to stay in sync with mythplugins
<Chipzz> unless that package doesn't have a maintainer in ubuntu and just gets synced blindly
<crimsun> infinity: I'm trying to decrease my misery, not increase it
<infinity> crimsun: Damn.  I just wanted to ping "ruby1.8 is broken on ppc64" on you, since it's causing one of your uploads (ruby-gnome2) to FTBFS on powerpc. :)
<infinity> s/ping/pin/
<crimsun> hmm, I think Lucas sent an e-mail about that
<slomo> infinity: did you see what i've written about apache2-dev? :)
<infinity> slomo: yeah, someone synced apache1.3 without me noticing, so apache-dev and apache2-dev aren't co-installable anymore.  I'll fix it.
<crimsun> [https://lists.ubuntu.com/archives/ubuntu-devel/2006-September/020769.html] 
<infinity> Yeah, I know.  The reason it "builds fin in Debian" is because the Debian powerpc buildd is a 32-bit system.
<slomo> infinity: thanks... just give-back mod-mono afterwards :) and we probably need a buildd only for openoffice :P i hate always waiting for other stuff to finish for > 12 hours ;)
<infinity> slomo: You and me both. :/
<infinity> "doko upload days" make me sad.
<Chipzz> crimsun: any better now?
<crimsun> Chipzz: sure.
<crimsun> I'll do the grunt work, then.
<Chipzz> that's as much information as I have
<Chipzz> without rebuilding it myself
<Chipzz> which I can do, if you want
<crimsun> that would be helpful, yes.
<Chipzz> but that would be something for tomorrow then
<Chipzz> allright with you?
<crimsun> sure
* Chipzz off to bed
<Chipzz> thx for the instructions crimsun :)
<doko_> infinity: http://librarian.launchpad.net/4315512/buildlog_ubuntu-dapper-powerpc.openoffice.org_2.0.3-6dapper3_FAILEDTOBUILD.txt.gz
<infinity> doko_: Ugh.  Will fix.
* infinity looks suspiciously at royal.
<infinity> /dev/md0               74G   48G   27G  65% /srv
<infinity> No space, my ass.
<infinity> Oh, wait.
<infinity> That's not royal, I'm retarded.
* infinity wakes up first.
<doko_> I'm currently clueless for the sparc fai?ure 
<jdub> man
<jdub> server bootups are pretty surreal now
<jdub> grub spew... (minor initramfs spew, won't be there forever)... login:
<Gman> almost like you were running solaris...
* Gman ducks
<mjg59> Nngh grah kernel
<jdub> Gman: more like AIX with the console font we're using
<Gman> :)
<jdong> oh god, a new dbus update... will my hotplugging break this time? :)
<mjg59> jdub: It's *bad*, isn't it?
<jdub> mjg59: i quite like it 8)
<mjg59> Hm.
<mjg59> So.
<mjg59> If I hack out one line, the kernel boots
<mjg59> But
<jdub> i guess the only problem with it is that it's not as contrasty as the previous one
<mjg59> The code is identical on amd64, and that one boots /with/ that line
* mjg59 cries
<slomo> jdong: i doubt it ;)
<jdong> slomo: oh, but you know my luck with dbus recently :)
<jdong> slomo: my bugs tend not to be reproducable by anyone else
<jdong> like mjg59, you were there yesterday when I said ubiquity bombs out in knot 3 amd64, right?
<jdong> I can't get it to happen again
<jdong> I just tried for a good hour
<mjg59> CMOS_WRITE(save_control | RTC_PIE, RTC_CONTROL);
<mjg59> I wonder what this actually /does/
<jdub> maybe going greenscreen would help with the console font contrast issues
<infinity> doko_: powerpc rescued.
<infinity> doko_: Want me to retry sparc to see if that ICE was cosmic rays?
<mjg59> Any old-school x86 people around?
<bddebian> Howdy
<LaserJock> old-school?
<bddebian> old-school?
<jdong> bddebian: <mjg59> Any old-school x86 people around?
<jdong> before you hopped in
<bddebian> Ah
<bddebian> I'm just old, not "old-school" :-(
<mjg59> LaserJock: As in, knows what writing to various bits of hardware actually /does/
<bddebian> stuff? :)
<mjg59> Oh man
<mjg59> This is totally unfair
<mjg59> Upstream kernel works fine
* mjg59 starts diffing stuff
<ajmitch> mjg59: that console font we use has a certain style, really.. :)
<zul> mjg59: what borked?
<mjg59> zul: unlock_ExtINT_logic on x86 is broken
<mjg59> in arch/i386/kernel/io_apic.c
<zul> ah ok
<mjg59> Hangs when it hits CMOS_WRITE(save_control | RTC_PIE, RTC_CONTROL);
<bddebian> apic is just broken in general :-)
<mjg59> Yeah, utterly unlike xtpic
<mjg59> Oh, no, wait
<zul> mjg59: something to do with the real time clock?
<mjg59> zul: Yeah
<zul> edgy right?
<mjg59> Yup
<zul> well according to rtc.h RTC_PIE is the periodic interrupt enable
<mjg59> yeah
<mjg59> But why would enabling that instantly hang the machine?
<zul> no idea
<bddebian> Heya Hobbsee
* mjg59 tries reverting various things back to 2.6.17
<mjg59> Bastard.
<Hobbsee> hey bddebian 
<Hobbsee> mjg59: what's happened?
<mjg59> Narrowed down to one of two lines, neither of which looks obviously wrong
<ajmitch> hello Hobbsee 
<Hobbsee> hey ajmitch 
* mjg59 tries to work out WTF this patch is meant to be doing
<mjg59> Ooooooooooooooooooooooooooh
<mjg59> I see
* mjg59 wonders where this patch came from...
<Keybuk> OUTER SPACE
<mjg59> Now that is *really* odd
<mjg59> I can find the a git commit with that line and one without
<mjg59> But I can't find the commit that added it
<zul> have you tried in linus's tree?
<mjg59> Oh, no, here it is
* mjg59 looks a bit confused
<mjg59> No...
<mjg59> Sigh.
<mjg59> Dunno where it came from, but I'll send the fix
<mjg59> desrt: Around?
<AlinuxOS> Hehe Great: http://www.alinux.netsons.org/wp-content/writer.jpeg For first time here it is Georgian OO.org ;)
<AlinuxOS> http://www.alinux.netsons.org/wp-content/calc.jpeg  ;)
<AlinuxOS> http://www.alinux.netsons.org/wp-content/base.jpeg
<AlinuxOS> http://www.alinux.netsons.org/wp-content/impress.jpeg
<AlinuxOS> yuppy!
<LaserJock> wow, quite cool
<AlinuxOS> LaserJock, ;) Yeah!
<LaserJock> I've never seen Georgian before
<mjg59> No, seriously, this is mad
<mjg59> I genuinely can't work out where this line came from
* mjg59 cries
* bddebian hugs mjg59
<mjg59> Oh, I see
<mjg59> Still can't work out where it is in git, but still
<mjg59> I think I'm getting confused by how gitweb represents merging
<jdong> mjg59's state of enlightment can be modeled using a sine wave....
<AlinuxOS> LaserJock, hehe Ubuntu is the first distribution that supports it ;)
<AlinuxOS> http://ka.wikipedia.org/wiki/%E1%83%9A%E1%83%98%E1%83%9C%E1%83%A3%E1%83%A5%E1%83%A1%E1%83%98%E1%83%A1_%E1%83%93%E1%83%98%E1%83%A1%E1%83%A2%E1%83%A0%E1%83%98%E1%83%91%E1%83%A3%E1%83%A2%E1%83%98%E1%83%95%E1%83%94%E1%83%91%E1%83%98#Ubuntu_Linux
<AlinuxOS> LaserJock, some other screenshots.
<AlinuxOS> + Info of course in Georgian.
<jdong> AlinuxOS: if I saw that URL in my apache logs, I'd issue out an IP ban ;-)
<jdong> j/k
<AlinuxOS> jdong, :)
<mjg59> Yay I win
<bluefoxicy> oh
<jdong> note to self: mjg59 wins
<bluefoxicy> georgian is some kind of hebrew, ok
* bluefoxicy thought AlinuxOS meant like in BZFlag
<AlinuxOS> bluefoxicy, :) Not at all ;) It's Caucasian language with non Indoeuropean roots.
<jdong> so it's nobrew of hebrew?
<LaserJock> haha
<bluefoxicy> AlinuxOS:  yes but my point was I thought you meant Georgian == Georgia
<bddebian> yuck yuck
<bluefoxicy> I expected something like Redneck in BzFlag :P
<LaserJock> Georgia is a country too bluefoxicy 
<bluefoxicy> I did not know that
<bluefoxicy> I'm american, I don't care about the rest of the world wtf?  :P
<AlinuxOS> bluefoxicy, I don't really know what you are talking about :) I don't have 3d support on my computer :) So I can't play :)
<bluefoxicy> ah
<bluefoxicy> I'll find a screen
<AlinuxOS> bluefoxicy, Rep. Georgia.
<LaserJock> I'm american too but I remember a little from my college geography class ;-)
<LaserJock> and that isn't Representative Georgia either bluefoxicy ;-)
<bluefoxicy> haha
<AlinuxOS>   Here you are, a georgian complete modern alphabet :)
<AlinuxOS> we are small population, only 4 milions :)
<bluefoxicy> ah, that's like my state
<mjg59> Keybuk: Uhm.
<AlinuxOS> So it's normal that someone donn't knows about :)
<mjg59> Keybuk: As far as I can tell, current behaviour with usplash is to switch to vt 1, see the font change and then switch to gdm
<mjg59> Keybuk: I thought you said that had been fixed?
<bluefoxicy> mjg59:  is there a mode that makes Ubuntu display random cryptic messages during boot?
<AlinuxOS> And mjg59 :) Is a first Georgian font packager :p
<bluefoxicy> mjg59:  Smoothing landscape, rheticulating splines, etc
<Keybuk> mjg59: I think it still does that, yes
<Keybuk> don't think it switches to vt1 though?
<bluefoxicy> </simcity 2000)
<mjg59> Keybuk: That's why the clear statement was there
<Keybuk> right, but that clear statement clears whatever is on vt1 :p
<Keybuk> ie. getty
<Keybuk> why does it switch at all?
<mjg59> Keybuk: Because it's been asked to quit
<mjg59> And because you can't set the console font when the VT is in graphics mode
<Keybuk> looking at the current init script, it only switches to vt1 after it's set up the font
<Keybuk> assumedly to put it on the console with the getty in case gdm doesn't start
<mjg59> The font can't be set until usplash has exited
<Keybuk> right
<Keybuk> look at the init script
<Keybuk> I have 0.4-25 here
<Keybuk> it does usplash_write QUIT, loops until usplash's pid vanishes, then calls setupcon ($CONSOLE_SCREEN) and only then does it switch to vt1 if the fgconsole is 8
<Keybuk> you don't need to be on vt1 to change the font, just a text vt (which it is, because usplash has quit)
<mjg59> Keybuk: So usplash is asked to quit, and in the process changes to vt 1
<mjg59> Because that's the behaviour we generally want
<mjg59> Where "vt 1" is actually "whatever vt it started on"
<mjg59> s/it/it was/
<Keybuk> ah
<Keybuk> usplash doesn't change to vt 1 when it quits ;)
<Keybuk> should delete that code really, it's a total no-op
<Keybuk> switch_console () doesn't work in usplash
<mjg59> Keybuk: Mm?
<Keybuk> for one very good reason
<Keybuk> it opens /dev/tty1 ... which doesn't exit
<Keybuk> uh, exist
<mjg59> In what way "doesn't exist"?
<Keybuk> usplash is run from the initramfs
<Keybuk> in the namespace of the initramfs
<mjg59> Yes
<Keybuk> /dev in the initramfs is a tmpfs that is moved to the real root filesystem
<Keybuk> at which point it briefly exists as /root/dev/...
<Keybuk> before the initramfs is recursively deleted to free up memory
<mjg59> Oh
<Keybuk> so when usplash does it's final switch_console (saved_vt) thingy
<Keybuk> it actually does sod all, because open returns ENOENT :p
<mjg59> So what you mean is "switch_console() doesn't work after initramfs has gone away"
<Keybuk> right
<mjg59> Rather than "switch_console() doesn't work"
<Keybuk> so nothing switches to vt1 before the console is setup
<Keybuk> and this doesn't matter
<mjg59> Keybuk: Except that I end up on vt 1 before the console is setup
<Keybuk> at the point the font is changed, the current tty is tty8 (usplash's), but usplash has quit and reverted that console to text mode
<Keybuk> so setupcon works fine
<Keybuk> mjg59: you see the font change?
<mjg59> 03:01 < mjg59> Keybuk: As far as I can tell, current behaviour with usplash is  to switch to vt 1, see the font change and then switch to gdm
<Keybuk> that surprises me
<Keybuk> where is the "switch to vt1" coming from?
<mjg59> Just let me make sure I'm running the latst version of all this sutff
<Keybuk> (there'd actually be a terrible race if that code worked, btw ... people with fast machines would have usplash switch *away* from gdm, no?
<mjg59> No
<Keybuk> why not?
<mjg59> gdm wouldn't be able to change until usplash had released the lock
<Keybuk> what lock?
<mjg59> The vt switching madness
<mjg59> It's handled inside bogl or svgalib, depending
<Keybuk> except gdm does switch away, no?
<Keybuk> otherwise gdm wouldn't appear until the end of the boot process
<Keybuk> and it definitely appears long before that
<mjg59> Only after usplash has shut itself down
<Keybuk> how does usplash know to shut itself down?
<mjg59> Either the quit or the vt switch request
<Keybuk> ah, it gets a signal when gdm causes the vt to switch?
<mjg59> Yes
<Keybuk> right
<Keybuk> where is that code?
<Keybuk> I can't see it
<Keybuk> the only signal it appears to act on is SIGALRM
<Keybuk> inside bogl I guess?
<mjg59> In either bogl or svgalib
<mjg59> Yeah
<mjg59> You don't really want to go there unless you need to
<mjg59> Ok
<mjg59> Hm
<mjg59> That's interesting
<Keybuk> and that causes usplash to exit without switching the console back?
<Keybuk> (the interesting thing, of course, is that setupcon *must* work with a graphical tty, because it works just fine underneath X :p)
<mjg59> Keybuk: The kernel doesn't allow that
<mjg59> Hm.
<mjg59> so now I'm not seeing the font change, but I *am* seeing VT 1
<Keybuk> doesn't allow which?
<mjg59> Keybuk: Changing the console font
<Keybuk> it must do ...
<Keybuk> my console font is changed, and at no point do I see VT 1 during boot
<mjg59> Then conceivably it's doing it to vt 8
<mjg59> Nope, just saw the font change again
<Keybuk> oh, hmm, maybe I do see the font change
<Keybuk> it's just so fast that it's almost subliminal
<Keybuk> it's as gdm starts
<mjg59> Yes
<Keybuk> ahh
<Keybuk> gdm's init script runs the usplash init script!
<Keybuk> which calls setupcon;chvt 1
<mjg59> But we're on vt 1 before setupcon completes itself
<mjg59> Otherwise there'd be no visible change
<Keybuk> maybe setupcon isn't immediate?
<Keybuk> I remember Colin saying it forks off processes to do stuff
<Keybuk> if it doesn't wait() on those, it's entirely possible that setupcon exits before the font is properly set
<Keybuk> ah, it's just a shell script
<mjg59> Keybuk: static int con_font_set(struct vc_data *vc, struct console_font_op *op)
<mjg59>         if (vc->vc_mode != KD_TEXT)
<mjg59>                 return -EINVAL;
<Keybuk> mjg59: ok, I believe you :p
<mjg59> I've had this argument with Otavio after he bitched to Newsforge about usplash "fixing things the wrong way"
<Keybuk> surely that's not the current vt though, but any specified vt?
<Keybuk> there must be code like
<mjg59> Keybuk: Give me a sec
<mjg59> Hm.
<mjg59> Maybe that /does/ work
<mjg59> Oh, no
<mjg59> Keybuk: Doing so corrupts X
<mjg59> Actually, that's something of a point
<mjg59> /something/ is corrupting usplash around the time that gdm starts
<Keybuk> for (i = 1; i < 10; i++)  con_font_set (vt(i), ...)
<Keybuk> ie call con_font_set on all the vts
<Keybuk> or is the vt always the process-current vt?
<Keybuk> or is the vt always the kernel-current vt?
<Keybuk> (mmm.... vts are so complicated)
<Keybuk> X gets corrupted by a lot of things :)  never call TIOCSCTTY on /dev/console when X is running
<Keybuk> for some unknown reason, it gets upset by that
<mjg59> I have a feeling it might be the process-current vt
<mjg59> But I'll check now
<fabbione> morning guys
<Hobbsee> hi fabbione 
<ajmitch> hi fabbione 
<Keybuk> morning fabio
<mjg59> Keybuk: So the default behaviour of consolechars is to do it to the current vt, but it seems like it might work on others
<Keybuk> that doesn't need to be vt 1 though?
<Keybuk> when usplash exits is restores vt8 to be KD_TEXT, no?
<mjg59> Should do, yeah
<Keybuk> that's almost empty
<Keybuk> if gdm's init script called "DO_NOT_SWITCH_vt=y usplash start" and that stopped the chvt, that'd probably stop the font change being shown
<Keybuk> I imagine the only reason you see the font change is that it doesn't take effect immediately
<Keybuk> I'm guessing here though
<fabbione> Keybuk: hey dude
<jdub> fabbione: reboot successful!
<fabbione> jdub: score
<jdub> fabbione: thanks :-)
<fabbione> jdub: you should thanks Keybuk .. i only tested his fix and uploaded
<jdub> Keybuk: thanks!
<Keybuk> jdub: what did I unwittingly fix?
<bddebian> heh
<Keybuk> o/~ pia waugh / pia waugh / pia pia pia waugh
<jdub> Keybuk: you gave fabbione a fix for md/uuid
<Keybuk> so I did, aren't I clever?
* Keybuk hurls his laptop across the room (again)
* bddebian catches it and runs
<Keybuk> when doing readahead testing, the last thing you want is a laptop that doesn't reboot properly because it powers itself off
<Keybuk> NEVER BUY A LAPTOP WITH AN ATI CHIPSET
<fabbione> humpf.. waking up at 4am isn't exactly love
<bddebian> heh
<Keybuk> fabbione: depends how you're being woken up, I find
<fabbione> Keybuk: by a very hungry screaming little boy :)
<Keybuk> you've met David, right? :p
<fabbione> yeps :)
<Keybuk> is scary now, less than two weeks until he moves in
<Keybuk> my batchelor-hood is in its final days
<mjg59> Keybuk: So suspend now works on almost every machine. Except yours.
<Keybuk> mjg59: *cry*
<Keybuk> mjg59: could I have one of your spare laptops/ :p
<mjg59> I thought you had a newer one now?
<Keybuk> no, still the nc4010
<Keybuk> have started saving for a new one, but will be a year before I can afford it
<desrt> mjg59; or am i meant to see you here?
<Keybuk> someone needs to beat up smurfix
<Keybuk> it looks like he's got an autoresponder that replies to mailing list posts
<Keybuk> To: 	ubuntu-devel@lists.ubuntu.com, Ubuntu Installer <archive@ubuntu.com>
<Keybuk> is kinda worrying
<Fujitsu> Keybuk, somewhat.
<Fujitsu> I'm sure the archive is liking getting those responses :P
<Keybuk> in fact
<Keybuk> it looks like it's responding to edgy-changes mails!
<Fujitsu> Terrific!
<Fujitsu> Absolutely fantastic.
<Keybuk> or perhaps dapper-changes
<Fujitsu> archive actually has a mailbox?
<Hobbsee> Fujitsu: sure, it points to /dev/null
<Fujitsu> Ha. Ha.
<Fujitsu> Heya Hobbsee.
* Fujitsu yawns..
<Hobbsee> heya
* Hobbsee whines at her inbox
<Keybuk> Fujitsu: amusingly his responder appears to obey Reply-To
<Keybuk> and is thus sending them to ubuntu-devel
<Fujitsu> I noticed a couple of them appeared there.
<mjg59> desrt: Can't remember. Did you try pristine upstream sources for your timing problem?
<desrt> no
<Fujitsu> It's somewhat silly of smurfix to do such things...
<desrt> intuition tells me that it'll still be a problem though
* Fujitsu looks for the RFCs it violates.
<mjg59> desrt: Can you try Ubuntu sources with the patch from 53910?
<Keybuk> autoresponders don't, afaik, violate any RFC
<Keybuk> they're just stupid
<Fujitsu> Darn.
<Fujitsu> It'd be nice if they did.
<desrt> bug 53910
<Ubugtu> Malone bug 53910 in linux-source-2.6.17 "Can't boot: mp-bios bug timer not connected to io-acp" [Untriaged,Fix committed]  http://launchpad.net/bugs/53910
<mjg59> It won't actually fix things, but it might let you boot
<mjg59> (well, fix the fundamental issues)
<desrt> mjg59; NO
<desrt> mjg59; no no no
<desrt> wrong fix.
<mjg59> desrt: In what way? That's what upstream actually looks like.
<desrt> that's like taking the canary out of the cave because the damn thing keeps dieing
<mjg59> The bogomips figure will be recalculated later on anyway
<desrt> only for the other CPU
<mjg59> But the fact that we had that code was a bug
<desrt> so
<desrt> we accept that it's ok to have delay loops that run 4x faster than they're supposed to
<desrt> and we end up with really odd hardware driver bugs
<desrt> but at least your system boots....
<desrt> mjg59; that patch will definitely fix the symptom.  i had a patch like that in my kernel a month or two ago when i was trying to find the source of the problem
<mjg59> desrt: As I said, that's what upstream looks like
<mjg59> It's also what amd64 looks like
<desrt> what patch did this come in with?
<mjg59> An earlier fix for the ATI IGP200 chipsets defaulting to routing the timer interrupt via the 8259 and the APIC
<desrt> well... kill it off if you like
<mjg59> Well, it's dead
<desrt> but we should probably also fix the problem
<mjg59> Since it breaks the ATI systems
<mjg59> And much as I'd like to break them, since they're really, really horrible...
<ScreaminIke> i have a question... can i make a feature request from here?
<desrt> mjg59; i thought the patch was introduced to _fix_ them :p
<mjg59> desrt: It did, then they got fixed differently and we didn't revert the entirity of the patch
<desrt> ok.
<desrt> well
<desrt> there are clearly places in the kernel that assume that a mdelay() and friends will correspond to jiffies in some way or another
<mjg59> Yes
<desrt> i think the atheros driver might be one of them
<desrt> it used to randomly lock up my keyboard
<mjg59> But
<desrt> since i set the bogomips override it hasn't
<mjg59> bogomips get recalculated when CPU frequency changes
<desrt> so maybe we could force a step up/down on boot?
<mjg59> Well, it's likely that it gets done when the cpufreq driver is loaded
<Keybuk> I can never understand why you can't edit the BIOS options from VMware
<Keybuk> and why you have to boot the damned vm to do it
<desrt> mjg59; i always wondered how that worked
<mjg59> But it would be interesting to see whether the calculation continues to have errors
<mjg59> After booting
<desrt> mjg59; you can see the log message for cpu#1 being calibrated
<ScreaminIke> uhm... i don't know where else to air this... but i put in the edgy release today and did a dry run of the system install... and there is no option in the keyboard layouts for dvorak... can that be integrated?
<desrt> mjg59; it always gets it right
<desrt> it's just cpu0 that has the wrong value
<mjg59> Yeah
<desrt> so maybe by the time cpu1 comes up the system has gotten to a saner state
<desrt> or maybe it's just that SMIs are always done on cpu0
<mjg59> Well, SMM code will always run on CPU 0
<desrt> well
<mjg59> But I don't know if the rest of the system is blocked while that's happening
<desrt> that doesn't make much sense to me
<desrt> if an SMM is launched to emulate a port access then that has to happen on the CPU that initiated
<mjg59> No, the southbridge just has to give back the value that the processor requested
<desrt> so it executes the SMI on cpu0 while causing cpu1 to fly a holding pattern?
<mjg59> That's what I'd assume, though it's always possible that cpu 1 carries on executing code
<mjg59> I haven't checked the specs for that situation
<desrt> oh.  execiting
<desrt> bogomips are in /proc/cpuinfo
<desrt> let's check this out
<mjg59> Hm. Actually, maybe it just multiplies or divides the existing value.
<mjg59> How irritating.
<desrt> i think you're right
<desrt> i bugged teh calibration routine to dump some info to me at KERN_CRIT
<desrt> i see nothing
<mjg59> Well, the calibration routines are __init
<desrt> just the initial reading for each cpu
<desrt> ya... that too
<desrt> so either cpufreq reinvented the wheel as a better alternative to removing a couple of __init tags
<desrt> or you're right
<desrt> btw -- new console font looks really nice
<desrt> i think SMIs run on CPU1
<desrt> my reasoning is a bit handwavy but it goes as follows:
<desrt> actually.  i retract my argument.  it doesn't work
<desrt> nm.
<desrt> in any case something slows CPU#1 down vs CPU#0
<Keybuk> WHY is there a bootchart udeb!!
<desrt> what is a udeb?
<AlinuxOS> guys, I can't see my Ubuntu booting
<Fujitsu> Why not, Keybuk?
<mjg59> desrt: Microdeb
<AlinuxOS> usplash dosen't work.
<mjg59> Packages used in the installer
<Fujitsu> !doesn't work
<Fujitsu> Darn, no ubotu in here.
<desrt> mjg59; maybe we can force recalibration after the bootup is in full swing or something
<Fujitsu> AlinuxOS, what do you mean it doesn't work>
<AlinuxOS> title           Ubuntu, kernel 2.6.15-25-686
<AlinuxOS> root            (hd0,4)
<AlinuxOS> kernel          /vmlinuz-2.6.15-25-686 root=UUID=295e49f4-e2ab-4b75-804e-e02a6e95e23e ro quiet splash vga=0x342
<AlinuxOS> initrd          /initrd.img-2.6.15-25-686
<AlinuxOS> savedefault
<AlinuxOS> boot
<Fujitsu> Please don't paste!
<desrt> mjg59; but otherwise i think we should just detect the stupid ICH7 and kill off SMI_USB_EN during boot
<AlinuxOS> Fujitsu, that I se somtimes green lines ;)
<desrt> mjg59; as an alternative, we could encourage the upstream kernel guys to kill off the idea of bogomips
<desrt> because, really, if you have a TSC, bogomips and approximate delay loops are just a really dumb idea
<bluefoxicy> whoops
<bluefoxicy> oopsed my kernel
<AlinuxOS> Fujitsu, with Dapper usplash worked...but after upgrade I can't even switch in terminal mode.
<bluefoxicy> by killall'ing apport while it was trying to collect data
<AlinuxOS> Alt + F1
<Fujitsu> AlinuxOS, what type of video card?
<desrt> mjg59; with things like SMI's going off at random times you cannot assume that a delay loop run now will take the same number of ticks as a delay loop run later
<desrt> mjg59; which is the very basis of bogomips, unfortunately :(
<AlinuxOS> Fujitsu, 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M
<mjg59> desrt: It's hardly limited to ICH7
<Fujitsu> Ah, ATI...
<AlinuxOS> Fujitsu, yes ATI :)
* Fujitsu runs away from the abomination.
<AlinuxOS> Fujitsu, my new hardware configuration will be NVIDIA finally! :)
<AlinuxOS> but on laptop I have ATI card.
<Fujitsu> Urgh, Nvidia.
<desrt> mjg59; how easy do you figure it would be to replace the delay loop with an accurate equivlent of itself that requires no calibration?
<Keybuk> mjg59: interestingly, the vt switch does not come from the usplash init script
<Keybuk> mjg59: could setupcon be doing that itself?
<desrt> any system which abuses SMM to the extent that my macbook does would have TSC
<AlinuxOS> Fujitsu, so which one ?
<AlinuxOS> I would like to use compiz XGL things :)
<Keybuk> mjg59: nope, that's not it either
<Fujitsu> My Intel thing works fine, but I don't like Xgl-ish stuff.
<AlinuxOS> Fujitsu, I understand.
<AlinuxOS> Fujitsu, some people said that gnome 2-16 includes some visual effects...but I can't see anything :)
<AlinuxOS> maybe it's my card issue.
<AlinuxOS> good night chanel!;)
<Keybuk> mjg59: ooh, S4 actually appears to work on my laptop now \o/
<fabbione> slomo: ping?
<Keybuk> don't suppose anyone knows off-hand the mkisofs runes to turn an ubuntu cd tree into a bootable iso?
<Keybuk> (i386)
<fabbione> oh it was on the wiki
<Keybuk> ah, found it on kubuntu stuff
<Keybuk> well, let's see if this works
<Keybuk> mjg59: no joy with S3 :(
<Keybuk> mjg59: on resume from S4, the fan state seems screwed.
<Keybuk> mjg59: they're all off, but /proc/acpi/fan/*/state say they're all on
<ScreaminIke> check? check one? check one two...
<ScreaminIke> anyone out there?
<infinity> ScreaminIke: Yes, but you probably don't need to do a mic test to determine that.
<ScreaminIke> :) alright. can i make feature requests here? is there a mailing list for that?
<ScreaminIke> it's kind of important, and oct 1st is coming fast... so i wanted to know the easiest way to request something...
<infinity> We're way past feature freeze.
<Keybuk> what happens on oct 1st?
<infinity> Keybuk: I turn into a pumpkin.
<infinity> No, wait, that's the 31st.
<infinity> I have no idea, then.
<ScreaminIke> well... it's just that the installer ... i tried it out earlier in a dry run, and it doesn't have my kbd layout in it
<ScreaminIke> i use dvorak... 
<fabbione> ScreaminIke: then file a bug in launchpad
<ScreaminIke> it has been in past releases... 
<ScreaminIke> ok
<ScreaminIke> will do
<fabbione> it's a regression, not a feature in this case
<fabbione> infinity: are you busy now or can we check a few things together?
<infinity> fabbione: A bit busy, but if it's something quick (or something I can think about while working on other stuff), hit me. :)
<fabbione> infinity: just curious about sparc livecd.. is it done the same way as other primary arches or did we still need to do the transition for it?
<fabbione> infinity: do we actually do it at all ?
<infinity> fabbione: We've not been building it at all recently, though I'll turn it back on for testing before beta, if you really want to play with it.
<infinity> fabbione: And it'll be squash+union, same as the others, cloop is long dead.
<fabbione> infinity: i would like to give it a shot.. can you let one build now?
<infinity> Sure, I can do a 1-off build right now.
<infinity> Do you want a whole desktop, or are you just testing the theory?  (if the latter, I'll just build the "base" livecd)
<fabbione> base is enough
<fabbione> i want to see if it can boot
<infinity> Oh, crap.  Someone mentioned pizza, and instantly I'm both craving and starving.
<infinity> Ngh.
<fabbione> hmm pizza.. at 6am
<fabbione> no way i can get it here
<infinity> Can't order any here either, I'd have to go out.
<infinity> Uncivilised wasteland.
<infinity> No one starts delivering until dinner.
* Fujitsu runs some pizza down to infinity.
<infinity> Fujitsu: If you did, I'd love you...
<Fujitsu> Unfortunately, I'm stuck at school :P
* infinity remembers talk of Fujitsu fetching him McDonald's some late night or other during the release crunch, and that never happened...
<Fujitsu> What, I never said that? :P
<infinity> Or was that some other Melbournian?  Hrm.
<Fujitsu> You're eastern suburbs, aren't you?
<Hobbsee> infinity: hehe, it's still 6 weeks to go till release, he's got time
<infinity> Hobbsee: No, it was during the dapper release that this conversation happened. :)
<Hobbsee> ahhh :P
<Hobbsee> he's been too busy filing merges, i expect
<infinity> Hobbsee: I was somewhere in the middle of a 72-hour day, and a bit hungry at 3am. :)
<infinity> Fujitsu: Armadale.
<Hobbsee> hehe
<Fujitsu> More syncs than merges, Hobbsee :P
<Fujitsu> infinity, I thought so.
<Hobbsee> them too
<Fujitsu> And a couple of bugfixes.
* Fujitsu is in the middle of nowhere (ie. Ringwood East)
<infinity> Fujitsu: Sweet Jesus.  That *is* the middle of nowhere (I just looked at a map)
* Fujitsu slaps infinity.
<ajmitch> to think that even I've been there
<Fujitsu> ajmitch, did I miss you? :(
<fabbione> ajmitch: to what email address should i flood you with build logs?
<infinity> Aren't there wild animals and other such things that far out?
<ajmitch> Fujitsu: I was only there for a couple of days in july
<Fujitsu> fabbione, that's actually happening?
<ajmitch> in ringwood
<Fujitsu> infinity, not quite :P
<ajmitch> fabbione: ajmitch@ubuntu.com
<infinity> Fujitsu: No, seriously.  By the time I zoomed the map out far enough that I could see the bay on the left, I could also see New Zealand on the right.
<fabbione> infinity: you should still be able to access the IMAP folder on my server.. want to check or should i forward?
<fabbione> Fujitsu: no, this is only for a local test run on sparc
<Fujitsu> infinity, ha ha.
<Fujitsu> fabbione, OK.
<infinity> fabbione: Pretty sure I deleted that account from my tbird setup.  Easier to just forward, and I can procmail it to somewhere.
<fabbione> infinity: favourite email?
<infinity> fabbione: adconrad@0c3.net, to avoid bouncing it through 12 other mail servers before it lands there anyway. :)
<fabbione> ok done
<fabbione> you might get a few spam mails while i make the system start up
<infinity> ajmitch: You may want to do the same, so you're not passing a few gigs of logs through fiordland for no good reason.
<ajmitch> true
<Fujitsu> infinity, I was thinking that might be advisable.
<infinity> fabbione: What's going to be the From: address, I'll procmail it now.
<fabbione> infinity: something like sparcbuildd@fabbione.net or very close to that
<infinity> "or very close to that"...
<infinity> Helpful.
<ajmitch> ajmitch@tauware.de might be better, it won't overflow as fast :)
<fabbione> i don't remember :)
<fabbione> ah there it is
<infinity> :0
<infinity> * ^From:.*sparcbuildd@fabbione.net.*
<infinity> sparc-rebuild
<fabbione> From: Buildd user <buildd*@sunfire.int.fabbione.net>
<infinity> procmail needs an "or something like that" option.
<fabbione> mind the * there will be about 24 buildd users running
<Fujitsu> infinity, precisely.
<Fujitsu> 24!?
<Fujitsu> Over how many machines?
<infinity> Fujitsu: One for each CPU.
<fabbione> Fujitsu: one machine
<infinity> (Well, for each core/thread)
<Fujitsu> ....
<Fujitsu> Most impressive.
<fabbione> unfortunatly i will get the 64 CPU only next year
<fabbione> 64 or 128
<infinity> Only impressive when they're all running.  Each individual one is kinda sad. :)
<Fujitsu> How long would a complete build like that take?
<fabbione> not sure yet
<Fujitsu> fabbione, why do you have such machines at your disposal?
<fabbione> Fujitsu: about 48 hours for all of archive
<fabbione> Fujitsu: because i am a developer?
<infinity> fabbione: Okay, procmail happy.
<Fujitsu> That really is quite impressive!
<jdub> Fujitsu: also he has no heating. in demark.
<fabbione> infinity, ajmitch: ignore the first few emails you will get.. they will be mostlikely crap from wanna-build and one/two build tests to ensure that the chroots and the * are happy
* ajmitch has procmail tweaked to suit
<infinity> fabbione: *nod*
<fabbione> infinity:  i didn't run this in the last 6 months.. and i need to restore the setup..
<infinity> fabbione: Understood.  I always spend a few minutes fiddling with a new w-b/buildd setup too. :)
<fabbione> infinity: ehhe
<infinity> fabbione: But usually, no one else gets the logs, so I get to look all-knowing and unfailing.
<fabbione> infinity:  i know :)
<fabbione> i might just remove your forward while i do that.. but i am lazy :)
<fabbione> lazy as any other sysadm in this world
<infinity> I'm pretty sure I define lazy in the sysadmin world these days.
<infinity> I have a "new" colo box I started setting up a year ago.. And then never finished.
<Fujitsu> Fantastic!
<infinity> And i think it's been a couple of months since I've attacked the freedesktop.org sysadmin backlog, though we have enough people to share that load that I can pretend I don't feel guilty.
<mjg59> Keybuk: Ought to be fixed in -8
<mjg59> If not, I'll take a look into it
<Keybuk> mjg59: -8 ?
<Keybuk> kernel ?
<Hobbsee> likely
* infinity tries this livefs build for the third time...
<infinity> vivies needs to be faster, so it'll fail quicker...
<mjg59> Keybuk: Yeah
<mjg59> Keybuk: If you want mad crack, install uswsusp
<mjg59> It ought to be quite a bit faster. It's certainly prettier.
<lifeless> mjg59: will that ever be in our default config ?
<fabbione> Keybuk: nice shot with readahead
<pitti> Good morning
<ajmitch> morning pitti 
<mjg59> lifeless: +1, I hope
<Keybuk> 'Could not find the frame base for "main".' ?!
<Keybuk> WTF ?!
* pitti hugs ajmitch 
<Hobbsee> hi pitti 
<jdong> Keybuk: you did bump up usplash_timeout for foreground readaheading, right?
<Keybuk> jdong: no, didn't think of it
<jdong> Keybuk: yeah... that's kinda necessary, especially for slower hd's
<_ion> Great, new xmoto (0.2.1) in universe.
<Fujitsu> _ion, yup :)
<Fujitsu> Hm.. I did the sync before that, not that one. :(
* pitti hugs Hobbsee as well
<Hobbsee> :)
<pitti> hey Keybuk 
<pitti> Keybuk: wow, so early today? :)
<Keybuk> pitti: late :p
<dholbach> good morning
<Mithrandir> iwj: can I get firefox to resize tabs rather than adding the scroll thingies at the ned of the tab bar?
<Chipzz> Mithrandir: there is a minimal tab width in about:preferences
<Chipzz> which will give you more tabs
<Chipzz> but it will still give you the scroll thingies given enough tabs
* ajmitch gave up & used an extension instead
<Mithrandir> Chipzz: ah, thanks.  Seems to have helped.
<Mithrandir> (browser.tabs.tabClipWidth = 1 , browser.tabs.tabMinWidth = 1)
<enrico> Hi.  Who's in charge on i18n these days?
<Chipzz> Mithrandir: you're welcome ;)
<pitti> enrico: mostly me
<pitti> enrico: will come back shortly, I need a quick reboot
<sabdfl> doko: anybody else seeing openoffice crash-on-save?
<fabbione> sabdfl: known issue
<fabbione> sabdfl: they are working on it
<Hobbsee> any reports of X breaking with the -8 kernel?
<carlos> sabdfl: https://launchpad.net/distros/ubuntu/+source/openoffice.org/+bug/58508
<Ubugtu> Malone bug 58508 in openoffice.org "cant save under edgy" [High,In progress]  
* Mithrandir wonders what the fix for vmware on edgy is.
<Hobbsee> hey Mithrandir 
<Mithrandir> hiya Hobbsee
<seb128> doko, doko_: ping?
<seb128> I don't know which one to /query :p
<doko_> seb128: pong
<seb128> doko_: https://launchpad.net/distros/ubuntu/+source/pygobject/+bug/61323 ... do you have any idea on the topic?
<Ubugtu> Malone bug 61323 in pygobject "[Edgy]  python-gobject is missing a Conflicts[/Replaces]  python-gtk-1.2" [Untriaged,Confirmed]  
<seb128> doko_: looks like a python-support issue no?
<mvo> mako: GREAT blogpost!
<doko_> seb128: get rid of python-support ...
<seb128> doko_: I've nothing against that, I would appreciate a quicker resolution for now though ;)
<dholbach> seb128: pysupport -> pycentral should be quick enough ;-p
<seb128> dholbach: feel free, I'm assigning those bugs to you then ;)
<dholbach> don't even think about it
<seb128> dholbach: and do that quick freeze for beta is tomorrow, thank you
<enrico> uhm, who's in charge of im-switch?  http://packages.ubuntu.com/dapper/x11/im-switch doesn't say (and BTW, links to the warty BTS :)
<seb128> dholbach: so don't tell me it's quick enough :p
* dholbach hugs seb128
<seb128> enrico: we don't really have people "in charge" for it I think, what is your issue?
<enrico> the scim-chewing upstream would like to discuss packaging issues
<enrico> seb128: ^
<mvo> hey enrico!
<enrico> mvo: hi!!
<enrico> mvo: did you see my wxssearch?
<mvo> enrico: no, do you have a link?
<seb128> enrico: feel free to discuss those here
<mvo> enrico: or in #ubuntu-l10n :)
<seb128> mvo is what is the nearer or a im-switch maintainer here I think ;o
<enrico> mvo: sure I do: svn co svn://svn.debian.org/debtags/python
<seb128> mvo: I've not on that chan :p
<seb128> s/I've not/I'm not
* mvo checks it out
<mvo> seb128: its easy to join :P
<seb128> oh, "click on a chan to join" is broken
<enrico> mvo: also read http://lists.alioth.debian.org/pipermail/debtags-devel/2006-August/001324.html
<seb128> doko_, dholbach:
<seb128> <lool> seb128: it seems to be due to the alternatives, and the current consensus is that we should remove the alternatives and use diversions instead
<seb128> lool: thank you ;)
* dholbach hugs lool
<mvo> enrico: nice tool! and AFAICS all python :)
<Mithrandir> mjg59: is usplash supposed to use tabs or spaces?  Its coding style could use a bit of.. unification.
<enrico> mvo: yes, all python.   If  youw ant to borroww... :)
<enrico> as much as I don't fancyy python that much, it's  the only languaeg I know whicch has nattive sest (beyoond  C++, of ccourse)
<minghua> enrico: by scim-chewing upstream do you mean Andrew Lee?
<minghua> enrico: I know something about im-switch but am not familiar about how Ubuntu uses it
<enrico> minghua: yes, I'm talking with him.  Appearently, Ubuntu has a patch on top of debian's im-switch that break things
<StevenK> enrico: That should be easily determinable using http://patches.ubuntu.com/
<seb128> enrico: what about telling him to join the chan on telling here what is wrong?
<minghua> StevenK: not really when you look at a 443K patch :-(
<minghua> for those interested: we are talking about bug #57081
<Ubugtu> Malone bug 57081 in scim-chewing "scim-chewing cannot enter any Chinese character" [Untriaged,Confirmed]  http://launchpad.net/bugs/57081
<mvo> enrico: or can we join the channel where he is hanging out?
<Kamion> mjg59: uh, re that conversation with Keybuk - I already fixed the business where usplash can't switch back to tty1 because /dev/tty1 doesn't exist, by just holding the fd open
<Kamion> also, I hate C++
<lifeless> anything specific, or just its existence ?
<Kamion> lifeless: I have an excellent rant on this subject, but this IRC channel is too narrow to contain it
<Kamion> I think "Note that the definition of operator[]  is extremely simple: m[k]  is equivalent to (*((m.insert(value_type(k, data_type()))).first)).second." kind of sums it up
<Kamion> SIMPLE AS OPPOSED TO *(m+k), YOU FREAKING LOONS
<enrico> mvo: we /msg
<lifeless> Kamion: heh. its kindof like having the implementation of a functional language shoved up your nose, without type inferencing
<hunger> Kamion: You are aware that you can code m[k]  as k[m]  just as well? :-)
<lifeless> Kamion: so I can see that
<Kamion> hunger: yes
<lifeless> hunger: in c++ m[k]  is also the syntax for inserting into a set
<Kamion> hunger: although not in C++
<lifeless> hunger: aka dictionary
<Kamion> hunger: this is std::map
<lifeless> hunger: so they are not isomorphic for that case.
<Mithrandir> hunger: that follows trivially from *(m+k) given that + tends to be communicative.
<hunger> Kamion: Oh, yes, that dirty little trick to increase job security does not work with maps.
<lifeless> hunger: also, I'd note that just because you *can* do something, does not mean you *should* do something
<pitti> Mithrandir: mmm, communicative addition :)
<hunger> lifeless: There is a excelent HOWTO on writing unmaintainable code...
<pitti> definitively worth discussing in our commutation channels
<Mithrandir> pitti: addition, not addiction. :-P
<lifeless> hunger: I really hope its a 'DONTDO' not a "HOWTO"
<minghua> Oh, sorry, it seems I was wrong, enrico was not talking about bug #57081
<pitti> Mithrandir: of course, I'm not under the alcafluence of incahol that some thinkle peep I am
<Ubugtu> Malone bug 57081 in scim-chewing "scim-chewing cannot enter any Chinese character" [Untriaged,Confirmed]  http://launchpad.net/bugs/57081
<pygi> pitti: libburn is almost release ready, ahead of schedule ;)
<hunger> lifeless: It is a good read (and pretty hilarious in places) and demonstrates all kinds of stupid ideas:-)
<pitti> pygi: cool
<hunger> lifeless: http://thc.segfault.net/root/phun/unmaintain.html
<hunger> lifeless: The scary part is how much of that HOWTO made it into a best practice in the windows world.
<Hobbsee> i'm sad to say that our comp lecturer does something close to that
<ajmitch> hunger: yes, something I should pin up at work
<Hobbsee> read string and write sting
<shining> nice one, + is a communicative addiction
<minghua> mvo, enrico: I talked briefly with Andrew Lee (in Chinese), but he had to leave
<minghua> mvo, enrico: my understanding is that he thinks it's wrong for the scim-chewing package in ubuntu to provide its own im-switch settings 
<pitti> minghua: btw, I'm just talking with AndrewLee about scim stuff, but I don't know anything about it
<pitti> minghua: ok to forward him to you?
<hunger> Hobbsee: One of my coworkers keeps writing "ressource":-)
<Hobbsee> heh
<minghua> scim-chewing should just use the im-switch settings provided by scim
<shining> hunger: that's how it's written :)
<minghua> pitti: I think I know most of his opinions, but sure, forwarding won't hurt, minghua-list@sbcglobal.net
<hunger> shining: Yeap... but not in english.
<shining> hunger: oh :)
<minghua> pitti: I roughly know how scim works in Debian, but unfortunately Ubuntu uses a quite different system
<hunger> shining: It is the one place where german spelling shines through in the app.
<mvo> pitti, minghua: what should it do instead (scim-chewing)? just provide the default scim setting in im-switch?
* pitti makes a totally clueless face
<shining> hunger: french too
<hunger> shining: Well, basically all proper languages spell ressource right;-)
<minghua> mvo: I can't say for sure.  but Andrew Lee (scim-chewing's Debian maintainer) thinks it should USE the im-switch settings provided by scim package
<caleb-> mvo: im-switch in edgy/sid provides all_ALL for default, so it can support all locales. Dapper's im-switch has not all_ALL, so every scim engines has its own setting.
<minghua> mvo: im-switch is just a framework, it doesn't provide any settings for particular input method by its own
<mvo> caleb-, minghua: thanks. so we should probably change this in edgy because we have a newer scim there
<mvo> im-switch I mean
<minghua> mvo: good, it seems caleb- knows more about im-switch than I do :-)
<shining> hunger: I didn't know such a thing existed
<shining> hunger: proper language, I mean
<\sh> any schedule when sync requests for universe are processed? :)
<freeflying> mvo: minghua caleb-  as to the im-switch and scim, can we talk in #ubuntu-l10n
<tkamppeter> doko_, I have answered to the two OOo bugs which appeared now in the list of subscribed bugs for the printing team
<tkamppeter> They both seem to be really problems of OOo.
<doko_> tkamppeter: thanks, unfortunately that were the only printing related OOo reports ;)
<tkamppeter> doko_, "unfortunately"? I think it is a good result having only these few problems in such a big project. The OOo printing part seems to be one of the best printing facilities in applications.
<doko_> tkamppeter: no,  in the sense, that I have to care about the remaining bugs mysel =)
<pygi> doko_: could you please report our SoC results to soc-admin mailing lists? We want to be in good connection with Google folks ^_^
<doko_> f
<tkamppeter> General question about bug reports: On many the original poster did not answer our questions for months, should I reject them?
<doko_> pygi: it's on my list
<pygi> doko_: oki, thanks
<tkamppeter> Mike Sweet, upstream maintainer of CUPS, rejects unanswered bug reports after two weeks.
<doko_> tkamppeter: I think sfllaw did want to document a howto on these.
<dholbach> tkamppeter: yes, the desktop team rejects them after four weeks of inactivity
<dholbach> tkamppeter: you can grab a standard response from http://wiki.ubuntu.com/Bugs/Responses, if you like
<Kamion> it's somewhat package-specific, of course. There are many ubiquity bugs I reject after a month (when I get round to it), but sometimes other people have asked for information which I don't really need ...
<Kamion> so I don't let other people do the rejecting
<Kamion> hal 0.5.7.1-0ubuntu11 produces uninstallable binaries:
<Kamion>   * hal-device-manager (amd64 i386 powerpc)
<Kamion> is that being worked on?
<pitti> Kamion: I'm just hacking at hal
<pitti> Kamion: so I can look into it; any way to find out why it's uninstallable?
<ajmitch> Kamion: too late to get UVF exception for f-spot 0.2.1, I presume?
<Kamion> only trying to install it in a clean system
<Kamion> ajmitch: that depends, you can send mail and see
<ajmitch> ok, I'll give it a go then
<slomo_> fabbione: pong?
<fabbione> slomo_: mplayer foo.mpg
<fabbione> mplayer: symbol lookup error: mplayer: undefined symbol: a52_resample
<fabbione> i need to run away 10 minutes
<fabbione> bbl
<slomo_> fabbione: known problem... Nafallo was working on it
<fabbione> ok
<fabbione> thanls
<fabbione> thanks
<pitti> Kamion: ah, I just saw that infinity uploaded a new hal this morning; infinity, was that to solve uninstallability?
<pitti> infinity: can you please put that change into the bzr?
<pitti> ogra: I just uploaded a new g-v-m which fixes the 'unsafe removal' warning for me; can you please test again?
<pitti> Kamion: indeed, I tried it in a clean pbuilder, and infinity's patch fixes it
<ogra> pitti, will do ...
<doko_> Kamion, mvo, iwj: can dapper's dpkg handle bzip2 compression?
<pitti> infinity: (I'm fixing the bzr for your hal version now)
<fabbione> pitti: yes it was to solve the installability issue
<Kamion> doko_: yes, we did that eons ago
<Kamion> pitti: ok, thanks
<Kamion> doko_: hoary's dpkg has that
<doko_> Kamion: trying to keep OOo at the same size as it was for the dapper release ...
<realist> Can anyone explain, or point me towards an explaination as to why the lynx patch wasn't applied to either breezy/etch?
<pitti> ah, the lynx patch
<pitti> realist: -v?
<thom> _the_ lynx patch
<pitti> thom: aaah, that one!
<realist> pitti: ?
<tseng> realist: --verbose
<pitti> realist: which lynx patch do you talk about?
<realist> pitti: just the person to field this question; https://launchpad.net/distros/ubuntu/+source/lynx/+bug/60879
<Ubugtu> Malone bug 60879 in lynx "lynx gets stuck in infinite loop rendering invalid HTML" [Medium,Confirmed]  
<pitti> realist: ah; well, I want to have it fixed in edgy, of course, just ENOTIME yet
<realist> Does this fix belong elsewhere? And if so, where?
<realist> I see, thanks :-)
<pitti> realist: I'm grabbing the bug and mark it so that I'll fix it ASAP in edgy
<pitti> realist: no, it's not something we will backport to stable releases; it's a simple bug only after all
<realist> It should still be considered a security/stability issue, imho.
<pitti> realist: why a security issue?
<pitti> realist: stability, granted
<realist> Software security _should_ also encompass 'availability'
<pitti> infinity: for the record, I'll fix the krb5 FTBFS now
<caleb-> realist: Once it is fixed, you may request a backports if you want. :-)
<pitti> realist: right
<pitti> realist: for a daemon or server a DoS is an issue
<pitti> realist: but not for a client-side program that you run
<pitti> realist: otherwise every application crash would be a security issue
<realist> If one users process swallows 100% cpu, wouldn't that be an issue for the other users?
<pitti> realist: that can't be fixed in packages like lynx
<pitti> realist: you have to have pam limits and kernel support for resource limiting
<realist> I suppose, it's just my personal opinion after all :-)
<pitti> cat /dev/zero > /dev/null, there you go :)
<dholbach> realist: that'd be so lovely - we could assign all our bugs to pitti that way
<pitti> realist: the point is, it is unrealistic to fix all simple application crashes in stable releases
<pitti> it would make the stable release unstable and would hide real vulns behind a ton of bogus fixes
<realist> I wouldn't have thought so, in this case.
<realist> Just found a similar bug in 'vim' actually
* Kamion does scary scary evil to gparted in the absence of ubiquity-advanced-partition
<Kamion> er
<Kamion> I'm going to add an installer-mode-only option that lets ubiquity fake its idea of what filesystem is on a partition
<Kamion> hopefully that should let me avoid a large number of the bugs of the form "I pressed Back and now the partitioner has gone all weird on me"
* pitti is grateful that de.archive just started working properly again when archive.u.c. is down :)
<ogra> urgh, beta freeze is tomorrow ? what made me think its on the 28th ?
<StevenK> ogra: Your dealer.
<StevenK> ogra: Well, more correctly, what he sells you. :-P
<ogra> shit, i thought i'd have time to at least recoiver a bit and get some sleep ...
<StevenK> ogra: Plenty of time for that after the 26th of October.
* ogra prepares for another nightshift after being up 35h already
<StevenK> Hrm. I wonder how much No-Doz Kamion and Keybuk have already bought.
<ogra> :(
<StevenK> ogra: Seriously though, want a hand with something?
<Mithrandir> oh, jay.  I fixed the usplash-jumps-around-bug in casper-md5check.
* Mithrandir growls at floating-point types in C.
<pitti> Mithrandir: do floats behave differently in other languages?
<ogra> StevenK, no, i need to fix one thing in ltsp that i prepared in detroit the last week (printing) and need to extensively test the last uploads i did ... and some finalization in edubuntu-artwork i didnt get yet ...
<ogra> nothing someone else could really help with
<ogra> (unless you have an ltsp lab)
<StevenK> ogra: Not so much, no.
<Mithrandir> pitti: in perl, they do, yes.
<Mithrandir> : tfheen@xoog ~ > perl -le '$a = 5; $b = 7; print $a / $b;'
<Mithrandir> 0.714285714285714
<Mithrandir> in python, they don't.
<pitti> Mithrandir: ah, you mean perl automatically converts ints to floats on division
<Mithrandir> pitti: yeah, while C forces me to cast, or it gives me overflows.
<Mithrandir> 100*$around_650_mb / 700mb doesn't work as you expect. :-P
<StevenK> >>> 5.0/7.0
<StevenK> 0.7142857142857143
<Mithrandir> StevenK: stat(2) doesn't return float values.
<pitti> StevenK: 5 != 5.0 :)
<Mithrandir> (for size, etc)
<StevenK> Then float() them
<pitti> no, just divide by 70000000.
<pitti> i. e. append a '.'
<Mithrandir> well, this is C.  I don't think we want python in the initramfs.
* Fade chuckles
<StevenK> Mithrandir: It's already Essential: yes, why not? :-P
<Mithrandir> StevenK: put the crack pipe down.  now.  slowly.
<Fade> 'cause a statically linked python is enormous? :)
<StevenK> Mithrandir: Hrmm. I can't seem to get my fingers to uncurl.
* ajmitch is surprised that upstart wasn't written in python, tbh
<minghua> Mithrandir: so did you use long int or float in the end? :-)
<thom> doko_: any chance you're gonna sync buildbot from debian? (and get 0.7.4 preferably)
<Mithrandir> minghua: long double.
<ajmitch> thom: bug 62358
<ajmitch> hm
<ajmitch> bug 61358
<Ubugtu> Malone bug 61358 in buildbot "please sync buildbot 0.7.4-1 from Debian unstable (main)" [Wishlist,Confirmed]  http://launchpad.net/bugs/61358
<Fade> Mithrandir: did you ever have a chance to look at my xemacs bug?
<ogra> rodarvus, any news on the via issue ? according to mdz's mail beta freeze is tomorrow ...
<Mithrandir> Fade: I fixed it in emacs as least.. can you try building xemacs with -fno-stack-protector added to cflags?
<rodarvus> ogra, I have the package ready since two days, was just waiting for your nod to upload it
<Fade> Mithrandir: okay
<rodarvus> (ie, did it work on *all* machines at the LTSP hackfest?)
<ogra> rodarvus, well, it makes all thin clients here work, but i actually have no other via based HW 
<rodarvus> no regressions caused by the test package I sent you?
<rodarvus> oh
<ogra> nope
<doko_> thom: yes, have to fix the login shell first
<rodarvus> ok, I'll upload it *now*
<ogra> the fact that xserver-xorg doesnt respect VideoRam preseeding is kinda odd though ...
<rodarvus> done
<ogra> one of the vias i have needs 16384 set ...
<thom> cool
<thom> oh well, i just backported it to dapper
<slomo_> rodarvus: and i read that a new radeon driver is on it's way that should fix some crashers with older radeons
<ogra> but i can work around that with a static xorg.conf though ... not elegant but i can write a howto if the bug i filed is not seen as RC
<slomo_> rodarvus: http://airlied.livejournal.com/32609.html   will we get this for edgy?
<rodarvus> ogra, video card detection, and generically speaking, xorg.conf creation *really* could use some love, but I guess that will have to wait for our full time X hacker (when we find one :) )
<Mithrandir> mjg59: is it on purpose that we don't display failures any more?
<ogra> (its always been a prob with that specific via board)
<rodarvus> slomo_, I've just seen this blog entry, was about to check what it is all about on git
<ogra> rodarvus, well, that specific bug just needs someoune with decent dbconf knowledge
<slomo_> rodarvus: perfect, thanks :)
<Mithrandir> mjg59: and would you like me to extend TEXT or have an TEXT-URGENT command?
<ogra> rodarvus, apparently xdebconfigurator fully supports it ... i wonder if we shouldnt sync that alongside with the debian packages ...
<rodarvus> ogra, the thing is we have quite a few failures and misdetections happening: xresprobe needs love, 'xorg' (package) needs love
<ogra> well, debian uses xdebconfigurator for all x detection ...
<ogra> they dont have such a thing like our postinst for xserver-xorg afaik
<Kamion> ogra: that's totally not true
<Kamion> our postinst comes from Debian and is still used there
<rodarvus> indeed, they don't use xdebconfigurator (at least not anymore)
<rodarvus> don't know in the past
<Kamion> never did as far as I know
<Kamion> not in the standard installer flow, anyway
<Kamion> as far as I know> i.e. in the last five years
<rodarvus> ogra, ubuntu changes to 'xorg' package are reasonably small
<ogra> ok
<rodarvus> and could be smaller if they were willing to collaborate with us instead of insisting in rolling their stuff all the time :D
<Kamion> debian-edu may do different things
<ogra> Kamion, yes, that might be it ... since petter and vagrantc told me it is like that 
<ogra> and they both are rather -edu guys
<azeem> xdebconfigurator was written by a skolelinux/debian-edu guy I think
<mjg59> Mithrandir: Just run indent over it
<mjg59> Mithrandir: And I'm easy over whether TEXT is extended or whether there's a specific command
<Kamion>  Package: xdebconfigurator
<Kamion>  Maintainer: Debian Edu Developers <debian-edu@lists.debian.org>
<Kamion> yeesh, it still provides a base-config menu item
<Kamion> I wonder when they'll discover 2006 :)
<ogra> heh
<Mithrandir> mjg59: it's trivial to add new commands, so I think I'll just have it be TEXT-URGENT.
<ogra> but it works :) at lest for stuff like VideoRam :)
<Mithrandir> mjg59: and I'll do the indent, yes.  Do you have a preference to what coding style it should use?
<ogra> we're missing so many options in our postinst ...
<Mithrandir> ogra: you're aware that specifying options in xorg.conf should generally be avoided?  Let the X server probe as much as possible.
<ogra> Mithrandir, right ... but if i have certain combos that only work with options like "VideoRam 16384" at least the preseedability should be there 
<ogra> like we added one for DefaultDepth
<Mithrandir> ogra: and that's impossible to detect?
<shining> couldn't it be just commented ?
<ogra> well, we could probably hardcode it somewhere ... "if certain chipset in certain HW combination then ..."
<ogra> shining, that wont help ltsp 
<ogra> nor the liveCD on such HW ... 
<ogra> most ltsp clients have these miniITX epia boards and some of them need such options ...
<mjg59> Mithrandir: I tend to use kernel style
<ogra> its a corner case in the software that affcts many users 
<Mithrandir> mjg59: ack, willdo
<ogra> rodarvus, thanks for the upload !
<rodarvus> ogra, thank YOU for the report!
<ogra> there goes a funny story with redhat alongside i'll tell if i have more time to chit chat ;) (we had warren from redhat/fedora at the hackfest)
<ogra> (who has the same prob but didnt get it fixed, but it wroked when he copied our binary from te modules dir into his)
<Kamion> "certain chipset in certain hardware combination"> that's what a lot of X hardware detection is like already. :)
<ogra> Kamion, right ... but i'll not be able to look deeper into it before beta ... so the question is if the bug is RC or not 
<ogra> is the "Go" button in ff for anyone else ridiculous big ? 
<ogra> makes my url field quite small here 
<_ion> I hate the button. I hope there's a way to hide it. (I skimmed through the preferences window, but didn't look at about:config yet.)
<Kamion> ogra: yes
<ogra> pitti, why is cryptosetup not in main ? (i know youre an extensive user of it)
<ogra> *cryptsetup
<ogra> Kamion, yes == its an RC bug ? 
<slomo_> ogra, pitti: it needs some upstart love for the password in the init script... but apart from that i want to see it in main too ;)
<pitti> ogra: I just never got to it
* ogra had a patch for encrypting nbd swap on ltsp he left out for edgy ... but would like to see in in edgy+1
<ogra> ok, then there is no technical reason, thats cool :)
<johnl> hi.  the latest ekiga package in edgy hasn't been built since it was uploaded (14 days ago) due to a dependency problem: https://launchpad.net/distros/ubuntu/edgy/+source/ekiga/+builds
<johnl> is this something I should report? and who to?
<dholbach> in fact that's a ftbfs because pwlib failed to build: http://librarian.launchpad.net/4293008/buildlog_ubuntu-edgy-i386.pwlib_1.10.2.dfsg-0ubuntu1_FAILEDTOBUILD.txt.gz
<dholbach> dpkg-deb: building package `libpt-plugins-alsa-dbgsym' in `../libpt-plugins-alsa-dbgsym_1.10.2.dfsg-0ubuntu1_i386.ddeb'.
<dholbach> objcopy: debian/libpt-1.10.0/usr/lib/debug//usr/lib/libpt.so.1.10.2: Invalid operation
<dholbach> dh_strip.pkg-create-dbgsym: command returned error code 256
<slomo_> pitti: ^----
<dholbach> pitti: ^ do you know what happened there?
<seb128> dholbach: iz pkg-create-dbgsym bog
<pitti> dholbach: will take a look at it after lunch
<dholbach> rock and roll
* dholbach is out for a dogwalk now
<pitti> dholbach: most probably yet another corner case pkg-create-dbgsym doesn't handle
<dholbach> seeya
* dholbach hugs pitti
<Kamion> ogra: yes == the go button in firefox is ridiculously big for me too
<Kagou> hey iwj, doing now a fresh daily install to (i hope) close the fontconfig-config bug ;) (yesterday iso didn't include the last version of fontconfig-config)
<tkamppeter> Thanks for the help regarding the old bug reports.
<tkamppeter> pitti, doko_, now I have another problem:
<elmo> who are our resident freenode staffers?
<tseng> seveas has connections if he isnt a staff himself
<tkamppeter> I want to update foomatic-db to today's state. For that I have downloaded the most recent unstable source of Debian (foomatic-db-20060822) to update it to today's snapshot with ""uupdate".
<elmo> he claims not to be staff, I forget who is, one of the  #ubuntu ops, IIRC
<tkamppeter> The uupdate works fine, I get a new directory with the ready to build source tree for 20060819.
<Kamion> nalioth IIRC
<Kamion> elmo: ^--
<Kamion> 13:11 [Freenode]  -!- nalioth [i=nalioth@freenode/staff/ubuntu.member.nalioth] 
<elmo> Kamion: ah, yeah, good call, thanks
<Kamion> there may be others
<Hobbsee> elmo: nalioth, rob, 
<tkamppeter> But if I build I get an error which lloks like that building on Debian and on Ubuntu are not compatible.
<Hobbsee> elmo: sometimes hedgemage
<elmo> Hobbsee: "sometimes"? :)
<Hobbsee> elmo: they're the current ones
<Hobbsee> elmo: as in, she's sometimes around the #ubuntu channels - she's not around all the time like the other two are
<elmo> ah
<tkamppeter> So I tried also to rebuild 20060822 in the old directory and got the same error there. See the log of the build process in
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/foomatic-db-20060822-rebuild.log
<Kamion> Hobbsee: rob?
<tkamppeter> and the source package used for that build in
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/
<Kamion> tkamppeter:           install -d //usr/share/cups/model; \
<Kamion> looks like DESTDIR isn't set?
<Kamion> or that the Makefile isn't honouring it
<Kamion> (DESTDIR's the conventional name, anyway)
<Hobbsee> Kamion: yes.  doesnt look to be around at the moment though - he usually is.
<Hobbsee> elmo: if you're looking for the various op type people, check #ubuntu-ops
<tkamppeter> And how did they get it building under Debian then?
<Hobbsee> the ubuntu + staffer people hang out there
<Kamion> we're not incompatible at that level. Let me look at the source
<Kamion> wah, foomatic-db upstream ship their own debian/rules? how confusing
<tkamppeter> I have once given write access to the repository to Chris Lawrence and he has maintained Debian directories in the foomatic subpackages for some time.
<tkamppeter> I never touched these Debian directories.
<Kamion> I see - I guess it's up to Chris then
<tkamppeter> And I doubt that the write access for Chris is still active, perhaps I better delete all debian directories from the upstream repositories.
<Kamion> best talk to Chris first
<elmo> Hobbsee: thanks
<tkamppeter> For the Mandriva RPM I install with
<tkamppeter> make PREFIX=%{_prefix} DESTDIR=%buildroot install
<Hobbsee> elmo: not a problem
<Kamion> tkamppeter: I have no idea why/how it worked on Debian, but debian/rules is wrong (or arguably the Makefile)
<doko_> tkamppeter: did you look for patches in the diff.gz? I never used uupdate
<Kamion> this isn't an incompatibility, it's just weird shit
<Kamion> tkamppeter: setting PREFIX does nothing. it's set but never references
<Kamion> referenced
<tkamppeter> Where %{_prefix} is /usr and %buildroot is the temporary directory for the directory tree which should be installed into the system when one installs the binary RPM. So DESTDIR in the upstream package should work/
<doko_> I think, changes in the diff.gz are not applied automatically, so you have to do that by hand
<Kamion> doko_: uupdate applies the Debian diff
<Kamion> that's kind of the point
<desrt> yay.  -8.
<Kamion> tkamppeter: debian/rules should be changed as follows, I think:
<desrt> happy -8, everyone.
<Kamion> -        $(MAKE) install prefix=$(CURDIR)/debian/foomatic-db/usr
<Kamion> +        $(MAKE) install DESTDIR=$(CURDIR)/debian/foomatic-db
<tkamppeter> So then the " PREFIX=%{_prefix}" is some cut'n'paste noise.
<pina> hi
<pina> doesnt ubuntu work with kerberos/ldap out of the box?
<Kamion> tkamppeter: oh, it probably worked for Chris because he already had the package installed, so /usr/share/cups/model was already there
<tkamppeter> Kamion, yes, this is how it is intended by my upstream Makefile.
<Kamion> although how 'ln -sf $(LIBDIR)/db/source/PPD $(DESTDIR)$(CUPS_PPDS)/foomatic-db-ppds' worked I'm not sure
<Kamion> maybe he built it as root :-/
<pina> anyone
<tkamppeter> But then Chris must either have /usr/share/cups/model world-writable or he must have run dpkg-build as root.
<Kamion> tkamppeter: note that the db/source/PPD symlink is missing from the Debian binary package
<tkamppeter> Both are not good ideas, you can mess up your system or you can take a mess of your system into the package.
<Kamion> so I reckon he built it as root and never noticed
<Kamion> indeed, you aren't meant to build Debian packages as root
<Kamion> oh, hmm, there's stuff in debian/rules that futzes around with db/source/PPD
<tkamppeter> Yes, I usually do not build packages as root, neither Debian nor RPM. All have to install into a temporary directory.
<Kamion> who knows ...
<pina> anyone just clue me in on the ldap issue
<tkamppeter> Did the Ubuntu maintainer of foomatic-db really rebuild it before uploading it into Ubuntu? Or did he simply copy Debian's binary packages?
<tkamppeter> Therefore perhaps foomatic-db is such outdated.
<Kamion> tkamppeter: we never under any circumstances copy binary packages. We often copy source packages.
<doko_> tkamppeter: we ususally just sync from unstable.
<Kamion> tkamppeter: the last version of foomatic-db was a direct copy of the Debian source package (a sync), not actually uploaded by an Ubuntu maintainer as such.
<doko_> tkamppeter: there's no "Ubuntu maintainer".
<Kagou> iwj: sorry to say that today iso don't contain last fontconfig package. Kamion is it normal that today iso do not contain a 2/3 days old package ?!
<Kamion> Kagou: desktop or alternate?
<Kamion> we build many CD images on a daily basis, and you must be specific
<Kamion> infinity: please re-enable the livefs cron jobs
<Kamion> Kagou: ^-- if you mean the desktop CD, then the above is the problem.
<Kagou> Kamion: desktop
<Kagou> Kamion: if i take alternate cd, it will contain more uptodate packages ?
<Kamion> Kagou: yes, today
<Kamion> the desktop CD will be fixed at some point after infinity is next awake to see my request above
<Kagou> ok Kamion . Thanks so i will do an alternate install to close a bug. :)
<tkamppeter> Kamion, and from where is the binary package?
<_ion> Yay. "lists are sorted into block order on each boot, rather than when generated", "readahead is run in the foreground"
<tkamppeter> According to the information which you see in the lower left of the bug 59829 web page, doko_ must have built our stone-old binary package.
<Ubugtu> Malone bug 59829 in foomatic-db "No driver for Samsung ML-1610 printer" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/59829
<Kamion> tkamppeter: we rebuild the binary package on our buildds
<pitti> dholbach: ah, pwlib's debian/rules has a wrong logic for dh_strip, shall I just fix that/
<pitti> ?
<Kamion> tkamppeter: that information is about the source package, NOT the binary package; furthermore in this case it merely means that doko requested the sync of the source package from Debian
<Kamion> note that the heading of the box you're looking at is ""foomatic-db" source package in ubuntu:"
<pitti> slomo_, dholbach: Fixed pwlib uploaded
<pitti> slomo_, dholbach: debian/rules just erroneously used 'ifndef' when it wanted 'ifdef' :)
<pitti> Hi Yagisan 
<slomo_> pitti: thanks :)
<Yagisan> G'day pitti 
* dholbach hugs pitti
<_ion> Hmm. Why is there a readahead package in both main and universe?
<zul> hi pitti 
<dholbach> pitti: thanks - I'll talk to kilian about that
<_ion> A source package that is.
<pitti> _ion: apparently the old readahead source was superseded by the readahead-list source
<_ion> Whoops, i misread apt-cache's output.
<tepsipakki> doko: could you backport the fix for debian bug #368583 to dapper-updates? It would also fix malone #48244
<Ubugtu> Debian bug 368583 in eclipse "eclipse: Does not work with sun-java5-bin package" [Grave,Open]  http://bugs.debian.org/368583
<Ubugtu> Malone bug 48244 in eclipse "eclipse does not locate java-1.5.0-sun" [Low,Confirmed]  http://launchpad.net/bugs/48244
<piratepenguin> anyone here know how the OpenCD bit on the ubuntu cd works/was developed? Where did Launch.exe come from?
<slomo_> infinity: please give-back tomboy on sparc
<doko_> Kamion, infinity: are there any plans to remove libdb4.3 from the CD's? remaining rdepends are iproute, libpam-modules, libsasl2, libwvstreams4.2-extra
<Kagou> iwj: it's ok for fontconfig-config :) so i close the bug Nice
<_ion> I quite like the fact that sulogin respawns until e.g. 'telinit 2' is executed.
<terlmann> will the 6.10 beta iso be out tomorrow or today?
<sbalneav> ogra: Hey!  Make it back safe?
<tseng> no
<dholbach> terlmann: it's the beta freeze, not the release of a cd
<tseng> https://wiki.ubuntu.com/EdgyReleaseSchedule
<ogra> sbalneav, 
<ogra> yes
<sbalneav> Excellent!
<ogra> but discovered that i missed out on a freeze date ... 
<terlmann> the beta release said thursday!
<tseng> terlmann: no, it doesnt
<dholbach> terlmann: where does it says something like that?
<ogra> s no sleep for me until tomorrow
<ogra> *so
<tseng> terlmann: read the link i just gave
<sbalneav> lol!  Anything I can help with?
<tseng> this is the official schedule
<terlmann> will it be up on the servers tonite?
<tseng> goodness
<tseng> no.
<piratepenguin> beta release next week
<terlmann> not
<dholbach> terlmann: freeze date != release data
<tseng> the release will be prepared on or around Sept 28
<tseng> and will be announced on all the usual channels
<ogra> sbalneav, i need the final stuff for ldm
<terlmann> the wiki says tommarow and the freeze is today.
<tseng> terlmann: please show us where you are seeing that
<tseng> because it isnt true
<terlmann> rats.
<terlmann>  14     September 21st 
<tseng> 15    Septermber 28th
<tseng> this is not "the next day"
<terlmann>  *15*     September !28th! i thought wrong... 
<tseng> by any means
<sbalneav> ogra: Has matt approved the ltspfs changes?
<tseng> when it is release you will know :)
<tkamppeter> pitti, doko_, mdz: The new foomatic-db (20060918) is now uploaded to my web space:
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/
<ogra> sbalneav, see pm
<tkamppeter> And the binary packages to
<tkamppeter> http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/binary/
<tkamppeter> Note that they have a Ubuntu release number now, as I had to to fixes on the packaging.
<terlmann> someone inform me at terlmann@yahoo.com the "Moment" I can get a beta alt. iso cd image......  and is their any proposals floating around about ubuntu on a dvd?
<dholbach> terlmann: please subscribe to ubuntu-devel-announce@lists.ubuntu.com
<dholbach> terlmann: and Ubuntu on DVD exist since the beginning of Ubuntu :)
<terlmann> where?
<dholbach> the place you get the CDs too
<dholbach> http://cdimage.ubuntu.com/
<iwj> Kagou: Excellent, thanks.
<terlmann> where can i get a edgy knot 3 delta dvd iso?
<dholbach> And that's more of a #ubuntu question, sorry.
<terlmann> ok got it. that's more of? what purpose is chatting except to ask questions?
<dholbach> we should have something about "chatting" in the topic :)
<tseng> dholbach: you are unshakeable
<dholbach> tseng: how do you mean?
<tseng> dholbach: staying polite
<dholbach> ahh good - I thought you were going to say I should have been more patient :)
<Kagou> iwj: your welcome
<gnomefreak> add to topic something like instead of (not support, even with edgy) use something like "for all support related questions join #ubuntu" " this channel is for development support only"?
<gnomefreak> not like people read topics :(
<tseng> thats awfully long, and no one reads anyway
<gnomefreak> its already in the topic anyway
<Chipzz> gnomefreak: s/development support/development OF ubuntu/
<Chipzz> or else you'll have people asking for support about developping WITH ubuntu
<gnomefreak> true
<imbrandon> infinity: ping
<tkamppeter> pitti, doko_, mdz: New foomatic-filters on http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-filters/, UVF ER sent out -> biff.
<dandrader> hi all
<dandrader> I'm experiencing a weird bug in my package building (actually, inside SCons) which only happens on those ubuntu package building boxes
<slomo_> doko: why is the -l10n package of openoffice separate although both are building a complete openoffice anyway? what am i missing? ;)
<dandrader> Is there a way to reproduce the building environment used on them?
<dandrader> So that I can track down that bug on my own box
<tseng> dandrader: https://wiki.ubuntu.com/PbuilderHowto
<tseng> dandrader: check that out
<jdong|laptop> infinity or Kamion, ping
<dandrader> tseng:  hmm... but it works fine on a regular pbuilder
<slomo_> dandrader: talk to infinity about it... iirc he knows about some weird failures with scons ;)
<tseng> dandrader: oh I see
<tseng> dandrader: then you probably need to talk to a real live build-admin
<slomo_> dandrader: it's not the first time that scons fails on the buildds but nowhere else... afaik it never worked
<dandrader> oh... so that's a kind of "known bug"
<tseng> sortof but you should pursue it
<dandrader> tseng:  yeah, I would like to
<dandrader> infinity:  ping
<Hobbsee> dandrader: infinity is likely asleep
<tseng> Hobbsee: as you should be
<Hobbsee> tseng: yeah well...
<Hobbsee> i'm being lazy, and on holidays
<`ph8> Mithrandir: ping :)
<`ph8> Mithrandir: happen to know if the kernel made it in today? i'll be home in a couple of hours
<crimsun> jdong|laptop: in the future, please don't randomly approve backport requests without first poking the person listed most recently in Changed-By
<jdong|laptop> crimsun: duly noted, sorry....
<mako> mvo: glad you appreciated it :)
<seaLne> mvo: is the new python-defaults related to these errors: http://rafb.net/paste/results/BLDqIf81.html ?
<mvo> seaLne: yes
<seaLne> cool, just discovered it on trying to upgrade a machine that hadn't been updated fro a few weeks
<mvo> seaLne: the update should fix that 
<seaLne> thanks
<mvo> seaLne: let me know if the issue is fixed for you once the new python-defaults is available
<seaLne> yep, not in the archive yet
* mvo is away for ~1,5h
<Hobbsee> doko: ping?
<Hobbsee> hey sabdfl 
<Hobbsee> doko: https://launchpad.net/distros/ubuntu/+bug/61453 <-- i suspect that wasnt quite what you intended to do
<Ubugtu> Malone bug 61453 in Ubuntu "sync request" [Untriaged,Unconfirmed]  
* Hobbsee goes back to ignoring -bugs
<slomo_> BenC: /usr/include/asm-i386/io.h seems to be broken... http://librarian.launchpad.net/4354262/buildlog_ubuntu-edgy-i386.irda-utils_0.9.16-11ubuntu3_FAILEDTOBUILD.txt.gz
<BenC> slomo_: it's probably another case of "don't use l-k-h/libc-linux-dev to get to kernel internals", but I'll check
<slomo_> BenC: thanks :)
<BenC> slomo_: that header doesn't seem broken, but I suspect that smc.c really wants to include sys/io.h instead of asm/io.h anyway
<BenC> err, does seem broken
<BenC> slomo_: can you file a bug?
<slomo_> BenC: i have no idea, i only uploaded a fix for the init script ;) i'll test it with sys/io.h later
<slomo_> about the broken header? sure...
<BenC> thanks
<iwj> Yay, printf-debugging with a program that takes 30m to build.
<bluefoxicy> damnit, why is killall -9 not killing gksu
<slomo_> BenC: bug #61455
<iwj> gksu is set-id so you have to sudo killall
<tkamppeter> pitti, doko_, mdz: New foomatic-db-hpijs corresponding to HPLIP 1.6.7 on http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db-hpijs/, Added to HPLIP UVF ER -> biff.
<Ubugtu> Malone bug 61455 in linux-source-2.6.17 "asm-i386/io.h includes non-existing header file" [High,Unconfirmed]  http://launchpad.net/bugs/61455
<Fade> Mithrandir: the stack trace from the segfault is a lot shorter now.
<doko_> tkamppeter: did you update the hplip package as well?
<bluefoxicy> pitti:  apport was gathering data on stratagus and I didn't care so I killlall'd apport
<pitti> tkamppeter, doko_: I'm currently on modem (broken main network connection), sorry; doko_, can you handle this?
<bluefoxicy> pitti:  my kernel oops'd
<pitti> bluefoxicy: can you please file a kernel bug and discuss that with BenC?
<tkamppeter> doko_, yes, last week, get it from http://www.freestandards.org/~till/tmp/ubuntu/edgy/hplip/
<bluefoxicy> the constant dialog to the face is more annoying than helpful :|
<BenC> pitti: we need to talk about that bug
<BenC> bluefoxicy: one is already filed, so if you want, just sub to it
<pitti> BenC: which one?
<BenC> pitti: killing apport causing an oops
<bluefoxicy> BenC:  I don't really care as long as you got it already.  Is there an OOPS paste from dmesg or should I throw one up?
<pitti> BenC: yeah, I meant the bug number
<BenC> there's one
<BenC> bluefoxicy: it crashes in filp_close, right?
<Kamion> doko_: we probably should, although db versions have historically been hard work to migrate. Do you know if the on-disk formats are compatible?
<tkamppeter> doko_, mdz has approved following UVF ERs: HPLIP 1.6.7, Gutenprint 5.0.0 final, foomatic-db 20060918
<Kamion> jdong|laptop: yes?
<bluefoxicy> [17302895.720000]  EIP is at mutex_unlock+0x1/0x10
<jdong|laptop> Kamion: can you do a flashplugin ~ubuntu2 backport real fast?
<jdong|laptop> Kamion: to fix breakage, my fault, really sorry
<Kamion> sure - what's the rush?
<Kamion> ok
<Kamion> is there a bug to close when I do?
<BenC> pitti: #60183
<doko_> Kamion: only asked infinity. he says yes. although we may need to look at the packages which use transactions
<jdong|laptop> Kamion: yeah, let me get it for you
<jdong|laptop> Kamion: bug 61404
<Kamion> jdong|laptop: it's ok, I'll find it
<Ubugtu> Malone bug 61404 in dapper-backports "Flashplugin-nonfree in backports fails to install" [High,Confirmed]  http://launchpad.net/bugs/61404
<tkamppeter> ubugtu has a bug, see his answer to my announcement of foomatic-db-hpijs
<Kamion> ok, thanks
<BenC> hmm, not that one
<doko_> tkamppeter: ok, I'll fetch the packages and upload. which packages are missing UVF exceptions?
<Kamion> tkamppeter: that wasn't a reply to you, it was a delayed reply to slomo a couple of lines above
<jdong|laptop> Kamion, crimsun, I'm really sorry about this one.... I mislabeled my edgy chroot as a dapper one, so that did little good in terms of testing... :(
<BenC> pitti: I can't find the actual one right this second, but the basic problem is that it crashes when you kill apport... fixed the bug where it sometimes would crash while it was running (caused by some issues in vfs_unlink())
<Kamion> jdong|laptop: ~ubuntu2 isn't in the archive; nothing to backport
<Kamion> unless it's publishing right now or something
<tkamppeter> Still waiting for approval is foomatic-filters, foo2zjs, foomatic-db-hpijs
<jdong|laptop> Kamion: well it was very recently uploaded
<BenC> pitti: The bug is concerning me a little because it's obviously a security issue at this point, anyone can crash the machine
<slomo_> Kamion: which reply for me?
<pitti> BenC: right
<Kamion> jdong|laptop: right, I'll need to wait until it's published
<pitti> BenC: is it just an oops, or does it have any negative system impact?
<jdong|laptop> Kamion: ok, then, thanks so much for you quick response
<Kamion> slomo_: 16:22 < slomo_> BenC: bug #61455
<Ubugtu> Malone bug 61455 in linux-source-2.6.17 "asm-i386/io.h includes non-existing header file" [High,Unconfirmed]  http://launchpad.net/bugs/61455
<pitti> BenC: anyway, from your question I infer that it's nontrivial to fix?
<tkamppeter> But I have already asked for approval for foomatic-db-hpijs together with HPLIP, I think you can consider this one as also approved.
<Kamion> of course this triggers Ubugtu again so we go round in circles ;)
<BenC> pitti: just an oops in the kernel thread that called apport
<BenC> pitti: it's non-trivial, and the only thing I can think of is making the fork that exec's apport non-killable
<slomo_> Kamion: ah ok... as it's your archive day tomorrow... is bug #56073 ok as a sync request or shall i file a separate bug for this?
<Ubugtu> Malone bug 56073 in xfsprogs "Include XFS corruption fix from 2.6.17.7" [Medium,Confirmed]  http://launchpad.net/bugs/56073
<BenC> slomo, Kamion: thanks
<Kamion> slomo_: actually my archive day is Friday
<bluefoxicy> pitti:  may have negative system impact
<Kamion> slomo_: yes, that's fine
<bluefoxicy> oopsen do strange things, right now I can't kill -9 some hanging gksu processes.
<slomo_> BenC: builds fine with sys/io.h btw
<BenC> slomo_: good deal
<Kamion> I'll do main syncs a bit sooner than that though to avoid beta freeze
<bluefoxicy> stuff like this is probably related :/
<pitti> BenC: what does it actually expect from apport?
<tkamppeter> Should I switch all bugs fixed by my packages to "Fix committed" or only for the packages where the UVF ER was approved?
<pitti> BenC: i. e. it seems to expect that the apport process terminates normally rather than due to a signal?
<pitti> tkamppeter: the latter is better for now, since only approved packages can actually be uploaded now
<BenC> pitti: I'm not sure exactly what the problem is, the crash happens in filp_close(), which is odd because that's called on the core file before we invoke apport
<Kamion> you know, I'd be a lot more pleased with firefox's "Restore Session" thing after a crash if it ACTUALLY WORKED
<BenC> the only thing happening after apport returns is the unlink of the core in cases where it isn't supposed to be left around
<Kamion> beta2 is crashier than a very crashy thing
<BenC> pitti: I fixed the vfs_unlink() I had to do that, to use inode->i_op->unlink() instead, since that is more appropriate, so maybe it fixes this problem too
<BenC> pitti: I'm trying to see if I can reproduce the problem, and test the fix today
<pitti> BenC: cool, thanks
<BenC> pitti: but just wanted you to know we have a serious blocker for apport at the moment
<BenC> last thing I want is a major security whole that is specific to ubuntu and code that I wrote :)
<BenC> s/whole/hole/
* BenC needs caffeine or sleep, or maybe both
<BenC> I'll try caffeine and cigarettes to start
<pitti> BenC: multivitamine juice helps as well :)
<BenC> just doesn't have the same kick :)
<bluefoxicy> ugh something tells me I should rm preload
* bluefoxicy is tired of opening things like rhythmbox and having his hard drive crank for hours while his system lags :|
<_ion> ...or just move the job to a more suitable time.
<bluefoxicy> It would probably help if I had DMA and 32-bit IO again though.  Maybe that will be fixed by Edgy+1.
<bluefoxicy> _ion:  huh?  It's constant
<_ion> Oh. I though prelink was supposed to have an exactly reverse effect.
<bluefoxicy> no, preload o.o
<bluefoxicy> it watches processes starting and reads files it thinks they'll use
<_ion> Oops, i misread.
<bluefoxicy> by watching them run and making note of what files get read
<bluefoxicy> all I'm getting is massive disk access
<bluefoxicy> but it WOULD help if I ever got DMA back... somewhere in the middle of Edgy I lost that
* _ion is having a bit of a headache.
<seaLne> mvo: didn't fix it...
<pygi> pitti, it's out ;)
* pitti hugs pygi
* pygi counterhugs pitti ;)
<pygi> it even works, hehe 
<pygi> will brb in sec
<pygi> pitti: so it's out, the first release ^_^
<pygi> complete libisofs rewrite, a lot of major changes in libburn and cdrskin, sweet
<pygi> libburn is now actually usable, as opposed to 0.2.0 :)
<Kamion> aha, purging mozilla-plugin-gnash fixes the worst of my firefox crashes
<iwj> OK, this other crash seems to be an unrelated bug in yelp.
<lucas> hi
<lucas> ubuntu ships with SELINUX enabled in the default kernel, which prevents me from reading /proc/kcore to find some data I just lost by mistake
<lucas> any idea on how to allow me to "cat /proc/kcore" ?
<Lathiat> write a kernel module? ;)
<Lathiat> dont panic it ;)
<Lathiat> u sure selinux is doing that?
<Lathiat> it says disabled at boot
<Kamion> er, that's not selinux
<mjg59> lucas: We don't set any selinux policies
<Kamion> static int open_kcore(struct inode * inode, struct file * filp)
<Kamion> {
<Kamion>         return -EPERM;
<Kamion> }
<Kamion> in fs/proc/kcore.c
<ssh_> Question: Where can I found the installer translations for edgy desktop live CD, I would like to help to review the translation.
<lucas> erm
<Kamion> ssh_: https://launchpad.net/distros/ubuntu/edgy/+source/debian-installer/+translations but they probably aren't quite ready to go yet
<lucas> Kamion: is that an ubuntu specific change ?
<ssh_> Kamion: but debian-installer is text install messages  
<Kamion> lucas: http://www.redhat.com/archives/nahant-list/2006-February/msg00125.html
<Kamion> ssh_: take my word for it
<Kamion> ssh_: for the purposes of translation, they're merged
<lucas> great.
<ssh_> Kamion: hmm 
<mjg59> lucas: It's not Ubuntu-specific, but it is different to upstream
<Kamion> lucas: it's an Ubuntu patch, but not unique to us
<lucas> ok...
<lucas> and what about this one:
<lucas> # cat /proc/21805/mem 
<lucas> cat: /proc/21805/mem: No such process
<agutierr> hi all. I have a question. What is exactly ubiquity-casper? I dont find so much information about this.
<Lathiat> agutierr: "apt-cache show ubiquity-casper"
<Kamion> agutierr: it's a collection of hooks exported by casper to replicate stuff that it does on live CD boot after ubiquity does the install
<agutierr> Umm
<agutierr> I have another question :-)
<agutierr> This system replaces debian preseeds?
<Kamion> agutierr: no
<Kamion> it's orthogonal to preseeding
<agutierr> But, its a similar system ?
<Kamion> no
<Lathiat> "I've had similar situation before. Just coded a small app that eat up enough of ram to push the -- otherwise inactive -- konqueror to swap space, sync()'ed /dev/hda and rebooted.
<Kamion> it's totally unrelated
<agutierr> Ok
<Lathiat> lucas: 
<mjg59> lucas: Looks like you get that if you have no ability to ptrace the process
<lucas> why would it be like this ? I also get it for:
<lucas> # cat /proc/$$/mem
<lucas> cat: /proc/26648/mem: No such process
<bddebian> Heya folks
<kmr> with edgy about to be released, is their a place to bug a maintainer about incorporating an imporant patch. The patch has been accepted by the debian ackage, but messages send directly to the ubuntu maintainer have one unanswered: https://launchpad.net/distros/ubuntu/+source/imagemagick/+bug/44307
<Ubugtu> Malone bug 44307 in imagemagick "Assertion failure processing ICC profiles with perlmagick" [Unknown,Fix committed]  
<Kamion> what Ubuntu maintainer? I don't think we have anyone explicitly caring about imagemagick
<kmr> does ubuntu have bug-smashing parties to encourage fixes of open bugs and unapplied patches?
<Kamion> yeah
<Kamion> I'll get that patch merged
<kmr> Ryuichi Arafune is the maintainer listed on malone
<Kamion> that's just the Maintainer field inherited from Debian
<kmr> Kamion: that'll be great. it'll be one lesss package that I have to maintain in local repository -- thanks!
<ogra> thats sadly the debian maintainer
<kmr> Kamion: oh, that's right, ubuntu doesn't have the strong maintainer roles that debian has, is that correct?
<ogra> so he might not be happy being mailed directly 
<Kamion> kmr: correct
<Kamion> kmr: erm, I'm confused
<Kamion> kmr: the changelog in our current package has a 6:6.2.4.5-0.7 version, but it's not the same as the one you cite in that bug
<Kamion> kmr: is it possible that the Debian maintainer dropped your NMU?
<kmr> ogra: well, that's okay, I first filed a debian bug about 4 months before filing the ubuntu bug
<ogra> but he fixed it in debian 
<Kamion> actually, it's an upload from Daniel Kobras several months before your NMU
<ogra> and might not care about ubuntu
<kmr> ogra: yes, on Sep 10.
<kmr> I sent email to hive back in May
<Kamion> anyway, I've got to go and do yet more house-moving, but I'll see about figuring out what happened and merging the fix when I get back
<ogra> Kamion, i feel with you ...
* ogra came back to a roofless house from detroit
<kmr> Kamion: I never did a nmu. Looking at the debian changelog looks like it was fixed Sept 11 someone else doing an NMU 
<Kamion> kmr: oh, I *see*
<kmr> Kamion: the patch I submitted was several versions ago. imagemagick has had a number of security updates.
<Kamion> that makes sense then
<kmr> for myself, I've been backporting my patch to each security update and storing it in alocal repository. a bit of a pain
<kmr> Kamion: good luck with the moving. it's only a 3-line patch
<Kamion> yeah, just need to see whether we should take the other patches in that upload too
<kmr> removes the double freeing of strings as verify by upstream on the imagemagick-devel list
<Kamion> we're in feature freeze so I need to be reasonably careful
<kmr> Kamion: makes sense, appreciate your efforts
<Kamion> your patch looks entirely unproblematic
<micahcowan> mvo, you know python-central's broken, right?
<Kamion> thanks for letting us know
<kmr> Kamion: there's a careful test case Iposted on the debian bug list if you want to exercise the current bug yourself. but, I spent many hours tracking it down and verifying with upgrade
<kmr> Kamion: thans for listening!
<Kamion> I can probably follow through the XS well enough - it's been a few years, but :)
<kmr> er, verifying with upstream
<Kamion> right, I need to wait for a gparted build anyway, so time to move the tumble-dryer
<kmr> Kamion: looking through the XS you can find where the string is freed once down deep, and then twice in the enclosng function
<svu_tv> who would be the person to talk about edgy kernels?
<Nafallo> svu_tv: BenC 
<seb128> svu_tv: #ubuntu-kernel or BenC
<jdong> Kamion: nudge, maybe flashplayer is ready now?
<Zdra> Is there a way to have -dbg package for libnotify ? I heared there was work done to get debug symbols in stack traces in ubuntu in a new way but I don't know how...
<Zdra> s/heared/heard/
<svu_tv> seb128, thanks
<elmo> zul: ping?
<zul> elmo: pong
<zul> elmo: whats up
<elmo> zul: just wondering why our xen is targeted at 2.6.16 still?
<zul> elmo: because xen-unstable is still using 2.6.16 and i havent had the chance to port it yet
<elmo> zul: how are the debian guys producing 2.6.17 debs?
<zul> they have it in their kernel not as s a seperate package
<elmo> ok - but would their patch for the kernel not be usable for us?
<elmo> I'm just kind of keen to get rid of the version desync - supporting two kernel versions is going to be a nightmare
<zul> elmo: tell me about it, but thats the way we went because of the headaches at the beinging of the edgy cycle with alt-smp if i remmeber correctly
<elmo> hmm
<elmo> zul: is it too late to fix this?
<zul> elmo: i believe so, but you would have to talk to BenC 
<zul> i can get a 2.6.17 working this weekend though for xen
<elmo> zul: sorry, I don't mean merged into our main kernel
<elmo> zul: I just mean the xen kernel source being brought up to 2.6.17
<elmo> but still being a separate + distinct copy
<zul> elmo: i can do it this weekend
<zul> and starting tonight of course
<elmo> I more meant in terms of freezes and stuff, sorry I wasn't trying to pressure you or anything
<elmo> but I guess since Xen is still in universe, that's less of/not an issue
<zul> no problem..
<zul> yeah the universe freeze is on the 28th i believe
<zul> still plenty of time
<zul> elmo: ill keep you updated ok?
<elmo> zul: super, thanks a lot
<zul> nop
* mvo switches networks
<BenC> elmo: I would be willing to guess that the debian guys are only applying the xen patch for the actual xen build of the kernel, not normal buids
<BenC> elmo: The reason I don't have it in ours is because non-xen builds with the xen patch applied are broken and non-booting
<elmo> BenC: yeah, sure, I appreciate that
<elmo> BenC: I wasn't pushing for us to build Xen from our mainline kernel sources
<BenC> just for 2.6.17?
<elmo> BenC: I just wanted the separate Xen-kernel-sources to be 2.6.17
<elmo> that way I only have to track security stuff in one kernel version
<BenC> it would actually be nice of the xen build build-dep'd on linux-source-2.6.17, cp'd it and applied the xen patch for the build
<BenC> s/cp/untar/
<elmo> BenC: yeah, I agree, that'd be wonderful
<zul> i could try :)
<BenC> zul: you're the man, you can do it :)
<zul> but i always updated it from the stable trees from kernel.org/git
<BenC> or at least I think you're just crazy enough to get it working
<zul> done it before...will do it again
<zul> thanks though :)
<BenC> that would be xen would be added to the ever growing list of things that need to be rebuilt when the main kernel is uploaded
<BenC> xen would be an "always" rebuild, even for non-abi-bump uploads
<elmo> eventually, we should just rebuild thearchive when we upload the kernel
<elmo> \o/
<zul> elmo: but if im bald in the next couple of days im blaming you ;)
<zul> BenC: we still have the alt-smp stuff in edgy right?
<BenC> zul: yeah
<zul> greeeat...
<fabbione> the smp-alt has been dropped from .18
<elmo> zul: hahaha
<fabbione> because it gives issues on some compilers
<elmo> dropped upstream?
<fabbione> it was merged in .17 and reverted shortly before .18 release
<fabbione> some compilers don't like it
<fabbione> it might go back later on with more testing
<elmo> ah, ok
<fabbione> xen security wise is a pain to track
<fabbione> have been there before
<BenC> odd that smp-alt caused problems when the core functionality has always been there
<BenC> it's just a separate table for swapping stuff
<fabbione> anything that touches arch/i386 or include/* will need porting and propagation
<fabbione> BenC: according to what i read it's a compiler issue
<fabbione> not the patch in itself
<BenC> I guess I need to get this kernel uploaded tonight before the beta freeze
<BenC> someone remind me when the dev meeting is this week
<zul> 11am tomorrow
<BenC> zul: our time?
<zul> yep
<BenC> thanks
<fabbione> speaking of which.. i need to push to rookery
<fabbione> BenC: can you give me 2 minutes to commit and push?
<fabbione> stuff is already tested
<fabbione> i just forgot the most interesting bits for you
<BenC> sure thing
<fabbione> BenC: done.. you can pull from me (edgy branch)
<fabbione> commit e86c55006a692292bf93c44ea4373f57d44f92f4
<fabbione>     [UBUNTU:fs/gfs2]  Update for gfs2
<fabbione> and
<fabbione> commit ed1c788a9576a6a99db200fc1818e26540796382
<fabbione>     [UBUNTU: include/linux]  Export lm_interface.h
<fabbione> they are both upstream
<fabbione> our delta is down to 3 liners now :)
<Seveas> sabdfl, ping
<Seveas> Anyone around who knows where sabdfl physically is? He's supposed to chair a BOF at EuroOscon right now
<Seveas> mdz, Kamion ?
<Seveas> (I hate poking people, but there are a lot of people here wondering where Mark is)
<elmo> Seveas: AFAIK he's still in London
<Seveas> elmo, righhht...
<Seveas> and no one notified EuroOscon?
<elmo> I thought they had, but there's been lots of flip-flopping, and I haven't actually been involved, just overhearing stuff in the office
<elmo> I'm not sure tho - I'll txt him
<Seveas> thank you
<mdz> Seveas: afaik he was scheduled to go there tomorrow
<BenC> fabbione: done
<elmo> Seveas: what mdz said.  He's coming tomorrow, definitely won't be there tonight.  Sorry if communication wires got crossed
<Seveas> elmo, ok, thank you, I'll disappoint the people here 
<elmo> Seveas: guess so, thanks
<trappist> is there a bug to be filed if there's a gpl package in multiverse?
<crimsun> which package?
<trappist> xaralx
<Burgwork> trappist, depends on a non-free rendering engine
<trappist> ah.
<Burgwork> multiverse is a combo of non-free and contrib from debian
<trappist> I don't think I've run across that piece of info before
<trappist> thanks
<Burgwork> http://www.ubuntu.com/ubuntu/components
<Burgwork> file a bug against the website to add that information to that page
<trappist> can do
<Burgwork> thanks
<trappist> done.
<Burgwork> cheers
<Seveas> elmo/mdz: I chaired the BOF and it went pretty decent, people weren't too disappointed 
<mjg59> Ok, so doing iwconfig foo power on saves a ridiculous amount of power
<jdong> mjg59: does it? what kind of wireless?
<mjg59> jdong: ipw2100
<jdong> fascinating
<jdong> on my ip3945, the difference between on and off is only like 10-20 minutes of battery life, tops
<Burgwork> jdong, that would be half my battery life
<jdong> note to self: get Burgwork a new battery for christmas
<Burgwork> mjg59, how can I usefully debug why I only have 40 minutes of battery life and my laptop is brand new and gpm reports my battery is still charging to factory full
<Burgwork> jdong, no, the sad part is: I am charge to the factory max, at least according to gpm
<jdong> Burgwork: that means nothing if your acpi implementation is subpar 
<jdong> Burgwork: my 4 year old toshiba claims it charges to factory max
<Burgwork> right
<mjg59> Burgwork: With difficulty
<mjg59> What hardware?
<Burgwork> toshiba tecra a5
<jdong> hehe, toshiba, how'd I guess?
<jdong> have I ever mentioned my factory BIOS revision didn't even report batteries to ACPI?
<Burgwork> jdong, ouch
<Treenaks> jdong: sounds like my Acer
<Treenaks> which has a 'smart battery'
<jdong> Treenaks: ouch... smart battery :-/
<jdong> Treenaks: fortunately acer stopped doing that now :)
<Treenaks> jdong: it works now...
<mjg59> The Tecras are generally fine
<Burgwork> jdong, I have an open bug that apparently my latop does not report any useful information when about half my fn keys are hit
<mjg59> Burgwork: When on battery, what does /proc/acpi/battery/* look like?
<Burgwork> I will check when I get home
<mjg59> Burgwork: And yes, Toshiba changed the way their hotkeys work. We have no idea how to drive the new ones.
<Burgwork> I got the first of the new models
<jdong> mjg59: oh btw, do you have any idea why gpm is reporting bogus percentages to me?
<mjg59> jdong: No
<jdong> well that solves that problem :)
<Burgwork> mjg59, what I am looking for in /proc/acpi/battery/* ?
<mjg59> Burgwork: Battery rate, manufacturer values, that sort of thing
<tseng> jdong: gpm gets them from hal
<jdong> tseng: hal is reporting bogus
<tseng> jdong: hal mostly gets them from your hardware
<tseng> jdong: which is often bogus
<jdong> tseng: /proc/acpi is correct
<jdong> tseng: acpi -V is also correct
<jdong> just hal is wrong
<tseng> file a hal bug, then
<jdong> hal used to be right before the recent hal update
<jdong> I filed bug 60989 on this
<Ubugtu> Malone bug 60989 in hal "HAL reports incorrect battery percentages" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/60989
<tseng> there you go, see, you know more than anyone here.
<jdong> hal and acpi's discrepancies confuse me
<jdong>      Battery 1: discharging, 96%, 02:33:40 remaining
<jdong>   battery.charge_level.percentage = 100 (0x64) (int)
<jdong> same point in time, same laptop :)
<ph8`> Mithrandir: around? wondering if that kernel patch made it in to today's build.. because it's not working :s
<Treenaks> jdong: multiple laptops?
* jdong smacks Treenaks :)
<Treenaks> jdong: uhr, multiple batteries?
<mjg59> ph8`: Which kernel patch?
<Treenaks> jdong: I blame the wine :P
<jdong> Treenaks: nope, single battery :)
<Mithrandir> ph8`: no idea; you can check the list of packages used for each cd on cdimage.ubuntu.com
<zul> mjg59: jmicron
<mjg59> Oh, today's build of the CD
<wasabi__> Hmm. CUps isn't letting me login, even though I am in lpadmin
<mjg59> Sorry, that makes more sense
<wasabi__> pam error.
<mjg59> present rate:            8895 mW
<mjg59> Not bad
<ph8`> Mithrandir: HI, here? -> http://cdimage.ubuntu.com/daily/20060920/source/edgy-src-1.list
<ph8`> i can't find anything with kernel in the name
<shining> isn't it linux-image ?
<ph8`> good point, nothing with '-image' in it though either, apart from 3 unrelated pkgs
<Mithrandir> ph8`: why are you looking at the lists for the source images?
<Mithrandir> http://cdimage.ubuntu.com/daily/20060920/edgy-alternate-i386.list is more likely what you want
<ph8`> because that was the only list that might resemble what i'm after? ;)
<shining> there is linux-source
<ph8`> cheers
<ph8`> so..
<ph8`>  /pool/main/l/linux-source-2.6.17/linux-image-2.6.17-8-generic_2.6.17-8.22_i386.deb
<ph8`>  /pool/main/l/linux-source-2.6.17/linux-image-2.6.17-8-386_2.6.17-8.22_i386.deb
<ph8`> wondering how to find whether that's meant to contain the bugfix i'm after or not
<mjg59> -8 contains the code
<mjg59> -7 doesn't
<ph8`> so, if i'm using the alternate img..
<ph8`> that should also contain the jmicron 'fix'?
<ph8`> or will it for some bizarre reason only be on i386?
<mjg59> It should, yes
<ph8`> unfortunately the fix doesn't work then
<mjg59> You'll need to check the amd64 data to be sure
<ph8`> bugger.
<ph8`>  /pool/main/l/linux-source-2.6.17/linux-headers-2.6.17-8_2.6.17-8.22_amd64.deb
<ph8`> :(
<ph8`> oh that's mega-rubbish
<ph8`> i'll see about reopening the bug or something
<Keybuk> version recommends are still useless, aren't they?
<wasabi__> Looking at a package published in dapper-updates through launchpad. There anyway to find the changelog?
<micahcowan> wasabi, if you're looking at a source package, the changelog is available at the top of the left-hand column.
<micahcowan> Check https://launchpad.net/distros/ubuntu/edgy/+source/opie for example
<jdong> Keybuk: poke?
<jdong> Keybuk: when you get a chance, can you do the backport in bug 61404?
<Ubugtu> Malone bug 61404 in dapper-backports "Flashplugin-nonfree in backports fails to install" [High,Confirmed]  http://launchpad.net/bugs/61404
<jdong> Keybuk: the ~ubuntu2 edgy release should be there by now
<Keybuk> jdong: no, I disagree with that
<Keybuk> the ubuntu2 in edgy should be reverted
<Keybuk> bugs in dapper-backports should not be worked around in edgy
<jdong> Keybuk: ok, then should a manual upload be done instead?
<Keybuk> jdong: then that's not a backport, no?
<jdong> Keybuk: can we just fix this one this way for now, since it's already been done?
<jdong> Keybuk: before I break too many people's flash
<Keybuk> sure, but at this point it's probably worth discussing improvements to your "ok for backporting" procedure
<Keybuk> as that didn't pick this up
<jdong> Keybuk: yeah, my stupidity is to blame for this one :(
<Nafallo> Keybuk: want to sync erlang and ejabberd while you're at it? :-)
<Keybuk> Nafallo: there's no request for those
<Nafallo> 6116[79] 
<Nafallo> there are :-). the bugs above.
<Keybuk> ubuntu-archive has not been subscribed to those bugs
<Nafallo> aha, subscribed.
<Nafallo> I was told assign.
<Keybuk> yes, the policy says subscribed
<Keybuk> it explicitly says "do not assign"
<Nafallo> oh? I can't find that in the mail to ubuntu-devel-announce.
<Nafallo> I've subscribed them now though.
<Kamion> Keybuk: are you doing flashplugin-nonfree then?
<Kamion> as I was about to
<Kamion> Nafallo: http://wiki.ubuntu.com/DeveloperResource
<Kamion> s
<Kamion> sorry, dicky s key
<Nafallo> aha.
<Nafallo> didn't know that this time, will do next time :-)
<Kamion> which was the originally-announced sync policy post-soyuz
<Kamion> we've tweaked it a bit since, but ...
<Keybuk> Kamion: have done it
<Kamion> ok
<Nafallo> I was working after that, I only just found time to get back now :-).
<Nafallo> anyway. will you do them Keybuk? :-)
<Keybuk> Nafallo: no, not today
<Nafallo> okidoki.
<Keybuk> I doubt I will have sufficient round tuits
<Nafallo> hmm, is it just me or has the wiki become awfully slow lately?
<Keybuk> it has
<Fujitsu> Like, really really slow.
<Fujitsu> Any idea why?
<Keybuk> probably LP authentication related
<Keybuk> (random guess)
<Fujitsu> When in doubt, blame LP :P
<Keybuk> exactly
<Nafallo> hehe
<Fujitsu> Probably right, LP is the source of everything that goes wrong :P
#ubuntu-devel 2006-09-21
<ajmitch> can we attach files to bugs by email yet?
<Fujitsu> ajmitch, nope.
<Fujitsu> I was looking at that bug last night.
<ajmitch> irritating
<Fujitsu> Yeah.
<Fujitsu> There's no way to do merges properly without using the web interface D:
<Fujitsu> And wouldn't it be nice if LP exposed a sane machine-parsable interface so external applications could be written to access it, rather than having things like Conseil parse the HTML?
<ajmitch> it will
<Keybuk> "do merges" ?
<Fujitsu> Keybuk, file merge requests.
<Fujitsu> (with debdiffs)
<Fujitsu> (for non-devs)
<Keybuk> I still don't follow?  Why do you use LP for that?
<ajmitch> there are teams on launchpad for sponsoring uploads
<Fujitsu> Keybuk, the new merge workflow means non-MOTUs have to file bugs, attach debdiffs, and subscribe ubuntu-universe-sponsors to get a change done.
<Keybuk> ok
<Fujitsu> It's not a bad system, except that it can't be automated.
<mdz> Fujitsu: launchpad has an XML-RPC interface
<Fujitsu> mdz, I read on the Launchpad wiki that it didn't have it yet...
<Fujitsu> How long has it had it, and where is it documented?
<mdz> months
<Fujitsu> When I asked a couple of months ago they didn't have it.
<mdz> probably on help.launchpad.net somewhere
<Fujitsu> Yes, I'm checking now...
<Fujitsu> Thanks :)
<mdz> searching for 'rpc' on the front page finds it
<ajmitch> mdz: bug 61550, anything else you want on it?
<Ubugtu> Malone bug 61550 in f-spot "UVF exception request for f-spot 0.2.1" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61550
<mdz> it doesn't support attachments or subscriptions yet as far as I know
<mdz> ajmitch: it's a new feature release :-/
<ajmitch> mdz: yeah, that's why I wasn't sure of getting it 
<mdz> ajmitch: I'd appreciate a more detailed rationale; I commented on the bug
<ajmitch> ok
<ajmitch> thanks for looking
<Fujitsu> mdz, I wouldn't say that Launchpad had an XML-RPC interface... I'd say that Malone had a severely crippled attempt at an XML-RPC method for filing bugs.
<Fujitsu> But it's a start.
<elmo> Fujitsu: it has an XML-RPC interface that's a WIP
<Fujitsu> elmo, there is actually some work being done on it?
<elmo> no, we just added the functionality to taunt and tease people tantalus-style
<elmo> (or: yes, of course it is)
<elmo> s/it/there/
<Fujitsu> OK, good :_)
<Fujitsu> *:)
* Kamion scratches his head at ubiquity. It's only displaying rows in the mountpoints table after you go back to gparted and forward again ...
<fdsd> hey guys does edgy still use usplash?
<Fujitsu> fdsd, it's completely different, but yes.
<fdsd> Fujitsu, is there a guide on how to change the boot splash?
<Fujitsu> fdsd, yes, but I can't remember where it is.
<Fujitsu> On the wiki somewhere, I think.
<fdsd> Fujitsu, okay, I made my own project out of the stable livecds but the kernel used on the ppc version has issues with firewire so I would like to modify edgy (powerpc) live cd to do the same thing.. 
<Burgwork> fdsd, talk to Sevea
<Burgwork> seveas, rather
<fdsd> Burgwork, okay
<Fujitsu> Yes, Seveas is master of all things usplash-customisation.
<fdsd> Burgwork, lol sounds good
<gnomefreak> !usplash
<fdsd> Do you guys know if its possible to use the egdy knot 3 powerpc kernel and insert it into stable?, I modified the initrd files to include the /lib/modules dir, but it just stalls at boot
<fdsd> any idea?
<Spads> Also I love how people think ftp is "File TRansfer Program"
<Spads> mcm
<gnomefreak> https://help.ubuntu.com/community/USplashCustomizationHowto
<fdsd> into the livecd
<fdsd> gnomefreak, yeah I use that howto for stable, but how about for edgy knot 3?
<gnomefreak> i havent tried it yet im assuming the same
<fdsd> ok
<Kamion> totally different
<gnomefreak> the alternatives file and everything else needed hasnt changed names that im aware of
<fdsd> yeah I figured it looks completely different
<Kamion> pngtobogl -> pngtousplash
<fdsd> there is a new utility?
<Kamion> you need to write a short C file with theme structures in it
<gnomefreak> ah
<Kamion> it's basically just a renaming because usplash doesn't always use BOGL any more, and in principle the structures might not stay the same
<Kamion> don't use vga= any more
<fdsd> I see, so is there a howto?
<Kamion> not to my knowledge
<Kamion> I'd grab one of the existing usplash theme packages and poke around
<Kamion> usplash-theme-ubuntu should be reasonable
<fdsd> Kamion, does pngtousplash make the C file with the theme stuctures?
<Kamion> yes
<Kamion> er
<Kamion> no
<Kamion> :-)
<fdsd> lol
<Kamion> pngtousplash just converts a .png file to a C file representing that .png
<fdsd> pngtousplash usplash-artwork.png > usplash-artwork.c
<Kamion> but you need a C wrapper that includes to potentially multiple such files and provides structure descriptions of them
<Kamion> see usplash-theme-ubuntu.c
<Kamion> s/includes to/includes/
<jdub> Kamion: who is dealing with mozcorp re: firefox stuff atm?
<Kamion> actually s/includes/links/, you don't need to #include them
<Kamion> jdub: dunno, sorry
<fdsd> Kamion, where can I find that package
<Kamion> fdsd: apt-get source usplash-theme-ubuntu - it's in edgy
<fdsd> Kamion, I dont have ubuntu installed right now
<Kamion> well pick it out of archive.ubuntu.com in the usual way
<Kamion> you're on #ubuntu-devel so I expect you know :-)
<fdsd> Kamion, ok
<fdsd> Kamion, im a guest
<Kamion> s/know/know or can make educated guesses/
<fdsd> Kamion, well I have
<Kamion> also if you aren't running Ubuntu you will have difficulty building theme packages
<Kamion> you need to have libusplash-dev installed
<fdsd> Kamion, I will install it to modify it
* jdub roars laughing
<jdub> "I haven't been this excited since the introduction of devfs." - Mark Rosenstand on upstart-devel list
<mjg59> Promising. Erm.
<slomo_> infinity: ping?
<Nafallo> Kamion: you just synced erlang and ejabberd? :-)
<Nafallo> s/just// ;-)
<Nafallo> thanks in that case :-)
<Fujitsu> Nafallo, not really just... It was quite some time ago :P
<Nafallo> Fujitsu: you, noticed now :-)
<Kamion> Nafallo: no
<fdsd> Hey guys, Do you know what the pool directory is on the ubuntu livecd?
<Nafallo> hm, so thanks whoever did that :-)
<Kamion> fdsd: it's for various packages that we want to make available after installation but don't actually want to have preinstalled
<Fujitsu> Nafallo, about 50 minutes ago.
<fdsd> Kamion, oh cool
<Kamion> fdsd: chiefly for unusual network access methods and means to bootstrap yourself up for such (i.e. compiler and kernel headers)
<Kamion> though I think the latter are in desktop now
<Kamion> see http://people.ubuntu.com/~cjwatson/seeds/edgy/ship-live for the top-level list of things in there
<fdsd> Kamion, I am trying to take the kernel from the edgy powerpc knot3 live cd and put it in the 6.06 desktop powerpc livecd, I extracted the vmlinuz files put them in /casper/powerpc and /boot/  and transfered /lib/modules over and inserted them also into the initrd.gz file, do you know if I need to do anything else?
<Kamion> I thought there was a minor kernel/udev compatibility issue with using edgy's kernel on dapper
<Kamion> but others would know more than I on that
<fdsd> Kamion, it hangs on boot
<jdong> don't you kind of need kernel modules?
<Kamion> I imagine you screwed up one of the many steps required to get the above procedure exactly right
<jdong> oh, nvm
* jdong needs to learn to read
<Kamion> yes, you'll also need to update /lib/modules in the squashfs
<Kamion> but it's probably not that
<fdsd> Kamion, I did
<Kamion> my guess is you got the initrd.gz format wrong
<Kamion> check mkinitramfs for exactly how it creates it
<fdsd> Kamion, I modified the initrd.gz all the time for usplash
<Kamion> I don't know then, sorry
<Kamion> upgrading the kernel is not an easy task - it takes us a while to cope with the fallout each time, these days
<fdsd> ok
<fdsd> I thought it might have to do with the new init process
<jdub> tseng: ping
<Kamion> fdsd: no, not if you didn't suck in upstart
<Kamion> the new kernel doesn't require upstart
<jdub> slomo_: ping
<slomo_> jdong: pong
<jdub> heh
<slomo_> oh, wrong one
* jdong bumps jdub/jdong counter to 6
<jdub> slomo_: you planning to migrate all mono stuff to 2.0?
<slomo_> jdub: no that would be insane and useless... why?
<fdsd> Kamion, I guess I can just modify the knot 3 livecd, hopefully someone will post a howto on how to modify the usplash 
<jdub> slomo_: just noticed that banshee has cranked up
<slomo_> jdub: but f-spot and banshee upstream switched over... so we'll get 2.0 stuff slowly
<jdub> slomo_: for edgy?
<Kamion> not unless there's a damn good reason, at this point
<jdub> just worried we're going to have yucky duplicate action
<Burgwork> slomo_, that would be Kamion sharpening his knives ;)
<jdub> though thus far not on the desktop CD
<slomo_> jdub: f-spot no... but banshee already is and we also have some other 2.0 stuff in universe already
<Burgwork> Kamion, is there a reason why still have gthumb on the desktop cd?
<jdub> mmm, good point
<slomo_> jdub: if upstream switches we switch too... but everything else just makes no sense :)
<Kamion> Burgwork: the arguments did not appear conclusive to me
<Burgwork> Kamion, arguments over which to ship or over whether or not they are duplicative?
<micahcowan> the latter
<Kamion> Burgwork: arguments on whether f-spot provided everything that real gthumb users actually needed
<Burgwork> ah, taht
<Kamion> it is possible to duplicate much of something's functionality without providing a complete replacement
<Burgwork> yes
<jdub> Kamion: and the only reason this matters is because we've shipped gthumb previously?
<Kamion> jdub: yes
<jdub> considering that 'real gthumb users' will get it via upgrade, how much does that matter?
<Kamion> anyway, I'm not that interested in the discussion, we aren't desperately short of space right now and we found a number of very lucrative ways of saving space
<Kamion> take it up with a core developer who cares ;)
<jdub> what are the other space-saving changes?
<mjg59> Kamion: ubiquity seems to have rewritten my partition table even though I didn't change its contents?
<jdub> Kamion: (who ultimately makes that decision? isn't it roughly you?)
<tseng> jdub: hello
<mjg59> It's possible that it didn't - I failed to check properly beforehand
<jdub> yo tseng 
<Kamion> move the Ubuntu book to online content only, recode the video to make more sensible use of space, vim -> vim-tiny, console-* -> console-setup, ongoing work on recoding .pngs, on-the-fly PPD generation, getting rid of some other unused printing stuff, probably more stuff I forgot
<infinity> jdub: Whoever collects a rough concensus from a few people and then edits the seeds.
<Kamion> jdub: anyone in core-dev can edit the seeds; final decision in case of conflict would be the technical board, of which I am not a member
<tseng> jdub: whats up?
<jdub> i guess i'll talk to sebuild and dhbuild
<micahcowan> Burgwork, the thread discussing gthumb/f-spot is quite large, but you can see it at https://lists.ubuntu.com/archives/ubuntu-devel/2006-July/thread.html#19593 (the mono one)
<jdub> tseng: ended up pinging slomo
<tseng> jdub: oh
<tseng> jdub: thats always a good idea
<tseng> slomo is brilliant
<Burgwork> micahcowan, I remember that, but it never came to a conclusion
<tseng> I'm useless
<Kamion> almost all the above changes were more lucrative than gthumb, but they did not attract as much attention because people find it harder to think about more subtle but more worthwhile changes rather than "omg let's remove an application at a time"
<ajmitch> at the moment gthumb is still used as the default import action
<Kamion> mjg59: happy to look at a partman log, if you used manual partitioning
<mjg59> Kamion: Sure
<mjg59> I'll take a look myself first
<Kamion> mjg59: and it's also entirely possible that partman will do that anyway *shrug*
<Kamion> it's probably a bug, but where to start ...
<jdub> Kamion: i'm not raising it as a matter of gaining space
<micahcowan> Burgwork, I think the (non-explicit) conclusion was more or less that there were enough people who needed feature-sets in the one that weren't in the other, that they were both necessary (although I still don't see why that means they both have to be on the CD, along with mono). But I just don't care enough about it to be bothered.
<Kamion> jdub: I was explicitly raising it as a matter of gaining space, originally
<Kamion> and most people talk about it in those terms
<Kamion> "why are we wasting space on this when we could be using it on such-and-such"
<ajmitch> jdub: f-spot --view still sucks, and being feature stuff won't really see love for edgy
<jdub> ajmitch: yeah, i'm thinking the major use case people are concerned about is porn, and they don't want porn in their photo management application
<ajmitch> heh
<Keybuk> worryingly, that's probably true :p
<tseng> jdub: and then there are the people that refuse to accept they are part of the Matrix
* ajmitch blames those warty backgrounds...
<Fujitsu> ajmitch, haha.
<tseng> jdub: er.. that you can sort photos w/o directories
<Keybuk> though I find nautilus and eog fine for viewing porn
<Keybuk> I get to tile multiple pleasing pictures
<Keybuk> *ahem*
<tseng> jdub: we don't free a mind past a certain age
<jdub> Keybuk: and set them as backgrounds? :)
<Fujitsu> This is the second time this has come up in 48 hours :P
<Keybuk> jdub: heh, yes
<Keybuk> it's much funnier when poeple see screenshots then
<Burgwork> micahcowan, I saw a lot of edge use cases
<infinity> slomo_: pong
<micahcowan> Burgwork, yeah.
<jdub> Keybuk: "is this your sister's laptop?"
<Kamion> micahcowan: (f-spot wasn't the first thing that dragged mono in)
<Keybuk> mono is vaguely interesting
<slomo_> infinity: (please give-back tomboy on sparc) do you have any ETA for apache2-dev and apache-dev beeing installable at the same time again? :)
<Keybuk> for a while it seemed to be the poster child of GNOME's future
<jdub> wow, this thread was totally derailed by noise and uninteresting goals
<Keybuk> but the wind seems to be blowing towards Python at the moment
<infinity> slomo_: https://launchpad.net/+builds/+build/247087/  <-- Already done.
<Fujitsu> Keybuk, good.
<Kamion> infinity: oh, while you're here, livefs cron jobs?
<infinity> slomo_: As for apache, it'll get done after I do some "OMG, beta freeze" stuff for the day.
<infinity> Kamion: Done last night.
<micahcowan> Kamion, oh. Tomboy, right?  Didn't remember that it had started there and moved on to f-spot.
<tseng> Keybuk: people who equated mono with The One Future were faux-journalists misquoting miguel
<slomo_> infinity: oh... you're too fast for me :) thanks
<Kamion> infinity: ah, cool, thanks
<Kamion> micahcowan: right
<ajmitch> jdub: I have fix for f-spot --view crashing here to upload
<jdub> Keybuk: i added that "haven't been this excited since devfs" comment to my sig file ;)
* ajmitch hunts on disk
<Keybuk> Fujitsu: why good?  surely the more languages we have complete development environments for, the better?
<Keybuk> jdong: lol
<Keybuk> jdub: lol
<Keybuk> I mean
<jdong> hehe
<Keybuk> I spent all of yesterday evening getting "MOST IMPORTANT CHANGE IN 30 YEARS!!" jokes
<jdub> Keybuk: that was GOLD
<jdub> Keybuk: where's that? lugradio?
<Kamion> micahcowan: I parenthesised it because I don't think it's especially critical, and could be removed if we really wanted - although now that we've got a lot of PR saying that we're going to be shipping Mono by default in edgy, it's hard to go back
<Keybuk> yeah
<jdub> bonus
<Keybuk> I'm a guest on Monday's show
<jdub> should be a good episode
<jdub> cute boys, cute girls
* Keybuk hums the "Pia Waugh" song
<tseng> Kamion: I wouldnt cry, for the record
<Keybuk> it's interesting
<Keybuk> what would we put on instead of mono?
<tseng> Kamion: One cd is one of our most important features
<Keybuk> if you said "telepathy, farsight, galago and avahi"
<Keybuk> then I would wave mono goodbye today
<micahcowan> Kamion, yes, I heard that argument. I thought it was a little humorous, because at the time people started arguing about whether to include mono, the response to space issues was that we had a decent amount of space at that time. Now that we /are/ hitting space boundaries, and the question was asked regarding what to remove, the first thing that was said was that mono isn't attractive because now that we've got it in there, it's given us good PR 
<micahcowan> ^_^
<Keybuk> but f-spot is damned nice
<ajmitch> damn, added fix to wrong bzr branch
<slomo_> Keybuk: avahi is not interesting... only avahi-daemon is missing ;)
<Kamion> micahcowan: I don't think anyone actually researched the space issues before saying that ...
<Kamion> (unfortunately)
<Kamion> they just said "yeah sure loads of space let's go shopping"
<Keybuk> I'd still rather see OpenOffice go away, and get replaced by something that's not fucking awful
<Keybuk> but sadly that something doesn't exist
<micahcowan> Yes, I thought it was a weak argument in the first place. Like running into space issues wasn't already a given, whether or not we had actually done so yet :/
<Kamion> nobody observed that, if nothing else, we're *always* anxious for more space to shove localisation into
<Keybuk> do we really need 20MB of games on the CD?
<Kamion> and that there were known things that were going to arrive later in the cycle and clamour for space
<micahcowan> Well, but we'll never actually have /that/ sort of space (on the CD) will we?
<micahcowan> Keybuk, IMHO, including a decent amount of quality games is a good PR move.
<Kamion> the games are quite a good draw for new users, I've found
<micahcowan> (look at me! I'm using the same argument I was just deriding re: mono!)
<Keybuk> I agree, but then I also thing a good photo management app is a good draw for new users *and* at the same time a good PR move due to including mono
<Kamion> my parents sat for long enough playing the games that it became embedded in their heads that Ubuntu was worth a try, and they've been playing around more since :)
<ajmitch> approx what time is beta freeze? end of thurs?
<jdub> Keybuk: that should totally be fixed upstream... what a mess.
<Kamion> 20MB does seem a bit too much though
<Kamion> ajmitch: traditionally, start of distro team meeting
<Keybuk> I converted two users to Ubuntu with f-spot alone
<micahcowan> Keybuk, well, as Kamion already pointed out, mono wasn't brought in for f-spot (but for Tomboy).
<Keybuk> (well, f-spot and gphoto)
<jdong> Keybuk: YES we need 20MB of games on the livecd
<micahcowan> Keybuk, awesome.
<jdong> what the hell else am I supposed to do watching ubiquity? :)
<ajmitch> Kamion: thanks
<Keybuk> jdong: I always press Alt+F4 during the installer to look at what it's really doing
<Keybuk> ...this doesn't work so well with u6y :(
<Kamion> sucks to be Keybuk ;)
<jdub> Keybuk: ha ha ha
<jdong> Keybuk: that's about as entertaining as watching a gentoo install
<Kamion> maybe I should rebind alt-f4 to a "Hi Scott!" dialog
* micahcowan thinks sgt-puzzles should be among the games included on the CD.
<Kamion> micahcowan: yes!
<Kamion> micahcowan: (Simon's a friend of mine, lives a few streets away ...)
<Keybuk> there really is a random bunch of crap on the CD though
<Kamion> the games there are much higher quality than many of the GNOME games, IMHO
<micahcowan> Kamion, really? That's frikking awesome. Where do you live, anyway? (no, I'm not gonna stalk either you or sgt ;o)
<Kamion> although possibly not quite so much UI focus, though it's not dreadful
<Kamion> micahcowan: Cambridge, England
<micahcowan> Kamion, totally, totally agreed. I'm personally impressed by his proven-solvable mines implementation, and I really enjoy playing netgame).
<jdub> Kamion: hrm, perhaps we should do some introductions
<Keybuk> Kamion: I'm increasingly wondering whether the time is fast coming where we start shipping localised CDs
<Kamion> Keybuk: *shudder*
<Keybuk> testing nightmare though
<jdub> Keybuk: YAY NO SHIPIT!
<Kamion> right, to both
<Kamion> though shipit wants to be devolved eventually anyway
<infinity> I look forward to the day when CDs go the way of the floppy, and we can just throw DVDs at everyone.
<infinity> Of course, I also look forward to getting 10 times the bandwidth, so I can download DVD ISOs and test them...
<jdub> Kamion: that's what i mean; without shipit to worry about, things like that become slightly more viable
<ajmitch> infinity: of course the software grows to fill the DVD
<Keybuk> Vista is only shipped on DVD
<Keybuk> so it may not be seen as unreasonable if we start doing the same
<Keybuk> I think OS X is only on DVD too
<Kamion> jdub: the combinatorial testing thing is still a very valid argument though, IMHO
<infinity> Keybuk: Vista is only meant for new hardware, and is not distributed on the internet, so they have two wins over us there.
<Keybuk> infinity: I don't think it's unreasonable to say that Ubuntu is only meant for modern hardware
<Kamion> and I'm very concerned about giving the official Ubuntu stamp to localised CDs that we haven't QAed
<jdub> Kamion: did that layering stuff happen? (filesystems with only language stuff in them vs. filesystem with system files, then building CDs by switching language filesystems)?
<Keybuk> we can always have a CD-shipped bling-less derivative for lower hardware
<Kamion> jdub: -> infinity - it was nearly there last I checked
<jdub> infinity: ^?
<Kamion> jdub: though possibly not that specific thing, but the underlying technology
<infinity> It's rolling out today, though we've certainly not attacked using it for localisation.
<infinity> (Though we'll use it to ship a live dvd with all the langpacks...)
<alex-weej> anyone else noticed audio stops playing very often when installing packages, etc., with the new CPU scheduling stuff?
<jdub> might reduce the feeling of sickness about combinatorial test fuckage somewhat
<Burgwork> Kamion, the gnome-games maintainers have started a process to pull in better games
<micahcowan> Hey Kamion, ooc what OS does sgt run (primarily) on his computer?
<infinity> jdub: Still need to boot the final ISO for each one, and see if the langpack plays along okay.
<jdub> infinity: thus 'feeling of sickness'
<Keybuk> infinity: interestingly, using the "recommended spec" guide we established; edgy+1 can recommend a Dual Core 64-bit capable processor, 1GB RAM, High Performance 3D card, 160GB drive and a combo CD-RW/DVD drive
<alex-weej> why do you need a CD-RW?
<jdub> alex-weej: thanks for enhancing the absurdity
<Keybuk> alex-weej: the "recommended spec" guide is "what you can buy from Dell for $500 at the _start_ of the development process for that release"
<jdong> Keybuk: yikes! what on earth!
<Keybuk> (ie. a cheap PC that's already 6 months out of date)
<Kamion> anyone have any idea why a GtkTable might allegedly have the right number of rows/columns, but the children I've added dynamically (as opposed to being in glade) completely fail to display? this is the ubiquity mountpoints table ...
<jdong> Keybuk: since when was that necessary to run ubuntu?
<alex-weej> :P
<Keybuk> jdong: that is recommended since edgy+1
<ajmitch> jdong: recommended, not required
<Kamion> micahcowan: err, iirc Windows and Debian, although I think he flirted with OS X too for a bit
<Keybuk> err, that wollen is been recommendeding sonce to edgy+1
<jdong> Keybuk: what warrants that recommendation though?
<Keybuk> jdong: you appear to be misunderstanding
<Keybuk> when we talked about this a while back, we needed some kind of metric for deciding what kind of things were acceptable to require, and what kind of things weren't
<Keybuk> in particular, memory usage; but it also applies to building features around the availability of a 3D graphics card (mmm.. compiz)
<jdong> I see
<Keybuk> so we came up with the idea that a given release of Ubuntu should not require anything more than a $500 PC bought online from a major retailer 6 months previously to the release
<jdong> ok, and recommends is if you put as much shiny stuff onto ubuntu as you physically can...
<Kamion> while I see the point, I think we would need to check whether this is in fact at all in touch with our userbase
<jdub> i think this is an elaborate scheme for keybuk to get new $500 PCs bought from major retailers every six months
<Keybuk> right, this is just recommends, not requires
<jdong> Keybuk: what are you looking at for requires?
<Keybuk> jdong: we just make that up as we go along <g>
<Kamion> "... that a given release of Ubuntu should not require ..."
<Kamion> did you mean "should not recommend" then?
<Keybuk> I'm probably the only person who actually knows the minimum spec edgy can boot on
<Kamion> or something that actually makes sense :)
<Keybuk> Kamion: yes, sorry, thinko
<Burgwork> Kamion, what does hdwb give us? might it be possible to plan an hwdb-ng for edgy+1 to collect better stats and also help the laptop|server testing programs?
<Kamion> Burgwork: hwdb has always been a bit of a mystery to me, I must admit
<Keybuk> Burgwork: that would assume that people would not be upgrading their machine at the same time as their operating system
<Kamion> I agree that it ought to be involved if possibl
<Kamion> e
<Keybuk> which I think is an invalid assumption
<bddebian> Howdy folks
<Kamion> Keybuk: the converse is also an invalid assumption, though
<Keybuk> indeed
<Kamion> Keybuk: otherwise we wouldn't provide the dist-upgrader
<Keybuk> I don't disagree
<Burgwork> Kamion, it is a giant group of flat files, afaik
<Keybuk> however we do need a metric to make decisions like "enable compiz by default, and treat it as a feature" against
* ajmitch tends towards upgrades every 2-3 years (or in case of theft :) )
<Kamion> Burgwork: the backend, right, but I don't even know what information it stores :)
<Burgwork> Keybuk, if we get a new program created and a new db, we can answer those questions better
<jdub> apparently hwdb-client is not longer required
<Kamion> details of format are a bit irrelevant - that can be recoded
<infinity> Debian (and derivatives) pretty much encourages keeping old hardware, since it's easy to upgrade.  The "throw out the machine and get a new one with a new OS" thing is more likely in the Windows world where you pretty much have to reinstall *anyway*.
<Keybuk> and I don't think that "does a 6-month old entry-level PC support that" is unreasonable in this regard
<alex-weej> infinity: actually it's not true, you can prepare a Windows installation for a hardware gutting, and the next time it boots it does all HW detection and setup again but keeps everything else intact
<Keybuk> (fwiw. the required ram for edgy should probably be stated as 256MB)
<Burgwork> Kamion, yep. it tests a few basic things, like sound and networking and then sends the cpu type, amount of ram, harddrive size, etc.
<infinity> alex-weej: I was referring to upgrading the OS.
<tseng> alex-weej: we arent talking about expert users nessecarily, anyway
<infinity> alex-weej: Like, if you instend to get vista, and you know you're reinstalling anyway, you'll be more tempted to reinstall to new hardware.
<alex-weej> infinity: ah ok i understand
<Keybuk> infinity: why is this bad for new releases of ubuntu?
<infinity> alex-weej: Whereas, if yo uintend to get edgy, you just dist-upgrade.
<Burgwork> Kamion, http://hwdb.ubuntu.com/?xml=8784c7ac0118f31e4c134ed872051615
<alex-weej> tbh i'd say 6 month-old entry level is the equivalent of a 24 month-old top-end machine - something to bear in mind
<infinity> Keybuk: With upgrading being so easy, when I see update-manager offer to upgrade my OS, I'm not going to say "hey, this is a good time to go buy a new computer", I'm just going to say "new OS?  sure!" and upgrade my existing machine.
<Keybuk> alex-weej: yes, that was very deliberate
<Keybuk> infinity: so you're saying that we should never add a feature to Ubuntu if it could possibly increase the RAM, CPU or other hardware requirements on the system?
<infinity> Keybuk: You know I'm not saying that. :)
<Keybuk> it's not an unreasonable position, and if adopted, I have a long list of things we need to remove that have been added since warty ;)
<Keybuk> infinity: right... but then what are you saying? :p
<infinity> Keybuk: Though, if thta would somehow get rid of OpenOffice, I'll stand behind that position firmly. :)
<Keybuk> oddly enough oo2 is in that list, yes
<Keybuk> it's drastically larger than oo1
<infinity> Keybuk: I'm just prodiving the flipside of the "people buy new machines for new OSs" coin, really.  Which I think is much less likely in our world, since we've removed the one thing that tends to trigger that response (requiring a fresh install on upgrade)
<Keybuk> infinity: I'm not disagreeing with you here ;)
<alex-weej> OOo still feels like some kind of after-market spoiler kit to me
<Keybuk> I happen to think that the minimum required specification should not change since warty
<Keybuk> but that's sadly impossible, it seems :-/
<alex-weej> one that just looks like an ironing board
<Keybuk> though edgy has reduced it slightly compared to breezy
<Keybuk> but then there's a difference between "required" and "recommended"
<infinity> (I know my parents bought a new machine for each of Win95, Win2K, and WinXP, but I doubt they'd have been so religious about it if they were doing incremental Ubuntu or Debian upgrades)
<Keybuk> maybe the dist-upgrader should actually *check* the system, and not display a "upgrade now!" if the system wouldn't meet the requirements?
<Keybuk> or perhaps be more useful and suggest hardware upgrades?
<infinity> Keybuk: Not presenting an upgrade option would be a bit harsh, but warning that the system kinda sucks would be cool.
<infinity> "Your video card is bling-free, and your RAM is pitiful."
<jdong> lol, warning that the system kinda sucks
<Kamion> "your father was a hamster"
<jdong> "Infinity has said that your computer blows"
<Keybuk> "Leaping Lion recommends the use of a 4D graphics card; you can purchase one from INTEL"
<jdong> "Dist-upgrader cannot continue. apt-get upgrade-your-damn-hardware has failed"
<infinity> Keybuk: Making vendor recommendations feels wrong to me.
<Keybuk> infinity: it's been proposed for hardware in general "you bought an Nvidia, IDIOT! Go buy INTEL!"
<infinity> Keybuk: But "any video card manufactured in this century should do, you dumpster-diving freak", I could live with.
<Burgwork> infinity, it is hard, given a lack of standard critera to judge computer bits by
<jdub> "NOT. FUCKING. LIKELY."
<jdong> jdub: LOL
<jdong> maybe a "blunt" localization would be nice
* jdong wonders if rosetta can do that magic
<alex-weej> can we just get a big flashing red ACCESS DENIED!
<alex-weej> and a robot woman with a british accent
<jdong> have Ubuntu swear at you for making typos in sources.list or typing in wrong commands
<infinity> Oddly enough, the big red ACCESS DENIED was deemed unfriendly.
<alex-weej> how the fuck is it unfriendly
<alex-weej> every single person on the planet who has seen any movie with a computer in
<alex-weej> knows that when it flashes red and says ACCESS DENIED
<alex-weej> you made a boo boo
* micahcowan takes it that #ubuntu-devel isn't meant to be "family-friendly"? :)
<HrdwrBoB> alex-weej: no, it means you have to hack it
<HrdwrBoB> which requires ~30 seconds of random keypresses
<jdong> micahcowan: we tend to drift in and out of that zone :)
<infinity> Which is vaguely what my password looks like.
<alex-weej> haha
* infinity notes that he was working as of 9 minutes ago, finishes breakfast and idle chatter, and goes to it.
<jdong> pancakes.....
<Keybuk> so it turns out that you *really* don't want usplash to flip back to tty1 now
<Keybuk> even in the case of timeout
<fdsd> Kamion, thanks, I figured out how to modify the usplash on edgy thanks to you:)
<Keybuk> mdz: in fact, it appears that the vt flip is deep inside svgalib
<mdz> Keybuk: #@$@#%
<bddebian> Hey, watch the language :-)
<Keybuk> at least I've learned that the code inside usplash is busted, even after Colin "fixed" it :p
<Keybuk> $ grep ioctl *
<Keybuk> ^ <g>
<imbrandon> moins Keybuk & mdz 
<Keybuk> I still can't work out why /dev/console seems to change with svgalib usplash, but not with bogl usplash
<Keybuk> heh
<Keybuk> doko has DoS'd the i386 buildds
<Hobbsee> hah.  oh dear
<fdsd> hey guys, How do I make edgy knot3 boot to the shell with no login?>
<Keybuk> single user mode?
<Keybuk> choose the "(recovery mode)" option from grub?
<fdsd> no
<fdsd> I have gdm turned off, and I need it to autologin , like how 6.06 does with its livecd
<Keybuk> need gdm to autologin?
<fdsd> I turn off gdm
<Keybuk> then what do you want to autologin?
<fdsd> the shell
<fdsd> after usplash it says username and password, I want it to go directly into my user
<fabbione> morning guys
<zul> evening fabbione 
<ajmitch> hey fabbione 
<fdsd> Keybuk, do you know what I mean?
<Keybuk> edit /etc/event.d/tty1 and change the "respawn /sbin/getty..." to "respawn /bin/login -f $USERNAME"
<ajmitch> mdz: added some info to the f-spot request
<Keybuk> (where $USERNAME is whatever you want to login as)
<Keybuk> you'll obviously need to remove the password from that user account too
<fdsd> ok
<fdsd> Keybuk, cool
<Keybuk> mdz: so I got rid of the vt flip ...
<Keybuk> ... which made X crash on startup
<mdz> Keybuk: ...
<mdz> that's a neat trick. how does it crash X?
<Hobbsee> Keybuk: by chance, did you happen to upload that to the archives?
<Keybuk> mdz: who knows
<Keybuk> mdz: you can crash X by just making any process receive ^C for /dev/console :p
<zul> neat!
<fabbione> you can crash X just running it!
* fabbione hides
<Hobbsee> heh
<Keybuk> fabbione: that appears to be what's happening here, yes
<Keybuk> it starts, and then seems to decide to go back to bed
<fabbione> Keybuk: ehhe
<fabbione> what's the bug exactly?
<Keybuk> fabbione: trying to stop usplash switching to VT 1 when it terminates
<fdsd> Keybuk, how to do I remove the password for the user?
* fabbione still has nightmares debugging X but might help
<Keybuk> fdsd: passwd -d $USERNAME
<Keybuk> fabbione: hmm, it didn't do it that time
<Keybuk> weird
<fabbione> Keybuk: so... boot -> end of boot -> X starts -> vt1 -> stop usplash -> world goes boom
<fabbione> ?
<Keybuk> boot -> stop usplash -> vt1 -> X starts
<Keybuk> which looks ugly
<Keybuk> so I made it just stop usplash -> X starts
<fabbione> and that makes world suck..
<Keybuk> which just leaves you on a corrupt VT 8, and X isn't running
<fabbione> is it possible to simulate that without reboots?
<fabbione> ya know.. to get sshd and be able to fire up something useful
<Keybuk> dunno yet, still trying to work out what went wrong
<fabbione> ok
<Keybuk> I'm wondering whether usplash hooks the vt flip code to revert VT 8 to text mode
<Keybuk> so without the vt flip, it leaves it graphical
<fabbione> if it happens only at boot and it's not reproducible otherwise, it will be hell to debug
<Keybuk> typically it's not doing it _now_
<fabbione> who can reproduce it constantly?
<Keybuk> nobody ;p  it only occurs on my machine, with the hacked version of usplash that doesn't flip vts :p
* Hobbsee can reproduce X dying constantly with the new kernel, but i dont think that's what you want.
<Hobbsee> infinity: you around?
<infinity> Hobbsee: For another hour or so, yes.  'sup?
<Hobbsee> infinity: there's a section of kde-guidance sitting in binary NEW - any chance you could shove that thru before i go nuts?
<Hobbsee> i'm not sure what it's called, sorry
* Hobbsee has no power manager, which means her laptop keeps dying, as she doesnt get alerts :P
<Keybuk> mdz: oh, even better reason why the vt flip is needed :-/
<infinity> Erm, I thought I NEWed that eons ago..
<Keybuk> when gdm terminates, it actives the console it was on when it was started
<ajmitch> Hobbsee: sorry, go nuts? :)
<Hobbsee> infinity: apparently not as of last night?
<Keybuk> which means gdm stop would flip to vt 8
<infinity> Hobbsee: Yes, actually...
<Hobbsee> ajmitch: well, more crazy than i am already
<fabbione> Keybuk: we have 2 options in X that might help you
<Keybuk> ... though that explains why splash_down doesn't work <g>  gdm starts usplash, then flips to VT 1, killing it
<fabbione> Keybuk: -sharevts and -novtswitch
<infinity> Hobbsee: kde-guidance | 0.6.7svn20060919-0ubuntu1 |          edgy | source, amd64, i386, ia64, powerpc, sparc
<infinity> Hobbsee: It's up-to-date and in the archive on all arches.
<Keybuk> fabbione: it consistently doesn't crash for me now ... so I think I'm going to pretend it never happened <g>
<Hobbsee> infinity: the source got split into two binaries, i believe.  i'll ask further
<fabbione> Keybuk: i am sure it will crash here after you upload :P
<fabbione> Keybuk: you know.. that fabbione'fs magic all together with my baby crying thingy
<Hobbsee> in fact, the changelog says it has.
<infinity> Hobbsee: Perhaps you just need to install 'kde-guidance-powermanager'?
<infinity> Hobbsee: (which is also in the archive.. I can't just accept a single binary without accepting the whole upload) :)
<Hobbsee> infinity: ahhh....thanks :)
<Hobbsee> infinity: much appreciated.
* Hobbsee wonders why that isnt a dep of kubuntu-desktop
<infinity> Hobbsee: If there are broken dependencies there or things need seeding or something, bug Riddell. :)
<fabbione> Keybuk: anyway i pasted to you the option you might find useful to debug if the problem shows up again
<Keybuk> thanks
* Hobbsee seemed to miss that, when she looked last night
<fabbione> Keybuk: not all of them are documented afaict
<Hobbsee> infinity: or just fix them.  although i wouldnt know about the seeding, i guess
<Hobbsee> infinity: thanks again
<Keybuk> mdz: ah, taking out the vt switch *does* fix splash_down :p
<fdsd> Keybuk, I am getting an error with tty1, init: tty1 process (3484) terminated with status 1
<mdz> Keybuk: perhaps usplash should be stopped after X starts? or does that prevent it from cleaning up the terminal properly?
<fabbione> infinity, ajmitch: i won't be able to fire up the buildd till monday FYI.  My wife invited guests and i can't keep them awake 2/3 days
<ajmitch> fabbione: fine by me
* ajmitch will be away all weekend anyway :)
<Keybuk> fdsd: check it works
<infinity> fabbione: Good 'nuff.  Should be a good, quiet time to do it (beta freeze, yay)
<Keybuk> mdz: that prevents console-setup from being run
<fabbione> SAN + SUN = more noise than airplane
<fdsd> Keybuk, hmm, ok
<zul> fabbione: tell me about it
<Keybuk> fdsd: ie. the command you put in there
<fabbione> zul: yes i do tell you.. the stuff you have there isn't noisy at all compared to Niagara machines
<fdsd> Keybuk, could you post it one more time, my irc buffer just lost it
<Keybuk> respawn /bin/login -f $USER
<Keybuk> (replace $USER with your username)
<fdsd> Keybuk, i have exactly that
<Keybuk> exactly that?  with the $USER? :p
<fdsd> respawn /bin/login -f stimm
<mdz> Keybuk: I don't particularly like what console-setup does to the console anyway :-P
<mdz> maybe console-setup ought to get run before usplash starts, then the console would be usable in initramfs
<Keybuk> or we could fix the kernel bugs that mean console-setup doesn't work when usplash is running :)
<infinity> Well, /bin/setupcon is certainly tiny enough to throw in the initramfs, not sure how large the supporting data (fonts and keymaps and crap) is.
* fabbione takes away the pipe from Keybuk ....
<fdsd> Keybuk, do you know why the console font looks so strange in knot3?
<fdsd> when it first boots
<infinity> fdsd: dpkg-reconfigure console-setup and pick "VGA", if you like the old-skool font.
<fdsd> infinity, cool
<Keybuk> infinity: X11 
<Keybuk> AND WE'RE NOT PUTTING THAT IN THE INITRAMFS, OK? :p
<infinity> Aww. :)
<fabbione> Keybuk: why not? i did it.. it's relatively small
<fabbione> Keybuk: and it boots REALLY fast
<Keybuk> fabbione: you'll bitch when you discover silo can't load the initramfs because it's too large
<Keybuk> and none of your sparcs boot anymore
<fabbione> Keybuk: oh we fixed that alraedy :)
<fabbione> we can load arbitrary initramfs size now
<infinity> (When it boots at all...)
<HrdwrBoB> just load the whole system into the initramfs
<fabbione> infinity: that too... 
<infinity> With the right compiler and the right silo source snapshot, compiled on the third tuesday of the month, and booting on a blue moon, it all goes well.
<fabbione> infinity: ehhehehe
<infinity> I'd be laughing too, if it weren't true.
<fabbione> it's not THAT true anymore
<infinity> At my last job, I had 3 different silo builds, with different compilers and different patches to silo, just to boot the variety of sparcs in the place.
<fabbione> now i can reproduce silo not booting with both gcc 4.0 and 4.1 without mangling the code :)
<infinity> Well, I guess that's an improvement?
<fabbione> oh yeah
<fabbione> it's more consistent
<infinity> Okay, now I'm laughing. :)
<fabbione> (in not booting)
* infinity needed that.
<fabbione> infinity: see /msg
<Keybuk> mdz: btw, we're SO NOT fading out the mixer sound in ALSA :p
<Keybuk> because that's a VERY HARD PROBLEM
<fdsd> does any one know if knot3 has the issue with kernel panicing randomly on macbooks at startup?
<Keybuk> -> "amixer controls" ... pick one
<infinity> Why fade the mixer when we can just fade the shutdown sound instead?
<fabbione> Keybuk: i think you can rely on the "Master" control being always there, but you also need to make sure you can restore the setting at the next reboot or people will be pissed to death
<Keybuk> heh
<Keybuk> for time in 0 1 2 3 4 5 6 7 8 9; do
<Keybuk>   amixer sset Master 10-
* infinity watches a livefs build complete without mangling his console in the process and decides to call that "progress".
<Keybuk>   sleep 0.1
<Keybuk> done
<Keybuk> ? :p
<StevenK> Keybuk: $(seq 0 9)
<fabbione> Keybuk: basically.. but you need to get the output first of the previous value
<Keybuk> fabbione: why?
<fabbione> to restore it
<fabbione> alsa setting are saved almost realtime
<fabbione> so you want:
<fabbione> orig=$read Master
<Keybuk> eh?
<fabbione> fadegap=$orig / 10
<Keybuk> they're saved on shutdown
<fabbione> yeah and you are shutting down
<HrdwrBoB> and hope you don't get raced to being killed
<HrdwrBoB> in which case it won't save right
<fabbione> for time in 0 1 2 3 4 5 6 7 8 9; do
<Keybuk> fabbione: so do that after you've saved the volume?
<fabbione>  amixer sset Master $fadegap -
<fabbione> sleep 0.1
<fabbione> done
<fabbione> Keybuk: if that gives enough time to fade.. yeah
<fabbione> you still want a fadegap proportional to the original volume
<fabbione> otherwise the sound might fade too fast
<fdsd> Keybuk, this is the file that results in the error, does it look correct to you? http://keanmarine.com/tty1
<Keybuk> isn't that exactly what I just typed?
<Keybuk> fdsd: yes.  what happens if you run "/bin/login -f dcstimm" as root?
<fdsd> Keybuk, let me check
<fabbione> Keybuk: amixer sset Master 10- <- takes 10 away?
<Keybuk> fabbione: yes
<fabbione> KaiL: that assume you are at 100% of the volume
<fabbione> Keybuk: ^^
<fabbione> 10 iterations from 100 to 0
<mdz> fabbione: it would just fade instead of muting where it currently does
<mdz> which is after saving
<Keybuk> fabbione: it doesn't matter
<fdsd> Keybuk, no problems when I run that from root
<fabbione> Keybuk: with fadegap if the volume is 80 you get steps of 8 down
<Keybuk> fabbione: that would involve figuring out the volume first
<fdsd> Keybuk, logs directly into the user
<fabbione> Keybuk: yeah.. exactly as i wrote :P
<Keybuk> fabbione: where did you get $read from though? :p
<fabbione> <fabbione> orig=$read Master <-
<Keybuk> you missed the ALL IMPORTANT STEP
<fabbione> pseudo codfe
<Keybuk> it appears that Master is a non-trivial value
<Keybuk> because it can have as many different current values as you have speakers
<jdub> untz untz untz
<Keybuk> oh, hmm, maybe it's only Mono?
<fabbione> i think Master is "mono" 
<fabbione> numid=2,iface=MIXER,name='Master Playback Volume'
<Keybuk> $orig / 10 won't mute it
<Keybuk> if $orig is 79, $fadegap will be 7
<fabbione> Keybuk: you can calculate it properly.. that was just the idea
<fabbione> amixer cget numid=2
<fabbione> numid=2,iface=MIXER,name='Master Playback Volume'
<fabbione>   ; type=INTEGER,access=rw---,values=2,min=0,max=31,step=0
<fabbione>   : values=29,29
<fdsd> Keybuk, any other ideas?
<fdsd> Keybuk, sorry to keep bugging you
<Keybuk> fdsd: what does "status tty1" say?
<fdsd> let me check
<Keybuk> oh
<Keybuk> obvious duh
<fabbione> brb
<fdsd> Keybuk, tty1 (stop) waiting
<Keybuk> add " </dev/tty1 >/dev/tty1 2>&1" (without the quotes) on the end of the respawn line
<fdsd> ok
<fdsd> let me try it
<Keybuk> just "start tty1"
<fdsd> Keybuk, that works
<fdsd> Keybuk, thanks so much
<Keybuk> mdz: giving up on the fade out idea
<Keybuk> it sounds exactly the same unless you fade really slowly
<Keybuk> the shortest "ok-sounding" fade was 2s
<mdz> Keybuk: what do you think is the best solution?
<mdz> perhaps having a very short shutdown sound is best
<Keybuk> yeah, I'm inclined to say that the shutdown sound is just too long
<mdz> something <= sum(sleeps during shutdown process)
<mdz> so that we have some lower limit where we can be sure it isn't truncated
<Keybuk> yes
<Keybuk> if you want to do something really sick :p
<AlinuxOS> Keybuk, yes I agree that shutdonw sound is little bit long.
<Keybuk> make the sound player ignore SIGTERM
<Keybuk> you can then have the 5s between SIGTERM and SIGKILL <g>
<mdz> the XP one is pretty short
<Keybuk> heh, figured out the occasional double-flicker in splash down now too
<Keybuk> TIMEOUT 0 doesn't do what somebody thought it did :p
<Keybuk> or maybe, looking at blame, timeout 0 no longer does what it used to do
<Keybuk> heh
<Keybuk> the changelog for that change gives "Sending TERM signal seems to take forever" as the rationale
<Keybuk> I think that predates us realising that the reason it took forever was that usplash just got killed
<infinity> Keybuk: No, that wasa different "sending TERM signal"
<infinity> Keybuk: There were two in the old shutdown world order.
<infinity> Keybuk: One right after GDM starts the shutdown (that was what "took forever"), and then the "sending TERM to all processes" later, which killed usplash.
<infinity> Keybuk: I suspect that in the new world order, the first one no longer exists, so the hack is pointless.
<Keybuk> what was the first one?
<infinity> Heck if I can recall.  Go reboot a breezy machine. :)
<infinity> Or, dapper rather.
<Keybuk> dapper doesn't have it
<Keybuk> unless it's from !init
<infinity> Could have been.
<infinity> Anyhow, I'm off.
<Keybuk> interestingly, our principal "dead periods" in boot now are udev and setupcon
<Keybuk> the setupcon is quite obvious; it wastes almost 5s
<Keybuk> udev in total wastes about another 10s
<Keybuk> get rid of those "sleeps" and we get a 30s boot
<desrt> as in, almost entirely idle time?
<desrt> what is it doing?
<Keybuk> which?
<desrt> udev, setupcon
<Keybuk> setupcon is setting up the console fonts and stuff, but it has to be blocked and do it in the foreground, going around changing vts -- instead of just adjusting kernel crap
<Keybuk> because the kernel sucks
<Keybuk> udev is just sleeping because ... well ... it needs a nap
<desrt> so uhm
<desrt> nobody uses the console
<Keybuk> (actually it's because we have things following it that assume that devices are now ready to be mounted, etc.)
<desrt> setting console font seems a bit odd
<desrt> plus, it screws up the splash screen
<desrt> the splash has to be down while you do that
<Keybuk> it shouldn't have to be down at all
<desrt> the console setup is at 90 now
<desrt> it used to be at 40something
<desrt> when it was at 40something, when it ran, it would muck up the top few (30 or so) lines of pixels on the splashscreen
<Keybuk> it mucks up the entire thing now
<desrt> lovely :)
<Keybuk> mdz: ok, splash down is mostly pleasant now
<Keybuk> svgalib seems to go out of its way to reset a VT to text mode if it's already in graphics mode when it starts
<Keybuk> so there's an annoyingly black screen and flicker, where before it just drew over the top
<Keybuk> but I don't think that's avoidable
<desrt> hack svgalib
<desrt> ...and X...
<Keybuk> desrt: I can assure you, that's rather far down the list of the things I want to do with my life ... just under placing my testicles in a blender to see what it feels like
<desrt> :)
<desrt> i'd hack svgalib somewhat before trying the blender thing
<mdz> Keybuk: sounds reasonable, I'll have a look once it lands
* desrt notes that svgalib uses 1024x768 for him but X uses 1280x800 (not supported by svgalib)
<Keybuk> about the only annoying thing now is that if you do "/etc/init.d/gdm stop" on a console, it switches to vt8 for you
<Keybuk> which has nothing on it
<desrt> that's a really quick X hack to fix
<Keybuk> desrt: what vt would you have it switch to instead?
<desrt> Keybuk; none
<desrt> when X terminates it switches to the VT that was running when it started
<desrt> it does this even if its not active at the time
<desrt> just conditionalise the VT switch to only happen if the X server was active
<Keybuk> yes, that should definitely be fixed
<Keybuk> it should only switch VTs if it's on its own
<desrt> i'll take care of it
<Keybuk> sweet
<Keybuk> now I know why usplash crashes X
<Keybuk> it's the same bug I had with upstart crashing X :)
<Keybuk> it does open("/dev/console", O_RDWR) after calling setsid()
<Keybuk> which means /dev/console becomes the controlling terminal
<Keybuk> and for some reason, X takes an exception to that and crashes
<Keybuk> (how X even knows, I have no idea)
<fabbione> Keybuk: i think it's not impossible to check X code in that respect...
<Keybuk> fabbione: I wouldn't even know what to look for
<Keybuk> as far as I know, as many processes as they like can have the same controlling terminal
<fabbione> grep open * -r | grep console? :P
<Keybuk> and they aren't notified if another process also takes it
<fabbione> anyway.. gotta get ready for hw maintainance
<fabbione> and a few security reboots/updates
<desrt> Keybuk; can you upload X?
<Keybuk> desrt: define "can" ?
<desrt> would anyone be angry at you?
<desrt> i have a fix for the VT-switching problem
<Keybuk> I doubt they would be angry
<desrt> ok
<desrt> just making sure it builds :)
<keescook> in launchpad, when linking to an upstream bugtracker, there is an "Inkscape bug tracker".  Shouldn't this really be "SourceForge bug tracker"?
<Burgundavia> keescook: file a bug against malone
<desrt> man.  autotoolsed X
<Keybuk> oh, now that's interesting
<desrt> my amusement is deep.
<Burgundavia> desrt: you did?
<desrt> Burgundavia; no.  "they" did.
<Keybuk> daniels did, specifically
<Keybuk> stub: hey, how goes the revolution?
<desrt> it was one of the things that happened xfree86 -> xorg
<desrt> the more you learn about X the harder it is to hate it
<stub> Keybuk: business as usual today - people took all their photos posing infront of the soliders and tanks yesterday. no curfew. everything back open except the laos and burma borders I think.
<desrt> oh.  .th.  cool :)
<stub> They still knock BBC and CNN off air whenever they put on a story about the coup though
<desrt> news here has been largely ... neutral
<desrt> they're like "it happened.  wednesday is a holiday.  next story."
<Burgundavia> desrt: I wonder if apple would have decided differently about X had they had to make the decision they did now
<Fujitsu> It's just been briefly mentioned in news here.
<desrt> Burgundavia; i think they'd do the same thing
<Fujitsu> Burgundavia, ?
<desrt> stub; any news on when martial law is lifted?
<Burgundavia> desrt: likely
<desrt> Burgundavia; if macos looks too much like linux then people can run linux instead
<Burgundavia> desrt: no, talking about archecture, not looks
<stub> desrt: Probably two weeks when the interim government is appointed
<desrt> stub; why did it happen?  news here has been short on details
<stub> desrt: The incumbent government is hated by the population of Bangkok, but has won the last few elections by 'landslide' having bought votes in the rural areas (literally). The last election was boycotted, leaving the country with no real government, although a good outcome was the corrupt electoral commission was sacked or jailed. 
<desrt> so a pretty legit/well-needed coup, then
<desrt> congrats :)
<stub> desrt: It appeared though that when the next election was finally called, not enough would have changed so the existing government would probably stay in office. This would have solved no problems, so the army stepped in (with strong rumor having support from the King, who is the real power)
<stub> Esp. as the existing government was looking at replacing the military leaders in charge of Bangkok with cronies, so any protests during the next election would have been crushed.
<Kagou> hi
<Keybuk> fabbione: actually, this X crash is entirely reasonable
<Keybuk> usplash is stealing tty7 from X
<Keybuk> after which point, X would no longer receive signals about it, and is no longer the controlling process on that terminal, etc.
<desrt> keybuk; http://desrt.mcmaster.ca/random/xorg-server_1.1.1-0ubuntu11.debdiff
<desrt> Keybuk; upload, k plz thx :)
<desrt> well... you probably want to test it first
<Keybuk> did you test what happens if you shutdown X while X is active?
<desrt> yes
<desrt> then it works
<desrt> that's the testing that led me to conclude that checking vtSema _doesn't_ work
<Burgundavia> mjg59: are you up yet?
<desrt> when X comes down it briefly returns to text mode on the console it runs on before switching back to the other console
<desrt> my code runs at that point
<fdsd> You blokes may know this, I just want a very bare min install of ubuntu, I want it to boot with usplash right to the console (I am making a very basic livecd)  It doesnt need anything except fdisk, bash, mount.. etc.. is there a easy way to remove all those unneeded packages?
<Keybuk> fdsd: it'd be easier to just install it fresh with only the minimal set
<fdsd> Keybuk, okay, how do I go about doing that? is it an install option?
<Keybuk> fdsd: it's an option on the alternate install CD
<fdsd> Keybuk, oh I see
<Keybuk> though if you're making a Live CD, you'd probably stage the install on your filesystem anyway
<Keybuk> so can just use debootstrap
<Keybuk> mkdir /tmp/fs-image; debootstrap edgy /tmp/fs-image
<fdsd> Keybuk, is there a way to get a list of packages that are in the minimal set?
<Keybuk> gives you a minimal edgy install (literally only the essential pieces and no config) under /tmp/fs-image
<fdsd> Keybuk, oh interesting
<Keybuk> http://people.ubuntu.com/~cjwatson/germinate-output/edgy/minimal
<fdsd> Keybuk, the amount of time iv put into this you could have done in two seconds
<Mithrandir> fdsd: you're aware that we provide a base image you can just use?
<fdsd> Mithrandir, does is have usplash?
<Mithrandir> fdsd: nope
<fdsd> Keybuk, is there a list for powerpc edgy?
<Keybuk> of course, you can just "apt-get install usplash" into the base image ;)
<Keybuk> fdsd: it's the same
<fdsd> cool
<fdsd> Keybuk, true
<fdsd> Mithrandir, where is that image I can try?
<Mithrandir> fdsd: http://cdimage.ubuntu.com/livecd-base/current/
<Mithrandir> note that they require you to supply an initramfs yourself; they're just the base squashfs images
<fdsd> Mithrandir, thats no problem
<fdsd> Mithrandir, what kernel and such do they have? is it the latest?
<Mithrandir> fdsd: look at the manifest; they're built daily so they should have the latest, yes.
<fdsd> cool
<fdsd> Mithrandir, thanks a bunch
<fdsd> Mithrandir, if I drop this into the knot 3 livecd and remake the iso will it boot okay?
<Burgundavia> gnomefreak: ping
<pitti> Good morning
<Fujitsu> Morning, pitti.
<pitti> hi Fujitsu 
<ajmitch> hi pitti 
<Mithrandir> fdsd: yes, it should
<fdsd> Mithrandir, awesome, saved me alot of time
<Burgundavia> sladen: ping
<Mithrandir> fdsd: note that if you just use the initramfs from knot3 the initramfs will have usplash, you might want to not have "splash" on the kernel command line
<Mithrandir> (if you don't want usplash)
<fdsd> Mithrandir, I do want usplash
<fdsd> Mithrandir, I made a dialog based shell script that launches at boot, so basicly it boots, shows usplash logo, then goes straight to the dialog shell script
<keescook> pitti: is your net connection okay again?  :)  that bug I was talking about is 6293
<pitti> keescook: no, network still out, I'm currently dealing with it
<pitti> keescook: it is very important that our POT files are built in debian/rules
<pitti> keescook: Rosetta relies on them always being up to date
<pitti> keescook: so e. g. if we apply a patch that changes a string, this must be immediately reflected in the pot
<keescook> Makes sense.  What would be the "correct" fix for 6293, then, from ubuntu's perspective?  Regen from the makefile?
<keescook> pitti: I'm out for the evening.  good luck with the connectivity issues!
<pitti> keescook: wrt the bug
<pitti> keescook: it is very confusing
<pitti> keescook: now, does it contain two POT files or none at all?
<desrt> wow.  builds are getting backed up
<desrt> some idiot kicked off oo.o builds :p
<Fujitsu> Oh dear.
<Keybuk> yeah, doko DoS'd the buildds
<ajmitch> I think there need to be buildds set aside just for him
<desrt> the build queue just needs to implement a LCFS policy
<Fujitsu> OOo is very effective at DoSing.
<desrt> it's more fair when the workload consists of many small jobs and a few large jobs
<zakame> keescook: ping, good to see you here :)
* Starting logfile irclogs/ubuntu-devel.log
(desrt/#ubuntu-devel) better in edgy?
(pitti/#ubuntu-devel) desrt: it also still has many holes left, too
* pitti doesn't know the edgy situation
(desrt/#ubuntu-devel) well
(desrt/#ubuntu-devel) edgy has canaries anyway
<pitti> they don't help you on the heap
<desrt> neither does libc address randomisation
<desrt> unless you can manage to overflow the heap in such a way that you can redirect a callback pointer
<desrt> and also in such a way as to ensure that that callback pointer gets called with the values you like
<desrt> i bet vcalls in c++ make that really easy
<desrt> if you can overwrite an object instance then you can change its class pointer to point to some evil vtable that contains system() as one of the methods
<desrt> then when that method gets called you automatically have the object (which you just overwrote) passed as the implicit instance pointer
<desrt> but system() doesn't expect an object instance... so it just treats the pointer as the first argument
<desrt> you have 4 bytes of junk at the start of the object instance for your class pointer... just put a ";" after it and then fill in the command you want executed
<desrt> another ; and fill in your vtable
<desrt> of course, you could do the same thing with gobjects, too
<desrt> you'd need deterministic heap addresses, though
<desrt> so i guess address randomisation still has a place
<pitti> desrt: I'm not that much of an expert in that, but I read that once you plug a few more holes, it's pretty good
<desrt> pitti; well... you could always just ask the programmers very nicely to write code without bugs :)
<pitti> programmers: pretty please write good code
<Keybuk> desrt: works fine for me in all situations, and solves the bug
<desrt> Keybuk; awesome.
<pitti> 'k, topic solved then? :)
<pitti> hey Keybuk 
<desrt> my plan for the course is i'm gonna run some process on a server
<Keybuk> pitti: heh, referring to desrt's fix to stop X flipping to some random VT when you kill it
<desrt> that'll be like main() { buffer[20] ; gets(buffer); return 0; }
<desrt> i give them the source to the server and the compiled binary
<desrt> and their assignment is to create a file on the server that contains their name and student number :p
<pitti> nice ;)
* pitti wishes he had done such h4x0r courses in uni
<desrt> it's an assembly course
<desrt> we cover topics
<desrt>  - assembly basics
<desrt>  - calling to/from C.  stack layout
<desrt>  - debugging
<desrt>  - hax0ring
<desrt> or so is the plan :)
<desrt> (new course next term)
<desrt> in any case i'm off to bed.  ciao :)
<pitti> desrt: sleep well
<dholbach> good morning
* Keybuk hugs dholbach 
<Keybuk> Happy Beta Freeze Day!
<Hobbsee> argh, surely not
* dholbach hugs Keybuk back
<Hobbsee> i *knew* there was something else i was going to fix in main today
<Seveas> mornin'
<Hobbsee> hey Seveas 
<Seveas> hey Hobbsee 
<Hobbsee> two things, in fact.
* Seveas is proud of himself, I chaired the ubuntu BOF at eurooscon today and people actually liked it
<Fujitsu> :)
<Seveas> People were disappointed though that Mark didn't show up ;)
<Keybuk> did he know that he was supposed to show up?
<Seveas> I'd assume so, if I understood it correctly there was some miscommunication about canceling
<Seveas> after Jeff canceled 
<Kagou> Kamion: just for informations, today desktop daily iso is like yesterday, not very uptodate.
<Keybuk> Kagou: compared to?
<Hobbsee> Seveas: you could have tried pretending to be mark :P
<Kagou> Keybuk: desktop daily iso do not contain old packages (3/4 days old) 
<Kagou> Keybuk: specially i'm looking at fontconfig
<Seveas> Hobbsee, that wouldn't have worked ;)
<Treenaks> Seveas: it's the accent, isn't it? :P
<Hobbsee> Seveas: i know, but it could have been awful fun to try
<Hobbsee> heh.  my machine is hitting 83C again
<Keybuk> Kagou: hmm, are you just checking the manifest file, or the actual iso?
<Kagou> Keybuk: actual iso (burnt and booted on)
<Keybuk> ah, openoffice is uninstallable
<Kamion> Keybuk: reading scrollback - setupcon does not actually change VTs any more, you know
<Keybuk> Kamion: no, but it appears to take a long time ;-/
<Kamion> Keybuk: anyway, I just made setupcon not do font setup if usplash is running, which should fix the video corruption
<Keybuk> yeah I saw
<Keybuk> it would still be "nice" if setupcon could just work even if usplash or X were running
<Keybuk> but there be kernel bugs, arr
<Kamion> Kagou: it's ok, you don't need to tell us about this
<Kamion> Kagou: the livefs failed to build - http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/ubuntu/latest/livecd-20060921-i386.out
<Kamion> Keybuk: any idea which bit of setupcon is taking ages? it's presumably some child process
<Keybuk> ckbcomp/setupcon/loadkeys
<Kamion> oh right
<Keybuk> hmm
<Kamion> it'll be ckbcomp then
<Keybuk> I wonder whether it's taking longer for me because I'm still running it under strace :p
<Kamion> well, it's doing a chunk of work
<Keybuk> *nods*
<Kamion> there's an argument that if you didn't say --save and there's a boottime keymap saved, it should just use that
<Keybuk> the fact it gets run twice is probably not helping either
<Kamion> or maybe if the boottime keymap's timestamp is at least as new as /etc/default/console-setup
<Kamion> that would probably be a good enough check
<Kamion> the first run won't work if you have a separate /usr ;)
<Keybuk> heh
<Keybuk> we should so just outlaw that ;)
<cbx33> is there any possibliilty that ubiquity can have a slight change made to it ?
<Kamion> cbx33: depends on the change :)
<cbx33> scanning for a mirror
<cbx33> I'm behind a proxy...
<cbx33> installing fro ma live cd
<Kamion> known bug that I need to investigate
<Kamion> but it's probably not "a slight change"
<cbx33> will it eventually get there?
<cbx33> sorry Kamion just asking
<cbx33> oh yep...it's moved onto the security mirror now
<Kamion> should do, you can find the http child processes and strace them to see if it's doing anything
<cbx33> well i know what it's doing.....sitting waiting for a responce
<cbx33> which it's not going oto get
<cbx33> also do we know of issues with NVIDIA 7300 series on PCI-E
<cbx33> my brand new PC for ubuntu development is sick...
<cbx33> it thinks it's an ATI card :S
<Keybuk> rofl
<cbx33> that sux...
<cbx33> heheh
<cbx33> I hate ATI
<Keybuk> paste the relevant line from lspci -n
<cbx33> I will when I get home
<cbx33> it was a fresh install of dapper
<Fujitsu> Silly silly NVIDIA.
<Keybuk> nvidia should be 10de:????
<Mithrandir> hmm, shouldn't gnome-games really just be a recommends of ubuntu-desktop?
* cbx33 is the proud owner of a nice 4200 X2 :)
<Burgundavia> Mithrandir: probably
<cbx33> just got it yesterday
<Fujitsu> No no, it's a critical part. You can't have a desktop without games! It must /never/ be allowed to be removed by users.
<Kamion> Mithrandir: that seems like a fair argument
<HiddenWolf> Mithrandir: yeah, it should
<Kamion> I can't decide whether I like the way that https://launchpad.net/distros/ubuntu/+milestone/ubuntu-6.10-beta lists fix-released bugs
<Kamion> I guess it gives an impression of progress
<Keybuk> Kamion: makes it more like an mdz poster/blame board
<Kamion> right :)
<cbx33> is mdz around
<Kamion> I doubt it
<Keybuk> cbx33: almost certainly in bed
<Keybuk> or a pumpkin
<cbx33> maybe someone else can help ;)
<cbx33> I have to make a change to my student-control-panel pacakge
<cbx33> but beta freeze has p[assed hasn't it
<Kamion> what's the change?
<cbx33> I only found out about the change yesterday
<cbx33> but my pc had blown up, so I'd ordered my new bits
<cbx33> but didn't get it together intime
<cbx33> I need to make it only run if an environment variable is set
<Kamion> detail?
<cbx33> well, if the LTSP_CLIENT enviroment variable is set, it should run, if not it shouldn't
<Kamion> that sounds pretty safe; what's the reasoning?
<cbx33> well
<Kamion> (I don't know LTSP)
<cbx33> people running as a user on the LTSP server, shouldn;lt show up in the LTSP users list ;)
<Hobbsee> doko: you around?
<Kamion> that's fair enough - I suppose you should make sure that it exits 0 if LTSP_CLIENT isn't set
<Fujitsu> Can I presume that SCP will be modifiable for use on non-Edubuntu LTSP servers?
<cbx33> Kamion: that was the plan
<cbx33> Fujitsu: yes
<lastnode> imbrandon, you around mate?
<Fujitsu> Great, cbx33 :)
<Kamion> cbx33: go ahead then
<cbx33> Kamion: ok, I'll try and get that done today
<Kamion> cbx33: if you get it done before the development team meeting, probably nobody will notice anyway :)
<cbx33> Kamion: there is also a change to the usplash artwork I need to make
<cbx33> Kamion: how long is that away?
<Kamion> seven hours
<cbx33> Kamion: hopefully should be doable
<Kamion> what's the usplash artwork change?
<cbx33> I'm at work now, but I'm hoping to sneak some ubuntu time in
<cbx33> the images are resulting in a 2Mb .so file ;)
<cbx33> which is a little large
* cbx33 is trying to either desat and/or pngcrush them
<Kamion> same for Ubuntu apparently
<cbx33> really?
<cbx33> must be the new 256 colours
<Hobbsee> lastnode: he went to get some sleep
<cbx33> ogra is concerned that 2Mb over the LTSP will slow down
<Kamion> I don't think that's beta-critical, but if you can get it reduced without losing quality, I'm all for it
<Kamion> fair enough
<cbx33> Kamion: does that mean I could do it after
<cbx33> cos that one will take some testing and time
<Kamion> yes, we'll open up slightly again (back to FF levels) after the beta release
<lastnode> alright Hobbsee, i was just trying to see if i could catch him to talk about upstream, and to get some advice on where to head now. (we have a working POST backend and a semi-working GUI, as well as three devs). even if you're free sometime, id love to have a design related chat. 
<cbx33> Kamion: right ok, that gives me a little time on that one....as I said I only found out yesterday, 
<Hobbsee> lastnode: right....i know nothing at all about this :P
<lastnode> Hobbsee, it's a python script. anyway, ill wait for him to wake up. much thanks.
<Hobbsee> ah
<cbx33> Thanks for the info Kamion 
<Burgundavia> lastnode: what sort of project are you working on?
<lastnode> Burgundavia, http://sourceforge.net/projects/upstream <-- a log transfer system.
<Burgundavia> lastnode: ah, interesting
<Kamion> wow, most confusing project name ever :)
<Kamion> "who's the upstream for upstream again?"
<Kamion> "huh?"
<lastnode> Kamion, i thought about that, i did ;-)
<Keybuk> Kamion: the author is a Mr Upstream
<lastnode> it just was too good to pass up - logs, etc, and keeping with the usual corniness of naming *nix projects, i thought id give it a go
<Hobbsee> Kamion: hehe, that's what i thought
<Fujitsu> Hobbsee, same here.
* Hobbsee thumps imbrandon's machine
<Hobbsee> stop saying that i'm working with an unsigned key!
<Fujitsu> Keybuk, what's wrong with convertall's debian/copyright?
* Fujitsu checks it....
* lastnode curses shift+backspace
<Fujitsu> Oh...
<Fujitsu> Woops.
<Fujitsu> Something went /really/ wrong there.
<Keybuk> :P
<Hobbsee> what, it doesnt exist?
<Fujitsu> No, it's all screwed...
<Fujitsu> Hey, I haven't even got the latest version here...
<Fujitsu> I forget where I last did it, it was two weeks ago...
* Fujitsu grabs it from REVU instead.
<Fujitsu> Oh, woops. I do have the latest version here. It was lucidlife's debian/copyright I was thinking of that had those changes...
<Burgundavia> lastnode: last years SoC had an innovative bug/defect system you should look at
<lastnode> Burgundavia, got a link? although i must add that this is mainly concerned with sending logs for troubleshooting (although it could tie in with a bug system)
<Burgundavia> not off hand
<lastnode> ok, thanks anyway Burgundavia. :-) it was originally written in bash (I know, I know) but then imbrandom convinced me to rewrite it in python.
<doko_> pitti: did you look at Till's packages? else I would do it now
<pitti> doko_: not yet, sorry; please go ahead if you have time
<doko_> time ... no, but I go ahead =)
* pitti hugs doko_
<dholbach> heya doko_
<mvo> hey doko_!
* dholbach hugs doko_
* mvo hugs doko_
<doko_> hi gnome slackers ;)
<dholbach> haha
* dholbach slaps doko_ :)
<Mithrandir> doko_: are you responding to mdz's mail about the daily health checks?
<doko_> Mithrandir: after OOo hits the archive
<Mithrandir> doko_: as in, it's fixed when the new ooo hits or you'll respond after it hits?
<doko_> Mithrandir: most of it will be fixed, I'll look at it again, after the health check is updated.
<Mithrandir> doko_: 'k
<doko_> oh, the first build did finish
<doko_> Kamion: please approve the new openoffice.org binaries in NEW
<Kamion> they aren't there (yet, or Keybuk's already approved them)
<doko_> ahh, no new packages for amd64 and powerpc, and the i386 build just finished
<Kamion> crimsun: could you pass on that somebody needs to rebuild xubuntu-system-tools for the new liboobs? before beta if possible
<crimsun> Kamion: yessir
<Kamion> thanks
<doko_> Kamion: hmm, trying to find the queue view again ... have to save the link
<crimsun> Kamion: just a simple rebuild?
<Kamion> dunno, may need to be a merge from gnome-system-tools
<crimsun> ok, thanks
<Kamion> I just noticed it as a blocked not-built-from-source removal
<doko_> nevermind, found it
<Kamion> doko_: /distros/ubuntu/edgy/+queue
<seb128> doko_: read the /query from yesterday? do you still have your libgnome-java changes locally?
<doko_> seb128: have to read it ...
<Mithrandir> dholbach: libgnomeuimm-2.6-1c2a seems to be uninstallable due to libcairomm-1.0-0 soname bump.  Are you on it?
<dholbach> Mithrandir: yeah, can do - thanks
<Nafallo> morning * :-)
<dholbach> Mithrandir: I'll rebuild the others too
<Mithrandir> dholbach: yay, thanks.
* Mithrandir hugs dholbach 
* dholbach hugs Mithrandir back :)
<Kamion> damn, I've just noticed why auto-resize isn't working very well in edgy's ubiquity
<Kamion> no 64-bit maths in the shell ...
<Mithrandir> we should just stop supporting 32 bit arches. :-P
* Mithrandir hides
<Nafallo> LOL
<Nafallo> Mithrandir: or implement your multi-arch ;-)
<Mithrandir> Nafallo: that doesn't help in this case
<Kamion> int
<Kamion> arith(s)
<Kamion> ...
<Kamion>         long result;
<Kamion> ...
<Kamion>         return (result);
<Kamion> score
* Nafallo just noticed we have alsa in -minimal.
<Kamion> not that it matters much
<Nafallo> why do we have sound on a server? :-)
<Kamion> Nafallo: originally, that was so that we had the hotplug blacklist files consistently installed
<Kamion> they're in linux-sound-base now, so it's possible that that can be tweaked, but it would require careful thought
<Nafallo> and now? can we move it to somewhere not servisch? :-)
<Kamion> read what I just wrote
<Nafallo> hmmm
<Kamion> "it's possible that that can be tweaked, but it would require careful thought"
<Kamion> i.e. I don't have time to check now :)
<Nafallo> Recommends might help? :-)
<Kamion> no
<Kamion> helps absolutely not at all
<Nafallo> that would make me have my server installed with ubuntu-minimal ;-)
<Kamion> it would be wrong
<Kamion> either it should be in minimal, or it shouldn't
<Kamion> there should be no halfway houses for minimal
<Nafallo> oki.
<Kamion> note that debootstrap's automatic dependency resolution does not follow Recommends
<Nafallo> ah, makes sence then.
<Nafallo> hmm, we have ppp* and reiserfsprogs in -standard?
<Nafallo> Kamion: maybe I should go write a spec for edgy+1? :-)
<Nafallo> if that would be helpful etcetera.
<Kamion> Nafallo: I don't think it would be helpful
<Kamion> a spec would be overkill here
<Kamion> we don't need a spec for every little seed tweak
<Kamion> reiserfsprogs is there because by policy we have a reasonable set of filesystem support as standard
<Kamion> (that could arguably be recommends, though)
<Nafallo> i.e. ext3+reiser :-)
<Kamion> please take the filesystem advocacy elsewhere; thank you :)
<Nafallo> hehe, we already advocate ext3 quite hard, that should be enough. so I argue the same for -standard ;-)
<Kamion> whatever
<Nafallo> how do you want me to move forward with those seed changes, since I guess it's not really edgy material this late in the cycle? :-)
<Kamion> feel free to file bugs on ubuntu-meta
<Trewas> could someone take a look at bug 58927 and maybe assign it to someone? it's a configuration issue with dhcp3 which causes problems only with ~broken routers, but these a-link roadrunners (and I doubt they are the only broken ones) are very common here and if the config is not changed for edgy, there will be many with non-working networks
<Ubugtu> Malone bug 58927 in Ubuntu "Network unreachable with Edgy" [Untriaged,Confirmed]  http://launchpad.net/bugs/58927
<Kamion> anything complicated should be discussed on -devel
<Nafallo> oki, will do then :-). thanks Kamion *hug*.
<Kamion> pitti: have you seen the further discussion on Debian #
<Kamion> er Debian #383314?
<Ubugtu> Debian bug 383314 in libmagick9 "libmagick9: Buffer overflow in SGI parser [CVE-2006-4144] " [Grave,Open]  http://bugs.debian.org/383314
<Kamion> pitti: I'm just going to sync in unstable's imagemagick for edgy, unless you have any objections, but you might want to revisit the fixes for dapper etc.
<pitti> Kamion: yeah, I saw it
<pitti> Kamion: it's on my TODO list
<pitti> Kamion: yeah, syncing for edgy would be appreciated
<Kamion> ok, doing, thanks
<Nafallo> Kamion: there is some reason we have aptitude in -minimal rather than standard I guess? :-)
<seb128> iwj: hi. When do you think you will upload a firefox shipping xpidl again? The build of some packages is broken by that at the moment
<jdub> Seveas: onya - bof was good?
<dholbach> pitti: opal seems to suffer from a pkg-create-dbgsym problem as well
<dholbach> pitti: can you tell me, what you changed yesterday, so I can check it on my own?
<pitti> dholbach: ok, I'll deal with it, but I'd like to finish with this thunderbird/firefox mess
<dholbach> sure, take your time
<pitti> dholbach: yesterday? I just fixed debian/rules to do what it wanted to
<dholbach> pitti: ok, I check
<pitti> dholbach: in general, I fix stuff in pkg-create-dbgsym, though
<dholbach> I believe this might be the same problem
<pitti> since it shouldn't alter build behaviour normally
<pitti> dholbach: but with yesterday's package it executed dh_strip under compat level 5, but thought it would be < 5 (due to the wrong test)
<dholbach> thanks - I'll check it out
<Kamion> Nafallo: yes; the installer uses it to install the rest of the system.
<Kamion> including, oh just for example, standard
<Nafallo> thought so :-)
<Fujitsu> Kamion, thanks for those syncs :)
<dholbach> pitti: looks like a similar problem *testbuild*
<Seveas> jdub, yeah, bof was good ;0
<Seveas> 
<Seveas> jdub, I'm expecting a few mails from people who attended with feedback theywant to be forwarded to people "higher in the chain" than me, so people should expect some spam from me ;)
<Nafallo> Kamion: there you go. 7 bugs filed for discussion ;-).
<jdub> Seveas: rock on - thanks!
<Nafallo> Kamion: in case you're not subscribed to the ML, I also mailed -server about them. Invited for discussion :-).
<cbx33> Kamion: I fixed that bug with a 2 liner, so I'll rebuild the package and get ogra to upload in the next 5 hours
<tepsipakki> latest flashplugin-nonfree for dapper-backports has some problems
<tepsipakki> it isn't built yet
<Fujitsu> tepsipakki, that was fixed with a new upload earlier today.
<tepsipakki> fujitsu: oh, there's nothing on dapper-changes
<Fujitsu> tepsipakki, what was the last upload you saw?
<tepsipakki> ubuntu2~dapper1 is the latest there
<Fujitsu> Hm.
<Fujitsu> Yes, that's what I meant.
<Fujitsu> And you're right, it's not built.
<Fujitsu> The buildds are rather tied up at the moment, unfortunately.
<StevenK> ln -s buildds dokos-bitches
<cbx33> guys I have a python script that is run as part of the Xsession.d
<tepsipakki> is there redistribution problems with the plugin, or why is a complex wrapper needed?
<cbx33> when X session finishes, the script should be closed too
<tepsipakki> s/is/are/
<cbx33> why isn't....there is no signal handling in it yet....is that why?
<cbx33> but the scipt still runs when the user logs out
<cbx33> and continues to run
<cbx33> I don't want this happeneing
<Riddell> carlos: did you get the desktop*pot files?  and did the utf8 issues get fixed?
<carlos> Riddell: I guess, because we got 30000 new files in our import queue, let me check it (oo.org import is delaying those imports)
<carlos> Riddell: yeah, I see some .po files for desktop templates
<carlos> about the UTF-8 issue, I see that konqueror.pot has the UTF-8 tag, so it should be fixed
<carlos> Riddell: thanks!!
<dholbach> my wifi hates me today
<dholbach> narf
<dholbach> pitti: I did some changes to the opal package, but it's not quite it yet - if you could have a look later on, that'd be nice -- I have my changes on http://daniel.holba.ch/temp/
<pitti> dholbach: ok, I'll look at it ASAP
<dholbach> pitti: take your time :)
<StevenK> dholbach: Heh, nice domain.
<dholbach> StevenK: thanks :)
<cbx33> anyone know how when an X session closes it stops the processes called in the /etc/X11/Xsession.d/ configs?
<Riddell> carlos: great
<carlos> Riddell: I will confirm that anyway as soon as all files are imported (it would take a day or two)
<Riddell> carlos, jordi: did you write a response to that KDE wiki page?
<carlos> Riddell: jordi told me that he will have it ready before tomorrow night
<jordi> yeah
<xadf> hi
<xadf> why is there no security update for flashplugin-nonfree for dappefr?
<pitti> xadf: it's not supported, thus it may take a while
<pitti> or not even be done at all
<xadf> very clever
<Fujitsu> ?
<jono> anyone else getting an openoffice.org crash whenever it loads a file picker?
<Fujitsu> jono, known bug...
<dholbach> jono: yes, known issue
<jono> ahhh cool
<Fujitsu> I forget which one, but it'll be fixed when OOo is rebuilt...
<dholbach> you can change the filechooser to be non-gnome
<dholbach> (as a tempoary workaroung)
<Fujitsu> In fact, it should be fixed very shortly, as OOo has finished building on a couple of archs.
<Treenaks> hm, _something_ in my apache2 on dapper is leaking memory at ~30mb/day
<Treenaks> how do I find out what it is?
<jdub> Treenaks: it's php
<Treenaks> jdub: PHP is not even installed
<Treenaks> I suspect fcgid though
<jdub> Treenaks: yep. that's just how scary it is.
<Treenaks> jdub: ;)
<Nafallo> lol
<jdub> Treenaks: check where your server is hosted - i'm sure there'll be a php installation nearby, sucking its will to live
<Treenaks> jdub: it's in a shared colo, so it's very likely, yes...
<Treenaks> *hmm*
* Fujitsu moves into Treenaks' server, and begins to eat the RAM.
<Nafallo> Treenaks: seems you have a bad harddrive ;-)
<Treenaks> I just want apache to show me why its heap is 40MB (and no, valgrinding it is not really an option :))
<Fujitsu> I am a hard drive... a 10.4GB one.
<pitti> dudes, dudettest, and duderinos: May I proudly present http://people.ubuntu.com/~pitti/ddebs/
<Fujitsu> Wow!
<Fujitsu> Yay!
<Fujitsu> Finally :D
<pitti> seb128: debug crack for the world!
<Fujitsu> I presume they actually have the stuff in them?
<pitti> sure
<Fujitsu> Good!
<pitti> Fujitsu: but we only started grabbing them yesterday, so it's veeery incomplete
* pitti hugs infinity for doing the buildd side
<Fujitsu> pitti, at least it's there now :)
<Fujitsu> Arsgdfgdgd.
<Fujitsu> I just clicked on one in Firefo.
<Fujitsu> *Firefox
<Fujitsu> Of course, it decided it wanted to render it as unicode.
<Fujitsu> Hi, sabdfl!
<seb128> pitti: WAOUH
* seb128 hugs pitti
<Treenaks> Fujitsu: sounds like a mis-configured webserver
<pitti> Fujitsu: don't worry, to make this actually useful I'll update the apport-retrace script to automatically fetch them
<Fujitsu> Good idea, I was wondering how they were usable :)
<sabdfl> hi guys
<seb128> hey sabdfl
* pitti crons
<seb128> pitti: so we can apt-get install package-sbgsym now? :)
<pitti> hi sabdfl 
<Nafallo> morning sabdfl :-)
<cbx33> hey sabdfl 
<pitti> seb128: if you want to, yes
<seb128> pitti: can I blog about it? ;)
<pitti> seb128: I didn't test it with apt-get yet, though
<dholbach> pitti: YOU ROCK
<pitti> seb128: wait until it's polished a bit :) I'll do an official announcement on u-d-a
* pitti hugs dholbach 
<mvo> hey sabdfl
* dholbach hugs pitti back
<seb128> pitti: ok, cool
<pitti> seb128: I do create indexes, but I'm not sure whether apt-get is happy with '.ddeb'
<pitti> seb128: after I finish the last bits on rookery, I'll try that
<pitti> BenC: good bye, hello, goodbye, hello :)
<Nafallo> haha
<Mithrandir> iwj: my firefox has managed to lose all its CA certificates.  Is there an easy way to reload them without trashing all the settings?
<Mithrandir> iwj: I _think_ it happened when my ~ filled completely.
<mjg59> Burgundavia: Hi
<mjg59> Keybuk: So what happens now if usplash times out and gdm doesn't get started?
<Keybuk> mjg59: *shrug* what happens if usplash times out and gives you a blank console instead of the one with the waiting fsck?
<Keybuk> the answer to your question is that after a short period, they will get flipped to vt1 by the usplash init script in the ordinary boot sequence
<iwj> Mithrandir: Sorry, I'm afraid I don't know.
<iwj> And I have to go to the bank now before the queues get insane.  Back after lunch ...
<mjg59> Keybuk: Right, that was what I wanted to know
<mjg59> Keybuk: As long as they do end up back on vt1
<Keybuk> there will always be something on the vt8 under usplash, because that's where notification of fsck ends up
<Keybuk> yes, they either end up in gdm, or on vt1
<Keybuk> I did check that :p
<Keybuk> if gdm times out, *and* the boot sequence stops, then a shell will be on vt8 for some reason
<Keybuk> either spawned from an init script, or by upstart
<cbx33> guys I need some realy help here
<Keybuk> it's ugly, but it's a necessary hack while we need to switch to a text vt before starting gdm
<Keybuk> if we could just start gdm, then usplash could exit because of the vt flip
<cbx33> does any one know how the Xsession.d configs should be closed
<Keybuk> and it could flip to vt1 if it existed normally
<cbx33> are they sent a signal....
<cbx33> ogra asked me to look at my scp-client script as when a user logs out of X, it stays running
<cbx33> but then so does dbus
<cbx33> and gnome-vfs
<cbx33> are they sent a special signal...?
<cbx33> their ppid is 1, so their parent never dies
<Keybuk> they may be sent SIGHUP
<cbx33> Keybuk: nope already tried that
<mvo> Kamion: I have a small fix in the auto-remove view code in synaptic, ok to upload http://people.ubuntu.com/~mvo/tmp/synaptic-view-fix.diff?
<Keybuk> ah, if their ppid is 1, then no, they'll be sent no signal
<cbx33> indeed
<Keybuk> you only get SIGHUP if you're in the foreground process group of a controlling terminal
<cbx33> so how are they asked to die.....or.....more pretenantly...are they actually asked to die?
<Keybuk> (yes, I've read that chapter of Stevens, and made it through to the end <g>)
<Keybuk> I think they just time out and go away on their own
<cbx33> well that's the problem....they don;t ;)
<Keybuk> they usually do for me
<_ion> keybuk: Btw, i quite like the fact that sulogin respawns.
<Keybuk> hmm
<cbx33> Keybuk: these procs have been stable for the last 30mins
<Keybuk> cbx33: here, gnome-vfs-daemon is in the same session as dbus-daemon (session)
<Keybuk> and dbus-daemon is in its own session
<cbx33> hmmm.....
<cbx33> hang on
<cbx33> lemme try a few things
<seanh> Hi - I asked on here a few days ago about a way of automatically 'cleaning up' the home directory of a public user account, i.e. deleting stuff ppl download. PAM was mentioned, and I wondered if someone could expand on how I'd use PAM to achieve this, and why it's better than rsync'ing the homedir?
<cbx33> i was reading s wrong
<cbx33> ps
<cbx33> you're right Keybuk, they are children of x-session-manager
<cbx33> are they going to be sent a SIGHUP?
<cbx33> because I tried handling that in my python script but it doesn't work
<Keybuk> no, they won't be sent that
<Keybuk> ah
<cbx33> will they be sent anythin?
<Keybuk> so x-session-manager has a child called dbus-launch
<cbx33> yes
<Keybuk> that will be sent some kind of signal when the session terminates
<Keybuk> and that dbus-launch will send a signal to dbus-daemon to die (maybe just TERM)
<cbx33> hmm....
<Keybuk> and that will, in turn, send a signal to other processes in its session (maybe HUP)
* Keybuk guesses
<cbx33> http://pastebin.ca/178574
<Mithrandir> iwj: in case somebody gets the same problem: rm-ing extensions.cache from the profile fixed the problem for me
<cbx33> Keybuk: you can see it's a child process
<cbx33> so what happens when x-session-manager get's killed?
<Keybuk> you'll have to look at the code for x-session-manager for that
<Keybuk> nothing automatic
<cbx33> damn 
<pitti> seb128: $ sudo apt-get install yelp-dbgsym -> works!!!11!!
<mvo> pitti: cool!
<pitti> just with 'deb http://people.ubuntu.com/~pitti/ddebs edgy main'
<pitti> time for an announcement, I guess
<slomo_> pitti: now we only need to rebuild the complete archive? ;)
<pitti> slomo_: sure, trivial, isn't it? :)
<slomo_> pitti: would also have the advantage of ssp everywhere ;) i guess we still have some packages that didn't had an upload since ages
<Mithrandir> problem of rebuilding the archive is more the mirror hit than rebuilding the archive..
<Mithrandir> it takes a week or so, but that's not really a problem.
<seb128> pitti: rock on ;)
<seb128> pitti: I tried before but there was no dists yet :)
<pitti> seb128: yeah, I trashed and fixed it several times
<iwj> Mithrandir: Noted, thanks.
<pitti> Mithrandir: I think for edgy we should just rebuild some crucial packages; between beta and final there'll be a fair number of uploads anyawy
<iwj> Good technique: guess what to rm :-).
<seb128> pitti: we will have the whole GNOME with GNOME 2.16.1 anyway :p
<pitti> seb128: nice
<seb128> pitti: should we drop the -dbg packages then?
<pitti> seb128: if we have ubuntu specific changes anyway, and it doesn't make merging much harder, sure
<pitti> seb128: but we shuold just keep them for packages which we can sync
<slomo_> pitti: can't we just let the buildds drop every package named *-dbg?
<pitti> slomo_: that would be inconsistent with source *.dsc and will probably disrupt other thing, too
<pitti> can any native English speaker please take a look at the announcement (for u-devel-announce) at http://paste.ubuntu-nl.org/24232 and suggest some language/grammar/typo/madness corrections?
<ogra> infinity, around ? 
<Fujitsu> That's fine, pitti.
<pitti> Fujitsu: thanks
<Fujitsu> No problem.
<ajmitch> pitti: splendid
<ajmitch> now I just need to be able to ship mono debugging info automatically :)
<Kamion> mvo: yes, that looks OK
<Kamion> (synaptic auto-remove)
<seanh> Anyone know what package I need to have to use the notify-send commnand?
<pitti> seanh: libnotify-bin
<slomo_> seanh: libnotify-bin
<seanh> thanks
<pitti> slomo_: snap!
<_ion> seanh: apt-file :-)
<mvo> Kamion: thanks! is the freeze in effect already? or only after the meeting?
<pitti> seanh: great way to test command-not-found magic :)
<slomo_> pitti: hm in my xchat my response is above your's ;)
* ajmitch hopes he has time to get this f-spot update in
<mvo> command-not-found magic!
<pitti> slomo_: hm, not in mine, darn race conditions :)
<mvo> slomo_: my reality supports pittis view
<ajmitch> slomo_: xchat cheats
* mvo likes his reality, all fluffy
<Kamion> mvo: undefined :-)
<seanh> I'm not on edgy, don't think I have the c-n-f magic
<mvo> Kamion: lol! ok :)
<slomo_> mvo: my reality is more beautiful ;)
<mvo> :-D
<Kamion> my opinion is generally that freezes start at the development team meeting, but I don't know if that agrees with Matt's :-)
<Keybuk> that's certainly true this time
<Keybuk> because Matt's in bed
<Keybuk> and we can't be frozen until he's had coffee
<ogra> heh
<ogra> so its a coffe issue :)
<ogra> someone go and steal his coffee :)
<iwj> Yay!  My fix worked *astonishment*
<iwj> pitti: I have a working ff1.5+yelp+epiphany for breezy.
<iwj> I just need to get rid of the debugging printfs (and file a few bugs upstream).
<iwj> What would you like me to do with them ?
<iwj> The epiphany just needs a rebuild.  yelp needs a bugfix too.
<iwj> A one-line variable initialisation.
<pitti> iwj: rock!
<Hobbsee> pitti: paper!
<pitti> Hobbsee: scissors
<_ion> hammer time
<Hobbsee> heh
* pitti hugs Hobbsee 
<ogra> tsk
* Hobbsee hugs pitti, and drops a large sink on ogra's head
<ajmitch> Hobbsee: be nice to poor ogra 
<Hobbsee> ajmitch: why?
<Hobbsee> he's tsk'ing
<ajmitch> because he's busy working hard 
<pitti> iwj: once firefox itself works fine, you should upload it to jackass; then I'll publish it to jackass' internal archive, so that the reverse dependencies can build against it
<ogra> hey, come on ... i had 5 wonderful hours of sleep after being up 54h in a row :)
<pitti> iwj: then all depending packages (yelp, epiphany, etc.) can be uploaded (they should preferably have a versioned build-dep against f-dev)
<Hobbsee> ogra: ouch :P
<pitti> iwj: once everything is ready, I can release all packages in a single shot, so that we don't break upgrades
<ogra> Hobbsee, well, sleep is for after freeze ;)
<Hobbsee> heh
<_ion> http://www.umop.com/images/rps25.jpg
<iwj> pitti: OK.  But WDYM `upload to jackass' ?
<pitti> iwj: aka security.upload.ubuntu.com
<pitti> iwj: I'm just releasing tbird 1.5 + two handfuls of reverse deps to breezy, I'll see how it goes :)
<pitti> tkamppeter: lol @ 'Debian user's morning gymnastics' :)
<pitti> tkamppeter: (btw, new hplip is not yet uploaded, doko_ kindly agreed to review/upload it soon)
<doko_> pitti: soon ...
<doko_> fighting with OOo and the archive :-/
<janimo> pitti, tkamppeter: hi, is the new foomatic-db still planned?
<pitti> janimo: yes, it is
<tkamppeter> janimo, yes, it only needs to get uploaded. The bug reports I have already switched to "Fix Committed".
<iwj> pitti: Good luck.
<ogra> how do i force usplash to 100% ?
<ogra> would: usplash_write "PROGRESS 100" work ? 
<LeeJunFan> gcc's stack smashing protection probably isn't a good thing to have on by default. :(
<Fujitsu> Why not, LeeJunFan?
<LeeJunFan> you can't build most kernels with it on.
<LeeJunFan> http://lists-archives.org/linux-kernel/973030-2-6-17-mm5-busted-toolchain-usr-klibc-exec_l-c-59-undefined-reference-to-__stack_chk_fail.html
<zul> LeeJunFan: thats why the ubuntu kernels use -fno-stack-protector
<LeeJunFan> zul: yeah, so I gathered now.
<bddebian> Howdy folks
<Yagisan> can someone please confirm this bug #61663
<Ubugtu> Malone bug 61663 in linux-source-2.6.17 "Displays "ILLEGAL EXTENDED X86 OPCODE" on VT1 during boot" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61663
<Fujitsu> Yagisan, I'd say it was only AMD64.
<Yagisan> Fujitsu, you are probably right, but it concerns me
<pitti> Yagisan: yup, amd64+nvidia
<Yagisan> pitti, thanks. thats my combination too
<pitti> Yagisan: it's a dup of bug 60135
<Ubugtu> Malone bug 60135 in usplash "does not work at all on amd64 with nvidia card" [Medium,Confirmed]  http://launchpad.net/bugs/60135
<Yagisan> ah crap. sorry for the dupe
<pitti> no problem
<iwj> pitti: breezy-security, then, not breezy-updates, I take it.
<pitti> iwj: yes, since it fixes two tons of security bugs
<pitti> and -updates does not allow us staging
<iwj> And -sa (include the .orig.tar.gz) ?
<iwj> Staging is really necessary here.
<pitti> iwj: yes, you'll need that
<iwj> FYI, Mozilla 353641 has my report about the main reason why it hasn't been working.
<Ubugtu> Mozilla bug 353641 in String "ToLowerCase assumes iterators comparable but old string ones aren't" [Normal,Unconfirmed]  http://bugzilla.mozilla.org/show_bug.cgi?id=353641
<iwj> It's a sad sad tale.
<pitti> uh
<pitti> argh, who broke mplayer? *sigh*
<iwj> And I'm pretty sure the fix isn't right but I think it's safe and will make the symptoms go away.
<Nafallo> pitti: fix uploaded
* pitti hugs Nafallo 
* Nafallo hugs pitti back :-)
<pitti> seb128: the last time I claimed that totem-gst would work I must have used totem-xine accidentally; -gst is still unusable for me :(
<slomo_> pitti: what's broken with totem-gst for you?
<pitti> slomo_: audio lags behind video for one or two seconds
<pitti> format-wise it's pretty good
<slomo_> pitti: which container, audio and video format is this?
<pitti> (format -> codeds)
<ogra> Kamion, i know youre a bit familiar with portmap ... and idea about bug 61668 ?
<Ubugtu> Malone bug 61668 in portmap "Building LTSP chroot stops during portmap installation" [Untriaged,Confirmed]  http://launchpad.net/bugs/61668
<ogra> it seems to run a very long lasting netstat test from the postinst
<slomo_> pitti: you might want to try the gst-ffmpeg cvs snapshot i have locally... there were many timestamp (and other fixes)
<pitti> slomo_: AVI MPEG4, mp3 audio
<slomo_> pitti: http://slomosnail.de/~slomo/temp/libgstffmpeg.so  put this in /usr/lib/gstreamer0.10 and retry :)
<pitti> slomo_: is that amd64?
<slomo_> pitti: no... sorry
<ogra> s/and/any/
<Kamion> ogra: actually, I don't really know portmap at all, I'm afraid
<slomo_> pitti: cvs -z3 -d:ext:developername@cvs.freedesktop.org:/cvs/gstreamer co gst-ffmpeg   if you want to build it yourself
<ogra> ok
<Kamion> I think I uploaded it once to fix something I did understand
<slomo_> pitti: otherwise... can you upload the video somewhere? :)
<pitti> slomo_: will try it at some time
<ogra> good, i'll try to find it out myself then ...
<pitti> slomo_: erm, well, it's huge, and it's copyrighted, too (ripped from a friend's DVD)
<jdong> Kamion: is it normal for a package to stay in "needs building" for nearly 24 hours?
<jdong> Kamion: https://launchpad.net/+builds/+build/247502
<Kamion> jdong: -> infinity
<madduck> does anyone know Dennis Kaarsemaker ?
<_ion> He's Seveas.
<madduck> thx.
<madduck> he won the Nokia 770 from the calibre.ie project survey, but he's not responded... :/
<Nafallo> kewl
<Nafallo> :-)
<madduck> I hope he replies in time. I hate it when the second draw get the price because someone is AFK
<_ion> *cough* In that case, i'm him. ;-)
<madduck> hehe
<mjg59> madduck: He's generally active, but not so often during the day
<madduck> mjg59: ok, i hope he answers to the mail.
<madduck> it's been almost a week now i think.
<madduck> but i guess we'll just wait, given that he's known by you guys..
<elmo> madduck: he's been at EuroOScon recently and had limited connectivity
<madduck> we'll wait. thanks guys.
<mjg59> Kamion: So there's a minor issue with usplash right now
<mjg59> Kamion: It seems that some cards don't bother to implement palette setting in 256 colour vesa modes
<mjg59> Kamion: So it may be necessary to add 16 bit support and use that by default, then fall back to 256 colour if we can't set that mode
<mjg59> Which obviously means a certain amount of pain
<_ion> It would also be nice if usplash fell back from a failing resolution to 640x400 or so.
<mjg59> _ion: 640x400 isn't a vesa mode, so no
<mjg59> I don't know what you mean by a "failing resolution"
<_ion> E.g. here usplash.conf defaults to 1024x768 and usplash isn't able to initialize the screen in that resolution for some reason. I tried to debug it a few days ago, but didn't have success.
<mjg59> _ion: On what hardware?
<_ion> 01:00.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4800 SE]  (rev a1)
<mjg59> On x86?
<_ion> Yes.
<mjg59> Ok
<mjg59> And if you use a different resolution it works?
<_ion> I manually changed it to 800x600 and it worked fine.
<mjg59> Hm
<gnomefreak> mine works with 1024x768 but only on shutdown
<_ion> gnomefreak: Try update-initramfs -u
<_ion> gnomefreak: AFAIK usplash initially reads usplash.conf from initramfs, and from /etc on shutdown.
<gnomefreak> ah
<gnomefreak> its running now ty
<gnomefreak> ok brb reboot see if it works
<doko_> tkamppeter, pitti: I don't see UVF exceptions for foo2zjs and foomatic-filters. Did I just overlook these?
<iwj> Is there an reasonably easy way to get a copy of a .diff.gz which has expired from ftp.debian.org ?
<pitti> iwj: snapshot.debian.net?
<pitti> iwj: it usually works quite fine nowadays
<iwj> Thanks.  I thought something like that existed but I forgot the domain.  I should have zone dumped debian.org :-).
<Riddell> dholbach: are you planning to package the docs?
<tkamppeter> doko_, you should have gotten both by e-mail now (doko@ubuntu.com) -> biff.
<dholbach> Riddell: what are you referring to?
<Riddell> dholbach: ubuntu-docs
<Riddell> dholbach: doc freeze is today
<dholbach> ok
<dholbach> I'll talk to some of the folks and ask them beforehand
<dholbach> but yeah, I can do it
<Riddell> dholbach: could we do it as 1 source package?
<doko_> tkamppeter: ok, but I don't see the exception for foo2zjs
<dholbach> Riddell: I would prefer to do that at some other time - surely it needs buildsystem/packaging changes?
<Riddell> dholbach: yes, it would
<gnomefreak> _ion: ty it worked :)
<dholbach> Riddell: I'm too busy to do that today
<dholbach> Riddell: can't we postpone that idea?
<Riddell> Kamion: scroll view added to mount page for kde ubiquity http://kubuntu.org/~jriddell/bzr/ubiquity/ubuntu/
<Riddell> dholbach: ok
<dholbach> Riddell: thanks
<Riddell> dholbach: so I'll package the kubuntu docs then
<dholbach> ok
<ogra> Riddell, is the menu-xdg dep in kdelibs gnoe ? 
<ogra> *gone
<Riddell> ogra: no, I can do that now
<ogra> would be nice, thanks
<tkamppeter> doko_: Current foo2zjs is from January, so it is REALLY old. The upstream package has a lot of changes, especially
<tkamppeter> - it fixes the UDEV rules so that the automatic firmware loading for the HP LaserJet 1000, 1005, 1018, and 1020 really takes place.
<doko_> tkamppeter: I agree, I see no reason why we should not include it. but formally we need the exception from mdz or Kamion 
<tkamppeter> - It adds support for many printers including LJ 1018, 1020, 1022
<tkamppeter> Kamion, MDZ, WDYT about the foo2zjs update?
<mdz> tkamppeter: not enough information to say; please email as usual
<mdz> tkamppeter: we need to weigh the risk of all the other changes vs. the changes you watn
<tkamppeter> mdz, I have e-mailed all UVF ERs to you yesterday (and before).
<mdz> tkamppeter: I have one yesterday and one today
<tkamppeter> doko_: Thanks for tellin that Kamion also decides about UVF ERs, I have forwarded all to him now.
<tkamppeter> mdz: which packages?
<tkamppeter> Kamion: I have forwarded all my UVF ERs to you now -> biff.
<doko_> tkamppeter, mdz: I uploaded all but foo2zjs
<mdz> tkamppeter: after the meeting
<tkamppeter> Thanks doko_, so it seems as I have to close some bugs.
<tkamppeter> doko_, Kamion, mdz, pitti: I have tested foo2zjs on the LaserJet 1020, 1022, and Color LaserJet 2600n, all are working correctly.
<mdz> tkamppeter: the meeting is in progress in #ubuntu-meeting
<tkamppeter> The 1022 was used with HPIJS before and this did not really work, too slow and half of the files did not print at all.
<pitti> mvo: is there a bug about the u-desktop dependency handling already or shall I create one?
<mvo> pitti: I think there is no bug yet, so feel free :)
* pitti creates
<mvo> pitti: make sure to subscribe the livefs build masters as well :)
<pitti> yep
<Kamion> Riddell: thanks, will check it over
<Kamion> Riddell: please use UNRELEASED as the distribution in ubiquity changelogs unless you've actually uploaded it; it makes it a lot less confusing
<Riddell> Kamion: ok
<Kamion> that's quite a common convention, particularly now that dch does it by default
<Kamion> (though my uch script overrides that to edgy, slightly unfortunately - dunno about yours
<Kamion> )
<pitti> mvo: done (bug 61684)
<Ubugtu> Malone bug 61684 in Ubuntu "Removing any u-desktop depdencency marks all other packages for auto-removal" [Untriaged,Confirmed]  http://launchpad.net/bugs/61684
<mvo> pitti: thanks, what do you think priority "high"?
<ogra> Riddell, thanks so much :)
<pitti> mvo: for me at least, I find it highly annoying, but maybe it's not for other people
<mvo> the questions was high or critical ;)
<pitti> mvo: but it has the milestone tag now, so it'll be on Matt's monitor
<pitti> mvo: heh :) high then
* pitti changes
<mvo> thanks
<pitti> mdz: I added a few milestone tags to bugs which I consider beta critical
<neo_> Hi@ all! I've got a problem, am I in the right channel to ask for a way to track my error down?
<neo_> It is very strange... when I'm hitting ctrl alt Fx , I don't get a console...all I see is a black screen... is there any configuration file or hint you could tell me?
<ivoks> neo_: right channel is https://launchpad.net/malone
<ivoks> neo_: i'm sure you'll find some duplicates
<neo_> thank you very much!!! I'll go a take a look... bye
<Kamion> mdz: (for after the meeting) ok to upload Riddell's ubiquity branch? it adds scrolling to the KDE mountpoints page, which is something I've already done for GTK and is needed if you have a lot of partitions to stop the UI resizing itself to be bigger than the screen
<Kamion> Riddell: merged, thanks
<janimo> Gloubiboulga: the redhat tool for printer GUI seems to work ok, so we'll have add printer functionality in edgy
<Gloubiboulga> janimo, great :)
<wiz> Will python 2.5 be avaiable in Edgy?
<dholbach> wiz: it is
<dholbach> wiz:  edgy-changes@lists.ubuntu.com
<wiz> niisssse..... (8
<Gloubiboulga> janimo, do you have an idea why the i386 alternate iso is still oversized?
<janimo> Gloubiboulga: no, I took out at-spi and related gnome bits last week, but looks like it grew back
<janimo> I'll look at the list
<janimo> Gloubiboulga: python-gnome2 is in
<janimo> wonder what put it in and when
<janimo> Gloubiboulga: hmm, it may be that recommends are now installe dby default?
<janimo> we'll have to ask mvo
<Gloubiboulga> ah, yes, maybe
<janimo> python-gnpome2 is recommended only by update-manager (which uses gconf python if available)
<mvo> hello janimo! I'm in a meeting right now
<janimo> so if handling of recommends changed
<mvo> can we talk after it?
<janimo> mvo I know, no hurry sure :)
<Kamion> recommends should only be installed by default for stuff in Section: metapackages
<mvo> thanks
<mvo> otherwise what Kamion said
<janimo> Kamion: hmm then it is something else, as this is Section:gnome
<Kamion> janimo: ship:python-gnome2                  | gnome-python                    | ldm
<janimo> Kamion: ok, thanks, seems like I don't know what I explcitelly aded to ship :(
<Kamion> janimo: i.e. ldm Depends: python-gnome2 and is in your ship seed
<janimo> I remember now, it is needed by ldm.
<janimo> hmm one more resason to split g-python. I think that ldm only uses the canvas
<Gloubiboulga> janimo, cpufreq and cpu-freq are two different plugins
<Kamion> pitti: huh, I thought I'd already closed those oem-config bugs, evidently not
<Kamion> anyway, closing
<lastnode_> imbrandon, you around, mate?
<Gloubiboulga> janimo, but they do the same thing I guess, not sure that we need to have both in the archive
<pitti> Kamion: yay, one less :)
<imbrandon> lastnode_: give me just a few minutes bro
<imbrandon> lastnode_: reading in on a meeting atm
<lastnode_> imbrandon, sure, we've just got all three of us in #upstream, so ready for a brief chat whenever you are
<imbrandon> lastnode_: ok
<mjg59> crimsun: I don't seem to be getting any audio on my Intel iMac...
<janimo> Gloubiboulga: then it may be that the latter is better
<jdong> hey, anyone know if the xvid codec in our mencoder is multithreading-capable?
<ogra> fabbione, is there a special key combo in sparc so i could see a bit more stuff in the bootsequence ? 
<jdong> it seems to take the threads argument, but even at 8 threads it sticks to only 1 CPU's worth of load
<ogra> currently its showing an hourglass and restarts over and over 
<Nafallo> jdong: -> slomo_ :-)
<fabbione> ogra: uh? hourglass???
<ogra> i'd like to look behind that screen
<fabbione> ogra: i have never seen stuff like that..
<ogra> yes and a little salamander as mouse pointer
<fabbione> are you sure that the thinclient is a sparc CPU?
<ogra> looks a bit like booting an apple
<fabbione> normal sparc goes to OBP
<slomo_> jdong: no idea... is our xvid capable to do so? ;)
<fabbione> that's like a text promp
<fabbione> no, no idea about that
<fabbione> never seen anything like that
<ogra> hmm, probably they have a non standard thing 
<kmr> kamion: thanks for the update to imagemagick, appreciated!
<ogra> its only a thin client ... not really something thats usual sparc
<fabbione> ogra: if they have a non-standard thingy, you will need to read on that
<ogra> right
<jdong> slomo_: i don't know, you're the expert :P
<Kamion> kmr: no worries
<ogra> i was hoping for a key combo like apple has to get into the open firmware prompt
<Kamion> syncs are easy, once investigated ;)
<fabbione> ogra: stop+a
<fabbione> ogra: that's on normal sparc
<ogra> i know people booted these clients off the d-i netboot image
<fabbione> i don't know that thin client at all
<fabbione> sorry
<Keybuk> ogra: pancake-waffle-butterfly-f
<fabbione> i don't use these kind of toys..
<fabbione> only *REAL* hardware
<kmr> Kamion: very good, as a debian developer I tried to help a bit with the underlying work to simply the decision to sync
<dholbach> can somebody give back libgnomeuimm2.6?
<ogra> Keybuk, i find the pancake key, but there is no butterfly one ...
<kmr> is there a MOTU channel or other means to draw attention to a bug I filed about a universe package?
<Kamion> kmr: yeah, that is definitely helpful, thanks
<ogra> fabbione, its a request that we suport them in out ubuntu ltsp ... if it doesnt work thats not the end of the world ...
<Kamion> kmr: #ubuntu-motu
<ogra> but the desgn is neat, i'd like to use the HW on my desk
<fabbione> ogra: yeah. just kidding.. i don't know what they are... sorry
<kmr> Kamion: very end of the work very appreciated, thanks for the channel link
<ogra> fabbione, apparently they work with a binary image sun offers for installation on linux servers
<slomo_> jdong: i don't know :P
<fabbione> ogra: can you take it to MountainView?
<kmr> s/very end/your end/
<jdong> slomo_: I'm playing with it...
<ogra> so worst case i could write a downloader package for it that installs and configures it
<ogra> fabbione, uh ... i dont like to travel qith much HW to the US ...
<ogra> but if whiprush is coming *he* can bring one i guess
<fabbione> ogra: ok. i understand that.
<ogra> whiprush, ping ? 
<ogra> he has plenty of them
<whiprush> ogra: pong
<ogra> see above
<ogra> whiprush, youre coming to mountainview, right ? 
<whiprush> yeah
<whiprush> I'll bring some
<ogra> could you bring one of the sunrays ?
<ogra> yeah !
<ogra> thanks a lot :)
<whiprush> I'll bring as many as I can
<jdong> slomo_: grr, needs CVS or 1.2.x builds :-(
<fabbione> whiprush: i don't need a dedicated one.. jsut to look what we can do for them
<desrt> good morning, hax0rs
<jdong> slomo_: and I'm guessing introducing a newer xvid into edgy at this point is a bad idea? ;-)
<slomo_> jdong: yes... edgy+1 please :)
<jdong> slomo_: hehe, we're already dreaming about edgy+1 :)
<fsmw> hi all!
<slomo_> jdong: always :)
<fsmw> is there a way to make a mirror for an specific dist (eg dapper), instead mirroring the whole repo?
<Nafallo> debmirror should work, but this channel is for development. #ubuntu is for support.
<Nafallo> fsmw: ^
<ogra> dholbach, did you say you would be on the "evo doesnt jump to next message after delete" bug ? its still here 
* ogra thinks that justifies for RC
* fabbione can finally upgrade to edgy
<dholbach> ogra: it's reported upstream
<fabbione> these meetings are taking too long
<ogra> dholbach, with high importance so we have a chance to see a fix in edgy ? 
<dholbach> ogra: i hope we get a fix too
<Kamion> mdz: oh, heh, that progress-info-jumps-around bug turned out to be really easy following jdahlin's hint: make it ellipsize, make it expand and fill, make the surrounding hbox fill but not expand, blam, progress info label is magically locked to the size of the progress bar above
<ogra> i'll switch to thunderbird if we dont ... it slows me down to much :/
<ogra> i can bear a lot annoyances, especially in evo ... but well ... at some point it gets to much ...
* ogra stops ranting now :)
<dholbach> ogra: thanks :)
* fabbione goes offline for dist-upgrade
<Nafallo> hehe
* pitti hugs dholbach and finally looks into the opal FTBFS
<pitti> yay silly objcopy
* dholbach hugs pitti
<dholbach> see you later!
<jdong> infinity: poke
<fabbione> mvo, iwj: ping?
<Riddell> pitti: any chance of a language pack update for beta?  getting the kde stock strings fixed would be great
<pitti> Riddell: if Mithrandir and mdz are fine with it, sure
<fabbione> hem.. unping
<pitti> Riddell: oh, dear, the daily langpacks are ages old, there must be something wrong; I'll investigate shortly
<Riddell> pitti: let me know if you fix that and I'll test them out to confirm the kde issue is fixed
<Nafallo> pitti: oh! I thought that was intentional or something. I could have told you days ago. Will do next time :-).
<mdz> pitti: yes, I think an update would be appropriate
<mdz> Kamion: oh good
<mdz> Kamion: scrolling for kde mountpoints -> OK with me
<mdz> tkamppeter: ok, so regarding your freeze exception requests
<carlos> Riddell: hi, katapult is also affected with https://launchpad.net/distros/ubuntu/+source/kde-i18n/+bug/60049
<Ubugtu> Malone bug 60049 in kde-i18n "Import of translations for KDE's desktop-* failed" [Untriaged,Confirmed]  
<Kamion> ogra: bug 61688 fixed
<Ubugtu> Malone bug 61688 in lsb "[Edgy]  "unbound variable" in /etc/lsb-base-logging.sh" [Untriaged,Fix released]  http://launchpad.net/bugs/61688
<pitti> carlos: do you know why the edgy tarballs in your rookery home are so old?
<carlos> ?
<pitti> carlos: likewise with dapper&co
<carlos> those are being updated every day...
<pitti> carlos: latest version is from Sept 12
<carlos> let me check whether I did a mistake...
<pitti> carlos: and edgy is Sept 10
<carlos> pitti: ... I did a mistake... :-(
<carlos> I was pushing them to the wrong directory...
<carlos> let me fix it
<carlos> pitti: fixed
<pitti> carlos: thanks
<carlos> tomorrow the push should work as expected
<pitti> ah, so we don't have current tarballs on rookery now?
<carlos> pitti: edgy is  another thing, seems like I forgot to move it back to daily snapshots...
<pitti> well, tomorrow should be fine
<carlos> pitti: we do
<carlos> I mean that tomorrow, the updates will go to the right place
<ogra> Kamion, thanks :)
<pitti> dholbach: gar, opal debian/rules makes me wanting nasty things to it
<pitti> dholbach: I'll fix pkg-create-dbgsym to cope with it, but it won't change the fact that opal's -dbg deb is empty
<dholbach> pitti: that's ok with me :)
* dholbach hugs pitti
<dholbach> pitti: thanks a lot
<pitti> I mean, I can fix opal to just not build a -dbg at all, since it is useless anyway
<dholbach> as you like it
<dholbach> I had no chance to talk to Kilian about it yet
<siretart> is main already frozen for beta release?
<fabbione> Kamion,  mdz: do we need to start to ask permssion to uploads pkgs in main?
<siretart> I'd like to upload a new xine
<fabbione> pitti: ping?
<fabbione> doko: ping
<pitti> fabbione: hey dude
<siretart> huhu fabbione, hi pitti 
<fabbione> pitti: there is an upgrade bug od cupsys from dapper to edgy. It's a missing C/R somewhere.
<mdz> fabbione: I was about to announce the freeze, but uploads are not locked down yet
<fabbione> pitti: you should probably take a look at it
<pitti> fabbione: thanks for spotting, will do
<pitti> fabbione: do you have the output somewhere?
<mdz> probably won't be until tomorrow, or perhaps even monday depending on how things go
<zyga> pitti: whoah for debug magick!
<fabbione> mdz: ok, i have a bug fix for mdadm upgrading from dapper. It's just the way the shell is called. nothing more
<pitti> zyga: :)
<fabbione> pitti: no sorry.. console-setup did trash my X session during the dist-upgrade
<fabbione> pitti: had to kill X to get keyboard back
<mdz> fabbione: sounds appropriate for beta.  set the milestone on the bug and go ahead
<fabbione> mdz: no bug.. i just found it myself
<fabbione> mdz: i was dist upgrading my laptop since i didn't get that far before the meeting
<doko_> fabbione: pong
<fabbione> doko: are there known issues with python2.4-minimal? it gave me errors dist upgrading from dapper
<tkamppeter> mdz, I was for dinner, I am back, you wanted to tell me something about the UVF ERs
<mdz> tkamppeter: you asked which ones I had
<mdz> tkamppeter: I have only one outstanding, which is foo2zjs received yesterday
<fabbione> doko: it seems like it's a missing dependency. It doesn't fail on a fully upgraded system
<fabbione> mdz: mdadm fix uploaded.
* fabbione reboots into .17
<fabbione> brb
<tkamppeter> mdz, so foomatic-db, foomatic-filters, foomatic-db-hpijs, and HPLIP are all approved and uploaded?
<fabbione> rodarvus: ping?
<mdz> tkamppeter: I have replied to all of the emails I have received from you
<mdz> tkamppeter: I do not upload the packages for you; pitti can help with that
<fabbione> well this ride wan't too bad
<fabbione> mdz: we should probably create a meta bug in LP for dapper -> edgy upgrades
<fabbione> mdz: there are a few.. not many
<tkamppeter> Riddell, Kamion, was it someone of you talking with me about a printing problem with KDE?
<pitti> tkamppeter: yes, they are
<pitti> mdz: ^ (FYI)
<mdz> fabbione: a tag would be better
<mdz> fabbione: also they should have the beta milestone
<mdz> since beta will be an upgrade target
<fabbione> mdz: ok
<fabbione> hmm Frank is already offline
<fabbione> what package provides themes for usplash?
<fabbione> ubuntu-artwork?
<fabbione> oh nevermind there is already a bug filed
<Nafallo> doko: ping :-)
<lucas> the ruby interpreter still segfaults on powerpc (on the buildd at least)
<lucas> I've already mailed infinity twice about it, and once ubuntu-devel. what else should I do, given that I don't have access to a powerpc system ?
<fabbione> lucas: coordinate with Riddel
<fabbione> he is working on it
<lucas> ok
<pitti> Mithrandir, mdz: permission to upload a new pkg-create-dbgsym which fixes the opal FTBFS?
<mdz> pitti: certainly
<fabbione> hmm
<fabbione> mvo is offline too...
<fabbione> mdz: one question.. all these hacks we are doing to distupgrade from dapper to edgy, like installing new dpkg/apt before the rest of the world..
<fabbione> how are we going to reflect that in server tools?
* fabbione takes a break and will rethink about it for a bit
<pitti> dholbach: pkg-create-dbgsym 0.14 uploaded, right in time for this cron.daily; so in about an hour we can ask for a give-back of opal
* dholbach hugs pitti
* pitti -> dinner, bbl
<dholbach> and after that a give back of ekiga
<dholbach> pitti: enjoy
<pitti> dholbach: bah, does that fail as well?
<dholbach> it requires opal
<pitti> ah
<dholbach> opal and pwlib are ... weird :)
<pitti> you bet...
<tkamppeter> mdz, I do not ask you to upload anything, I have only asked for the current state. Uploads were done by pitti, and doko_.
<pitti> tkamppeter: (FYI, you can check this on https://launchpad.net/distros/ubuntu/+source/foomatic-db and similar)
<tkamppeter> Riddell: ping
<tkamppeter> Kamion: ping
<ajmitch> morning all
* jdong prepares to summon infinity.....
* jdong draws Circles on the floor and sprinkles salt
<ajmitch> jdong: 5am in melbourne, you'd be lucky
* jdong puts 5 candles in Circle and draws lines
<jdong> infinity: ARRRISE from your eternal sleep!
<Treenaks> infernal sleep?
<micahcowan> if he arose from it, it could hardly be eternal, now could it? :p
<jdong> anyone else have a good explanation why a trivially small package would wait 24 hours and still await building? :P
<jdong> other than karma's trying to punish me for my dyslexic QA?
<slomo_> jdong: openoffice and build priorities ;)
<jdong> slomo_: grr, openoffice
<jdong> you guys shoved like 3 through within the past 24 hours :P
<Nafallo> no, there where more than 3 :-)
<tseng> it isnt really " you guys "
* jdong gets more salt and candles
<tseng> infinity: could you look at "chroot problem" on beagle 0.2.9-1ubuntu2?
<tseng> infinity: amd64, ia64, ppc
<tseng> infinity: please
* jdong recommends salt-and-candles approach :)
<tseng> whatever that means
<cbx33> guys...how do I go about installing the smp kernel?
<micahcowan> micah prefers the lim[x->5]  1/(x-5) approach. There! Now you're guaranteed to find infinity.
<micahcowan> speaking of which: http://immense-world.blogspot.com/2006/09/mathematics-genius.html
<Burgwork> micahcowan, that is kind of off topic
<micahcowan> Well, it's at least heading in that direction, yes. My apologies.
<Burgwork> cbx33, this is -devel, not user support. If you use x86, smp support is built into the standard kernel and enabled upon cpu detection
<Nafallo> Burgwork: not just x86 fwiw :-)
<cbx33> sorry Burgwork 
<Burgwork> Nafallo, yes, but if you have big iron, you need specific kernels for dapper
<Nafallo> infinity: where is erlang-nox? :-)
<Nafallo> Burgwork: that would be x86 ;-). amd64 and friend have the SMP-stuff as well :-)
<Nafallo> Burgwork: that's more my point :-)
<Kamion> tkamppeter: yes?
<fabbione> good night everybody
<fabbione> cya tomorrw
<Nafallo> Kamion: maybe you know where erlang-nox is? should have been built after the erlang sync and ejabberd needs it :-).
<mdz> pitti: do the ddebs have proper dependencies?
<Kamion> Nafallo: version number?
<Nafallo> Kamion: 1:11.b.1-1
<Kamion> Nafallo: there is no package called erlang-nox in the archive
<Kamion> ah, it's in NEW
<pitti> mdz: FSVO 'proper', yes; they depend on the exact version of the corresponding deb and don't have any other dependencies
<Kamion> Nafallo: https://launchpad.net/distros/ubuntu/edgy/+queue for future reference
<Nafallo> Kamion: ah! care to wave it through so that I can close the "please update ejabberd"-bug? :-)
<mdz> pitti: I mean, e.g. where a package depends on libraries, does it depend/recommend/suggest the corresponding debug symbols?
<pitti> mdz: ah; no, it doesn't
<mdz> I think it's appropriate to at least suggest all of the symbols, and in some cases recommend
* Nafallo bookmarks
<Kamion> Nafallo: guess what I was doing right after telling you it was in NEW ...
<pitti> mdz: I was going to handle that in apport-retrace
<mdz> pitti: hmm, interesting
<Nafallo> Kamion: thanks! :-)
<Kamion> you're welcome
<pitti> mdz: suggests: would be appropriate, though, I'll TODO that
<pitti> mdz: the more important thing is that I have to Conflicts: to a -dbg, if present
<BenC> did lp just die?
<tseng> BenC: works for me
<ajmitch> gave me issues a few minutes ago
<BenC> working now it seems
<BenC> went away for about 1 minute
<mdz> tkamppeter: btw, it looks like your uploads used an invalid email address in the .changes file.  If you use a correct email address (a confirmed email address in launchpad) you will receive notification when your uploads are accepted
<tkamppeter> mdz, I did not do any upload. pitti and doko_ did them. pitti told me that one needs special permissions for uploading.
<tkamppeter> Kamion, did you have a problem of printing with KDE? What is exactly your problem?
<mdz> tkamppeter: we often use "upload" to refer to the .changes and associated files which are uploaded
<mdz> tkamppeter: what I mean is that if you prepare the .changes correctly, and then give it to pitti or doko, you can still receive a notification when it is processed
<Kamion> tkamppeter: I don't use KDE, so no, that wasn't me
<mdz> tkamppeter: usually this is done by setting the DEBEMAIL environment variable
<mdz> tkamppeter: it was Riddell who mentioned a KDE printing issue during the meeting earlier
<doko_> mdz: I didn't see  an approval for foo2zjs
<Kamion> mdz: bug 61723 often happens to me when I run setupcon from an X terminal (X apparently gets horribly confused by the invasion of /dev/console and throws a wobbly), so if that's happening during upgrade, I think I should beta it
<Ubugtu> Malone bug 61723 in console-setup "[PPC]  distupgrade from dapper to edgy kills X keyboard" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61723
<tkamppeter> for example foo2zjs_20060625dfsg-2_i386.changes? Do I have to edit the "Changed-by:" field in it so that I get notification?
<mdz> Kamion: agreed
<mdz> Kamion: I have an idle ppc here if you need help testing
<mdz> I think it may even have a fresh dapper on it
<Kamion> not for that particular bug, but it may be useful for other things
<tkamppeter> Thanks, mdz, have added this variable in my .bashrc
<tkamppeter> Riddell, are you here?
<mdz> tkamppeter: when you run dpkg-buildpackage, it will put $DEBEMAIL in the right place
<tkamppeter> doko_, pitti: mdz has approved the update of foo2zjs.
<tkamppeter> mdz, I will see it on my next package build.
<pitti> tkamppeter: ah, nice
<doko_> tkamppeter: uploaded
<agutierr> I have a problem remastering a ubuntu cd: after the isolinux load and search the cdrom drivers, I have the next error: "The CD available is not a Ubuntu cd" :?
<desrt> so uh.  the ATI thing is cute.
<desrt> i wonder how we're gonna deal with it.
<BenC> deal with what?
<HiddenWolf> BenC: fglrx now comes in a -legacy edition too
<HiddenWolf> desrt: -legacy will only be for cards that are well supported by open drivers, so it shouldn't be too big a deal.
<desrt> ya.  time to relive the madwifi thing
<desrt> except backwards
<desrt> the new ati drivers (fglrx) drop support for a bunch of cards
<Burgwork> desrt, aren't closed and semi closed drivers great?
<desrt> heh.
<desrt> i guess we'll have fglrx and fglrx_og (old generation)
<Yagisan> pitti, you here ?
<desrt> with _og only enabled for the cards that _require_ it
<HiddenWolf> Burgwork: I'm secretly hoping they'll open up the old stuff at least partially. Call me an optimist.
<HiddenWolf> desrt: og would only be for pre-9250, which all work fine with open drivers already, so there is no real _need_ for those closed drivers. It's just the upgrade that should be handled.
<desrt> fglrx works better than dri in most cases
<Yagisan> pitti, O_O -> jamie@doomguy:~/COIT12170_Data_Comms$ *** stack smashing detected ***: /usr/lib/openoffice/program/soffice.bin terminated
<HiddenWolf> desrt: but it's open, so you can debug it and fix it and backtrace it. :)
<KaiL> Riddell, amarok 1.4.3 is searching a "libvisual-0.4-0", which isn't anywhere :(
<JamieBE> Hello, could someone with javascript know-how answer me a really quick question?
<JamieBE> ...Please
<beuno> sure
<beuno> I'll give it a try
<sharms> !offtopic
<gnomefreak> JamieBE: support questions should be in #ubuntu, #ubuntu+1, #kubuntu, #xubuntu. this channel should be used only for development topics. (im guessing this is what sharms meant by !offtopic) :)
<beuno> JamieBE: you can private me if you want to
<gnomefreak> ubotu test
<gnomefreak> !test
<JamieBE> OK, This is a little complicated. I have an ubuntu app - Lodju which is now quite outdated and a little unsupported. What this app does is created HTML pages for information and images you feed it to create a web gallery. It uses python variables within HTML templates that came packaged with it to dynamically generate the complete HTML product. The problem is that in the HTML thumbnails page the code basically produces: Show image one. Show Image two
<JamieBE> . Show Image three...all next to eachother and so on... What I want is for 4 columns on images (as I have different resolutions of thumbnails) to sit neatly within a valign="center" table cell. What i can to is to call a new table with tr and td for each image, and then on every multiple of 4 call a <br clear="all"> but I need to generate this as the HTML is build by the app. Hence the javascript idea. I need something along the lines in pseudo code 
<JamieBE> of: <script = javascript> variable of integer called "Num1". Set Num1 to %python.value. If Num1 = multiple of 4 (4th table generated) then javascript.write <br clear="all"></script>
<gnomefreak> :(
<dholbach> can somebody please give back libgnomeuimm2.6?
* beuno checks his pockets
<tkamppeter> doko_, thanks for the upload, I am closing some more bugs now.
<JamieBE> In Javascript is there a way of saying "If this number is a multiple of 4 then..."
<Kamion> use the % operator, as in many other languages
<Kamion> (number % 4) will be zero if number is a multiple of 4
* Kamion -> bed, night all
<JamieBE> Night kamion
<mdz> doko: when did oo.o start using bzip2?  I don't see it in the changelog
<Riddell> mdz: are we frozen yet?
<Nafallo> Riddell: mail on ubuntu-devel-announce :-)
<Nafallo> that's a yes btw ;-)
<beuno> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-September/000196.html
<mdz> Riddell: right on schedule
<mdz> Riddell: though we're a little bit slushy
<mdz> I still wouldn't recommend any swimming
<Riddell> mdz: right, I have a slightly altered usplash from kwwii to upload and kubuntu-docs if that's ok
<mdz> Riddell: yep
#ubuntu-devel 2006-09-22
<ajmitch> hi mdz 
<mdz> hi
<jdub> untz untz untz
<gnomefreak> when was gksudo symlinked to gksu?
<gnomefreak> last i remember gksu = "su password" and gksudo "sudo password"
<jdub> infinity, pitti: WOOHOOO!
<pitti> jdub: :)
<Riddell> mdz: I'd like to upload gs-esp to fix a failed compile, and I'd also like to move kdm to start at the same init level as gdm which is a regretion from dapper
<jdong> infinity: poke......
<crimsun> mjg59: I have some sigmatel diffs enqueued that I need to merge, bumping their priority
<crimsun> (sorry, life being a bit cumbersome atm)
<leonel> Hello  Is there  a release  date for Edgy release   on the wiki  says    around  october 
<crimsun> http://wiki.ubuntu.com/EdgyReleaseSchedule
<jdub> EdgyReleaseSchedule on the wiki
<leonel> thanks  
<bddebian> Howdy folks
<mdz> Riddell: both sound fine
<tritium> hi bddebian 
<bddebian> tritium!!
<bddebian> How you been man?
<tritium> dude, I had kidney stones :(
<mdz> Riddell: just be conservative until uploads are locked down for real
<bddebian> tritium: Oh man, that sucks :-(
<tritium> yeah, but I was happy to see upon my recovery that mythtv 0.20 is in edgy ;)
<bddebian> Heh
<tritium> I assume you had a part in that, so thanks :)
<bddebian> Nah, I have no part in anything :-)
<tritium> Don't give me that!  Not when I'm on bed rest.
<bddebian> tritium: And to think you are the one that really got me started down this dark path! :-)
<tritium> Yes, but now _you_ are the master, and I am but the learner.
<bddebian> Master?  HAH.  bater maybe ;-P
<slomo> Kamion: hm, didn't you want to handle main syncs before beta freeze? i ask because of bug #56073 which is imho important
<Ubugtu> Malone bug 56073 in xfsprogs "Include XFS corruption fix from 2.6.17.7" [Medium,Confirmed]  http://launchpad.net/bugs/56073
<mjg59> crimsun: Cool - send me a copy if you want testing?
<crimsun> mjg59: roger.
<Burgundavia> mjg59: is that battery information we spoke about useful?
<mjg59> Burgundavia: If you stick it somewhere, I'll take a look
<Burgundavia> http://pastebin.ca/179281
<Burgundavia> mjg59: &
<mjg59> Burgundavia: On battery?
<Burgundavia> on AC
<mjg59> Sorry, can you do it on battery?
<mjg59> Wait a few seconds afterwards
<Burgundavia> http://pastebin.ca/179287
<mjg59> Burgundavia: Hm. present rate never shows anything?
<Burgundavia> mjg59: nope
<Burgundavia> probably why HAL/gpm have never given me accurate numbers
<mjg59> 4300mAh is a perfectly reasonable capacity
<mjg59> So if it's draining fast, it's because we're actually drawing that much power
<Burgundavia> yep
<mjg59> (or the battery is just lying through its teeth)
<Burgundavia> I am interested to see what it does when that RH polling stuff hits
<fabbione> morning
<fabbione> canybody awake?
<fabbione> -c
<fabbione> it seems like https is broken in the last FF update.. can someone please check LP if it has been reported?
<fabbione> or a workaround available?
<Toadstool> fabbione: bug 61660, no workaround :/
<Ubugtu> Malone bug 61660 in firefox "https doesn't work." [Untriaged,Needs info]  http://launchpad.net/bugs/61660
<fabbione> Toadstool: thanks
<Fujitsu> fabbione, did you open the link from Thunderbird?
<Fujitsu> Because that's been causing issues for some time...
<fabbione> Fujitsu: no.. 
<Toadstool> there are a few "firefox: https not working" bugs on LP but not enough info to determine whether these are duplicates...
* fabbione is kind of doomed without FF
<Fujitsu> fabbione, links! :P
* fabbione larts Fujitsu with links and launchpad
<Fujitsu> I think I tried that a while back...
<fabbione> i am not in the mood to file bugs with links :) not at 7 am
* fabbione does feel really adventurous today
<Fujitsu> A bit silly to feel adventurous the day after BetaFreeze.
<Treenaks> well, adventurous could mean filing bugs with links :P
* Treenaks hides
<dholbach> good morning
<jdub> GOOD MORNING FREEDOM DHOLBACHS!
<dholbach> YO JEFF! HOW ARE YOU?
<jdub> A LITTLE BIT HOARSE, ACTUALLY
<dholbach> . o O { I CAN IMAGINE }
* dholbach HUGS JDUB
<dholbach> . o O { "and now my throat hurts" }
<_ion> foomatic-db (in main) seems to depend on linuxprinting.org-ppds (in universe).
<doko_> infinity, Kamion, mdz: please process the openoffice.org and openoffice.org-l10n binaries in NEW
<Kagou> hi
<Fujitsu> doko, does this mean we'll have a new OOo, with working GNOME file-browsers, shortly?
* fabbione digs into a couple of glibc bugs
<Mithrandir> mdz: the date for the beta milestone in LP seems wrong.  It says 2006-10-19 (which is RC), not 2006-09-28.
<Mithrandir> mdz: I'm changing it, if I'm wrong, do of course feel free to change it back. :-)
* ..[topic/#ubuntu-devel:Keybuk] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | 6.06.1 released | Beta Freeze in effect
<Mithrandir> hi Scott
<Keybuk> morning
<Keybuk> hoes goes it?
<Mithrandir> a bit of a slow morning here
<agutierr> I have the problem: "The cd available not is a ubuntu cd" remastering a dapper cd. Someone can help  me? Thanks.
<dholbach> hi Scott - hi Tollef
<Mithrandir> hi Daniel!
<Mithrandir> dholbach: can you or Seb grab https://launchpad.net/distros/ubuntu/+source/control-center/+bug/59217 ?  (As in, assign it to one of you)
<Ubugtu> Malone bug 59217 in control-center "[Edgy]  gnome-settings-daemon acting up" [High,Confirmed]  
<Keybuk> Mithrandir: tell me about it :-/  my brain seems to have reached maximum mount count
<dholbach> Mithrandir: I'll talk to Sb about it - as he's one-tenth upstream I'd think it's his domain ;)
<Mithrandir> dholbach: sure, I just want the beta blockers list to show who's responsible for fixing stuff too.
<Mithrandir> on https://launchpad.net/distros/ubuntu/+milestone/ubuntu-6.10-beta , is the sorting-by-clicking-column header only spectacularly broken for me, or is it for everybody else too?
<Keybuk> Mithrandir: I didn't think Malone supported that?
<Keybuk> oh, maybe it does, but oddly
<Fujitsu> Mithrandir, unless it's meant to randomly assort, it's broken.
<Mithrandir> Fujitsu: I assume it's not meant to do that, no.
<Fujitsu> You never know...
<Kamion> slomo: ok, I'll do that this morning
<pitti> Good morning
<Kamion> agutierr: bet you forgot to copy over the .disk directory
<agutierr> yes
<agutierr> it is
<agutierr> :_(
<agutierr> thanks :-)
<Kamion> common mistake :)
* pitti discovers a bad beta-blocker bug: firefox still says '6.06 Dapper'...
<Mithrandir> pitti: please file the bug and target it for beta.
<Fujitsu> pitti, I noticed a bug this morning targeted for Hoary Preview, it was about the Firefox start page still being Warty's :P
<Mithrandir> Fujitsu: you can close that bug. :-)
<Fujitsu> It's /long/ closed :)
<Mithrandir> ah, ok
<fabbione> you are lucky that FF works for you :)
<fabbione> https is busted here
<pitti> Mithrandir: just did that
<Kamion> somebody should go through ReleaseChecklist
<Mithrandir> fabbione: try moveing extensions.cache from your profile directory out of the way.
<Mithrandir> Kamion: I'll do it once I've trawled my nightly emails.
<Mithrandir> Kamion: I guess you have enough ubiquity/d-i stuff on your plate that you don't want to have to RM as well?
<fabbione> Mithrandir: there is no extension.cache ?
<pitti> Kamion: Jeff Bailey suggested to urgently update tzdata, and mdz approved it 'as long as it doesn't effect the installer'; in a way it does (well, updated timezones), what do you think about it? shall I update now or after beta?
<Mithrandir> fabbione: sure?  In your ~/.mozilla/firefox/$garbledstring/ ?
<fabbione> oh found it
<fabbione> i was expecting a dir
<Mithrandir> fabbione: just try moving it out of the way; this sounds like a firefox bug since I saw the same yesterday
<fabbione> yeps.. this seems to work!
<Fujitsu> Yay :)
<Mithrandir> fabbione: cool.  Feel like filing a bug on firefox and subscribing me too to it?
<fabbione> i think there is one already.. but let me check and blabla
<fabbione> Mithrandir: #61660
<fabbione> Ubugtu: but #61660
<fabbione> feh
<fabbione> Ubugtu: bug #61660
<Ubugtu> Malone bug 61660 in firefox "https doesn't work." [Critical,Confirmed]  http://launchpad.net/bugs/61660
<Mithrandir> yeah, looks like the same bug.
<fabbione> it is
* fabbione hugs lvm
<Fujitsu> ?
<fabbione> lvextend -L+10G /dev/mofo/ubuntu-cd  
<fabbione>   Extending logical volume ubuntu-cd to 35.00 GB
<fabbione>   Logical volume ubuntu-cd successfully resized
<fabbione> i just did run out of space on a device :)
<fabbione> there.. zack fixed
<Fujitsu> Yep, I love that :)
<Kamion> Mithrandir: not sure - willing to do big chunks of RM, but moving house means there's a point where I may be difficult to contact at strange hours
<Kamion> pitti: hmm, are there any big timezone changes? tzsetup might need to be tweaked
<Kamion> only really if timezones have merged or split, not just DST tweaks
<Mithrandir> Kamion: I'm fine with RM-ing so unless you want to..
<Kamion> that's fine by me, thanks
<pitti> Kamion: some new TZ aliases, some added timezones, some new DST rules, and I soptted one removed timezone which is now subsumed by another one
<Kamion> can you e-mail me the details and I'll see if tzsetup needs any changes?
<pitti> Kamion: sure
<pitti> Kamion: diff -Nur between the two data sets, with comment changes removed?
<pitti> Kamion: mailed
<tepsipakki> what's taking so long with the flashplugin-nonfree for dapper-backports?=
<tepsipakki> it's still not built
<devilsadvocate> hello
<mdz> Mithrandir: you are correct re: the beta date
<mdz> Mithrandir: in LP
<devilsadvocate> i realize this is probably the wrong place to ask this, but can someone tell me how the ubuntu xorg is different from debians?
<devilsadvocate> as in ... how ubuntu's 7.0 works with the intel945 while debian's experimental only does...
<fabbione> Dear glibc.. please build faster
<Mithrandir> fabbione: I hope you're using ccache?
<fabbione> Mithrandir: new gcc.. bye bye ccache
<Mithrandir> ah. :-)
<fabbione> even on a 24 CPU it's taking too long
<fabbione> the best is that i am building only to understand why #DEBHELPER# is not replaced properly in libc6-opt on sparc
<fabbione> while it works on i386
<Fujitsu> How long has it been?
<fabbione> how long what?
<fabbione> the build
<fabbione> ?
<tepsipakki> who handles backport-builds?
<Fujitsu> fabbione, the build, yes.
<fabbione> Fujitsu: about 30 minutes.. 
<fabbione> it will need another 40 more or les
<fabbione> +s
<Fujitsu> On 24 CPUs!? That's... wow.
<fabbione> Fujitsu: glibc is built 6 times on sparc
<fabbione> that's why it takes so long
<Fujitsu> Why so many?
<[MaKuBeX] > Visit http://www.omgema.lt  its good . Have a nice day!
<fabbione> sparc sparc64 sparcv9v sparcv9b sparc64b and sparc64v
<fabbione> different optimizations level
<fabbione> multi arch
<fabbione> etc.
<Fujitsu> Aha.
<Fujitsu> Ouch.
<tepsipakki> fine, I'll build flasplugin-nonfree locally
<Mithrandir> hmm, libgl1-mesa-glx and libgl1-mesa-swx11 are both part of ubuntu-desktop.  That looks.. wrong.
<Mithrandir> I presume we should add libgl1-mesa-glx to the germinate workarounds bit of the seeds.
<Mithrandir> Kamion: ^^ ?
<pitti> dholbach: do you have an idea why /usr/share/ubuntu-artwork/home/index.html does not belong to any package any more?
<pitti> dholbach: is it generated in a postinst or so?
<dholbach> pitti: um? it should be part of ubuntu-docs
<seb128> pitti: it's an alternative
<pitti> ubuntu-docs has /usr/share/ubuntu-artwork/home/firefox-index.html
<dholbach> hellas mvo
* Keybuk sticks killev into cron.hourl
<seb128> pitti: did you read what I said :p
<pitti> yes, I did
<seb128> alternative are supposed to be owned by the package?
<seb128> the alternative is created by the postinst
<pitti> seb128: yes, I just read it too late, sorry :)
<dalfz> could someone please update package kile? current package is v1.8, 1.9 has been out of ages
<seb128> pitti: ah, k, np :)
<seb128> pitti: I was wondering if I was saying something wrong ;)
<pitti> seb128: no, you are perfectly right of course :)
* pitti grabs more tee
<pitti> tea, too
<Fujitsu> dalfz, 1.9 is in Edgy.
<mvo> hey dholbach
<fabbione> mvo: hey dude
<mvo> hey fabbione!
<dalfz> Fujitsu, 1.8 isn't exactly stable either, so i suppose 1.9 could be in regular repos :)
<Mithrandir> mvo: yo.  You needed to talk with me about g-a-i thingamob updates for milestones?
<Kamion> Mithrandir: libgl1-mesa-glx> yeah, that might unfortunately be necessary
<mvo> Mithrandir: right. I would like to update the desktop files/icons in g-a-i. is that ok? I want to do it today. when it is done I can post a debdiff (that is going to be quite long ;)
<Mithrandir> mvo: I think what mdz meant was in relation to milestones.  What's the procedure for updating the files/icons?
<mvo> Mithrandir: do you already use apt for the livefs build thing?
<Mithrandir> mvo: yes, we use apt-get.
<mvo> cool!
<mvo> the procedure is to run a desktopfile/icon extract script on the complete archive and put the result (moduleo blacklists) into the bzr archive
<Mithrandir> mvo: ok.  Can you document that somewhere on the wiki so I can link to it (as well as add a bullet point saying "poke mvo about g-a-i desktop/icons, if that fails, follow [this]  procedure")
<Mithrandir> (please)
<Mithrandir> afk, food
<mvo> Mithrandir: ok, will do that
<dalfz> I have one table with two slim but high tabulars, that i want to place on the side of each other. how should i do accomplish that?
<Nafallo> infinity: can you kick mplayer 2:0.99+1.0pre8-0ubuntu5 amd64 for me?
<Nafallo> infinity: please :-)
<dalfz> ops, wrong chan sorry :)
<hunger> synaptic recommends deborphan which claims to be deprecated. Should I file a bug about that?
<Kamion> where does deborphan claim to be deprecated?
<hunger> Kamion: Oh, sorry, you are right.
<hunger> Kamion: I confused deborphan with debfoster! The later is deprecated.
<Kamion> ah
<hunger> aptitude has all the functionality of debfoster now... so debfoster development was stopped.
* hunger wonders whether debfoster is still in active development.
* Nafallo wonders who will build i386 kernels first, his server or the buildd ;-)
<Nafallo> Kamion: hi! what do you think about the patch in bug #61173? might be beta-material? :-)
<Ubugtu> Malone bug 61173 in mdadm "boot script returns error "fail" if no raids are configured" [Untriaged,Confirmed]  http://launchpad.net/bugs/61173
<Kamion> Nafallo: perhaps you should ask somebody who actually knows about RAID
<madduck> Nafallo: how can such a patch be beta?
<Kamion> madduck: he means a candidate for our upcoming beta release
<madduck> ah
<Nafallo> right :-)
<fabbione> Nafallo: that patch is pointless IMHO
<fabbione> it's only a matter of aestethic
<fabbione> if raid subsystem is not there, mdadm has all the rights to report a fail
<Nafallo> fabbione: indeed. lvm2 pulls in mdadm, so I always have that failing on me. just lucks bad :-).
<Nafallo> s/lucks/looks/
<fabbione> lvm2 ?
<madduck> why does lvm2 pull in mdadm?
<Nafallo> well, that's another question ;-)
<madduck> fabbione: i agree. it's not really a patch to be considered, imho.
* Nafallo investigates.
<madduck> fabbione: btw: what was the cause for you removing set -u in ubuntu4 ?
<fabbione> lvm2 doesn't pull in mdadm
<fabbione> madduck: /bin/sh -> dash
<Nafallo> fabbione: lvm2 -> lvm-common -> mdadm
<fabbione> -u fails somewhere in lsb scripts
<madduck> fabbione: i use dash fir /bin/sh and see no problems.
<madduck> fabbione: aha...
<janimo> Kamion: can you please let python-cups binaries into the pool, and review system-config-printer (NEW) when you have time? I'd like to have those in main for beta. thanks
<fabbione> Nafallo: uh weird.. but i can see it...
<Keybuk> fabbione: didn't Kamion fix that bug?
<fabbione> i don't know the rationale for that
<fabbione> Keybuk: i saw it yesterday on ppc
<fabbione> something about loop: not being set or defined
<Keybuk> fabbione: he fixed it yesterday evening
<Keybuk> yes, definitely the bug Kamion fixed
<fabbione> feeeh
<fabbione> ok
<fabbione> well
<Nafallo> I wonder why that dep is there... *checks changelog*
<fabbione> madduck: what was the rationale for using -u anyway?
<janimo> Kamion: is the stacked livefs feature implemented? You said a while ago that could be used for selectively adding the a11y packages in a xubuntu desktop
<fabbione> madduck: i can revert my change, that's nothing you need to worry about.. just curious
<fabbione> Nafallo: i don't see any real reason for that Depends
<fabbione> Nafallo: can you?
<Nafallo> fabbione: me neither.
<Nafallo> can't find anything in the changelog either.
<Nafallo> fabbione: maybe we should drop it and see what breaks? ;-)
<fabbione> Nafallo: not at beta release.. no
<fabbione> Nafallo: it has been there for ages for what i can see.. it can stay there
<fabbione> it's of no harm
<Nafallo> except the damn fail-message ;-)
<Keybuk> janimo: I'm actually looking at system-config-printer right now
<Keybuk> didn't I reject python-cups yesterday?
<Keybuk> or maybe I accepted it
<Keybuk> there's NEW binaries, so I guess I accepted it ;)
<fabbione> madduck: well i understand what -u does, but is it really required to run mdadm init stuff?
<Keybuk> janimo: you're supposed to delete the "now look at the other files" comment from the debian/copyright template
<fabbione> Keybuk: funny.. Kamion uploaded the fix 40 minutes before my upload.. 
<fabbione> that's why i saw the bug too
<Keybuk> fabbione: yeah, doko was probably still DoS'ing the buildds ;)
<fabbione> binary was not available yet
<fabbione> Keybuk: ROFL
<Nafallo> Keybuk: yea, and now BenC took over :-P
<Nafallo> Keybuk: oh! can you kick builds? :-)
<Keybuk> Nafallo: he did?
<Nafallo> Keybuk: new kernel etc... :-)
<Hobbsee> what, again?
<Keybuk> Nafallo: that's not a DoS, that's just a build
<Hobbsee> excellent, i wonder if X will work with this kernel
<Keybuk> doko uploaded four or five consecutive versions of openoffice ;)  so multiple buildds were working on them
<Keybuk> Nafallo: I can kick builds
<Keybuk> though infinity has very large toes, and I prefer not to stamp on them too often
<Nafallo> Keybuk: can you kick mplayer 2:0.99+1.0pre8-0ubuntu5 amd64 for me please? :-)
<Nafallo> Keybuk: I think that build got a gcc that have been fixed since :-).
<Nafallo> fabbione: how about I build a lvm-common without the dep and ask people to try it out without mdadm on the bug-report? :-)
<Keybuk> Nafallo: BZZT
<Keybuk> nope, that's a good and proper FTBFS
<fabbione> Nafallo:ah i found it
<fabbione> Nafallo: i think..
<fabbione> hold on
<Nafallo> Keybuk: gaah. what do I do about it then :-P? I didn't even touch that code in the last upload ;-).
<Keybuk> Nafallo: fix it?
<fabbione> Nafallo: it's for initramfs
<fabbione> Nafallo: lvm-common has a PREREQ set on md for initramfs exec seq
<Nafallo> Keybuk: I don't know assembler that well and probably need an amd64 to try it out :-).
<fabbione> to ensure that md is called before lvm
<fabbione> Nafallo: so no.. we can't drop the Depends
<Keybuk> fabbione: I thought infinity fixed initramfs so you could do an ordering depend without requiring the other script be there
<Nafallo> fabbione: hmm, sounds evil. maybe we should find an alternative solution to that :-).
<fabbione> Keybuk: if he did, lvm2 script has not been updated.. 
<janimo> Keybuk: thanks for reviewing. I did not notice the comments I should delete, it was separated by the rest of the text by two blank lines, looked like a complete page to me :)
<fabbione> Keybuk: and at beta stage i am not happy to change it
<Keybuk> fabbione: nobody touches lvm for fear of catching something nasty
<fabbione> Nafallo: edgy+1
<Nafallo> fabbione: yea, but I can still work on it now ;-)
<fabbione> Keybuk: is that why my skin is melting?
<janimo> Keybuk: do I make a new upload with same version but with those comments removed?
<jdub> Keybuk: lvm is precisely what happened to lca2006!
<Keybuk> janimo: no, just fix the next one?
<Keybuk> jdub: hmm?
<janimo> Keybuk: ok, thanks
<Nafallo> fabbione: I'll follow up to the bug-report in the meantime :-)
<fabbione> jdub: ???
<jdub> Keybuk: vomiting, sweating, fainting -- LVM!
<dholbach> Kamion: am I ok to upload a new human-icon-theme? (added icons, fixes three bugs)
<Keybuk> jdub: was there a plague?
<fabbione> jdub: it sounds like you want to take over lvm2 maintainance :)
* Nafallo assigns the bug to himself :-)
<Nafallo> if that's okey :-)
<Kamion> janimo: stacked livefs> talk to infinity about that
<Keybuk> Overriding ichthux-artwork-usplash_1:6.10-1 (universe/kde/OPTIONAL)
<Keybuk> ... I'm reminded of the original "example" warty artwork
<Kamion> oh, I was just doing ichthux
<jdub> ha ha
<Mithrandir> Keybuk: it's not Tuesday today. ;-P
<Kamion> hence why it showed up as universe already for you
<Kamion> dholbach: yes, if you're being conservative
* Nafallo tickles Mithrandir :-)
<Keybuk> Mithrandir: it is in my timezone ;)
<Nafallo> lol
<Mithrandir> Keybuk: your timezone is broken. :-)
* Hobbsee tickles Mithrandir 
<Nafallo> :-)
* Hobbsee stomps on Mithrandir's feet
<dholbach> Kamion: thanks
* Mithrandir jumped away already
<Nafallo> Hobbsee: yay! team work! :-)
<Hobbsee> hehe
* Mithrandir tickles Nafallo and Hobbsee back
<Hobbsee> Mithrandir: no you didnt.  you jumped towards me
* Nafallo ties Mithrandir's feet with Dreyfus ;-)
<Keybuk> actually, I was just doing the binaries that I NEW'd the sources for on Tuesday
<Mithrandir> Hobbsee: actually, I just pulled my feet up and put them underneath me on the chair.
<Hobbsee> Mithrandir: heh, excuses excuses :P
<Fujitsu> There are still a lot of sources in NEW... *hint hint*
<Fujitsu> :P
<Keybuk> Fujitsu: there's not many
<Kamion> phrases like "hint hint" do *so* motivate me, I must say :P
<Keybuk> the only thing that's been in there longer than a week is something that scared me slightly
<Keybuk> so I put it to one side for later
* Mithrandir gives Kamion a pint of ale to help his motivation.
<Fujitsu> There's convertall that's been there just a couple of days, after sitting there for two weeks only to be rejecting 'cause I managed to stuff up debian/copyright. I don't know how I managed that :(
<Fujitsu> *rejected
<Keybuk> it wasn't in there for two weeks
<Kamion>    97054 | S- | convertall           | 0.3.1-0ubuntu1       | 24 hours
* Kamion is not concerned about that particular response time
<Keybuk> it was in there for 8 days, iirc
<Fujitsu> The previous one...
<Fujitsu> Hm.
* Fujitsu checks.
<Keybuk> I can probably still scroll up and give you the figure ;)
<Mithrandir> mvo: I'm looking at ReleaseChecklist and https://wiki.ubuntu.com/CodeNamesToVersionNumbers ; there it says we should change update-manager, including previous version's -updates.  Do you know what needs to be done?
<madduck> fabbione: i just use -u for everything, just like use strict in Perl
<Fujitsu> 9 days, I think. Oops.
<madduck> forces me to anticipate everything.
<Kamion> pitti: new openoffice.org-l10n adds openoffice.org-l10n-ka and openoffice.org-l10n-pt; do you need to update language-support-* to match?
<pitti> Kamion: yes, would be nice to do that; I can upload immediately
<Keybuk> Fujitsu: and it was only in there that long because the initial quick check failed, and I put it aside for later
<Fujitsu> Ah, OK.
<fabbione> does anybody have a dapper machine handy?
<Keybuk> Kamion: hmm, libburn appears to have lost its soname
<Fujitsu> I didn't things generally sat around for that long :)
<fabbione> i need the output from dpkg -p gfs-tools
<Keybuk> Fujitsu: things in the NEW queue will normally be processed within one week
<janimo> dholbach: hi, do you know if garnacho is around these days?
<Fujitsu> Keybuk, I thought that was about it...
<dholbach> janimo: I haven't talked to him for a while
<Kamion> Keybuk: I'll skip it for now
<Fujitsu> fabbione, said package is somewhat absent.
<Kamion> pitti: you might want to audit the whole lot - I know we don't always remember to tell you about such changes
<pitti> Kamion: ok, I'll go over it
<fabbione> Fujitsu: it's in main... i know that for a fact
<pitti> Kamion: while I'm at it, may I also add ttf-nafees to l-s-ur? it's an urdu font, trivial, I approved the MIR a while ago
<pitti> Kamion: but it would need main promotion
<Kamion> Fujitsu: if you haven't ever run 'dselect update', 'dpkg -p' won't work for you.
<Kamion> pitti: sure, I'll do the MIR in a moment
<Fujitsu> Ah, that'd do it.
<Kamion> pitti: do you know of any Dzongkha fonts, BTW?
<pitti> Kamion: no, are there any we could add?
<Kamion> dunno - I was wondering about it for ubiquity
<fabbione> Fujitsu: nevermind.. i got the output
<Keybuk> Kamion: oh, and watch out for any really new binaries ... the i386 buildd is lagging
<Kamion> it's visible on the first ubiquity screen that there's a missing font
<Fujitsu> fabbione, OK.
<Nafallo> Keybuk: hehe, the poor machines are DDoS'd ;-)
<pitti> Kamion: indeed, there are six new l10n and 8 new help OO.o packages, I'll add them as well
<Kamion> ttf-nafees promoted
<mvo> Mithrandir: can you please give me the url of your milestone checklist (or where I should document how the g-a-i desktop files are generated)?
<Mithrandir> mvo: MilestoneRhythm on the wiki
<Mithrandir> mvo: if the procedure for generating new g-a-i desktop files is long, please make a new page and link to it from MilestoneRhythm.
<mvo> Mithrandir: thanks
<pitti> Kamion: there would be thee NEW language-support packages, if that's fine
<pitti> Kamion: (oh, only two)
<pitti> Kamion: all uploaded now
<Kamion> pitti: that's ok
<doko_> tkamppeter, Kamion: due to the dependency of foomatic-db on linuxprinting.org-ppds, the CD's will increase by 13,5MB. Is this dependency really necessary?
<Keybuk> Description: the power of "find" with the versatility of "grep"
<Keybuk> ...so, a bit like "find | xargs grep" then?
<Mithrandir> Keybuk: or just grep and zsh.
<jdub> Keybuk: $ apt-cache search powerful | wc -l
<jdub> 486
<Keybuk> jdub: ironic
<jdub> ^ 8==============D
<Mithrandir> jdub: 486-es aren't powerful.
<Mithrandir> :-P
<Keybuk> if only we could remove all the duplicated or pointless cruft from the archive
<pitti> carlos: when do your langpack cronjobs trigger?
<jdub> $ apt-cache search flexible | wc -l
<jdub> 355
<Keybuk> quest scott% apt-cache search next generation | wc -l
<Keybuk> 34
<jdub> $ apt-cache search loving | wc -l
<jdub> 3
<jdub> ^ what's wrong with software
<pitti> $ acs advanced|wc -l
<pitti> 318
<doko_> $ apt-cache search magic | wc -l
<doko_> 143
<pitti> it doesn't love you, but it's advanced
<Mithrandir> : tfheen@golem ~ > apt-cache search slow | wc -l
<Mithrandir> 86
<Mithrandir> : tfheen@golem ~ > apt-cache search buggy | wc -l
<Mithrandir> 13
<Mithrandir> : tfheen@golem ~ > apt-cache search security hole | wc -l
<Mithrandir> 3
<pitti> oh, '73' for obsolete ;)
<Mithrandir> : tfheen@golem ~ > apt-cache search love | wc -l
<Mithrandir> 65
<Mithrandir> jdub: ^^
<mjg59> Keybuk: We're loading the non-free nvidia module even when the user isn't using the non-free driver
<mjg59> Keybuk: This has the side-effect of breaking suspend for some people
<pitti> Mithrandir: well, that maches 'language Slovenian' and such :)
<Mithrandir> pitti: details. :-P
<Keybuk> mjg59: yes?
<Keybuk> if we don't load the non-free nvidia module then when the user tries to use it, it doesn't work
<pitti> heh, 'xsabre - fighter plane simulator' matches love --- make love, not war???
<Keybuk> for the module to be available, they have to have installed the package, no?
<mjg59> Keybuk: I have some issues with auto-loading non-free code into the kernel when there's no need for it
<mjg59> Keybuk: No, it's in l-r-m
<Keybuk> how do we decide if there's a need for it or not?
<mjg59> It basically means that we can't trust any kernel bug reports from anyone with an nvidia graphics card
<mjg59> Well, that's a good question
<Mithrandir> look at the X config?
<doko_> pitti, tkamppeter: we seem to have symbolic link loops for the ppd files
<doko_> $ ls -l /usr/share/ppd
<doko_> total 0
<doko_> drwxr-xr-x 7 root root    64 2006-08-31 22:17 cups-included
<doko_> lrwxrwxrwx 1 root root    13 2006-08-31 22:17 cups-transitional-dir -> ../cups/model
<doko_> drwxrwsr-t 2 root lpadmin  6 2006-08-30 17:01 custom
<mjg59> Ideally X would load it if it's using nvidia rather than nv
<doko_> drwxr-xr-x 3 root root    16 2006-08-31 22:27 gutenprint
<doko_> drwxr-xr-x 3 root root    30 2006-09-22 08:15 postscript
<doko_> $ ls -l /usr/share/cups/model/
<doko_> total 24
<doko_> lrwxrwxrwx 1 root root   23 2006-08-31 22:17 cups-included -> ../../ppd/cups-included
<doko_> lrwxrwxrwx 1 root root   16 2006-08-31 22:17 custom -> ../../ppd/custom
<doko_> lrwxrwxrwx 1 root root   20 2006-08-31 22:18 gutenprint -> ../../ppd/gutenprint
<doko_> -rw-r--r-- 1 root root 9645 2006-09-22 04:00 pxlcolor.ppd
<doko_> -rw-r--r-- 1 root root 9453 2006-09-22 04:00 pxlmono.ppd
<Keybuk> mjg59: the entire new world order is based on the theory that we always load all of the drivers for the underlying hardware
<Keybuk> admittedly, in this case, I would argue that the nvidia module is not a driver
<Keybuk> but a support module for X
<Keybuk> so X should just load it
<mjg59> Keybuk: In this case, doing so breaks things
<mjg59> Right
<Keybuk> it's a slippery slope though
<Keybuk> someone might have a wifi card that they never use, and the driver breaks suspend
<pitti> doko_: hmm, what's the loop exactly?
<mjg59> Keybuk: If we have the source to the driver, we can fix that
<carlos> pitti: not yet changed
<carlos> I need to readjust them to the new server
<Keybuk> mjg59: true, true
<doko_> pitti: looking for i.e. a gutenprint driver in /usr/share/ppd finds the driver twice.
<Keybuk> anyway yes, I agree that the non-free X server should load the non-free kernel module by hand
<carlos> pitti: so you have the tarballs available when you wake up (or near that)
<Keybuk> but given we don't have the source to either to fix that ...
<pitti> doko_: ah, ok; so it's not really a loop, but an undesirable 'fork'
<Nafallo> fabbione: know what. evms alsa has PREREQ on md, but mdadm reverse depends give mindi, lvm-common ;-)
<Nafallo> s/alsa/also/
<pitti> carlos: I just wondered when I'll get the current ones, since I urgently need to upload new edgy tarballs for the beta
* Nafallo fetches code :-)
<dholbach> can somebody please give back   opal   and   libgnomeuimm2.6  ?
<carlos> pitti: edgy ones should be being regenerated right now
<carlos> pitti: it's the last one to be generated
<carlos> let me check when did it starte
<carlos> started
<carlos> pitti: it started 20 minutes ago
<carlos> pitti: from previous exports, it takes between 3 hours and a half and 4 hours... (it's a full export...)
<pitti> carlos: ok, thanks
<Keybuk> Description: GNOME simulaton of Conway's Life
<Keybuk> oh, just what the archive needs
<Keybuk> ANOTHER frickin' game of life clone :p
<pitti> with aiglx support? :)
<Fujitsu> Keybuk, it's a lot more functional that anything else I've found.
<Fujitsu> And people requested it.
<Keybuk> it's about to get rejected, by the looks of it
<Keybuk> it's based on another program, yet entirely fails to mention any copyright :p
<Fujitsu> Wha? It does mention it...
<Keybuk> it says "based on GtkLife", and that's it
<Fujitsu> It mentions the copyright (Suzanne Skinner) in debian/copyright..
<Keybuk> Copyright: 2005, John Spray <jcspray@icculus.org>
<Keybuk> is all that's in debian/copyright
<Fujitsu> Mine here is:
<Fujitsu> Copyright: 2005 Suzanne Skinner, 2006 John Spray
<Fujitsu> Somebody must have grabbed an old version from REVU...
* Fujitsu checks.
<Keybuk> *shrug* that's not what's in NEW
<Fujitsu> Noted.
<Keybuk> and who is Suzanne Skinner anyway?
<Keybuk> that's not the name of the GtkLife author
<pitti> Keybuk: don't you require a proper license stanza, too?
<Fujitsu> Suzanne Britton is the GtkLife author, it appears. LucidLife upstream got it wrong!
* Nafallo ponders who he should talk to about initramfs-tools PREREQ ;-)
<Mithrandir> Nafallo: we won't change that for edgy; too late.
<Keybuk> Fujitsu: according to the gtklife website, she plans to integrate the lucidlife changes into gtklife
<Keybuk> I suspect it'd be better to package that
<Nafallo> Mithrandir: I know. but if I fix it now and put packages online for testing we can do it early edgy+1 :-).
<Fujitsu> Hmm... True. OK...
<Nafallo> fabbione: would it make sense to make pvmove work OOTB while I'm at it (load dm-mirror by default)? :-)
<fabbione> Nafallo: do you want to maintain mdadm?
<fabbione> if so why don't you talk directly to madduck ?
<Nafallo> this is lvm-common
<Nafallo> :-)
<fabbione> it's not my pet package.. i don't care how it's done until it does not break because most of my ssytems depends on /boot on raid
<fabbione> yeah that too
<fabbione> same story
<fabbione> and / on lvm
<Nafallo> oki :-)
<HrdwrBoB> Nafallo: and dm-snapshot
<Nafallo> I mostly want to scratch my itch :-)
<Nafallo> HrdwrBoB: already does.
<HrdwrBoB> ah, sweet
<madduck> Nafallo: co-maintainers always welcome, although there's fairly little to do right now.
<Nafallo> madduck: nice, I'll think about it. for the moment I think I will just send patches though :-). but thanks for the offer.
* Nafallo needs to reboot to try new kernel + initramfs :-)
<Nafallo> brb
<carlos> seb128: just in case I'm not around when you are back, it's a locale problem, LC_ALL=C fix the issue with the hilight, but I don't find anything obvious in the .po file that would be producing this
<pitti> fabbione: ah, found and fixed the cupsys upgrade bug
<pitti> Mithrandir: ^ Simple conflicts/replaces version bump, I assume it's ok to upload?
<Mithrandir> go ahead
<iwj> I can't believe it.  This crazy firefox 1.5 string handling nightmare backport bug of doom which I have been wrestling all week has VANISHED.
<pitti> iwj: uh, how can that be???
<iwj> I don't know.  I think I need to have some food and some coffee and some staring out of the window scratching my head.
<Hobbsee> hehe
<jdub> $ apt-cache search christ on a stick
<jdub> libmail-audit-perl - Perl library for creating easy mail filters
<jdub> ^ no kidding
<Treenaks> jdub: LOL :)
<Mithrandir> doko_: ooo-common seems to need a replaces on ooo-math due to /usr/lib/openoffice/program/resource/sm680en-US.res
<Treenaks> jdub: how do you come up with stuff like that? :)
<jdub> Treenaks: baby jesus told me
<tkamppeter> doko_, cupsys provides /usr/share/ppd/cups-transitional-dir, so that PPD files in /usr/share/cups/model get found,
<Mithrandir> Treenaks: it all comes naturally to him.  He's jdub.
<Treenaks> Mithrandir: hm... that sounds reasonable too
<doko_> Mithrandir: ok, thanks
<tkamppeter> but Gutenprint, HPLIP, ... provide their own links to provide /usr/share/cups/model paths, probably for their internal tools, like hp-setup
<doko_> tkamppeter: IIRC, in dapper, we moved these into /usr/share/ppd/cups and 
<Mithrandir> tkamppeter: what about the linuxprinting.org-ppds package?  We just stopped shipping loads of precreated PPDs due to space issues.
<tkamppeter> At FSG/LSB (my main employment) we have decided on a file system standard for printer drivers, which will be finalized on the Printing Summit in October, once everyone have overtaken this the nightmare of links will stop.
<tkamppeter> linuxprinting.org-ppds dpes not contain any PPD which is built from Foomatic XML data. It contains only the PPDs which printer manufacturers have contributed to linuxprinting.org as ready-made PPDs.
<Mithrandir> tkamppeter: oh, ok.  So they're interesting to ship then.
<mjg59> desrt: I've just sent Ben a patch for iSight and the IR remote support
<Kamion> 13MB is still lots though
<Mithrandir> tkamppeter: we don't have space for 10MB though, so in that case we need to get rid of something else..
<Mithrandir> 13MB even
<desrt> mjg59; that's cool.
<desrt> mjg59; i'd be careful with the ir remote support one, though
<desrt> mjg59; if it's the one i tried it has some serious problems
<tkamppeter> Mithrandir, I have made them shipping by adding a dependency to foomatic-db. Through out games and such and it will work.
<Kamion> ! we need to discuss this sort of thing
<fabbione> pitti: cool
<Kamion> while the games probably ought to be made smaller, I don't want to just throw them out; they're a valuable draw for new users
<mjg59> desrt: Yeah. My hardware's support seems to be flaky anyway.
<Mithrandir> Kamion: and we don't ship 13MB of games.
<Kamion> no, indeed we don't
<Kamion> about 4MB
<tkamppeter> The necessity of space for printing on distros will get vastly reduced next year, as at FSG we will add distro-independent driver and PPD packages to linuxprinting.org and then the diistro will only carry a few very important drivers and download the rest automatically from linuxprinting.org.
<Kamion> which is about what it deserves
<Mithrandir> tkamppeter: you assume that people have bandwidth.  Often, they don't.
<desrt> mjg59; i'm sorry.  do you or do you not have a macbook?
<Mithrandir> I think we should demote that depends to recommends anyhow.
<mjg59> desrt: No, an iMac
<desrt> ah
<Kamion> at present, we will have to throw out localisation to gain that space, I think
* Nafallo just removed the mdadm dep from lvm-common successfully :-)
<lastnode> i think space is less valuable than bandwidth for most users (at least for desktop users)
<Kamion> currently, we have 2.5MB free on the alternate i386 CD
<mjg59> Hm. I'm in bed and I need to  be on my way to the airport in an hour
<Kamion> lastnode: CD space is strictly finite
<tkamppeter> The distro's tools will not download 13 MB if they discover a printer. They will download only one driver/PPD, for the printer they have detected.
<desrt> mjg59; where are you off to?
<mjg59> Akademy
<desrt> you turncoat freak
<HrdwrBoB> tkamppeter: doesn't help offline people though
<Kamion> there's about 12.4MB free on the desktop amd64 CD, which is the tightest of that set
<desrt> i hope you're there for purpose of infiltration
<Kamion> HrdwrBoB: I think that's OK in this case
<lastnode> Kamion, at the same time, it's not cool to assume the end user will have bandwidth. tools like printer drivers need to get shipped, i reckon.
<Kamion> lastnode: important ones, yes; absolutely everything, no
<Kamion> we cannot and do not ship everything possible
<Kamion> and it's "not cool" to cavalierly assume we can
<jdub> mjg59: i hope you pick up.
<lastnode> Kamion, i agree, i agree, a balance has to be found between the two
<lastnode> i guess im just kind of on the other side of this issue because i come from a bandwidth starved nation
<lastnode> where a lot of ubuntu users only have the ubuntu install cd as their "repo"
<lastnode> im lucky, i have dsl at home, but a lot of people don't.
<tkamppeter> For printer drivers, once there are many coming from manufacturers which are not free, they cannot be shipped, and from the free once we can leave out the once for less common or very old printers, like all these little 3rd-party thingies for Lexmark (not on Ubuntu anyway, but on other distros like Mandriva).
<HrdwrBoB> lexmark need to diaf
<Kamion> in order to find space for linuxprinting.org-ppds, I think we'd probably have to drop all language support other than English from the powerpc alternate install CD
<HrdwrBoB> after providing open drivers
<tkamppeter> HPLIP, Gutenprint, foo2zjs and drivers for Samsung should be shipped, all these printer brands are very common.
<Kamion> we need to consider whether that's worth it
<Mithrandir> Kamion: that's quite a tradeoff.
<Kamion> i386 would lose support for a number of less-common languages
<Hobbsee> just remove open office :P
<Kamion> why does every CD size discussion inspire suggestions that we all know won't happen?
<Hobbsee> heh, sorry
<tkamppeter> Yes, remove OOo, then we can nicely print the CUPS test page on 200 printer models, but can we create printable documents then?
<Kamion> sorry to snap, but that suggestion is made every time, and after the tenth time it starts to get boring
<tkamppeter> s/200/2000/
* Hobbsee goes back to hiding
<pitti> eventually we have to stop putting new crack onto the CDs anyway; there are only so many langpacks we can kill
<jdub> Kamion: reaching for absurdity is a common grieving technique
<Nafallo> pitti: yea, stop adding and start replacing :-)
<tkamppeter> Remove the kernel, there are many bugs in it.
<HrdwrBoB> unfortunately DVDs are nowhere near widespread enough
<pitti> Nafallo: well, python was replaced by mono, that was a good start
<Nafallo> pitti: :-)
<pitti> well, I mean for add->replace
<Nafallo> yea
<pitti> (not that I particularly favour mono, I mostly uninstall it anyway)
<Nafallo> but not really the same thing
<tkamppeter> pitti, should I tell the HP guys to rewrite the HPLIP tools in Mono?
<Nafallo> drop gthumb and add f-spot would be something like what I talk about :-)
<pitti> tkamppeter: well, first that wouldn't help, and second we have shipped hplip for a long time already
<pitti> Nafallo: we do have f-spot already
<Nafallo> pitti: yea, but we didn't replace something, we added it...
<pitti> <rant>and just for an overkill sticky notes app and an overly complicated photo management app we have to carry the whole mono stack on the CD</rant>
<pitti> (sorry)
<tkamppeter> But from gthumb and f-spot one perhaps needs only one. They both are image managers.
<Kamion> gthumb is 1.2MB, not enough to gain this kind of space
<Kamion> tkamppeter: f-spot doesn't have quite enough to replace gthumb yet
<Kamion> but it's a good preview of the future
<tseng> sigh people can drop mono if they really want to imo
<tkamppeter> Then leave gthumb in and take f-spot(+Mono) out.
<tseng> but it was approved by mdz ages ago and I didnt hear from you guys then
* pitti hugs tseng, wasn't meant really serious
<Nafallo> same here. maybe we should have ubuntu-extras.iso :-P
<Mithrandir> tseng: that'd leave us without a note thingabob applet, which we want.
<Kamion> can we focus on the present problem please?
<pitti> well, my gut feeling is to just throw out the additional PPDs again
<pitti> last come, last serve
<Nafallo> Kamion: I came in late, what is the present problem? OVERSIZE how much etc?
<jdub> pitti: overly complicated?
<pitti> we went through the CD so often, I doubt that there is much cruft left
<Mithrandir> tkamppeter: are there any particularly interesting PPDs we'd want, or a sensible way to split the package or something?
<Kamion> perhaps they can be split to include just the most common ones?
<Nafallo> pitti: agreed
<tkamppeter> The PPDs are all manufacturer-contributed.
<pitti> well, yeah, but we can't ship all possible PPDs the same way that we can't ship all possible gnome apps/mono apps/langpacks/python modules/firefox plugins/etc.
<Kamion> I'm still unconvinced by the 4MB ekiga (plus deps, haven't counted) on the CD, but I'd prefer to talk with mdz before removing that
<pitti> s/the same way/for the same reason/
<jdub> Kamion: gimp!
<Kamion> gimp < ekiga
<tkamppeter> The brands are: HP, Ricoh (with Infotec, Gestetner, Lanier, NRG, Ricoh, Savin), Kyocera, Brother, Oce, Okidata.
<Kamion> oh, no, maybe not with the data files. would have to count
<Kamion> maybe it would be worth it to shut jdub up :P
<jdub> $ apt-cache show gimp gimp-data gimp-python gimp-svg libgimp2.0 | grep ^Install
<jdub> Installed-Size: 7896
<jdub> Installed-Size: 20392
<jdub> Installed-Size: 380
<jdub> Installed-Size: 128
<jdub> Installed-Size: 2216
<jdub> 
<Kamion> installed-size is not what we care about
<tseng> installed-size != cd size
<pitti> jdub: I-S doesn't matter
<jdub> Kamion: i bring it up when these discussions come up because it has always been one of my "first against the wall" suggestions
<Kamion> I'm still not sure I agree with you though
<tkamppeter> Ricoh and partners are big workgroup devices, the printers of the other brands are smaller.
<jdub> oh, i thought for desktop cd installed-size mattered
<Kamion> I'm entirely aware it's been one of your suggestions from the year dot
<pitti> jdub: you want to ship three programs to watch pictures, but none to modify them?
<jdub> pitti: f-spot handles common photo use cases
<Kamion> jdub: the compression included in Size is much closer to the actual space taken up on the desktop CD
<jdub> Kamion: aha
<Kamion> we don't care about the uncompressed size of the squashfs
<Kamion> at least, not at this level
<tkamppeter> So perhaps we leave out the Ricoh brands then. These devices are usually also sold only with service and the service tells where the files can be found on linuxprinting.org.
<Kamion> I am persuadable about gimp, but I think many fewer users use ekiga
<jdub> Kamion: continuing to dismiss it like it's the ravings of a madman doesn't seem productive
<Kamion> jdub: you dismiss all the counterarguments though
<jdub> i don't
<Nafallo> ekiga seems to not be using SRV, so personally I hate it atm :-P
<jdub> note: i suggested gimp for warty, i supported its inclusion in every release since
<jdub> i don't suggest it because i don't want it to be there
<fabbione> jdub: that's why have been fighiting with cd size since :P
<Kamion> gimp is one of the most popular things I see real users of my acquaintance using
<tkamppeter> All the other brands are mostly printers which are sold "cash & carry", where service is supposed to come from the OS vendor.
<jdub> Kamion: the best reason for gimp being there is that it is one of the ultimate demo apps
<pitti> tkamppeter: that sounds as if you think a package split would make sense then?
<Kamion> surely it's that people use it (or something filling its slot)
<pitti> tkamppeter: a small deb with common drivers and a large with uncommon ones?
<jdub> Kamion: i think that's a supporting reason, but not the #1 reason
<Kamion> I think it is important for Ubuntu CDs to be useful to people, as well as being vehicles for advocacy
<det> Is it known that Edgy's ubuntu-desktop depends on a package in universe? linuxprinting.org-ppds
<jdub> Kamion: that's why gimp is still in the desktop CD
<Kamion> det: we are presently debating that extensively
<jdub> Kamion: ... but if we're up against the wall of reality ...
<jdub> that has *always* been the context of my suggestion
<Kamion> jdub: ... then every time I've checked, there have been better things to remove
<det> Kamion, I am not sure if you are being serious or sarcastic
<jdub> Kamion: that's why gimp is still in the desktop CD
<Kamion> det: entirely serious
<pitti> det: serious
<det> OK. Thanks.
<jdub> Kamion: this is why it's frustrating to be spoken to like an idiot.
<det> It broke my debootstrap until I added the extra repository.
<Kamion> jdub: so why is it always the first suggestion when a CD size debate comes up, rather than "let's look through what's in these packages and see if there's wasted space"?
<Kamion> jdub: I am frustrated with CD size debates always focusing on removing high-profile applications
<jdub> Kamion: because often the discussion happens with a lot of question marks involved
<Kamion> jdub: I find that it derails the debate hopelessly into bikeshedding
<Kamion> rather than getting the job done
<Kamion> I'm sorry I snapped, but that's why I find it irritating
<Kamion> and when a few people sit down quietly and look through things that are more subtle than just removing visible applications, they generally find several megabytes of wasted space
<tkamppeter> What's your opinion about splitting out the Ricoh PPDs as I mentioned, they make up something like 80% of the PPD package?
<Kamion> each time
<jdub> Kamion: the great thing is, after so many releases, i'm fully confident that you'll find better ways of solving the problem before we have to start doing things like this; but if it comes up, there are good reasons to prioritise some of those high-profile applications
<pitti> tkamppeter: 80% sounds pretty teasing if those Ricoh printers aren't that common
<Kamion> jdub: I don't disagree, but would you mind not contributing to every CD size discussion with "gimp!" :-)
<Kamion> ?
<jdub> Kamion: so if that's justification for treating me like an idiot, rock on
<pitti> tkamppeter: asked the other way around: how many of these extra PPDs cover printers which don't work with the foomatic PPDs at all?
<Kamion> because the "which application do we remove" flamewar every time really does get in the way of work
<tkamppeter> In companies where one uses such Ricoh printers, one usually does not run on a live CD.
<janimo> seb128: how do you see us going further with the whole python-gnome issue?
<Kamion> I agree that we should have an application ordering, but I don't want it to be the first resort every time
<tkamppeter> One adds software anyway.
<Kamion> we should only be going to applications after exhausting other possibilities
<pitti> tkamppeter: ok, then this indeed sounds like a good opportunity for a split and getting rid of ~ 10 MB
<Kamion> jdub: again, I apologise for my initial response
<tkamppeter> And there are sysads or Ricoh service who know how to add a package or how to get an even newer PPD from upstream.
<pitti> tkamppeter: the small main package can Suggests: the large ricoh universe package then
<Kamion> tkamppeter: that sounds like a productive approach; thanks
<Nafallo> pitti: have we done everything for reducing duplication yet?
<tkamppeter> I will perhaps also rename the packages into standard-ppds and enterprise-ppds and standard-ppds will suggest enterprise-ppds
<pitti> Nafallo: certainly not everything, but we aren't that bad
<pitti> Nafallo: e. g. we still have multible libdb4.x, but they are small
<Nafallo> pitti: oki. so nothing big to save there either :-/.
<pitti> tkamppeter: well, I'd avoid 'standard' and 'enterprise'
<pitti> tkamppeter: maybe linuxprinting.org-ppds-common and -extra
<pitti> or just keep the current linuxprinting.org-ppds and add an -extra one?
<det> pitti, I like that much better
<Kamion> Nafallo: there are always quite a lot of small things
<pitti> that is consistent with other packages
<Kamion> they just take more work
<seb128> janimo: let's talk about it after beta
<_ion> foopackage-enterprise, now with more XML and Web 2.0
<janimo> seb128: I'd like those apps tested in xubuntu context in beta (especiall a11y stuff)
<janimo> seb128: that way you'll get the other apps using them tested more widely
<janimo> seb128: after beta sounds riskier
<seb128> janimo: we are pretty much frozen for beta, I don't think splitting packages now is a good idea
<janimo> seb128: we could try to get an exception and defer for after beta if not given then?
<tkamppeter> So I will use linuxprinting.org-ppds and linuxprinting.org-ppds-extra
<Nafallo> tkamppeter: sounds good :-)
<pitti> tkamppeter: that sounds good to me
<seb128> janimo: feel free to try, I'm busy enough with other issues to fix before beta for my part
<pitti> tkamppeter: thank you!
<tkamppeter> So tell me when beta is over and I do the splitting then.
<janimo> seb128: the packages could get into the archive today and nothing else changes in gnome
<janimo> seb128: ok I'll try
<pitti> tkamppeter: well, we either need to drop the dependency or do the split now
<seb128> janimo: talk to mdz, if he agrees I'll do the change
<pitti> tkamppeter: right now the desktop CDs are uninstallable
<pitti> tkamppeter: (because lp-ppds is in universe, and even if we promote it, the CDs would overflow)
<seb128> janimo: is xubuntu CD oversized without that change?
<tkamppeter> So this means that we do a freeze exception?
<janimo> seb128: ok, do you want a patch for python-gome-extras in LP or do you want to do it yourself
<Kamion> how did linuxprinting.org-ppds get into ubuntu-desktop dependencies without being promoted?
<Kamion> the tools should make that impossible
<janimo> seb128: the alternate CD is oversized ~6M
<janimo> this would hekp about 4 I guess
<pitti> Kamion: it's a new foomatic-db dependency
<janimo> there are other things that made it oversized
<janimo> recently
<pitti> Kamion: not an u-d one
<Kamion> ah
<tkamppeter> Kanion, by adding a dependency to foomatic-db
<pitti> well, but that sounds wrong anyway
<Kamion> ok
<seb128> janimo: xfce is bigger than GNOME?
<Kamion> yeah, if you just want it in the desktop, it should be seeded
<Kamion> unless foomatic-db actually requires it for proper operation
<det> janimo, Yes, I had to burn it to a DVD. I feel so wasteful :( Also I discovered RAID and LVM are still not working on knot-3 :/
<pitti> Kamion: my gut says that we should drop the foomatic-db dependency now and add the small lp-ppds package to u-desktop after beta
<janimo> seb128: no, but it ships OOo, several language support packs and a full LTSP setup
<seb128> janimo: Ubuntu also ship OOo, easy target is to drop some language packs other way
<Nafallo> det: huh? I use LVM here :-)
<Kamion> pitti: I think I would like to get the split out of the way, in order to make sure the space doesn't get eaten elsewhere
<det> Nafallo, The knot-3 installer doesn't appear to support LVM
<janimo> det: RAID and LVM not working only sound a xubunt problem id I forgot something in xubuntu . Does it work in ubuntu Knot 3 otherise?
<Nafallo> det: ah, that's not the same thing then :-)
<det> Yeah, besides, probally the wrong place to discuss this.
<janimo> seb128: I'd ratrher not drop langpacks which are theoretically used if I can drop things which are certainly not used just there
<tseng> det: you need to use the alternate cd for advanced partitioning
<janimo> seb128: anyway the CD size is just one issue so it does not help in the p-g2 issue
<det> tseng, Yeah, it doesnt work on the alternate CD.
<seb128> janimo: I would prefer not hurry that split if possible though
<Nafallo> tseng, det: I made /, booted and then made the rest of the LVM-stuff :-)
<seb128> janimo: Loc seems to agree now than splitting can be useful for Debian so better to make sure they want to split the same way
<det> Nafallo, / is LVM on my setup, I have a seperate raid-1 /boot
<janimo> seb128: I'll talk to mdz and see. I prefer to hurry so I get the chance to get onboard tested in  xubuntu, and help with reducing the CD size. 
<Nafallo> ah
<janimo> seb128: ok, but I'd rather not wait till Etch is out :)
<seb128> janimo: that's not like you need lot of testing, you agree the split is no change
<seb128> janimo: so that's not something that needs maximal testing with beta
<janimo> seb128: right, not the split itself is that needs test but getting more apps on the CD
<fabbione> janimo: no.. i fixed RAID after knot-3
<janimo> seb128: but if debina do it soon and you can make the same changes for edgy I am ok weioth that too
<seb128> drop language packs for now if require and get them back after beta when we split
<Kamion> det: please file a bug on partman-lvm describing the problem
<Kamion> det: attach /var/log/syslog and /var/log/partman (you can extract them using "Save debug logs" from the installer main menu)
<det> Kamion, I suspect it is well known, it was mentioned on the forums.
<janimo> seb128: ok, so do you think debian will split for 2.16 and you can just reuse their split? That would be good. But must make sure it happens for edgy
<det> I'll search anyways.
<Kamion> det: I'm the maintainer
<Kamion> please file a bug :-)
<Kamion> I don't read the forums, in general
<seb128> janimo: I'm not sure, they don't need to though, we just have to agree on the binary split (what packages and the naming)
<janimo> seb128: well the names and content should be straightforward. It is mandated by the policy after all
<janimo> and the content cannot really be gotten wrong either
<seb128> janimo: name ares, remain to know if we want to split gnomevfs by example
<det> Kamion, for the raid too?
<janimo> seb128: the advantag of using tehir would be that no source diff would be needed at all
<Kamion> det: yes please, on partman-md
<janimo> Replaces fileds in particular. But if you're happy with source pkg diffs I am ok too
<seb128> janimo: Josselin proposed to split every component on his mail, not only canvas and gconf
<janimo> seb128: I'd suggest they not split too much, since it may not be a real gain. But it's up to them
<seb128> janimo: right, just need to be discussed so everybody agree
<janimo> seb128: yeah, I think that is overkill but it's their decission after all
<seb128> I don't expect it to be a long or hard topic
<janimo> especially not split egg and popt and other useless stuff
<seb128> right
<pitti> janimo: ah, system-config-printer :) you should definitively discuss this GUI work with tkamppeter 
<majyk> why would the vmware-player package want to remove libdbus-1.2? Isn't that a vital package needed by Gnome?
<Nafallo> majyk: we use libdbus-1.3 now
<majyk> ah, that would explain it
<janimo> pitti: I did not work on that mind you :)  It's just lifted from Fedora
<janimo> pitti: the GUI we looked at in paris was deprecated at that point and this new one one hidden in CVS somewhere
<janimo> pitti: found it accidentally while reading RH magazine two weeks ago
<tkamppeter> pitti, kamion, Nafallo, Mithrandir, mdz: The new foomatic-db package without dependency is as 0ubuntu2 on my web space now, grab it from http://www.freestandards.org/~till/tmp/ubuntu/edgy/foomatic-db/
<pitti> ^ grabbing, checking, and uploading
<tkamppeter> pitti, system-config-printer? Can it be that you are in a terminal window now where you sshed to a Fedora/RedHat box?
<pitti> tkamppeter: certainly not ;) no, I just spotted it on edgy-changes@
<pitti> tkamppeter: janimo uploaded it to universe
<tkamppeter> So someone has ported the Red Hat printer tool to Ubuntu? What is the package name to apt-get install it ("yum: Command not found.")?
<pitti> tkamppeter: it was just uploaded, it'll take a while to get published and built
<pitti> after that, 'system-config-printer'
<tkamppeter> How many days/weeks usually? The new foo2zjs did not arrive yet, too and doko_ told he has uploaded it yesterday.
<pitti> tkamppeter: usually about three hours
<tkamppeter> doko_, did you really upload the new foo2zjs?
<iwj> pitti: OK, what do you want me to do with this backport ?  I haven't tried compiling it yet but I'm pretty confident.
<pitti> iwj: 'this backport'?
<pitti> iwj: ffox 1.5.0.7 for breezy?
<iwj> Oh, sorry, I'm confused.
<iwj> I'm talking about a dpkg backport for mvo.
<iwj> I think my brain has melted due to too much mozilla source.
<pitti> iwj: btw, there is no firefox breezy upload from you in the queue
<ogra> Keybuk, is udev able to detect if i plug in anything into a parallel or serial port ? (esp. printers)
<iwj> pitti: It rejected itself for some reason.
<iwj> I forget what it was.
* pitti looks
<pitti> iwj: oh: firefox_1.5.dfsg+1.5.0.7.orig.tar.gz file already exists in the Accepted directory.
<doko_> $ cat foo2zjs_20060625dfsg-2_source.upload
<doko_> u foo2zjs_20060625dfsg-2.diff.gz upload.ubuntu.com Thu Sep 21 22:10:25 2006
<doko_> u foo2zjs_20060625dfsg-2.dsc upload.ubuntu.com Thu Sep 21 22:10:26 2006
<doko_> u foo2zjs_20060625dfsg.orig.tar.gz upload.ubuntu.com Thu Sep 21 22:10:48 2006
<doko_> u foo2zjs_20060625dfsg-2_source.changes upload.ubuntu.com Thu Sep 21 22:10:50 2006
<doko_> s foo2zjs_20060625dfsg-2_source.changes upload.ubuntu.com Thu Sep 21 22:10:50 2006
<doko_> hmm ...
<Keybuk> ogra: nope
<pitti> iwj: yes, sorry, after I told you about -sa, I uploaded the dapper version
<pitti> iwj: so, no -sa necessary any more
<ogra> Keybuk, thanks ... sad ...
<Keybuk> udev doesn't detect anything
<iwj> pitti: Yes, that sounds familiar.
<Keybuk> I suspect you may have meant "is THE KERNEL able to detect"
<iwj> But I'm currently stalled because this bug has gone away.
<ogra> well, does it get a kernel event then ? 
<Keybuk> nope
<pitti> iwj: *boggle*
<ogra> ok
<iwj> And my breezy machine isn't the one with the huge RAM so everything is slow (especially as there are two versions: 1.5.0.5 and 1.5.0.7) to consider.
<Keybuk> the common parallel port doesn't support insert notification ;)
<Keybuk> or device identification, for that matter
<iwj> I'm doing a set of really fresh builds just to make sure I'm not dreaming or something.
<ogra> well, parallel ports are quite intelligent so i had hopes :)
<iwj> The same is true of serial ports.
<iwj> M$ have a crazy plug and pray protocol but it makes assumptions about your devices that might not be true.
<doko_> tkamppeter: my mistake, needs a sync from unstable
<doko_> tkamppeter: Ubuntu #61874
<doko_> tkamppeter: bug #61874
<Ubugtu> Malone bug 61874 in Ubuntu "sync request" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61874
<Fujitsu> That doesn't meet the new sync requirements...
* fabbione is about to commit omicide
<bddebian> Doh :-(
<bddebian> Howdy folks
<zul> fabbione: how come?
<fabbione>   Volume group "Ubuntu" not found                                               
<zul> ah..
<fabbione> where.. there... is... ROOT
<zul> mdadm?
<fabbione> that's morelikely lvm
<Nafallo> fabbione: ehm, did you test my package or something? :-/
<fabbione> Nafallo: no, fresh install
<Nafallo> *puuh*
<tseng> Kamion_: would you mind promoting gsf-sharp? https://wiki.ubuntu.com/MainInclusionReportgsf-sharp
* jdong looks around for an archive admin
<jdong> Kamion_: poke?
* fabbione larts lvm initramfs script
<dholbach> can somebody give back opal and libgnomeuimm2.6?
<Kamion_> tseng: done
<Kamion_> jdong: yes?
<tseng> Kamion_: thanks!
<fabbione> Kamion_, Mithrandir: are you ok with a lvm-common upload to fix install with / on lvm ?
<fabbione> basically it adds a call to pvscan that gives a proper kick to devicemapper and allows vgchange to actually work
<Kamion_> fabbione: yes
<fabbione> hmm crap
<fabbione> the fix didn't work as expected..
* fabbione checks again
<tkamppeter> doko_, for what are you reporting bug #61874? Are you not supposed to upload my new foo2zjs packages?
<Ubugtu> Malone bug 61874 in Ubuntu "sync request" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61874
<doko_> tkamppeter: no, there are no changes compared to the debian version, it has to be synced
<doko_> Kamion, Keybuk: ^^^ would be nice to sync today, it should be in the beta
<Kamion_> doko_: your bug report contains only a version number and no package name
<tkamppeter> doko_, so I was not supposed to make a package, but someone with permissions has to trigger a sync bot?
<Hobbsee> heh
<Hobbsee> useful
<BenC> anyone mind kicking l-r-m for i386 out of dep wait?
* Hobbsee tried to point that out days ago :P
<Kamion_> doko_: please set the source package name on the bug in the usual way
<Kamion_> tkamppeter: if it's just copying a source package from Debian, then yes, the archive administrators do that on request
<doko_> Kamion: done
<tkamppeter> OK, then go ahead syncing foo2zjs with Debian unstable, my package is really exactly the Debian source, only rebuilt binaries for testing.
<Kamion_> doko_: synced
<Kamion_> argh, don't file new bugs for sync requests when there's already a bug, subscribe the archive team to the existing one
* Kamion_ cleans up
<Hobbsee> Kamion_: Keybuk said the other way, i believe
<Kamion_> Hobbsee: that would surprise me
<Hobbsee> Kamion_: either that, or fabo got it wrong.  /me double checks
<Kamion_> Hobbsee: fabo?
<StevenK> fabbione, I'm guessing
<Hobbsee> no, different
<Kamion_> fabbione had nothing to do with this bug, nor did anyone called fabo
<Hobbsee> a guy in #kubuntu-devel who's been requesting syncs
<Kamion_> Hobbsee: different case
<Hobbsee> wait, are you talking about that specific bug, or syncs in general?
<Hobbsee> right, dont mind me then
* Hobbsee goes back to hide in her corner
<Kamion_> Hobbsee: a *different* specific bug, but also syncs in general
<fabbione> i have done nothing.. i think...
<Hobbsee> fabbione: yes, wasnt you
<Kamion_> if you file a new bug when there's already one explicitly requesting the sync and asking for UVF approval, and if you don't bother to make any link between the two bugs, then the other one is liable to get lost
<Hobbsee> Kamion: gotcha.  sorry, didnt realise that's what you meant.
<fabbione> Keybuk: i think i found one of those udev create devices + kernel send notification + driver load timing issue
<Hobbsee> Kamion: however, if it's synced, and then needs to be synced again, you want a new bug, yes?
<fabbione> Keybuk: mind if i paste in /msg ?
<Kamion> Hobbsee: correct
<Keybuk> fabbione: sure
<Keybuk> Hobbsee: I've said not to reopen old sync request bugs!
<Hobbsee> Kamion: gotcha.  sorry for the noise
<Keybuk> if there's an open, unresolved sync request, you should not file a new one
<Hobbsee> Keybuk: so i hear, earlier today, i didnt do it.
<Hobbsee> duh :P
<Keybuk> but if there's an old, historic, closed, resolved, sync request, for an older version; you should file a new one, not reopen the old one :)
* Hobbsee hides from the scary K* people :P
<Hobbsee> gotcha
<Nafallo> haha
<Nafallo> K* people! :-)
<zul> kde people?
<Nafallo> rather archive admins ;-)
<Hobbsee> K people meaning Kamion and Keybuk, i was referring to.
<Hobbsee> then again, i see there are a few more of them
<Nafallo> Hobbsee: they might be equally scary :-P
<Hobbsee> Nafallo: they might.  i've not seen the others in action much
<blueyed> In which package is /usr/bin/pycentral? I want to file a bug with a patch that prevented dist-upgrade here.
<_ion> apt-file search pycentral
<blueyed> nothing..
<Nafallo> python-central maybe? :-)
* pygi nods :)
<blueyed> thanks.
<terlmann> this new gaim version is really useful.
<Keybuk> I read that as "really awful", and was about to agree with you
<Nafallo> :-)
<seb128> Keybuk: do you know an easy way to get the device path from the UUID in C?
<pitti> seb128: readlink(/dev/disk/by-uuid/$UUID) perhaps?
<Keybuk> define "device path" ?
<seb128> Keybuk: gnomevfs uses getmntent() and mntent->mnt_fsname to get it which gives paths like "UUID=984a612e-39f3-4be5-9abf-4879931460fc"
<Keybuk> if /dev, what pitti said
<Keybuk> ok
<seb128> pitti, Keybuk: thank you
<terlmann> but the beta version included with edgy is missing one thing.... the progress bars.but then again gaim  never told you much to begin with anyway.
<Keybuk> if in C, you can also link to libvolumeid
<gnomefreak> is there a python-gtk2 for python 2.5? if so did it change names?
<seb128> gnomefreak: yes and no
<gnomefreak> the depends on that package showed python (<< 2.5) was why i asked
<seb128> gnomefreak: that's because the current build ships only 2.4
<gnomefreak> oh ok
<seb128> gnomefreak: do you need 2.5?
<seb128> gnomefreak: 2.4 will stay default on edgy
<gnomefreak> no thats fine was wondering cause i went to grab it and saw it as 2.4
<BenC> Keybuk, Kamion: could either of you kick l-r-m out of dep-wait on i386, please?
<Kamion> I can't, not a buildd admin
<BenC> I thought you had magical powers, sorry :)
<Keybuk> kicked
<BenC> thanks
<BenC> getting close to release, you really start to notice the difference between a regular job, and getting paid to do open source...your users become your managers, and ride you constantly :)
<Kamion> BenC: in some areas :)
<Kamion> launchpad-buildd-admin is the particular variety of deityhood you need here
<fabbione> Kamion: lvm-common is up. The changelog looks scary but it's just very detailed on how to make a loop on 2 commands :)
<fabbione> BenC: did you get my email with the objdumps ?
<BenC> fabbione: I got email, let me see if it contains the objdumps
<fabbione> they are in attachment
<fabbione> it's crystal clear that they are different.. but why.. i have no idea
<blueyed> Nafallo: does "apt-file search pycentral" work on your system? I'll file a bug otherwise, because it does not find it here.. also "apt-file show python-central" does not work.
<janimo> Keybuk, Kamion: system-config-printer is built can you please let the binary through as well? thanks
<Nafallo> blueyed: I don't have the app install I guess.
<minghua> bluefoxicy: try "dpkg -S /usr/bin/pycentral" and "dpkg -L python-central" instead
<Keybuk> janimo: done
<dholbach> janimo: garnacho is in #gst
<BenC> fabbione: I have a sneaky suspicion this isn't a tool chain bug
<janimo> Keybuk: dholbach thanks
<BenC> fabbione: Working on it...I should know in about 10 minutes
<fabbione> BenC: ok
<fabbione> BenC: my Niagara is up for testing..
<blueyed> minghua: yes, found it. But I think it's a bug(?) with apt-file.. can anyone confirm?
<fabbione> BenC: btw.. laotse left AOHELL
<BenC> yeah he mentioned that the other day
<BenC> I wouldn't have stayed there as long as he did :)
<minghua> blueyed: did you do "apt-file update" (or something similar) recently?
<fabbione> ehhe
<blueyed> minghua: sure. even "purge" to be sure.
<minghua> blueyed: no idea then.  I don't use apt-file myself, sorry
<BenC> $ cmp dapper-first/ultra edgy-first/ultra
<BenC> $
<dholbach> what do I do in case of a kernel panic? what info is useful for a bug report?
<BenC> fabbione: the executable generated on dapper and edgy are exactly the same, so it's either elftoaout or the dd munging that's broken
<fabbione> BenC: feeeh
<fabbione> no old on.. elftoaout has to be ok... otherwise netboot would be horribly broken
<fabbione> and i did test that
<shining> dholbach: is it reproduceable? and is it using ubuntu kernel or vanilla too?
<fabbione> but we didn't change the dd munging either in ages and if the binaries are the same i don't see why it should change
<dholbach> newest ubuntu kernel, reproducable
<BenC> fabbione: elftoaout is ok, generated binary from that is exactly the same as well
<dholbach> (on amd64 k8)
<BenC> has to be the dd munging
<BenC> which is black magic I never understood very well
<dholbach> it says something about agp_amd64_probe and agp_generic_create_gatt_table
<dholbach> BenC: is a photo of the screen the best I can do for a bug report on kernel panic?
<azeem> dholbach: no, you can transcribe it to a machine-readable form :)
* dholbach slaps azeem
<dholbach> azeem: man... :-)
<_ion> Hehe.
<BenC> dholbach: that'll do
<dholbach> ok
<BenC> fabbione: here ya go
<BenC> -       $(DD) if=/dev/zero of=ultra.b bs=4 count=1 seek=127
<BenC> +       $(DD) if=/dev/zero of=ultra.b bs=4 count=1 seek=127 conv=notrunc
<BenC> that's in first/Makefile
<BenC> fabbione: That should fix it
<BenC> well, it does fix it for me
<fabbione> BenC: ok i will test on Niagara in a minute.. it's booting now
<fabbione> for some reasons the initramfs has been autobloated again
<fabbione> even with the fixed glibc
<Kamion> fabbione: hmm, what version of console-setup were you installing in bug 61723?
<Ubugtu> Malone bug 61723 in console-setup "[PPC]  distupgrade from dapper to edgy kills X keyboard" [High,Confirmed]  http://launchpad.net/bugs/61723
<Kamion> because the init script already checks -z $DISPLAY
<fabbione> Kamion: what was in the archive yesterday around 3pm UTC
<fabbione> 3:30
<Kamion> bizarre!
<fabbione> i distupgraded after the meeting
<Nafallo> pitti: invoke-rc.d: initscript apport, action "start" failed.
<Kamion> I made that change on 11 September
<Keybuk> fabbione: check dpkg.log
<fabbione> Kamion, Keybuk: ok.. just a minute that i boot the ppc
<pitti> Nafallo: uh, can you set -x the script and check? and file a bug please? (I have to leave RSN)
<Kamion> ta
<Nafallo> pitti: oki
<Kamion> fabbione: also, do you have a /lib/debian-installer directory on that system for any crazy reason?
<dholbach> BenC: it's bug 61898
<Ubugtu> Malone bug 61898 in linux-source-2.6.17 "Kernel Panic - agp_amd64_init" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61898
<fabbione> Kamion: will check.. machine is coming up
<fabbione> Kamion: no /lib/debian-installer (note i did a text install from netboot)
<Kamion> yeah, shouldn't matter
<fabbione> 2006-09-21 19:19:01 install console-setup <none> 1.7ubuntu10
<Kamion> so I know that running setupcon within X corrupts X; that's an X bug
<Kamion> but that version of console-setup definitely shouldn't try
<Kamion> weirdness
<fabbione> Kamion: dunno.. anything i can do other than reinstall dapper and try?
<Kamion> fabbione: you did have $DISPLAY set during the upgrade, didn't you?
<fabbione> no
<fabbione> su -
<Kamion> oh!
<fabbione> echo $DISPLAY
<fabbione> 
<Kamion> well, that would explain it
<Kamion> any other way to find out whether we're running in an X terminal so that I can avoid buggering it?
<fabbione> you can generally check if X is running... ?
<fabbione> if it's running don't bugger it..
<Kamion> but it should work fine if you switch to a vc
<Kamion> I think
<Mithrandir> Kamion: look at what `tty` returns?
<Kamion> hmm, I guess maybe it wouldn't
<BenC> dholbach: ok, thanks
<_ion> perhaps case $(tty) ... /dev/tty*) ...
<Kamion> that's already done in setupcon but we had to override it for other reasons
<dholbach> BenC: just tell me, if you should need anything else
<Kamion> maybe I can kill that override, if I'm careful
<Kamion> I'll test it out, thanks
<fabbione> Kamion: if it's really required i can reinstall dapper on my ppc and test it again.. but i would really love to avoid that if i can
<Kamion> fabbione: no, no need, thanks
<Kamion> it's not powerpc-specific, and can be tested without the need for an upgrade from dapper
<fabbione> Kamion: ok perfect! thanks a lot
<rod> Hi, can I ask here about the livecd installer of edgy?
<Kamion> rod: what's up?
<rod> liveinstaller fires up gparted which only sees one of the two disks... fdisk sees both discs... Any ideas how to troubleshoot this?
<Kamion> I'd strace gparted and see what it's doing on startup
<Kamion> I seem to remember seeing a bug about that
<smurf> Kamion: http://netz.smurf.noris.de/keymapper_0.5.3-7.diff.gz
<smurf> Kamion: two changes:
<Kamion> smurf: thanks! could you mail that to me? I'm about to go and move house
<Kamion> which is liable to drive keymapper right out of my head
<smurf> - prioritize the equivalent-letter file so that early stuff is first
<smurf> - add a new option asking whether something is on a normal-or-shift key (which is tried first, so should be the "normal" case)
<Kamion> note that there's a keymapper 0.5.3-6 in the Debian NEW queue
<pitti> Riddell: new edgy langpacks are up; can you please test them and give me feedback via mail?
<smurf> Kamion: bah ;-)
<Kamion> I can send it to you if you want to merge it
<smurf> Kamion: I'll go and merge that
<smurf> Kamion: please do
<Kamion> you won't be able to read it, hang on
<pitti> seb128: same here, can you please test new edgy langpacks from my daily page?
<Riddell> pitti: yes, but not immediately
<Kamion> smurf: I've stuck it in http://people.ubuntu.com/~cjwatson/tmp/
<fabbione> BenC: that didn't help... still no S
<pitti> Riddell: I have to leave in 10 minutes
<Kamion> feel free to revert the Maintainer/Uploader change if you want :) it just seemed more appropriate since I'm actually in the Debian keyring and IIRC you retired
<Riddell> pitti: ok, will e-mail you
<Riddell> pitti: URL?
<BenC> fabbione: hrmm
<seb128> pitti: ok
<pitti> Riddell: didn't change :) deb http://people.ubuntu.com/~pitti/langpacks/daily/edgy/ ./
<Kamion> smurf: presumably that new option will need a cdebconf-keystep change
<Riddell> thanks pitti 
<Kamion> oh, damn, I remember why console-setup had to use setupcon --force on boot - upstart doesn't (always) give it a tty
<fabbione> BenC: let me try to objdump what was built..
<Kamion> I think I should just make it not run on upgrade
<_ion> kamion: Would "exec </dev/console >/dev/console 2>&1" (as in checkroot.sh) perhaps work?
<_ion> kamion: At least the tty command seems to output /dev/console after that.
<_ion> Some kind of a check for X should naturally be before that.
<rod> is debian-installer in de reps the same as the ncurses ubuntu installer?
<Nafallo> rod: the graphical uses it as well IIRC :-). Kamion maintains that for Ubuntu.
<BenC> fabbione: This is weird, if I run the commands that are run under make by hand, it builds fine (exact file), if I use make, it builds wrong
<fabbione> BenC: WTF
<BenC> fabbione: even if I put the 4 commands that take ultra exec and turns it into ultra.b into a script, it creates a broken image too
<rod> Nafallo: i apt-got debian-installer ... do you know how to start this? lol
<rod> cant find no man pages or nothing
<Nafallo> rod: no :-)
<fabbione> BenC: something broken in the environment?
<Nafallo> rod: you want Kamion for that I guess ;-)
<fabbione> BenC: make does execute /bin/sh -$something on each make like
<fabbione> BenC: and now that one is pointing to dash
<Nafallo> BenC, fabbione: maybe bash vs dash again? :-)
<BenC> AH HA!!!
<BenC> it's fucking dash
<Nafallo> yes ;-)
<_ion> Add "SHELL = /bin/bash" to a broken Makefile.
<_ion> (IIRC)
<BenC> echo -n -e '\340' | dd of=ultra.aout bs=1 count=1 seek=7 conv=notrunc
<fabbione> BenC: does it work now?
<BenC> fabbione: yeah, add SHELL=/bin/bash to Rules.make
<fabbione> BenC: can i remove the patch to first/Makefile ?
<BenC> the echo -n -e '\340' doesn't work right in dash
<BenC> fabbione: yeah
<fabbione> BenC: i wonder if this same issue was screwing up the big initramfs
<fabbione> no.. that can't be the same
<BenC> dash outputs "-e \340" and bash just outputs "\340"
<BenC> why does dash have echo built-in anyway
<_ion> That specific problem can probably be fixed by changing echo to /bin/echo
<fabbione> diff -Naurd silo-1.4.12.orig/ silo-1.4.12 > debian/patches/30-silo_use_bash_because_dash_sucks.patch
<BenC> see, if you remove -e from the normal echo, it doesn't do the \ escaping
<BenC> and in dash, it does do it without the -e
<BenC> that's just broken
<_ion> Oh.
<BenC> one of them isn't working right
<smurf> Kamion: emailed
<_ion> What does POSIX say?
<BenC> no idea
<fabbione> BenC: installing/rebooting now
<Keybuk> http://www.opengroup.org/onlinepubs/009695399/utilities/echo.html
* BenC is just now realizing he'll be gone for two weeks at UDS and allhands
<BenC> wife wont be happy about that
<Keybuk> (POSIX say that echo takes no arguments
<Keybuk> uh, options
<BenC> A string to be written to standard output. If the first operand is -n, or if any of the operands contain a backslash ( '\' ) character, the results are implementation-defined.
<BenC> that sucks
<Keybuk> ah, yes, it does allow for -n only)
<Keybuk> if you want escape sequences, use printf, damnit
<BenC> yeah, seems printf is most appropriate
<zul> allhands?
<BenC> company
<zul> ah
<kristog> interesting to see an italian with german name :) trentino?
<Nafallo> kristog: I think you wanted that on -bugs :-P
<kristog> Nafallo: argh :)
<kristog> thank you
<Nafallo> :-)
* fabbione takes off for the weekend
<Nafallo> fabbione: see you :-)
<lamont> hrm... stupid question time...  how do I format a vfat partition
* lamont discovers mkfs.vfat
<jdub> Keybuk: nice entry
<Riddell> seb128: language packs work for me, do they work for you?
<Keybuk> jdub: which?
<seb128> Riddell: yep
<Riddell> seb128: great, I'll poke the dudes to upload
<seb128> Riddell: thank you
<jdub> Keybuk: TDD + XP
<Keybuk> jdub: that's an old one :p
<jdub> Keybuk: for some reaosn you spammed planet, and i didn't remember thta entry ;)
<Keybuk> changed blog backends
<Keybuk> BenC: got a moment for an odd bug?
<BenC> Keybuk: sure
<Keybuk> bug #61812
<Ubugtu> Malone bug 61812 in upstart "computer won't restart after upstart is installed" [Untriaged,Needs info]  http://launchpad.net/bugs/61812
<Keybuk> he blames upstart, but then people have been blaming that for all sorts of things
<Keybuk> the fact he gets "event queue paused" means that reboot was run
<Keybuk> and the monitor goes black
<Keybuk> which implies to me it's rebooting in the kernel too
<BenC> Keybuk: sounds like a acpi issue, reassign it to linux-source
<BenC> I have a few that I know are kernel and not upstart
<Keybuk> done
<Kamion> _ion: I've solved it a different way, but thanks - the problem was really that the check for X is too hard to do reliably given how badly X explodes if it goes wrong
<_ion> kamion: How did you solve it?
<_ion> Grep process list for X? :-)
<BenC> Riddell: ping
<iwj> mdz, Kamion: ping, we need to talk about update-manager and Breaks
<doko_> Kamion, Keybuk: please could you approve the various kernel and lrm binaries in NEW before the weekend, probably saves us some bug reports
<Riddell> hi BenC 
<BenC> Riddell: this ruby bug is really whacked out
<Riddell> BenC: I entirely agree
<BenC> Riddell: I can reproduce it on davis, but if I copy that same binary to my ppc64, it runs fine...if I build the miniruby on davis as a static bin, it still crashes on davis, but still runs find on my ppc64
<BenC> s/find/fine/
<BenC> so it's not like it's a toolchain issue or even a ruby issue
<BenC> there's no gdb on davis, so I can't tell where it's crashing
<Riddell> poke a sysadmin to install it
<BenC> elmo: ping
<elmo> BenC: done
<BenC> elmo: you rock, thanks
<Nafallo> :-)
<iwj> pitti: This is really crazy.  I can't get this bug to come back at all.
<iwj> I'm going to upload the firefox that seems to WFM now.
<mdz> iwj: pong
<BenC> Riddell: looks like it's crashing in some sort of longjump call
<BenC> why would it crash on those Xserve G5's and not my POWER or G5 machine
<iwj> mdz: Ah, hello.
<iwj> See Malone #54234.
<Ubugtu> Malone bug 54234 in update-manager "update-manager for edgy needs to upgrade dpkg/apt before calculating the upgrade to support the new "breaks" - otherwise the upgrade may fail" [High,Confirmed]  http://launchpad.net/bugs/54234
<iwj> mvo and I think these problems with update-manager seem to be getting rather out of hand, particularly for this stage of the release.
<iwj> I think we need to have some further input from people who are more familiar with all the other constraints, and in general having further clueful input would help.
<elmo> BenC: different kernel?
<iwj> mvo has unfortunately just disappeared for a bit.
<elmo> BenC: davis is running dapper's kernel, but you're working in an edgy chroot - maybe the kernel got fixed/changed?
<mvo> iwj: I'm still here, also half-way into the shower :)
<elmo> BenC: also davis is SMP - are your machines?
<elmo> (the buildds all are too)
<iwj> mvo: That sounds convenient for the electronics in your terminal :-).
<mvo> iwj: its fortunate that we don't use webcam :p
<iwj> pitti: There you go.  I rebuilt epiphany from breezy against it and it just works.  yelp needs a one-line fix.
<iwj> mdz: ...
<tkamppeter> Riddell, are you there?
<mdz> iwj: I'll have a look
<iwj> Thanks.
<Riddell> tkamppeter: hi
<tkamppeter> Yesterday you talked about a problem of printing with KDE
<tkamppeter> What is exactly the problem there?
<Riddell> tkamppeter: I don't know, I've not looked at it yet, I've just been told you can't add new printers in KDE
* mvo is back in a couple of minutes
<tkamppeter> I know about a problem that with the switch of CUPS to 1.2 there was no access more to the list of available printers
<tkamppeter> and this was due to the new domain socket support of CUPS 1.2.
<Riddell> tkamppeter: well we had cups 1.2 in dapper and it worked there
<tkamppeter> You could see the printers in the File->Print dialog, you could actually print, and you could add printers?
<mdz> iwj: commented
<Riddell> tkamppeter: yes
<iwj> mdz: AIUI mvo's problem with putting them on the CD is CD space.
<mdz> iwj: how much space?
<iwj> I don't know.
<mvo> ~4MB for i386
<mvo> I don't have figures for amd64/ppc yet
<mdz> mvo: surely we can find space for that
<tkamppeter> I have no Ubuntu box with KDE handy, I am trying now on Mandriva's Cooker (KDE 3.5.4, CUPS 1.2.3, CUPS also with the Debian patches)
<iwj> mvo: I take it there's no other difficulty ?
<mvo> well
<mvo> they need to be build somehow (dapper-backports is not working AFAIK)
<mvo> or build them "by-hand"
<mvo> and integrate it onto the CD build script
<mvo> but other than that :) no
<fdsd> hey guys, Anyone know why ubuntu ppc live cds spit this out at boot:  [ 39.971898} PCI: cannot allocate resource region 0 of device 0001:10:18.0, Iv tried to modify the kernel used various kernels from 2.6.15 to 2.6.17, any ideas how I can make it not output these errors since the livecds work perfectly otherwise
<iwj> I think we should build them by hand now for testing and of course we should expect backports to be fixed by then.
<mvo> right
<iwj> integrate> SMOP, surely ?
<mvo> the whole network based stuff is working now
<iwj> Excellent.
<mvo> teaching it to look for the backports on the cdrom is not hard
<iwj> I thought there was already an arrangement for `just a tarball' ?
<mvo> integration onto the cdbuild, I don't know :/ 
<mvo> yeah, I did some hacking on this before for the python arch-indep tarball
<dholbach> good night everybody - have a great WE!
<mvo> I think it shouldn't be hard to get this done for the rest too, but I need to investigate first
<mvo> bye dholbach
<iwj> dholbach: G'night.
<mvo> I will do this tonight
<dholbach> bye mvo, iwj
<iwj> I'm sort of worried that this seems to be drifting a bit.  Do we have a coherent plan with a list of all the things that need doing ?  I guess I'm volunteering to make one.
<mvo> I will leave now for about 1h for dinner+shower etc. then I continue on this. I will read scrollback if there is more discussion
<iwj> OK.  I will be departing soon and won't be back here until Monday.
<mvo> iwj: well, the plan is a) get apt/dpkg/python-apt into dapper-backports b) integrate the backports into the cd build c) teach dist-upgrader to deal with the stuff on the cd
<mvo> iwj: but I would certainly appreciate if you could add this to the bugreport in a more coherent way :)
<tkamppeter> On Mandriva 2007 adding printers with KDE works without problems.
<Ubugtu> Mandriva bug 2007 in Installation "Switching to alternate screens during install crashes X" [Normal,Resolved: fixed]  http://qa.mandriva.com/show_bug.cgi?id=2007
<iwj> OK, well, why don't I volunteer to find out about (b) if you tell me where this tarball is going to be made.
<iwj> bugreport> Will do that now.
<tkamppeter> Ubugtu, shut up!
<mvo> iwj: the tarball is added via debian-cd, see "bzr get http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/"
<mvo> iwj: then "tools/edgy/upgrade.sh"
<iwj> So the difficulty is getting the backports into the tarball ?
<mvo> no, I think we shouldn't put it into the tarbal itself, but rather add a additional directory to the CD
<mvo> afterall sysadmin who want to do the upgrade by-hand will need it too
<iwj> They can untar the tarball.
<iwj> That was the point of having a tarball.
<mvo> well, not exactly
<mvo> the tarball has (currently) arch-indep files
<iwj> Wasn't it ?  That there would be one thing with all the update-manager bits and bobs in it ?
<mvo> and I see no point in taring up deb, there is no benefit (unless I overlook something)
<iwj> You want a separate arch-dep tarball ?
<mvo> no :)
<mvo> just the debs in e.g. CDROM_ROOT/upgrades
<iwj> Well, it turns them into a single file which is nice and tractable compared to a pile of stuff with a particular structure.
<mvo> or something like this
<iwj> Since we already have stuff for downloading this tarball or getting it from CD and for building it and so on.
<mvo> IIRC a old debian cd had something like this, maybe potato?
<iwj> But if having a pile of files rather than a tarball isn't a problem then fine.
<mvo> right, well. maybe just CDROM_ROOT/dists/edgy/main/dist-upgrader/binary-$arch and then put the debs into that?
<Riddell> tkamppeter: it may well be just some kubuntu users, as I say I've not tried it myself
<Riddell> and I'm about to leave for ireland so I can't just now
<iwj> mvo: Does it matter ?  Just do something, surely.
<mvo> iwj: to a certain extend. the current dist-upgrader code assumes it is apt-get'able in the sense that it has a valid Packages.gz file 
<mvo> iwj: this makes the whole thing easier as I can reuse the acquire code in apt/python-apt to get the files onto the local-fs
<iwj> mvo: Err, OK.  I don't know about this.  What I mean is, just do what you think is best ?  Is there any difficulty here ?
<tkamppeter> I have done "apt-get install kdebase" on Ubuntu now, to add KDE and then I have started "kcontrol" from the command line.
<mvo> iwj: SMOP + testing
<tkamppeter> Then I have entered the print manager, chosen admin mode (button at the bottom)
<iwj> Right.
<tkamppeter> As password I have entered my own password.
<mvo> I keep hacking on it tonight, I expect the first usable version that fully supports Breaks tonight
* mvo is away now for real
<iwj> Goodnight, and thanks.
<tkamppeter> Then I have chosen "Add printer" at the top and followed the wizard (For HP printers select entries under "Others" in "Local printer", to get HPLIP support)
<tkamppeter> Test page worked, queue was created. No problem.
<iwj> Right, that's me gone as well.  Goodnight everyone, and thanks mdz.
<fdsd> anyone know how to generate ascii art so I can make an ubuntu logo for the powerpc ofboot.b file?
<tkamppeter> Under Ubuntu you even do not need admin mode of the print manager, as the first (and also other privileged users can create queues as normal user), so no passwords need to be entered to create queues with KDE.
<mdz> night iwj
<_ion> nafallo: bug #61925
<Ubugtu> Malone bug 61925 in mplayer "doesn't remove obsolete /etc/mplayer/codecs.conf" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/61925
<Nafallo> _ion: I know, it's a bit more tricky than just removing :-)
<_ion> nafallo: Did you read the script i posted?
<Nafallo> _ion: ah, will do :-)
<Riddell> tkamppeter: so sounding promising :)
<fdsd> hey guys, what replaced rc.local in edgy knot3?
<Nafallo> _ion: nice, thanks :-)
<BenC> elmo: My POWER ibm box is SMP
<BenC> I can try booting a dapper kernel
<robertj_> is the new compa package for upstart going to be default for edgy?
<robertj_> %s/compa/compat
<Keybuk> it is default now
<tkamppeter> Riddell, seems that the bug is between the user's chair and his keyboard.
<BenC> Riddell, elmo: Sweet, it's a kernel bug...if I boot into 2.6.15-27,it suddenly segfaults
<BenC> very odd that happens though
<mikefoo> I have a 14 drive raid5 array and its doing ~90Mbit/s seems to be bottle necking, a simply ls on the array hangs for 2-3 seconds. It is 95% wrties, is this the sheer bottle neck of raid5 due to all thr writes?
<Nafallo> mikefoo: Hi! This channel is for developing of Ubuntu. You might find an answer on our support channel: #ubuntu.
* Keybuk tries to persuade Typo not to keep publishing the article he's only saving because Firefox sucks
<Burgwork> evand, ping
<Kamion> _ion: no, I made console-setup just not reconfigure the console on upgrade, deferring it until the next time you boot, and print a message to that effect
<jdong> Kamion: regarding 'black hole backports', what do we need to do to get them to show up?
<jdong> (i.e. the ones that binary-rejected)
<jdong> xchat, kopete, I'm most interested in at the moment
<jdong> they build successfully but never made it out alive :)
<Fjodor> BenC: Sorry to say, but last entry on bug 36014 still doesn't resolve it for me...
<Ubugtu> Malone bug 36014 in linux-source-2.6.15 "kernel can't scale cpu frequency" [Medium,Confirmed]  http://launchpad.net/bugs/36014
<BenC> Fjodor: ok
<Kamion> jdong: I should be able to resurrect them, given ten minutes of poking about
<Fjodor> BenC: Has something specifically for this been done to the next version? I notice that current archive sources are 8.22, but changelog goes to 9.23. Should I get my hopes up? ;-)
<Kamion> I've done it before anyway
<jdong> Kamion: sure, no hurry at all
<pygi> Keybuk: you forgot libburn :)
<BenC> Fjodor: 9.23 is uploaded
<BenC> Fjodor: we had a lot of acpi updates that I was hoping would take care of it
<Kamion> jdong: does this list look plausible: amarok bluefish checkinstall config-manager debootstrap emacs-snapshot flashplugin-nonfree gcin gxine kbarcode kbfx krusader ktorrent mod-cband mplayerplug-in powersave rsibreak seahorse spamassassin taglib xchat xmoto
<Keybuk> pygi: it's the list of things that *I* want to see ;)
<Keybuk> I was vaguely hoping other people would start blogging about what *they* want to see
<jdong> Kamion: that does look entirely plausible :)
<pygi> Keybuk: I'm not on planet :P
<Kamion> that's the list of rejected packages with version numbers matching *~dapper*
<Keybuk> pygi: add yourself :
<Kamion> the oldest is 20060824
<Keybuk> :p
<pygi> Keybuk: perhaps :)
<Fjodor> BenC: Ok, I'll grab that and check then :-)
<jdong> Kamion: though somethings [amarok]  might be superceded already anyway
<Kamion> I think those should be discarded
<Kamion> (automatically)
<jdong> yeah
<jdong> ok
<jdong> then fire away :)
<Kamion> Keybuk: sanity-check? (if I reprocess old binary uploads some of which no longer have source in the archive, they'll be rejected?)
<pygi> Keybuk: so now you are making add myself to the planet :P
<Keybuk> Kamion: not that I'm aware
* Kamion wonders why there are a bunch of empty directories from (only) 20060823 in /srv/launchpad.net/builddmaster/incoming/
<Kamion> Keybuk: or otherwise safely ignored
<Kamion> maybe I'd better read the code
<Fjodor> BenC: Mind you that packages.ubuntu.com is still at 8.22, but offers .dsc and tar.gz for 9.23. I'll get those and dpkg-source -x and dpkg-buildpackage -rfakeroot
<BenC> Fjodor: the 9.23 binaries are on archive.ubuntu.com
<jdong> Kamion: well, I know for sure the dpkg-scanpackage or whatever code that you'd use to build a home-brew APT repository ignores older versions automagically
<Fjodor> BenC: Great. Didn't know of that one. Thanks
<BenC> Fjodor: it's the one that apt uses :)
<Fjodor> :-)
<Keybuk> Kamion: it'd be worth trying <g>
<Keybuk> let me know how that goes (tm)
<BenC> Fjodor: apt-get update; apt-get install linux-generic
<LaserJock> who's NEW day is it?
<Kamion> Keybuk: ah, there *is* a reject for source not being found, and it checks the version
<Kamion> LaserJock: mine, gimme a few minutes
<jdong> BenC: I still haven't gotten -9 yet
<Kamion> jdong: um, yeah, Soyuz is a bit more complicated than that :)
<BenC> weird, it's all built
<jdong> Kamion: I'd imagine :)
<Kamion> I don't want to explode the db, but it looks like uploading ancient binaries is perfectly safe
<jdong> BenC: linux-image-2.6.17-9-generic has no installation candidate
<LaserJock> Kamion: np, you guys both start with K so I can never remember who does which day ;-)
<Fjodor> BenC: Ok
<Kamion> Keybuk: (fortunately, I know where most of the interesting rejects live)
<Fjodor> BenC: Ah, there you have it. I wanted the source to build it myself :-)
<BenC> Fjodor: if you like uneeded pain, be my guest :)
<Fjodor> BenC: Actually, I do, but that's just me :-)
<BenC> Fjodor: be warned, I don't support self built stuff
<BenC> if you want help with the bug, you need to run what I upload at least for tests and debug that I request in the bug report
<Fjodor> BenC: Ok, I'll keep in mind, but hey, it might just work, and then I figure you wouldn't mind a positive status report, right?
<BenC> Fjodor: correct :)
<BenC> jdong: I see -9-powerpc
<BenC> wonder if i386 is still lagging behind
<jdong> BenC: the metapackages are all there and ready to go, but the actual packages aren't in the archives yet
<jdong> don't new kernels have to be approved through the NEW queue?
<Kamion> if the ABI changes, yes
<Kamion> i386 is probably lagging, because it wasn't there when I did some NEW processing earlier
<Kamion> I'll do it after this backport MADNESS
<Kamion> commands like this should not be required on production systems :P
<tseng> infinity: can you please look at beagle 0.2.9 builds? some archs had chroot problems
<Kamion> BenC: um, I don't need -server-di udebs
<Kamion> BenC: I want -386-di and -generic-di
<Kamion> I'll process this for now of course, but I think that should be changed
<BenC> Kamion: wow, I totally screwed that up
<BenC> Kamion: fixed in repo, so next upload
<Kamion> thanks
<Kamion> BenC: that probably goes for l-r-m too, although i386 for that isn't in NEW yet of course
<BenC> ok
<BenC> any one know why i386 was so backlogged last night?
<BenC> all the other architectures were done build the new kernel before i386 even started
<Keybuk> BenC: openoffice, openoffice, oh, and  another openoffice
<Kamion> jdong: ok, I think I've managed to resurrect all those backports binary uploads
<shining> how long did oo build take ?
<Nafallo> Keybuk: dokoDoS indeed ;-)
<Kamion> shining: you can see that information in the launchpad web UI, if you grub around
<Nafallo> shining: 14+12h IIRC
<Kamion> there's a build log for each binary - somewhere around there
<shining> Nafallo: lovely
<Nafallo> isn't it? ;-)
<shining> I'm curious if it fails sometimes, because that would be even more fun I guess
<Nafallo> shining: it does, and yesterday I think it built and then swallowed the binaries or something like that :-)
<jdong> Kamion: thanks very much :)
<BenC> Keybuk: Do I need to put a "kill openoffice build" script in the kernel source? :)
<shining> lol
<shining> and yep, actually it seems there has been quite a few problems, already ubuntu6
<jdong> shining: namely, unpluggin the red lights on the dashboard (SSP) because their constant blinking is annoying us?
<jdong> turn on SSP for the packages that don't buffer overflow, and shut off SSP when it trips :)
<Keybuk> BenC: wouldn't work
<Keybuk> obviously
<_ion> nVidia released a beta driver with AIGLX support. http://www.nzone.com/object/nzone_downloads_linux_display_x86_1.0-9625.html
<_ion> GLX_EXT_texture_from_pixmap support, to be exact.
<_ion> Is there a slightest chance of that getting to edgy?
<Seveas> mjg59, you still awake?
<jdong> _ion: a beta nvidia driver :D
* Nafallo just laughs at beta + edgy in the same phrase ;-)
<_ion> jdong: As an alternative to the default driver that is.
<Nafallo> atleast when it comes to unfree drivers :-)
<jdong> _ion: that sounds like _a lot_ of work :)
<_ion> How about if it gets out of beta soon? :-)
<Nafallo> _ion: maybe if you manage to persuade sabdfl :-P
<mvo> Kamion: I would like to talk to you about the whole "support Breaks during upgrades" business. to support this on the CD we need a backport for dpkg/apt/python-apt on the CD. because dapper-backports is currently not fully working I put those backports on my people.u.c account. I guess I can't add those packages to the cdbuild script unless they are in the official archive, right?
<Kamion> mvo: can, but I'd rather not, obviously
<Kamion> mvo: the 4MB on the CD is going to be a hassle, but necessary, I guess :(
<mvo> yeah :/
<jdong> mvo: dapper-backports basically works now, to my knowledge
<geser> Kamion: hello, I'm trying to find a sponsored upload targeting dapper-updates as it isn't on the archive yet. where do I look?
<jdong> mvo: and I believe all core-devs can upload to it manually, too
<Kamion> jdong's right
<Kamion> geser: sorry, could you please rephrase? I don't understand
<mvo> so the previous problems are all fixed now? great to hear!
<pygi> Kamion: I believe he wants someone to sponsor upload of his package to dapper-updates
<Kamion> um, backporting dpkg is going to be kind of interesting
<geser> Kamion: crimsun sponsored an upload of php4-yaz for me to be included in dapper-updates
<mvo> Kamion: its either the addional 4mb or no Breaks until edgy+1. choosing the later would save me quite a bit hassle, but iwj will not like this :)
<Kamion> do we actually want *everything* in new dpkg to be available for general use by dapper-backports users?
<mvo> Kamion: why? the only problem I had was with selinux but apparently iwj fixed that
<geser> Kamion: as it isn't available yet I'm trying to find out why
<Kamion> geser: dapper-updates is always held for manual approval, and that was shut down for the X business
<Kamion> geser: I believe we can open it up again now, but I want to double-check with mdz first
<Kamion> so please be patient
<geser> ok
<Kamion> mvo: the udeb shlibs stuff?
<mvo> Kamion: now that is a pretty good question. in my view we need either the full stack (dpkg/apt/aptitude/synaptic/adept etc) or nothing. but if nothing, then what to do for the people who want a clean upgrade
<mvo> Kamion: uh, no idea about that
<Kamion> I was more wondering if it was possible just to backport the feature we need
<mvo> right
<geser> Kamion: is the queue visible somewhere?
<mvo> at least for the breaks stuff in apt that should be possible and straightforward
<Kamion> geser: can you see https://launchpad.net/distros/ubuntu/dapper/+queue?queue_state=1&queue_text= ?
<Kamion> don't worry about the accept/reject buttons if you have them - they won't actually work for you
<jdong> Kamion: I don't think mortals can access that :)
<geser> Kamion: no, I can't see it
<Kamion> ok, then no
<Kamion> there are 28 items in it FWIW
<Kamion> php4-yaz is there
<geser> thanks for the info
<_ion> Could someone enlighten me: in what situations do two instances of the same file en up in dpkg/status Conffiles section?
<Kamion> mvo: I'm just a little worried really, there are 700 lines of changes in the dpkg changelog since dapper
<Kamion> mvo: I think this might be the first test case for manual core-dev uploads to backports
<mvo> Kamion: apt is pretty bad as well, lots of new code. 
<mdz> Kamion: hmm?
<Kamion> I know we're only promoting it for Breaks, but people will install it on normal systems
<Kamion> mdz: ?
<mdz> Kamion: double-check about what...ah, dapper-updates
<Kamion> mdz: right, I know StableReleaseUpdates is there now
<mdz> Kamion: yes, that's in full effect now
<mvo> Kamion: make that dapper-backports
<Kamion> just wanted to check that we could start cautiously letting things through that met the policy
<Kamion> mvo: two parallel discussions here
<mvo> aha, ok. sorry
<mdz> Kamion: the batch of stuff from Martin was the test run of the policy, and it seemed to work well
<Kamion> ah, hadn't seen that
<mdz> Kamion: my approval is on the bugs
<mdz> so the updates I approved should go through
<Kamion> mdz: SRU goes for universe too?
<mdz> Kamion: good question
<Kamion> php4-yaz being an example
<mdz> that's something we should discuss with MOTU
<Kamion> ok
* jdong personally thinks it should apply to universe
<mdz> most likely it should follow the same process with different names
<jdong> or something along the lines of SRU
<Kamion> wow, I'm kind of glad I didn't have to go through SRU for the dapper.1 ubiquity rush, though
<Kamion> though more enforced review of those changes might not have been a bad thing, of course
<Kamion> pygi: did Keybuk talk with you about the libburn package names?
<Keybuk> no?
<pygi> Kamion: not actually
<pygi> Kamion: was he supposed to?
<Keybuk> well, they're wrong, aren't they?
<pygi> Keybuk: dunno :)
<pygi> I'm not their maintainer :)
<pygi> (in Ubuntu)
<Kamion> oh, I didn't even look
<Keybuk> right, ivoks uploaded them
<Keybuk> and I've not seen him around yet
<Kamion> nod
<pygi> so if names are wrong, you'll have to discuss that with him :)
<pygi> If there are bugs in libburn, then poke me :)
<Keybuk> the funny thing is, he reverted names that were right
<pygi> heh :-/
<Kamion> they did need to be changed, as there was a new soname
<Keybuk> yes, but he just dropped soname naming altogether
<Kamion> I also didn't get why there was a "-" in the old names
<Kamion> should've been libburn1 surely, not libburn-1
<Keybuk> indeed
<Keybuk> should be libburn2 and libisofs2 now
* pygi think he'll take over those libburn packages when he can get his gpg keys signed =)
<pygi> that would probably be the best I take it
<Kamion> it's up to you - some people prefer to work with a downstream for packaging
<dieman> arugh. i have to make my own d-i initrd.
<dieman> garwr.
<dieman> Kamion: where can I find the debian-installer source package that built the point release images?
<dieman> n/m
<dieman> i may have found them
<Kamion> should be in dapper-updates
<dieman> yeah
<dieman> i couldn't find them on packages.ubuntu.com
<Kamion> it may not be configured to look at dapper-updates
<dieman> but thats just because its not the entire list of everything
<dieman> yeah
<Kamion> oh dear god, ruby1.8 uses macros with unbalanced braces
* Kamion cries
<dieman> aurghgh
<dieman> ok, yeah, this looks like the right one
<dieman> arugh, no bnx2 in 2.6.15-17 udeb nic-modules.
#ubuntu-devel 2006-09-23
<jdong> guess who just booted into new kernel... without realizing l-r-m isn't there yet :)
<dieman> doh :)
<majyk> have to say Knot 3 is sweet, my only beef is that today I had some upgrades that said a distribution upgrade was needed, doing so went just fine but I can't figure out why it had to remove xchat. I reinstalled it but that doesn't make much sense.
<majyk> just thought I'd point that out, to the normal joe it makes no sense to uninstall an app that is not related to the upgrade
<shackan> joe shouldn't be using edgy for that matter
<mvo> majyk: thanks for your report, but as shackan rightfully pointed out, edgy is still a development distro so things like this may happen
<majyk> yeah, I know
<mvo> on a stable system, the update-manager should never have to invoke the dist-upgrade-super-powers :)
<dieman> yeah
<dieman> dist-upgrade is super bad in cases like that
<wasabi__> Howdy. So. I'm going to embark on a network Apt thingy. The goal will be: point ubuntu systems at a local corporate Apt server, provide a web interface which proxies/caches to Ubuntu Central apt, and reporting abilities for each client to notify the server what updates it requies, and a web interface for the server admin to approve specific updates for delivery to clients. 
<wasabi__> There are pieces of this already in existance, non of the approval/disprove management interface thing.
<wasabi__> My first problem: I need a name. =(
<GyrosGeier> \o/
<GyrosGeier> is there an update planned for dapper for the issue described in http://www.ubuntuforums.org/showthread.php?t=189525&highlight=%22localhost%3A631%22
<mdz> wasabi__: sounds like NetworkWideUpdates
<mvo> wasabi__: you know that spec we have written for this?
<wasabi__> Nope. I did a quick search but didn't find it.
<mvo> wasabi__: have a look at https://wiki.ubuntu.com/NetworkWideUpdates
<Kamion> owowowow, ruby uses setjmp and threads
<wasabi__> k
<Nafallo> wasabi: that's totally NWU :-)
* Kamion puts his extra-thick thinking cap on
<mdz> Kamion: this is sounding worse by the hour
<mvo> wasabi__: someone even started to write code for this (well, I did for a first version but that was dumped later :)
<Nafallo> wasabi: just to make people confused with NVU ofcourse :-)
<mvo> hehe
<Kamion> mdz: I already put a suggestion for a workaround in the bug
<Kamion> although I haven't tried it yet
<mdz> next it'll be "ruby uses hackerlab" followed by "Kamion has quit (aieeeeeeeeeeee)"
<mvo> lol
<Nafallo> haha
<wasabi__> I was pretty much just planning to implement it with a simple apt proxy (auto generate releases, packages, etc, containing only approved packages), and a cron on the client to pull.
<wasabi__> apt-get dist-upgrade, nothing else.
<wasabi__> Not even going to attempt to deal with pushing, or anything more complicated. I personally don't think it's neccessary.
<mvo> wasabi__: if you are not afraid of using bazaar, there is a starting point for this in http://people.ubuntu.com/~mvo/arch/ubuntu/auto-pkg-update--main--0/
<wasabi__> I think the rest of the stuff, pushing config file updates, etc... no reason those couldn't be handled by using the service to push custom .debs
* Nafallo wishes mvo could upgrade his old branches to current bzr ;-)
<Kamion> there are a bunch of workarounds for crazy setjmp/getcontext-related register shit for certain architectures in eval.c; perhaps they just need to be augmented
<wasabi__> me->home
<Kamion> oh wow, some of this is absolute perverted genius
<Kamion> they had a problem wherein getcontext wasn't preserving the register stack/window
<Kamion> but gcc didn't know about this so wasn't generating safe code
<Kamion> so in order to work around this, they noted that setjmp has the same property and gcc *does* know about it, so they stuck setjmp calls either side of the getcontext which are never called (0 ? setjmp : 0) in order to persuade gcc to generate safe code
<Kamion> I can't decide whether this makes me want to use ruby more or less
<_ion> How pretty. :-)
* _ion wants ruby 2.0
<Nafallo> Soyuz still can't build from incoming I guess? :-/
<Kamion> no
<Nafallo> any ETA on that feature?
<Kamion> edgy-ish, I think
<Nafallo> oh, that would be now :-)
<Kamion> probably only for security though
<Kamion> that's where it really matters
<mdz> it'll do it for everything
<Kamion> aha
<mdz> and we'll likely get that before security-in-soyuz
<Nafallo> yay! :-)
<Nafallo> that's sounds good then :-)
<mdz> this is https://features.launchpad.net/products/soyuz/+spec/build-unpublished-source
* Nafallo subs
<Fjodor> BenC: Sorry, can't give the thumbs-up wrt to bug 36014
<Ubugtu> Malone bug 36014 in linux-source-2.6.15 "kernel can't scale cpu frequency" [Medium,Confirmed]  http://launchpad.net/bugs/36014
<Fjodor> I have my own reasons for going the compile-your-own route, so it might work for others. Just hoped I could give you a positive report
<treitter> mjg59: are there any detailed documents on usplash?
<pygi> night
<treitter> all I can seem to find is the bare Wiki page, the Customization document, and /usr/share/docs/usplash/*
<mdz> treitter: you forgot about the source code ;-)
<treitter> mdz: delightful :)
<treitter> Seveas: do you know if it's possible to turn off the progress bar and text field in usplash-0.2?
<mvo> mdz: I added what is required to make the dist-upgrade tarball self-contained to bug #54234
<Ubugtu> Malone bug 54234 in update-manager "update-manager for edgy needs to upgrade dpkg/apt before calculating the upgrade to support the new "breaks" - otherwise the upgrade may fail" [High,In progress]  http://launchpad.net/bugs/54234
* jdong kicks launchpad in hopes that a linux-restricted-modules package would fall out :)
* mvo goes to bed
<Kamion> jdong: your wish is my commanda
<Kamion> er, command
<jdong> Kamion: if we ever meet in person, I owe you some alcoholic beverages :)
<Kamion> ok, console-setup clearly isn't going to build any faster if I sit here watching it, so I'm going to bed
<Kamion> jdong: cheers :)
<jdong> good night, Kamion
<Kamion> mdz: my last two beta-relevant bugs are fixed on my hard disk, I believe, but I want to test them first (console-setup.config changes)
<Kamion> I've mopped up everything on cdimage I care about, which wasn't too much
<Kamion> (done ogra's edubuntu netcfg preseeding change)
<Kamion> debian-installer and ubiquity need final uploads at some point; ubiquity needs a bit of a tweak to fix that console-setup bug from knot-3, which relies on the console-setup changes I'm preparing now
<Kamion> d-i of course needs a kernel ABI bump; I'm deferring that until I've uploaded console-setup though, to save on d-i uploads
<Nafallo> mdz: I have a problem with mplayer (you marked it as a milestone), some amd64-assembler I get scared of makes it FTBFS :-). and I don't even have an amd64 myself.
* Kamion completes his brain dump and goes to bed
<Nafallo> Kamion: gnight :-)
<Kamion> mdz: oh, I'll be around extremely little at the weekend; maybe stopping in to upload console-setup at most
<Kamion> we've hired a van and are going to be busy shunting stuff to the new place
<Nafallo> Kamion: oh, you're moving again? :-)
<Kamion> somewhat extended move over the course of a week or two, yes
<Nafallo> nice :-)
<StevenK> Kamion: Yuck.
<StevenK> Kamion: A move is something you want get over with quickly.
<StevenK> s/want/want to/
<Nafallo> StevenK: depends on when the Internet starts working on the new place ;-)
<StevenK> Heh
<desrt> wow.  -9 already.
<desrt> exciting times
<jdong> desrt: careful, last time I tried restricted modules aren't there yet :)
<jdong> that was a very Dapper-reminiscent X-less reboot :)
<desrt> you are right
<Kamion> Internet> that would be late next week, unfortunately
<Kamion> so I shall be obliged to commute to the old house for work for a while
<Kamion> anyway, sleep required
<Nafallo> Kamion: maybe you can find some nice WLANs :-), yea gnight again :-)
<jdub> Kamion: good to have an office ;)
<mdz> Nafallo: I marked it for beta because a lot of folks will upgrade, and we'll get a lot more bug reports if mplayer breaks
<mdz> Kamion: nice, thanks
<Nafallo> mdz: yea, everything !amd64 should be fine now :-)
<Nafallo> mdz: I'll guess doko or Tollef might be good advisers on that FTBFS, right? :-)
<mdz> Nafallo: worth a try
<Nafallo> oki, I'll try to catch them tomorrow then :-). thanks.
* Nafallo > sleep
<bddebian> Howdy
<Fujitsu> Hi bddebian.
<bddebian> Heya Fujitsu
* robertj_ is in trouble now. grub autoconfig ate my wifes menu.lst :{
<bddebian> Uh oh :-)
<robertj_> I thought we made a deal with the devil that if you didn't touch menu.lst it wouldn't break :)
<robertj_> for some reason groot is showing as 0,1 now instead of 0,0
<robertj_> any kernel updates go in that affect drive naming?
* Hobbsee wonders how you debug an X not starting problem
<desrt> Hobbsee; as root, type X
<desrt> Hobbsee; then look at /var/log/Xorg.0.log
<desrt> (if the console output itself isn't good enough)
<Hobbsee> desrt: ahhh :)  X will start the X session, presumably
<desrt> it X started then it's some other problem caused by the use of a strange non-gnome desktop environment
<desrt> no.  X will just start the raw X server alone
* Hobbsee nods
<desrt> you need 'startx' if you want your session
<Hobbsee> desrt: does the /var/log/Xorg.0.log get rewritten on reboot?
<Hobbsee> yeah, startx is no good - i get a blank screen, and cant get back to a console
<desrt> it gets rewritten whenever the X server attempts to start
<Hobbsee> bugger
<desrt> oh.  that sounds like an X crash
<Hobbsee> due to the -8 kernel
<Hobbsee> same with kdm starting up normally
<desrt> assuming your disks synched ok, then restart in recovery and your Xorg.0.log should be from the crashed X instance
<desrt> failing that, ssh in
<Hobbsee> it'll show the spash screen, and then go blank.  useful of it
* Hobbsee nods
<Hobbsee> cant ssh easily - no ssh on the other machines
<Hobbsee> and i've never figured out putty
<desrt> it's pretty extremely easy
<desrt> you just download and run the .exe directly
<desrt> put in the IP address
<desrt> (done)
<Hobbsee> ahh, by IP address.  gotcha
* Hobbsee ssh's out a lot, but not in
<desrt> or hostname if you've got dns setup
<Hobbsee> anyway, thanks, will go and grab that log
* Hobbsee hopes the log doesnt get wiped by hitting the power button to force the machine off
<desrt> the only risk is that it will be stuck in the buffercache and won't have made it to disk yet
<Hobbsee> right
<desrt> got a sysrq key?
<Hobbsee> er, yes
<desrt> alt+sysrq+s will force a sync
<Hobbsee> i've never figured out what it does though :P
<desrt> hit that a couple of times before you hit the power
<desrt> and wait a few seconds
<Hobbsee> okay, cool
* Hobbsee nods
<Hobbsee> thanks heaps :)
<desrt> np.
<desrt> btw -- i wonder if you know that -9 is already out?
<Hobbsee> hey wait
<Hobbsee> yes, same problem
* desrt hey waits
<Hobbsee> the /var/log/Xorg.0.log.old is the log from -9
<desrt> Xorg.0.log... not .old
<desrt> .old is from the 2nd last run
<Hobbsee> yes - and i'm booted to -7 at the moment
<Hobbsee> -9 is one of the broken ones :)
<desrt> oh.  i see
<Hobbsee> so i suspect that's what i want
<desrt> yes
<Hobbsee> http://rafb.net/paste/results/psGXdi87.html
<desrt> if you start X then .0.log will be from the currently-running one
* desrt assumed you were doing it from the console :)
<desrt> (II) I810(0): detected 16252 kB stolen memory.
<desrt> last line?
<Hobbsee> desrt: once i've tried to start X from the console on any newer kernels, i get a blank screen that i cant get out of
<Hobbsee> so i wouldnt be doing that, no :P
<Hobbsee> er, okay?
<desrt> Hobbsee; but you could boot the newer kernel in recovery mode (in which case X doesn't start)
<Hobbsee> what's that mean?
<Hobbsee> true
<desrt> Hobbsee; i mean... is that the last line of your paste?
<Hobbsee> desrt: yes. taht's the last line in the log
<desrt> ow.
<Hobbsee> of course, i may have hit power too early.  *shrugs*
<desrt> compare with the Xorg.0.log from -7
<desrt> does it have that line?
<Hobbsee> http://rafb.net/paste/results/V3ZSeQ47.html
<Hobbsee> yep
<desrt> also -- are you positive the break happened -7 -> -8 and not -8 -> -9?  ben merged a bunch of new drm/agp code into -9 that would be a likely breaker
<Hobbsee> (line 409)
<Hobbsee> absolutely - well, it could have broken in -8 *and* -9, of course
<Hobbsee> my -7 works, my -8 doesnt :)
<desrt> ok.
<desrt> i don't see any relevant changes between those two
<Hobbsee> and the only thing i dont have upgraded is xserver-xorg-input-synaptics
<Hobbsee>   Installed: 0.14.6-0ubuntu2
<Hobbsee>   Candidate: 0.14.6-0ubuntu3
<Hobbsee> because it sends my touchpad on crack.
<desrt> lemme try something
<desrt> OH CURSE YOU
<desrt> the words "touchpad on crack" just triggered my touchpad's intermitent crack-induced behaviour
<Hobbsee> hehe, sorry :(
* Hobbsee hands desrt a USB mouse
<desrt> ok.  what driver do you get in the kernel?  i810?
<Hobbsee> i dont remember - the video one, found in lspci i presume?
<desrt> lsmod | grep drm
<Hobbsee> drm                    74196  3 i915
<Hobbsee> agpgart                33992  3 drm,intel_agp
<desrt> ok.  move that module out of the way (to ~ or something) from the 2.6.17-9 modules tree
<Hobbsee> desrt: er, how?
<Hobbsee> sorry, my X doesnt tend to break
<Hobbsee> i'm not very used to debugging such problems :P
<desrt> you should have a file /lib/modules/2.6.17-9-generic/kernel/drivers/char/drm/i915.ko
<desrt> mv it to your ~
<desrt> then boot into the -9-generic kernel and see if X still crashes
<Hobbsee> okay, will do.
<desrt> doing that effectively removes the kernel's support for your card and gives you just straight-up X.  since it seems to be a kernel problem that might stop the crashing
<Hobbsee> recovery mode?
<Hobbsee> right
<Hobbsee> or just normal, i guess
<desrt> normal mode should be fine as long as you make sure that module is moved out of the way
<Hobbsee> yep
<Hobbsee> okay, back in a bit
* Hobbsee needs another computer
* Hobbsee notes that dad explicitly told her that she couldnt borrow his new laptop :P
<Hobbsee> desrt: it still dies, with that module removed
<desrt> crud
<Hobbsee> yes
<Hobbsee> (is in a virtual terminal, not having separately tried to start X
<desrt> it's really weird that a kernel  ugprade would do that when clearly it's not the kernel driver at fault :(
<Hobbsee> rather, yes
<desrt> hmm?
<realist> kernel upgrade killed my X setup too ;p
<realist> clobbered my manually compiled modules
<desrt> oh.  the two of you need to figure this out then :p
<desrt> since my X is just peachy :)
<desrt> (for once)
<Hobbsee> yet, it has to be something related to that, as -7 works, -8 and -9 dont - i've been running -7 even after i found -{8,9} dont boot
<Hobbsee> s/boot/run X/g
<realist> I had to remove the ubuntu packaged modules, and replace them with my custom ones
* Hobbsee has never played with her X
<desrt> how... gentoo of you
<desrt> :)
<realist> desrt: it was necessary for my hardware / binary drivers
<fabbione> Hobbsee: can you try to comment out dri from xorg.conf ?
<fabbione> Hobbsee: usually kernel + X crash is related to dri.. it's worth to give it a shot
<desrt> fabbione; no DRI module it loaded :(
<fabbione> desrt: i want X to not init dri.. not from the kenel
<fabbione> kernel
<RootBeet> What is Ubuntu's primary target? Commercial users or Home users?
<fabbione> RootBeet: Bill Gate's workstation
<desrt> RootBeet; definitely the wrong forum for questions like this
<Hobbsee> fabbione: i'll give it a try, i'll probably lose this irc again though
<desrt> Hobbsee; steal your dad's laptop :p
<fabbione> Hobbsee: no problem.. it's worth a shot
<Hobbsee> right
<desrt> "don't irc as root"
<Hobbsee> (i'm in recovery mode)
<desrt> irssi.  a prudent choice.  :)
<Hobbsee> but yeah, as a general rule, i dont :P
<Hobbsee> no X, remember?
<Hobbsee> :P
<desrt> oh.  it's working?
<Hobbsee> havent tried
* desrt read that as "no.  X, remember?"
<desrt> nm :)
<RootBeet> ok thanks anyway... I use XP but was considering ubuntu.
<fabbione> RootBeet: you might want to ask in #ubuntu
<desrt> RootBeet; you'd probably get better answers in #ubuntu
<Hobbsee> desrt:  interesting, now that does work, using startx, with the dri module commented out, as fabbione suggested
* desrt gives fabbione secret handshak
<fabbione> that's probably thea better forum
* Hobbsee wonders what would happen with trying to put the other module back in
<RootBeet> ok.
<desrt> Hobbsee; lsmod | grep i915
<desrt> just to make sure it's really not loaded
<Hobbsee> desrt: returns empty
<fabbione> Hobbsee: even if you load the i915 kernel module it should work.. X is just not initializing dri
<desrt> try 'modprobe i915'
<desrt> should give an error?
<Hobbsee> yep, no such file or directory
<fabbione> desrt: you suggested her to move it away.. she will have to put it back... depmod -a and modprobe
<desrt> totally weird.
<fabbione> Hobbsee: ^^^
<fabbione> move it back
<fabbione> depmod -a
<fabbione> modprobe
<desrt> fabbione; i wanted to see the error, actually :)
* Hobbsee nods
<Hobbsee> desrt: well, i can write it out - i've got no real way of copying it that i know about :P
<Hobbsee> well, easily anyway
* fabbione hands desrt a G5
<Chipzz> Hobbsee: use screen
<desrt> it seems really odd that the X server can crash, dependent on kernel version, initialising DRI, even when the DRI module is not loaded
<desrt> fabbione; :)
<Chipzz> Hobbsee: you can dan ctrl-a,[ to copy
<Chipzz> Hobbsee: and ctrl-a,]  to paste
<fabbione> desrt: it's not weird.. DRI always attempt a load...
<Chipzz> s/dan/tehn/
<Chipzz> s/dan/then/
<desrt> fabbione; which will fail since the module is not there
<fabbione> desrt: even if later it decides that's not wise
<fabbione> desrt: and crash as it seems
<desrt> fabbione; i'd be fine if it was a non-kernel-version-dependent crash.....
<desrt> just blame it on crappy X drivers
* fabbione looks in a mirror and repeats to himself: "YOU DO NOT KNOW X! SHUTUP"
<Hobbsee> Chipzz: i'm using that :P
<desrt> fabbione; :p
<Hobbsee> fabbione: sure you do :P
<fabbione> no i don't
<fabbione> no i don't
<desrt> fabbione; you knew enough to have a better guess at a fix than i did :)
<fabbione> NOT AGAIN.. ALL THESE VOICES... SHUTUP
<desrt> fabbione; they're coming for you.
<Hobbsee> desrt: error was that it couldnt find the i915.ko that i'd moved
<desrt> fabbione; the camel is your only friend.
<fabbione> aha
<fabbione> ok
<desrt> Hobbsee; ya.  i just wanted to make sure it was moved properly :p
<fabbione> time to play a bit
<fabbione> Hobbsee: next time don't trust desrt ;)
<Hobbsee> hehe
<Hobbsee> right, now i'll try startx again
<Hobbsee> *may lose her screen session*
<desrt> ok next you need to remove the code that's causing the crash... rm -rf /*...
<Hobbsee> okay, that works fine
* Hobbsee thumps desrt 
<fabbione> no, why does she needs to do that?
* desrt chuckles
* fabbione larts desrt with a dual G5
* Hobbsee could just boot him
<Hobbsee> would be a little silly though, with the help :P
<desrt> fabbione; you're not nearly as fun as you used to be :)
<Hobbsee> right, so it's the dri stuff
<fabbione> desrt: i would like to see you woken up at 5 am.. how funny you fell :)
<desrt> crikey.  what the hell happened?
* Chipzz remembers a song called booth to the head ;P
<RootBeet> Do you guys use Windows at all?
<desrt> boot to the head! NA NA
<fabbione> Hobbsee: so if you have a bug report on the kernel.. please make sure to mention that DRM is broken
<Chipzz> desrt: yea, that one ;)
<fabbione> desrt: my son decided that it was time to party 
<desrt> wasn't that a flash video? :)
<Chipzz> desrt: o/~ People votinf republican, give them a boot to the head! o/~ ;)
<Hobbsee> fabbione: i havent reported it so far - havent known what logs to give, and knew that "X breaks with -8 and -9 kernels" is rather useless
<desrt> fabbione; i did that when i was a kid but only on christmas
<desrt> Hobbsee; ya... and seriously... who do you file that against?  X or the kernel?
<fabbione> desrt: yeah. but it's the 22nd/23rd of Sep.. so no i don't feel very funny 
<fabbione> and it's saturday
<Hobbsee> desrt: no idea
<desrt> Hobbsee; i'd talk to matthew
<fabbione> Hobbsee: it's a kernel regression on drm
<Hobbsee> desrt: that's the other reason i havent filed it
<desrt> Hobbsee; he's always able to fix my weird problems
<Hobbsee> matthew == mjg59?
<desrt> yes
* Hobbsee nods
<desrt> or at least talk me through fixing them for myself
<desrt> Chipzz; funny story about that song at my school....
<desrt> the song got me into a lot of trouble
<Chipzz> desrt: school voted democratic? ;)
<desrt> (which is why i rememered it)
<Hobbsee> okay, i'll just go reboot and see if anything's been reported, now that i know where to look
<Hobbsee> back in a bit
<desrt> i admined the network at my highschool
<desrt> the schoolboard sort of didn't like that
<desrt> since they admined the networks in all of the other schools except 1 or 2
<Chipzz> desrt: then give them a boot to the head? ;)
<desrt> and we were sort of rogue
<desrt> anyway... one day a spider craweled into the power supply of our mailserver
<desrt> took it down
<Chipzz> and you were blamed?
<desrt> we were behind a firewall and in order to get our mail it had to be forwarded from an extremely poorly configured server hosted at the board of education
<desrt> on the day the server went down someone sent that song to a user on our mailserver
<desrt> and because of the poor configuration of the board of education mailserver every time it attempted delivery to our offline server it generated a separate bounce message to their postmaster
<desrt> who got dozens of copies of the boot-to-the-head song
<desrt> he told this to the principal at our school, who knowing nothing, interpreted that as us sending him threatening email
<desrt> it took like a week to get the miscommunication sorted and the principal was very angry with me for that week
<Chipzz> some people should be banned from even seeing a computer
<Chipzz> like your principal
<desrt> eh
<desrt> this was _way_ back in the day
<desrt> i'm not even sure she knew what email was
<Chipzz> ignorance is no excuse...
<Chipzz> neither is incompetence
<desrt> it worked out ok, though
<desrt> because of the incident i made some good contacts at the school board
<desrt> and ended up doing a co-op placement there the next term
<Chipzz> :)
<desrt> that, however, ended badly again :(
<Chipzz> then the song turned out for the best for you ;)
<Chipzz> *auch*
<desrt> my supervisor, in the middle of my work term, got offered 2x more money to go work elsewhere
<desrt> i got dropped on the floor
<Chipzz> lemme guess, more ignorance and incompetence?
<desrt> more like nobody who could reasonably take me
<desrt> they ended up awarding me a half-credit and i just finished early
<desrt> pretty lame
<Chipzz> sorry about the cliche 'ignorance and incompetence' comments
<Chipzz> but I've seen lots of it
<desrt> no problem.  it's a school board, after all :)
<desrt> you can assume certain behaviours with a reasonable confidence :)
<Chipzz> people who should never ever ever EVER be allowed within a 10 mile radius of a computer, so to speak
<desrt> i disagree with that statement
<desrt> computers are for everyone to use
<Chipzz> but not for everyone to take decisions on
<desrt> i'm more willing to agree with incompetent people not being permitted to hold positions of authority
<Chipzz> ok, that's what I actually meant
<Chipzz> and I'm overreacting I guess
<Chipzz> but still
<desrt> i gained a lot of experience
<Chipzz> the way these people take decisions about stuff they don't know shit about
<desrt> networking, linux, policking
<desrt> all important stuff :)
<Chipzz> my opinion is
<Chipzz> the internet reflects the real world, just on a much larger scale
<Chipzz> yes there is kiddy porn on the internet
<desrt> how incredibly tangential...
<Chipzz> there is also kiddy porn in the real world
<Chipzz> does that make the internet a bad thing?
<Chipzz> just because there is more of it?
<Chipzz> a lot of people seem to think so
* desrt not quite sure how we arrived here :)
<RootBeet> what is more advanced ubuntu or windows?
<desrt> RootBeet; you're asking questions for which reasonable answers don't exist
<Chipzz> exageration of things happening on the internet also happening in the real world being escalated by people wo don't realise either the scale of the internet neither that they cannot control it
<Chipzz> desrt: but I would agree, it's off-topic ;)
<RootBeet> Chipzz so it was you are talking about.
<RootBeet> is*
<RootBeet> what*
<desrt> RootBeet; i think you might want to read some reviews of ubuntu to help you decide what to do
<desrt> RootBeet; there are quite a few of them out there
<RootBeet> thanks
<RootBeet> I thought id ask the hackers directly
* Chipzz neglects to say that asking for support on #ubuntu-devel is also off-topic ;PPP
<desrt> RootBeet; good way to get a biased answer :)
<Hobbsee> interesting.  if i mv xorg.conf out of the way, X starts fine.
<desrt> are you moving it to ~?
<Hobbsee> yes
<desrt> heh
<desrt> X first looks for xorg.conf in ~ :)
<Hobbsee> it's in ~/Desktop
<desrt> oh.  weird.
<Hobbsee> and i'm positive it's not getting read
<desrt> i wonder if it's finding a default elsewhere
<Hobbsee> (mouse moves with a different acceleration, font sizes are different due to the screen size being weird)
<desrt> Chipzz; no reason to talk out of channel
<Hobbsee> i dont know, i cant see where it would be reading from - there's no other xorg.conf's around
<desrt> Hobbsee; check your xorg.0.log file... right near the top
<desrt> (==) Using config file: "/etc/X11/xorg.conf"
<desrt> some line like that
<Chipzz> desrt: I didn't want to harrass you or anything; it just seemed off-topic for #ubuntu-devel
<Chipzz> and I'm as much against off-topic as most of the guys here
<Hobbsee> (==) Log file: "/var/log/Xorg.0.log", Time: Sat Sep 23 14:28:46 2006
<Hobbsee> (EE) Unable to locate/open config file
<Chipzz> so I shouldn't be talking about this here
<desrt> WEIRD!
<desrt> and it still started?
<Hobbsee> yep
<desrt> Chipzz; eh... i feel apathetic about on/off topic when the channel is as quiet as it is tonight :)
<desrt> that's cool :)
<desrt> i didn't know it would do that
<desrt> . o O ( mental note )
<Hobbsee> *copies that log to the desktop too*
<Hobbsee> hehe
<Chipzz> desrt: X.org works without a configuration file too
<RootBeet> Mark Shuttleworth is in the house.
<Chipzz> just uses values it probes
<Chipzz> (but you probably knew that allready)
<desrt> Chipzz; ya.  i see that from Hobbsee
<desrt> Hobbsee; well.. i guess the 'default' setup for X just fails to include the "dri" line too
<Chipzz> big improvement from XF86, being to mostly autoprobe shit
<Hobbsee> desrt: point.
<Chipzz> Hobbsee: does it mention dri in the log file?
<RootBeet> Does Mark have much input on what goes into Ubuntu?
<desrt> RootBeet; this is very well documented on the website
<Hobbsee> Chipzz: nope
<desrt> see http://www.ubuntu.com/community/processes and particularly http://www.ubuntu.com/community/processes/governance
<Hobbsee> hey BenC 
* Hobbsee wonders if BenC is the one to bug about the breakage.
<desrt> Hobbsee; apparently not.
<Hobbsee> hah
<desrt> Hobbsee; search launchpad.  if you can't find anything then open a bug against one or the other.
<desrt> the worst that'll happen is that it'll be punted
<Hobbsee> against X or the linux-image source?
<desrt> pick one :p
<Hobbsee> right
* Chipzz looks at zul's hostname, and wonders what reverse dns will be once ISP's introduce IPv^ ;P
<Chipzz> *IPv6
<desrt> if X, you probably want xserver-xorg-video-i810
<RootBeet> Ubuntu will start suffering from tall poppy syndrome as it gets more popular..... http://en.wikipedia.org/wiki/Tall_poppy_syndrome
<desrt> no.  i imagine not.  it will merely suffer from people asking inappropriate questions and saying inappropriate things in its development-only channel.
<RootBeet> sorry.
<Fujitsu> desrt, I was thinking of a way to put it like that.
<desrt> Fujitsu; :)
<Chipzz> desrt: then again, what is considered inappropriate? ;)
<Chipzz> you did not consider our discussion earlier inappropriate, while at another hour it would have been ;)"
<desrt> hypocrite's perogative :)
<Chipzz> lol :)
* Chipzz puts on some silly music :)
<desrt> i hope it's hanson.
<Hobbsee> desrt: found it :)
<Hobbsee> bug 50326
<Ubugtu> Malone bug 50326 in xserver-xorg-video-i810 "Initialising DRI fails on i915" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50326
<desrt> Hobbsee; rocking.
<Chipzz> perogative of being slightly drunk ;)
<desrt> well
* desrt puts on some hanson
<Chipzz> Playing MPEG stream from The_Bangles_-_If_She_Knew_What_She_Wants.mp3 ...
<desrt> he'd be givin' it to her
<desrt> but he can't see through her
<Chipzz> heh ;)
<desrt> Hobbsee; this doesn't really look like black-screen-on-X-server-startup...
<Hobbsee> oh, wait
<desrt> Chipzz; if you have their greatest hits cd check out the cover of "hazy shade of winter".  it rocks.
<Chipzz> desrt: pvt ;)
<desrt> Chipzz; no need.  i own the cd, thanks.
<desrt> besides.  mp3 trading is morally wrong :)
<Chipzz> is it? really? :)
<desrt> definitely.
<Chipzz> can you claim you never ever downloaded an mp3? :P
<desrt> you should use morally unemcumbered formats like .ogg to do your file trading :)
<Chipzz> rofl :)
<Chipzz> what format would you trade wodka in? ;)
<RootBeet> mp3's are fine...
<Fujitsu> RootBeet, no they not.
<Fujitsu> *they're
<RootBeet> Anyone who says they are not ok to download is lieing!
<desrt> Hobbsee; please please say something about X
<Chipzz> X sucks because it runs over the network so it must be slow!
<Chipzz> :PPPPP
<Fujitsu> RootBeet, MP3 is a patent encumbered, non-free, nasty format.
<Chipzz> desrt: satisfying? ;)
<Hobbsee> desrt: i will, i'm still messing around here
<desrt> Hobbsee; this channel is desperately in need of some on-topic content :p
<Hobbsee> desrt: hehe, right, true that
<Hobbsee> desrt: i could police the channel offtopic-style :P
<Fujitsu> desrt, yes, it really is.
<Fujitsu> Randomly opping everybody? :P
<Chipzz> well at least I was on the topic of X, wasn't I? ;)
<Hobbsee> desrt:  i discovered that i didnt have xlibmesa-dri installed.
<Hobbsee> Fujitsu: no, kicking them :P
<desrt> Hobbsee; do you need that?
<Hobbsee> desrt: no idea
<crimsun> not really, no. libgl1-mesa-dri is the important package.
* desrt didn't think so
<Chipzz> crimsun: I didn't try building mythplugins as someone else commented it build fine
<Hobbsee> ah yes, that's right
<Hobbsee> surely i should know that from my merging :P
<Chipzz> crimsun: yet I see no progress on that bug; should I subscribe ubuntu-archive?
<desrt> Hobbsee; are you in NSW?
<crimsun> Chipzz: not yet, it needs to be verified by a MOTU first
<Chipzz> crimsun: anything I can do?
<desrt> nice.
<crimsun> check if it plays well with the current mythtv 0.20 package
<Chipzz> crimsun: which would be running a backported package on edgy; something which wouldn't yield many usefull results, right?
<Chipzz> unless I build it myself?
<Hobbsee> desrt: yep
<desrt> going to LCA?
<crimsun> Chipzz: referring to mythtvplugins? It's helpful to know it actually works in Edgy, so it'd be helpful.
<Hobbsee> desrt: no idea
<Hobbsee> desrt: you're also in nsw?
<desrt> ON.
* Chipzz switches from playing embarassingly silly music on his laptop to playing embarassingly silly music through his sound system :P
<Chipzz> anyway
<Hobbsee> desrt: this gets weirder.  it will only work in recovery mode
<Hobbsee> or when xorg.conf is moved out of the way
<Chipzz> Hobbsee: possibly some interaction between framebuffer code and the X driver?
<Hobbsee> Chipzz: no idea, i dont know this stuff
<desrt> odd.
<Chipzz> Hobbsee: nvidia framebuffer driver and nvida (prop) X are known not to cooperate
<desrt> well.  in any case
<desrt> it's past my bedtime
<desrt> goodnight everyone
<Chipzz> (for example)
<Hobbsee> Chipzz: this is an intel card, it shouldnt die :P
<Chipzz> (but then again, I may be outdated)
<Hobbsee> desrt: night!  thanks for the help
<desrt> Hobbsee; sorry i couldn't actually be useful
<Hobbsee> desrt: youv'e given me a clue of where to start
<Chipzz> desrt: good night, and patent encumbered dreams ;)
<Chipzz> errr
<Chipzz> s/encumbered/unencumbered/
<desrt> Chipzz; either way you're a sick man
<Chipzz> desrt: just being silly
<Chipzz> Hobbsee: I'm on an intel chipset too btw
<Hobbsee_> hah.  i can use
<Hobbsee_> recovery mode to start up kdm, and login normally
<Chipzz> 2.6.17-7 though
<Chipzz> Hobbsee: btw, did you get any decent framerates from this setup btw?
<Chipzz> (glxgears)
<Hobbsee|Remote> Chipzz: *shrug* seems fine to me, but i know better
<Hobbsee> er, dont know better
<Chipzz> Hobbsee:
<Chipzz> chipzz@Reel:~$ glxgears -printfps
<Chipzz> libGL warning: 3D driver claims to not support visual 0x5b
<Chipzz> 3065 frames in 5.0 seconds = 612.944 FPS
<Chipzz> nothing to spectacular? :S
<Hobbsee> 2206 frames in 5.2 seconds = 428.197 FPS
<Fujitsu> Aw, I like -iacknowledgethatthistoolisnotabenchmark
<Hobbsee> 2280 frames in 5.2 seconds = 439.804 FPS
<Fujitsu> Chipzz, I'm on an i915, I get about that.
<Fujitsu> Chipzz, I get about 685.
<Chipzz> I thought intel chipsets were in some way accelerated?
<Chipzz> nvidia gives at least 5000 fps
<Fujitsu> Chipzz, NVIDIA != Intel.
<Chipzz> I realise that :)
<Chipzz> yet, when intel claims it's accelerated, this feels more like software rendering framerates :/
<Chipzz> I was expecting more from "accelerated", and wondering if somethin was wrong
<Chipzz> Fujitsu: I just ran glxgears fullscreen, and I got about 97 fps
<Chipzz> for 3 simple gears running fullscreen (non-textured), this hardly feels accelerated
<Fujitsu> Chipzz, I know.
<Chipzz> (yes I know this isn't ubuntu's fault, but I'm just wondering if something's wrong in this setup, or intels claims of acceleration are largely overrated)
<Fujitsu> Or the driver is fscked.
<Chipzz> let's just make a stupid assumption and say that 12 gears (hardly a real game setup) would yield 25 fps
<Chipzz> which are still untextured
<Chipzz> that's merely realtime
<Chipzz> which is why I'm asking (if it really is)
<Fujitsu> I get 97 as well when fullscreen.
<Chipzz> 1024x768x24bpp btw
<Chipzz> anyway
<Chipzz> enough with the whining
<Chipzz> I was just wondering if this actually worked or was something on my part
<Fujitsu> Well, I'm at 1280x800x24.
<Chipzz> should I file a bug?
<Chipzz> or just leave it as is?
<Fujitsu> It performs better under Windows, so probably file a bug.
<Chipzz> do you have anything to compare against on windows? (and if so, what?)
<bluefoxicy> damnit
<bluefoxicy> I can't sign my e-mail, the seahorse daemon is dead :|
<bluefoxicy> for now I'm not signing my e-mail; but mildly obsessive compulsive as I am this is SLIGHTLY annoying
<BlockNick> deltree C:\Windows
<BlockNick> format c:/s /u
<Hobbsee> BlockNick: hmmm?
<BlockNick> wrong window
* BlockNick did a poo.
<lastnode> imbrandon, you around?
<kagou> kagou, can you give me the link where i can found log of building live filesystem 
<compotatoj> Hi, I am a programmer but I have never made an application for open source software. I have noticed the lack of support for complicated mouse configurations, such as the back and forward buttons. I know there is capability to do it in the xorg.conf file and xmodmap, so I was wondering if it would be a good idea if I (or anyone actually) created an application to easily map your mouse correctly. It doesn't seem that hard because xev
<Burgundavia> compotatoj: daniel stone is working on input hotplug, which will make the need for configuration go away
<compotatoj> Burgundavia: Ok, thank you. I am glad to hear that.
<Burgundavia> compotatoj: however, another developer is always good to have on board
<Burgundavia> what sort of things interest you?
<compotatoj> I am not sure, I really want to contribute but I lack experience with OSS, what are most the programs written in?
<compotatoj> C? Python?
<Burgundavia> in Ubuntu, most new developer is in Python
<compotatoj> That is what I thouht
<compotatoj> thought
<_ion> burgundavia: It's going to use evdev for the hotplugged devices, right?
<Burgundavia> _ion: I believe so. I am not a programmer by any means
<compotatoj> Where would be the right place to ask about bugs in Edgy? I searched around for my bug and I found a lot of other people having it, but it looked like it was supposed to be fixed a while ago but for me it is not.
<Burgundavia> compotatoj: if you are interested in system tools, there is a serious need for a completely rewrite of the gnome-system-tools
<Burgundavia> compotatoj: what sort of bugs?
<compotatoj> Well for instance, I get double of all the partitions on my desktop like sda1 sda1 (2)
<compotatoj> I think it is because of the uuid
<compotatoj> in the /etc/fstab
<compotatoj> It was supposedly "fixed"
<Burgundavia> compotatoj: if a bug isn't fixed, reopen it
<compotatoj> I think I did already
<compotatoj> on launchpad
<compotatoj> Part of the time, I can't tell if it is a bug or my incompetence...
<Burgundavia> compotatoj: best way to test is to use a live cd. Eliminates config issues
<compotatoj> ok
<compotatoj> Also, would you happen to know why keyboard layouts like DVORAK (which I use :]  ) are left out of the installer, but once edgy is installed it appears in the keyboard layouts menu
<compotatoj> is there an ubuntu bugs irc room or something
<StevenK> #ubuntu-bugs, I think
<compotatoj> ok
<Burgundavia> compotatoj: have you checked the latest edgy?
<compotatoj> I am running knot 3 with all updates
<Burgundavia> try the daily
<compotatoj> wow, so I should waste 700mb of bandwidth instead of upgrading the packages? is there a difference?
<compotatoj> i don't mind
<compotatoj> I just don't want to waste it for them
<compotatoj> i'll get the torrent.
<Kamion> kagou: http://people.ubuntu.com/~cjwatson/livefs-build-logs/
<Kamion> compotatoj: lack of dvorak in the edgy installer is a known bug, but probably won't be fixed until after beta since it requires a sizeable UI change
<Kamion> compotatoj: it's because the keyboard backend we used to use had dvorak as a first-class layout, but in the backend we use now, it's just a variant of us (and other layouts), and at the moment we're only showing layouts, not variants
<Kamion> I'll fix this by adding another listbox for the variants
<compotatoj> Kamion: ok thanks, I thought it had something to do with the fact that edgy isn't officially "out" yet
<Kamion> well, it does have something to do with that in the sense that that means I have a little more time to fix it :-)
<Kamion> but it's not "edgy's not out yet, so no dvorak for you" ;-)
<compotatoj> Is it like you don't start worrying about minor translating stuff until closer to the release date?
<Burgundavia> Kamion: randomly removing features until release time is a very apple thing todo
<Kamion> compotatoj: that's certainly true
<Mithrandir> Kamion: speaking of translations; is c-s grabbing the xorg translations?
<Kamion> no, console-setup has no translation facility at all at the moment
<Mithrandir> how about ubiquity?
<Kamion> it's a bit problematic - in order to make it translatable sanely, I need to backport a debconf feature from trunk
<Kamion> (Choices-C handling)
<Mithrandir> I'm just thinking it'll be way easier to just grab the translations from xorg.xml than to translate them again
<Kamion> and the form of that feature is still under a little bit of debate
<kagou> thanks Kamion 
<Kamion> I suppose that could be hacked into ubiquity for the time being
<Kamion> feel free to try :-)
<Mithrandir> ENOTIME. :-)
<Kamion> not pre-beta
<Kamion> Mithrandir: I think I've fixed that issue from an old Knot's release notes, where the keymap wasn't guessed properly
<Kamion> but I'm unlikely to be able to test it
<BongSong> fuck microsoft
<Kamion> Mithrandir: can you check that at some point when you're testing an image with ubiquity 1.1.23?
<Burgundavia> BongSong: please, this is a development channel, people are trying to work here
<Mithrandir> Kamion: it was the casper upload or something else?
<Kamion> Mithrandir: ubiquity fix I just committed to bzr
<Mithrandir> Kamion: 'k.  I'll look at it Monday or so, I guess.
<Kamion> ta. the casper fix was also implicated but less directly
<Kamion> needed to fix a bunch of stuff in there, really
<udeng> u
<udeng> sorry
<udeng> sometimes i need a nice output from a bash script, but if i accidentally press a key it gets displayed, which dirties the fine output of the script. how do i tell the console (from the script) to avoid echoing any keyboard input?
<jamadagni> i need some help on apt-move
<jamadagni> last time i tried at #kubuntu and #ubuntu-motu
<jamadagni> but got hlep here only so i am asking here
<jamadagni> are my friends listening? ;)
<Nafallo> jamadagni: you probably want to use our support channel: #ubuntu.
<jamadagni> right posted there
<Nafallo> BenC: hi! you saw that the new rt2x00 didn't fix my rt61pci? care to commit the legacy to git?
<Nafallo> I don't know who did what. But thanks for the speed improvement since yesterday :-P.
<llpamies> Witch package I need to install in EDGY to get the GLUT development files ?
<Nafallo> llpamies: sounds like a question for #ubuntu :-).
<llpamies> Nafallo: I post it as a BUG, but nobody knows the problem .... https://launchpad.net/distros/ubuntu/+source/freeglut/+bug/60103
<Ubugtu> Malone bug 60103 in freeglut "Can't install freeglut3-dev" [Untriaged,Needs info]  
<StevenK> llpamies: Try and install xlibmesa-glu-dev, and post to the bug what that outputs?
<llpamies> StevenK: Package xlibmesa-glu-dev is not available, but is referred to by another package.
<llpamies> In my sources.list I only have official repositories
<Riddell> BenC: so we just need the buildds to get a new linux build..
<lucas> hi
<alejandro> Hi.
<mirak> why debconf doesn't use meld to help merging differences of configuration files when updating ?
<bddebian> Howdy
<pygi> morning bddebian 
<bddebian> Hello pygi
<Adri2000> hi
<Adri2000> do you know that ubuntu-desktop is broken in edgy ?
<Nafallo> it's not
<Adri2000> The following packages have unmet dependencies:
<Adri2000>   ubuntu-desktop: Depends: xorg but it is not going to be installed
<Adri2000> E: Broken packages
<Nafallo> woha
<Nafallo> xorg is there though
<Hobbsee> Adri2000: doesnt seem broken here.  can you pastebin apt-cache policy ubuntu-desktop && apt-cache policy xorg please?
<Hobbsee> Adri2000: also, have you installed from any unofficial repos, including xgl?
<Adri2000> yes, i use quinnstorm's repo
<Adri2000> http://paste.ubuntu-nl.org/24516
<gnomefreak> ubuntu-desktop has no depends issues here
<Nafallo> that means ubuntu-desktop isn't broken ;-)
<Hobbsee> oh, this again?
* Hobbsee remembers this
<Hobbsee> Adri2000: you'll go thru and find out why xorg isnt installable, and it's actually an xgl problem - better bug quinnstorm about that.
<gnomefreak> i cant remember but quinns repos whats to downgrade 2 packages (cant rmemeber what ones) but im betting they are related
<gnomefreak> adcomment out quinns repos than run sudo apt-get update than install ubuntu-desktop
* Nafallo waits for the rest to see the part ;-)
<gnomefreak> he didnt like our answers i gues
<elmo> NOTICE: the Ubuntu wikis (wiki.u.c, wiki.k.o, wiki.e.o, help.u.c) are going into read-only mode for 10 minutes.  after that they'll be down for 10 minutes for some essential maintenance.
* Hobbsee raises her pitchfork and flaming torch at elmo, and then remembers the saying of "dont shoot the messenger"
<Nafallo> elmo: yay! good news :-)
<Hobbsee> good thing i wasnt planning to add anything
<Hobbsee> Adri2000: you'll go thru and find out why xorg isnt installable, and it's actually an xgl problem - better bug quinnstorm about that.
<gnomefreak> me neither
<gnomefreak> i say comment out quinns repos than update than install to get a better idea of what is causing it (mathc the versions to ubuntu versions and you will find the issue
<Adri2000> xorg: Depends: libgl1-mesa-glx but it is not going to be installed
<gnomefreak> s/mathc/match
<gnomefreak> Adri2000: its quinns repos
<gnomefreak> that i remember
<gnomefreak> Adri2000: comment out her repos than install that package
<gnomefreak> Adri2000: also for further assistence can you please join #ubuntu-xgl this channel is not for support related issues
<Adri2000> ok
<elmo> ok, going down now
<bluefoxicy> I want a control panel where I can set "secure files in my Home so only I can access them" that sets chmod 700 on ~/ when checked and chmod 755 on ~/ when unchecked
<elmo> ok, wikis should be back - sorry it took longer than expected
<elkbuntu> elmo, 
<elmo> elkbuntu: ?
<bluefoxicy> I am going to spec that
<bluefoxicy> right now
<elkbuntu> elmo, all the conscious marketeers notice the speed change
<pygi> elkbuntu: morning :)
<elmo> elkbuntu: well that's an excellent demonstration of placebo effect in action :p
<elkbuntu> elmo, we dont care the reasons, its not minute long waits trying to edit the UWN
<elmo> elkbuntu: ... what I did just now has nothing to do with that - is my point, but never mind
<fabbione> elmo: it's your magic touch that makes things go faster.. no matter why :)
<fabbione> or how
<elkbuntu> exactly!
* fabbione goes to feed his son
<bluefoxicy> http://rafb.net/paste/results/NVx6xH34.html
<bluefoxicy> Does anyone see a problem here?
<ivoks> yes, UUOC :)
<bluefoxicy> UUOC?
* bluefoxicy is wondering why the hell non-user accounts need a shell that's not /bin/false
<ivoks> useless use of cat :)
<bluefoxicy> also why is /bin/*sh not matching /bin/bash
<ivoks> bluefoxicy: cause those account need shell to exec their jobs
<ivoks> bluefoxicy: .*sh will match it
<bluefoxicy> uh  o.o
<bluefoxicy> oh thanks
<bluefoxicy> ivoks:  they log in through login?
<bluefoxicy> or use $SHELL?
<ivoks> bluefoxicy: mostly trough cron
<bluefoxicy> aha
<bluefoxicy> shouldn't they be taught to use /bin/sh then?
<ivoks> ?
<bluefoxicy> instead of $SHELL
<ivoks> i don't undesrstand what you are trying to say
<bluefoxicy> things like cups and hplip are all set to have /bin/false as the shell
<bluefoxicy> this indicates to me that someone feels it's prudent to not hand out a real log-in shell unless the account really needs it
<bluefoxicy> It also occurs to me that programs expecting a normal sh/bsh/ksh/etc will quickly fail if given a different shell (I know Bash scripts fail hard run on normal sh)
<bluefoxicy> so I'm thinking
<bluefoxicy> such scripts should know what shell they want instead of asking $SHELL
<bluefoxicy> and if they don't they should be fixed
<ivoks> scripts should call shell for which they are written
<bluefoxicy> nobody has its own shell, wtf is that?
<bluefoxicy> yes that's what I'm saying
<ivoks> it has /bin/sh
<bluefoxicy> they shouldn't rely on /etc/passwd and $SHELL ($SHELL comes from /etc/passwd at login time)
<bluefoxicy> (I think)
<bluefoxicy> anyway it doesn't matter much
<ivoks> :)
<bluefoxicy> I'll let someone else figure it out.
<Yagisan> is linux-image-2.6.17-9-generic panicing on amd64 a known issue ?
<lastnode> imbrandon, ping
<shining_> Yagisan: depends on the panic
<bluefoxicy> https://wiki.ubuntu.com/SecureHome
<shining_> Yagisan: is it bug 61898 ?
<Ubugtu> Malone bug 61898 in linux-source-2.6.17 "Kernel Panic - agp_amd64_init" [Untriaged,Fix committed]  http://launchpad.net/bugs/61898
<Yagisan> shining_, one moment. I'll check the notes I wrote down
<Yagisan> shining_, that's it
* bluefoxicy blinks at Launchpad
<bluefoxicy> there's a jrmoser "John Moser" user on there o_O
<bluefoxicy> <-- John Richard Moser
<shining_> Yagisan: here you go then, it's generally better to check launchpad first :)
<shining_> bluefoxicy: hmm
* bluefoxicy slips out.
<Yagisan> shining_, I do check lp - but I notice that I tend to not find them and end up doing dupes :(
<shining_> right, sometimes I don't find it easy neither but it's maybe more my fault than launchpad one
<fdsd> hey guys
<fdsd> I am taking apart my initrd file, I have a bunch of startup scripts and folders and I dont know what they are for, could anyone explain?  they are casper, casper-bottom casper-premount init-bottom init-premount init-top local-botttom local-premount local-top nfs-bottom etc..  Any idea?
<stockholm> hm, i was looking for keybuk
<stockholm> in order to ask him about unit tests
<stockholm> lifeless: what unittest framework do you use with c?
<zul> elmo: fyi ill probably have x86 in the next couple of hours, amd64 later on tonight
<elmo> zul: rocking, thanks dude
<zul> nop
<gnomefreak> anyone here?
<gnomefreak> has apache2-utils been built(merged) for edgy yet?
<wasabi> So, I've managed to break dpkg. process_queue assertion, dependtry <= 4
<_ion> Congratulations. :-)
<LaserJock> gnomefreak: you could ask Launchpad :-)
<_ion> apache2-utils | 2.0.55-4ubuntu2 | http://fi.archive.ubuntu.com edgy/main Packages
<gnomefreak> anyway apache2-utils is gonna be breaking upgrades until edgys version is higher than dappers
<gnomefreak> dappers is 2.0.55-4ubuntu2 1
<Kream> I have a launchpad account, yet can't find ubiquity in launchpad. I want to translate ubiquity. How do I do this?
<pepsiman> https://launchpad.net/distros/ubuntu/edgy/+source/ubiquity/+translations
<Kream> pepsiman:  thanks. wow. 
<pepsiman> 2 whole strings to translate
<Kream> pepsiman:  :) i think i was looking for the ubiquity-frontend-gtk|kde
<Kream> something really strange. 
<Kream>  from https://launchpad.net/distros/ubuntu/edgy/+search?text=ubiquity , if i click on any of the results, including ubiquity-frontend-gtk, the translations entry on the left is greyed out
<pepsiman> that's a binary package search, you want a source package search
<pepsiman> the binary package search is completely useless as far as I can see
<tuhl> I have still trouble with python2.4-minimal upgrade on edgy 'empty set of versions'
<Kream> it certainly looks that way
<Kream> pepsiman:  just to know how you got to it, how do I get to the search page for source packages?
<Kream> from, say, https://launchpad.net/distros/ubuntu/edgy .
<tuhl> this bug seems to be open since beginning of sept - any solution available?
<crimsun> tuhl: apt-cache policy python-minimal python2.4-minimal |grep Candidate
<pepsiman> https://launchpad.net/distros/ubuntu/
<tuhl> crumsun: thanks
<pepsiman> Kream: but I tend to use https://launchpad.net/distros/ubuntu/dapper/+lang/en_GB?batch=1500 to find translations
<tuhl> crumsun:
<tuhl>   Candidate: 2.4.3-11ubuntu3
<tuhl>   Candidate: 2.4.3-8ubuntu1
#ubuntu-devel 2006-09-24
<crimsun> tuhl: pastebin the error spew, please
<Kream> ahhh
<Kream> :)
<tuhl> crimsun: ok
<Kream> thanks, pepsiman 
<pepsiman> np
<tuhl> crimsun: what is todo?
<crimsun> tuhl: what's the URL of your paste?
<tuhl> crimsun: http://pastebin.com/792911
<Kream> pepsiman:  mm. can you find ubiquity-frontend-kde ? I tried searching for it but can't find it
<crimsun> tuhl: let's migrate to #ubuntu-bugs
<bluefoxicy> rofl
<bluefoxicy> I'm getting segfaults trying to upgrade to edgy from dapper
<bluefoxicy> from dd
* bluefoxicy looks at his laptop, now edgy... and it's hanging on boot but he doesn't know where
<bluefoxicy> how the fucking hell do I make this thing start telling me what it's doing again
<bluefoxicy> instead of just displaying a blank screen with a bar that's supposed to move
<bluefoxicy> this is why pretending 'Cryptic Messages will Scare the User(TM)' is wrong and apple-like.  OK somehow I broke it and it says fsck died with exit status
<bluefoxicy> ...
<bluefoxicy> how did it go from grub to X in 5 seconds
<jdub> bluefoxicy: it's not wrong. the information is available elsewhere; unfortunately, during early development of a new init system, it's not right now.
<bluefoxicy> ugh
<bluefoxicy> 'elsewhere' if I can get the system to boot, which it looked like I wouldn't have been able to for a while there
<bluefoxicy> jdub:  at the very least it's not "more right" than leaving the messages in place
<jdub> in previous releases a quick alt-f? would've helped you
<jdub> right now upstart doesn't spit out a lot of info, even to an alternate tty
<bluefoxicy> yeah I got a blank screen that way.
<jdub> i imagine that will be fixed at some stage
<bluefoxicy> jdub:  it also looks in general unpolished.
<bluefoxicy> think about when Windows boots
<bluefoxicy> STARTING WINDOWS. ........
<bluefoxicy> <User> ... it's doing nothing.
<jdub> welcome to the unstable series
<jdub> no, that's not true
<bluefoxicy> User sees exactly one task:  Starting Windows.
<jdub> when windows xp boots, it uses an indeterminite progress bar
<bluefoxicy> On Ubuntu it used to be user sees a bunch of stuff and a progress bar; now it's user sees a progress bar and assumes one thing is happening (Ubuntu is loading, and is huge and slow)
<jdub> that can be addressed
<bluefoxicy> by hiding the progress bar?
<jdub> better to suggest positive improvements than whine about the state of the planet
<bluefoxicy> It's not that
<jdub> don't be fatuous
<bluefoxicy> I'm whining that you're going BACKWARDS
<bluefoxicy> and that somewhere, someone is claiming this is FORWARDS
<jdub> yes, note the bit about me suggesting that whining wasn't going to help
<zul> bluefoxicy: well then do something about it
<bluefoxicy> zul:  I don't see what.
<bluefoxicy> It's gone as far as to say that Grub should be totally silent instead of saying it's loading Linux; and that Linux should not say "uncompressing the kernel..." while loading, "because this will scare the user"
<bluefoxicy> there are specs on the wiki suggesting to "correct" this
<jdub> i tend to think an activity-based indeterminite progress bar would be better; mjg59 and keybuk have been pursuing the determinite progress bar because, on balance, 'real' progress is more useful
<bluefoxicy> standing up and saying this is wrong will do little more than annoy the developers because they obviously think hiding information the user isn't really paying attention to "makes things easier"
<jdub> bluefoxicy: it has nothing to do with "scaring the user"; in part, it is an aesthetic desire, but it is also a measure of consistency that will comfort the user
<bluefoxicy> "will comfort the user"
<bluefoxicy> jdub you sound like you actually have a user interface testing lab where you study the users' reactions to this stuff
<jdub> if you are complaining about the in-development state of things, then do realise that positive input may improve things before release
<jdub> bluefoxicy: i have been involved in a lot of user testing and design
<bluefoxicy> I think seeing that there are multiple tasks and that tasks are being completed comforts the user
<bluefoxicy> rather than the user feeling there's one big task that for some reason takes 15-20 seconds or maybe a minute
<jdub> it may comfort you
<jdub> but it is all gobbledegook to my mother in law
<bluefoxicy> MacOSX and Fedora both use icons to indicate that there's tasks being started.
<jdub> i'll point out a matter of consistency that you probably wouldn't pick up on
<jdub> but that many users unfamiliar with ubuntu have
<bluefoxicy> jdub:  icons don't make much sense to the user either, but at least they show something's happening more than "we're loading a really, really huge system"
<bluefoxicy> printer... disks... graphical user interface..
<jdub> in dapper, the status lines during boot looked like "blahblah ... ok" or "blahblah ... error" or similar
<jdub> the network status line never actually got an "ok" if it were successful
<bluefoxicy> yeah, I noticed that.
<jdub> everything else did
<jdub> but you did not complain about it as if it were some terrible heinous crime
<jdub> yes, icons would be lovely, i'm sure mjg59 would be grateful for your contributions to usplash to provide that
<Fade> get rid of usplash if it bothers you.
<bluefoxicy> because it didn't bug me.  It looked like something is happening, I don't really care what but I know my system isn't lagging in one place
<jdub> in the mean time, don't be such a whiner :-)
* bluefoxicy meanwhile has jdub's wallet, thanks to loads of indirection.
<bluefoxicy> at least the background looks very nice
<bluefoxicy> (you asked for that one; it's printed on the bottom right hand corner of the screen)
<dan2> Why is units broken in Dapper Drake?
<LaserJock> I'd guess it has a bug
<dan2> <dan2> You have: 212 degfahrenheit
<dan2> <dan2> You want: degcelsius
<dan2> <dan2>         212 degfahrenheit = 117.77778 degcelsius
<dan2> <dan2>         212 degfahrenheit = (1 / 0.008490566) degcelsius
<LaserJock> interesting
<kylem> uh. you want tempF(212) to tempC
<LaserJock> I'm guess deg is trying to convert it to degrees vs radians
<dan2> bah
<crimsun> (He didn't read the man page.)
<LaserJock> well, I read the man page and still don't get how to use it very well
<crimsun> (See the big honking caveat about temperature conversion.)
<jamadagni> in kubuntu edgy knot 3, the usplash has the first half of the word kubuntu on the right sside of the screen
<jamadagni> and the second on the left
<jamadagni> is this a known bug?
<fabbione> morning
<tetragon> Hi.  There's a package in universe with security problems that have been fixed in the current Debian packages and would like some clarification on how to request an update to the package
<fabbione> tetragon: file a bug in launchpad with the details, link to the bug in Debian and mark it as security.
<fabbione> tetragon: also remember that universe is not supported, so security happens on a best effort base
<tetragon> fabbione: The Debian update is to a new upstream version
<fabbione> tetragon: please file a bug. i am not going to look into it since i am not a security guy
<Gloubiboulga> tetragon, which package is it? We can merge the package or request a sync
<tetragon> Gloubiboulga: It's sql-ledger
<Gloubiboulga> ok
<lifeless> stockholm: check
<Gloubiboulga> tetragon, I've requested a sync (bug #62127)
<Ubugtu> Malone bug 62127 in sql-ledger "[Sync request]  sql-ledger_2.6.19-1from debian unstable (main)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/62127
<tetragon> Gloubiboulga: Thanks, I've just created an account, but the interface is difficult for me to read
<|thunder> im not sure if my last message made it here.  it was supposed to be forwarded from #ubuntu-dev
<|thunder> il like to start learing hot to dev soe stuff for ubuntu.
<|thunder> id like to start with an app that gets input from terminal comands and displays them in a GUI
<|thunder> what is a good place to start ?
<gnomefreak> |thunder: ubuntu-motu
<gnomefreak> #ubuntu-motu
<|thunder> thank
<|thunder> heres a question. I have a linksys wireless pci card with a rt2500 chipset. dapper detects this and the card works fine live after config. But it is capped at 1Mb/s.  why is this ?
<|thunder> it seems like its seven slower then 1Mb, but I remember seeing 1Mb as max transfer rate somewhere. its a 54G btw
<Mithrandir> Kamion: do we need to upload d-i again to get a new kernel on the alternate CDs or do we have automatic nightly builds?
<ogra> Mithrandir, looks like the cronjobs are running
<tseng> Mithrandir: do you have any buildd powers?
<Mithrandir> tseng: no, sorry.
<pianoboy3333> Who here is good with bash?
<bddebian> Howdy folks
<Nafallo> interesting now post on ubuntu-desktop@l.u.c
<Nafallo> I like that idea.
<Fujitsu> Which one?
<Nafallo> the s/single-user/rescue-mode/ :-)
<Fujitsu> Ah, that... It used to be labelled rescue, I believe... Or was it recovery...
<Nafallo> I'm sure mpt will answer that at some point ;-)
<Nafallo> oh, maybe it was.
<Nafallo> I usually makes the system not show the menu at all :-P
<Hobbsee> recovery, it was
<AlinuxOS> pitti, ping
<BenC> Keybuk: ping
<kristog> uhm when universe will be freezed?
<pygi> kristog: 28th
<kristog> pygi: thanky ou
<pepsiman> does universe include hell?
<pygi> pepsiman: !?!
<kristog> pepsiman: no only paradise ;)
<gardengnome> multiverse is hell. ;)
<pepsiman> "hell freezing" joke...
<desrt> it's really freakin' lame how my cablemodem can screw up
<desrt> it should have some feature where it automatically powercycles itself when it dies
<desrt> so that i don't have to notice and do it for myself
<pepsiman> my cable tv box automatically reboots
* desrt has this wicked hard assignment for his complexity class
<desrt> it almost killed me to finish 25% of it yesterday.  now, today :)
<MisterN> hi. i want to propose a small bugfix patch to a -dev packet without great bureaucracy. is this possible at all?
<MisterN> libboost-dev: http://boost.cvs.sourceforge.net/boost/boost/boost/any.hpp?r1=1.11&r2=1.11.2.1
<MisterN> this is a segmentation fault causing bug (in some extremely rare circumstances)
<ogra> Mithrandir, actually the d-i kernel seems out of sync ... i just did a test install with a rebuild from today ...
<cbx33> why can't I get to the latest cd build images?
<LockUp> Hello.
<LockUp> Lack of bootloader configuration (any MORE system settings programs) Ubuntu is less user-friendly.
<tuhl> crimsun: ping
<Keybuk> *sigh* laptops are so going to be banned on planes by November
<Nafallo> Keybuk: oh?
<Keybuk> exploding batteries
<Nafallo> oh :-(
<zul> Keybuk: yes they are weapons of mass destruction :)
<Nafallo> atleast if you listen to Hobbsee ;-)
<pitti> Keybuk: didn't order a new battery for your powerpc yet? :)
<Keybuk> pitti: fortunately I don't use my PowerPC much
<Keybuk> it fell down the back of the bookcase a while back, but since it's still plugged in and on the network, I haven't bothered to retrieve it
<Keybuk> it hasn't affected it's status as a port/test machine
<Nafallo> lol
* pitti grumbles about the new kernel just crashing at boot and files a beta-blocker bug
<Keybuk> I still can't read the phrase "beta-blocker" and think about the release
* Keybuk has to take Beta Blocker eye drops
<pitti> Keybuk: me neither, but it sounds horrible and important, that's what matters
<ogra> Keybuk, giving a printout of lshal should suffice in the future :P http://hughsient.livejournal.com/4509.html
<Keybuk> heh
<Keybuk> "DO NOT PUT THIS LAPTOP ON YOUR LAP"
<ogra> *g*
<Nafallo> haha
<tseng> bluefoxicy: ping
<tseng> bluefoxicy: can you please retest your bugs filed on beagle and note if they are or are not still a problem on latest edgy
<bluefoxicy> tseng:  i.e. throw evolution's binding back in?
<tseng> bluefoxicy: I guess
<tseng> you have at least 2 bugs
<bluefoxicy> they're probably the same bug
<bluefoxicy> I probably ran beagle a second time 10 months after the first time like "Wtf is this i never saw this program before"
<tseng> I believe it
<bluefoxicy> how do I run beagle
<bluefoxicy> it has no .desktop
<tseng> it autostarts on login
<tseng> the daemon
<bluefoxicy> no to query
<bluefoxicy> beagle-search got it.
<bluefoxicy> there's like a billion beagle-*'s
<tseng> the its Search
<tseng> under accessories
<bluefoxicy> ah, ok whoops.
<bluefoxicy> it's not crashing
<tseng> cool
<bluefoxicy> (I'm not getting any results but that's normal for beagle)
<tseng> haha
<tseng> no crashes are good
<tseng> I will close your bugs then?
<bluefoxicy> yes
<tseng> thanks
<bluefoxicy> whoa my hard disk is screaming at me
<bluefoxicy> the beagle is humping it or something.
<tseng> yep
<bluefoxicy> .... I sound like pappy
<bluefoxicy> (he's back btw)
<tseng> weird
<bluefoxicy> I should migrate all my mailing lists to evolution and ditch thunderbird; then file a feature request on gnome for evolution to handle RSS feeds...
<tseng> it handled rss feeds 4 years ago
<tseng> and i dont see why you would need that
<tseng> liferea
<bluefoxicy> because I don't want to run 2 programs :/
<tseng> yeah ok
<tseng> lets put a web browser in there, too
<bluefoxicy> hey they have mail and calendar,I think announcements goes well with it.
<bluefoxicy> subscribe to ubuntu-announce vs rss feed?
<tseng> sure, in liferea
<bluefoxicy> it costs an extra 50+ megs of memory in liferea to support a fresh gtk+ window, fresh X connection, fresh display area, fresh everything, and then 5 megs of data related to the specific task vo.ov
<tseng> 50mb is a lie
<tseng> http://bmaurer.blogspot.com/2006/03/memory-usage-with-smaps.html
<bluefoxicy> so basically remove the SHR from RSS, like every sane person does when they calculate memory usage; but do it in a more complicated way
<bluefoxicy> (actualy RSS is inaccurate because anything in swap is not RSS; you have to swapoff to get a good RSS value)
<bluefoxicy> 12937 bluefox   15   0  541m 432m 9244 S 30.2 45.6   0:16.32 beagled  
<bluefoxicy> fuck beagle
<tseng> brandon  14859  0.0  1.2  79376 25052 pts/1    Sl+  16:17   0:01 beagled --debug --debug /usr/lib/beagle/BeagleDaemon.exe --fg --debug
<bluefoxicy> I killall'd it and it's still growing
* bluefoxicy killall -9
<tseng> you're funny
<tseng> beagle-shutdown
<bluefoxicy> holy shit.
<bluefoxicy> Mem:    970640k total,   432432k used,   538208k free,      840k buffers
<bluefoxicy> Swap:  2104472k total,   755076k used,  1349396k free,    54820k cached
<bluefoxicy> from full memory usage and 822 megs swap usage, right after killall -9
<jdong> argh, nautilus-cd-burner, why isn't burnfree on by default?
* jdong not happy about losing CD-R's
* jdong paid a whopping $0.005 for it :P
<bluefoxicy> tseng:  every time I use this program it proves within 15 minutes to be a waste of time.  :/
<jdong> EVERY other cd burning app I know enables burn-free by default, except nautilus
<AlinuxOS> Kamion, hello, I saw that finally I can see Georgian debian-installer in Ubuntu Edgy Eft...I knew that the font that contains georgian is unifont... but it's not insalled (is not inside ubuntu-desktop) in my system...so which file is providing georgian font ? Can you help me please ? (I've redesigned glyphs, cause actual geo glyphs are horrible!)
<desrt> jdong; see also: serpentine burns in track-at-once mode
<desrt> that's another vaguely useless behaviour
<jdong> desrt: heh, no kidding
<jdong> desrt: doesn't rhythmbox burn CD's now anyway?
<desrt> that doesn't seem very important to me.  i really like serpentine.
<desrt> it's only that one tiny flaw
<jordi> AlinuxOS: have you played with fc-list?
<AlinuxOS> jordi, no.
<AlinuxOS> why ?
<jordi> that could help you know what font has your glyphs?
<LaserJock> jordi: how's the eyes?
<jordi> LaserJock: they are working ok since tuesday :)
<jordi> I mean, as expected
<LaserJock> jordi: good news
<jordi> I have an appointment tomorrow tho
<AlinuxOS> jordi, oh eyes...
<AlinuxOS> I have too some problems...
<MisterN> nacht
<AlinuxOS> :(
<AlinuxOS> jordi, don't worry ;)
<jordi> what problems?
<AlinuxOS> some camomilla tea..on eyes..is great..for relax.
<AlinuxOS> congiuntivite
<AlinuxOS> but chronic
<AlinuxOS> 3 years of Congiunctivit.
<jordi> LaserJock: I have been having problems to get rest lately, and those two days were even worse when I got little sleep
<jordi> and at odd hours
<jordi> I'm sleepinmg a lot more since
<AlinuxOS> I don't really know the name in english.
<jordi> today I slept like 8:30. A *lot* :)
<jordi> AlinuxOS: ugh, conjuntivitis, in Catalan
<AlinuxOS> jordi, exactly
<AlinuxOS> jordi, georgian font is not listed :/
<jordi> AlinuxOS: weird, and you get your characters drawn?
#ubuntu-devel 2007-09-17
<xtknight> what's the difference between /usr/share/applnk and /usr/share/applications?
<geser> afaik applnk was used by KDE before it switched to applications (which is also used by gnome)
<xtknight> geser,  ok.  i am trying to fix Bug 139980 , i'm just not sure quite how to go about it.
<ubotu> Launchpad bug 139980 in fltk1.1 "fluid missing menu icon" [Undecided,Confirmed]  https://launchpad.net/bugs/139980
<xtknight> i changed applnk to applications
<LaserJock> I think KDE apps usually go to /usr/share/applications/kde/
<xtknight> i was hoping i didnt have to install kde to test
<xtknight> hmm then there's this? /usr/share/app-install/desktop/
<LaserJock> that's for gnome-app-install (Add/Remove Applications)
<xtknight> ah
<Riddell> xtknight: since it's a standard it'll work in KDE, Gnome, XFCE etc
<xtknight> Riddell, /usr/share/applications/*.desktop ?
<Riddell> yes.  what's the Categories= line?
<xtknight> Development
<xtknight> it was in /usr/share/applnk/Development previously i believe
<Riddell> paste the line
<xtknight> this?   Categories=Development
<xtknight> here's the whole desktop file  : http://rafb.net/p/dZgM6Y48.html
<xtknight> after patch
<Riddell> xtknight: works for me (after I change TryExec to something I have installed)
<Riddell> although you should add a ; at the end of the categories line
<xtknight> Riddell, ah ok.  an icons shows for you in gnome+kde you mean?
<Riddell> xtknight: no, that should be changed to Icon=fluid
<xtknight> ok Icon=fluid didnt work
<Riddell> do you have a fluid icon installed?
<xtknight> (this is what it was previously)  it showed just a generic icon instead of the fluid icon.  i have the fluid icon installed in that specified location @ /usr/share/icons/hicolor/48x48/apps/fluid.png (as does anyone who installs the package)
<xtknight> I'm not sure where Icon=fluid tries to locate 'fluid', though
<Riddell> normal desktop icon paths
<Riddell> of which the above is one
<xtknight> ok, somehow that didnt work
<Riddell> shows icon for me if I install fluid
<xtknight> maybe it needed to be Icon=fluid.png?
<Riddell> no
<xtknight> do you use kde exclusively ?
<Riddell> yes
<xtknight> ok didnt work for gnome, i guess
<Riddell> even with Icon=fluid?
<xtknight> correct
<xtknight> but i didnt try Icon=fluid.png yet
<Riddell> maybe the package is missing dh_iconcache
<xtknight> to rebuild gnome icon cache ?
<Riddell> yes
<xtknight> ya quite possible
<xtknight> or dh_icons, i guess
<Riddell> and of course gnome won't use /usr/share/applnk
<Riddell> maybe, you'd need to ask a gnome person which was the right one
<xtknight> manual says dh_iconcache was deprecated
<xtknight> or "will go away"
<Riddell> ok
<LaserJock> xtknight: where do you see that?
<xtknight> LaserJock, "man dh_iconcache"
<LaserJock> I don't think it's gone now
<StevenK> Currently, it's a wrapper around dh_icons
<LaserJock> ah
<m1ke> Where do I get gutsy support from?
<m1ke> I am in all the main ubuntu channels but no ones respond. I am just trying to fix this error, http://www1.uploadhut.com/viewimage.php?type=2&id=24975-Screenshot-synaptic.png
<Hobbsee> m1ke: please see the /topic
<frostburn> where can i find a list of default installed devices, services, and configurations
<frostburn> for desktop/server etc
<LaserJock> frostburn: I think that would entirely dependon your hardware
<frostburn> LaserJock, can you give me a direction on where to search for the install scripts?
<LaserJock> frostburn: I'm not really sure what you mean
<`23meg> LaserJock, did you figure out a way to disable the XDG dirs independently?
<LaserJock> yes
<LaserJock> `23meg: if you edit ~/.config/user-dirs.dirs
<LaserJock> and set the ones you don't want to $HOME/
<LaserJock> then you can remove them
<`23meg> ok, thanks
<LaserJock> if you just try to remove the lines it recreates them
<frostburn> i'm trying to figure out how ubuntu detected my ir receiver and subsequent setup.  It was working before, but now is not.  I want to see what changed and what changed it.
<LaserJock> hmm, I have no idea
<LaserJock> you'd have to talk to somebody familar with IR I think
<frostburn> i thought it was lirc, but lirc was never installed or setup
<LaserJock> so have you tried installing lirc?
<frostburn> yes, but requires setup.  however my vanilla install worked flawlessly
<pitti> Good morning
<StevenK> Morning pitti
<Hobbsee> pitti!
<StevenK> pitti: A miro that provides a transitional package was uploaded yesterday, could you check it and wave it through NEW?
<Hobbsee> man, it must be late, and i havent had breakfast yet...
<LaserJock> pitti!!
<pitti> StevenK: sure
<StevenK> pitti: Thanks
<pitti> done
<kagou> Good Morning
<StevenK> pitti: Thanks!
<LaserJock> pitti: I've just re-added moodle to the MIR queue
<LaserJock> pitti: if you can look it over when you get a chance I'd be grateful
<pitti> LaserJock: http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=moodle makes me cry :(
<LaserJock> I know
<LaserJock> I looked at every single one of them
<LaserJock> took me a good amount of time
<LaserJock> but it seems like upstream has done a lot better with 1.8
<ajmitch> hi pitti
<dholbach> good morning
<LongPointyStick> morning dholbach!
<dholbach> hey LongPointyStick
<tepsipakki> doko: ping, eclipse
<LongPointyStick> (apologies for nickspam, changed from remote host to local host)
<holycow> LongPointyStick: love the nick
<Hobbsee> :)
<ion_> summon mvo
<mdke> dholbach: morning
<doko> tepsipakki: ?
<tepsipakki> doko: junit4-support has been disabled in eclipse, because junit4 was unavailable? It's now in unstable (4.3.1)
<tepsipakki> doko: I just got a request to update that (locally for feisty), and I wonder if it would be as easy to just edit the patch and adjust the build-deps
<doko> a) it's not in gutsy, b) is it found by eclipse?
<tepsipakki> a) right, b) haven't tried yet
<\sh> doko, could you have a look at bug 47232 and sponsor this upload?
<ubotu> Launchpad bug 47232 in redland-bindings "example file provided in /usr/share/doc/python2.4-librdf doesn't work" [Medium,New]  https://launchpad.net/bugs/47232
<dholbach> mdke: heya - you didn't add a changelog entry - am I supposed to upload and package a new version?
<mdke> dholbach: for which?
<dholbach> mdke: regarding your email: ubuntu-docs
<mdke> dholbach: ah, no - i didn't mean to ask you to do an upload, just general FYI
<dholbach> mdke: ah ok - thanks a lot for that
<mdke> dholbach: i wanted to ask about something else. You know the script that strips out unneeded directories for the ubuntu-docs source package? It looks like it didn't get run last time; do you think it would be a good idea to include it in debian/rules?
<dholbach> mdke: yeah, we could do that
<mdke> ok, i'll maybe add it for the next version
<dholbach> put it in the clean:: target
<mdke> dholbach: ok
<ccm> dholbach: will you attend the Gutsy release party on 26th of october?
<ccm> dholbach: the Berlin one
<dholbach> ccm: chances are good :)
<soren> dholbach: Won't you be on your way west at that time?
<dholbach> soren: urgh, yeah, I am
<ccm> dholbach: that sounds good, I actually had the idea of asking you if think think it's a good idea letting you show your dj skills there, too. but iI'll to so via mail.
<dholbach> ccm: no, I'm not going to be there :-(
<dholbach> I'll be on my way to UDS already
<ccm> okay
<soren> Sorry to spoil your fun :)
<ccm> thanks for clearing that out, soren ;9
<soren> ccm: :)
<ajmitch> hi soren
<soren> ajmitch: Hi, Andrew.
<soren> ajmitch: Did you ever get round to doing that Samba update?
<ajmitch> sure
<MacSlow> Greetings everybody!
<saispo> hi all
<saispo> BenC: ping ?
<saispo> BenC: i need you two minutes :)
<ajmitch> 3.0.26, just trying to test out a fix for bug 139265
<ubotu> Launchpad bug 139265 in samba "localized pam == no samba password changing" [High,New]  https://launchpad.net/bugs/139265
<ajmitch> everything else is merged
<pitti> saispo: not really his TZ...
<saispo> pitti: i think
<saispo> pitti: i need a Ubuntu kernel hacker :)
* Hobbsee wonders when UDS actually starts
<soren> ajmitch: Ah, great.
<Hobbsee> oh, hmm.  any aussies going would probably miss the release entirely.
<soren> Hobbsee: Huh?
<soren> Hobbsee: It takes a week to get from Aussieland to Boston?
<Hobbsee> soren: oh, i thought the release was on the 26th, as well as the release parties.
<Hobbsee> soren: sure feels like it, though.  or did for spain.
* soren mumbles something about the apparant differences between release managers' schedule and everyone else's.
<soren> :P
<Hobbsee> soren: well, i'm not the release manager, so...
* Hobbsee is just going off what launchpad says
* soren does a s/release manager's/members of the release team's/g
* Hobbsee has no idea what, if anything, she'll be doign on the release team soon.
* Hobbsee will have to wait and see
<\sh> doko, thx
<seb128> pitti: locate is quite handy, and indexer only list files in your user directory
<mhb> pitti: hi, are the gutsy daily langpacks built somewhere?
<pitti> mhb: they get uploaded straight to gutsy
<mhb> I thought it's http://ppa.dogfood.launchpad.net/ubuntu-langpack/ubuntu/
<mhb> pitti: 20070905 according to my apt
<mhb> pitti: that's not exactly daily
<pitti> mhb: I only build them twice a week, but that's indeed old
<carlos> hmm
<carlos> seems like for some reason, I'm not updating the link to the latest export...
<pitti> ah, indeed, that's it
* carlos checks
<Hobbsee> uh oh, it's jono, everyone behave.
* jono casts his beady eye on #ubuntu-devel
<jono> :)
* Hobbsee looks innocent
<Keybuk> seb128: how do I stop everything complaining that /usr/bin/esd doesn't exist?
<Keybuk> how did I end up without esd?
<seb128> Keybuk: talk to pitti, he patched libgnome to use aplay
<pitti> Keybuk: we unseeded esound, because it's evil and doesn't do any good nowadays
<pitti> Keybuk: however, when someone installs it, it should still be used IMHO
<Keybuk> err, ok...
<dholbach> we should patch gnome-desktop-environment (of meta-gnome) to not depends on esound too then :)
<ion_> Hi mvo
<mvo> hey ion_, thanks for your mail
<ion_> Heres the hardware-connected source, btw: http://codebrowse.launchpad.net/~ion/hardware-connected/main/annotate/johan%40kiviniemi.name-20070915054427-yxtfsp35hsf292a1?file_id=hardware_connected.c-20070408174135-e35gqc0of07mn3iy-1
<ion_> mvo: In case you decide to use hardware-connected, theres a branch with Ubuntu packaging for it as well.
<mvo> ion_: aha, I was going to ask if its available inside ubuntu already
<ion_> mvo: Unfortunately i only made the packaging two days ago.
<vprints> Hi! mvo, mhb asked me to ask you to move the restricted manager .mo file to a langpack common to both Gnome and Kde
<pitti> vprints: you probably want to talk to me
<pitti> vprints: indeed, that would be a good idea
<vprints> Hi pitti
<vprints> :)
<vprints> So You agree ?
<pitti> vprints: in principle yes, but we don't yet get translations for restricted in langpack exports
<pitti> carlos: ^ that's still true, correct?
<carlos> pitti: we don't update them automatically
<carlos> pitti: but if you provide with updates manually, the export should include it)
<carlos> pitti: it's just one package, right?
<pitti> carlos: how do you mean?
<pitti> carlos: yes, restricted-manager
<carlos> send me the tarball and I will upload it manually until we fix that in our code to get it done automatically
<pitti> ah, I see
<carlos> also, you need to strip translations or the ones from language packs will not be used ever
<pitti> carlos: I already do that
<carlos> ok
<carlos> then, provide me with latest tarball and I will do an upload
<carlos> pitti: also, I will check that language packs keep exporting those translations, even not being in main
<pitti> carlos: does the tarball need to have current translations from Rosetta?
<pitti> carlos: the .po files in trunk are some weeks old already
<carlos> no need to, just the tarball that the package build produces
<carlos> so we do manually what is done automatically for main
<pitti> carlos: http://people.ubuntu.com/~pitti/tmp/restricted-manager_0.31_amd64_translations.tar.gz
<carlos> pitti: ok, thanks
<pitti> carlos: thanks for handholding it
<vprints> pitti, carlos, thankyou!
<carlos> np
<carlos> vprints, pitti: You can track its import status from https://translations.edge.launchpad.net/ubuntu/gutsy/+source/restricted-manager/+imports
<carlos> it would take one or two days to get it imported because we are finishing importing OO.org which adds some delays to the queue
<\sh> seb128, do you happen to know who I can recreate my local gconf default settings? those which are shipped by default of ubuntu?
<\sh> s/who/how/
<seb128> \sh: rm -rf .gconf
<seb128> \sh: you will also delete your configs though
<seb128> like evolution accounts, etc
<\sh> seb128, well, this I did, since then I don't have any default icons and no default key-accels
<seb128> you can gconftool-2 --recursive-unset /app/appname also
<seb128> what do you mean?
<\sh> seb128, all my settings were destroyed during an update 2 weeks ago...and I deleted all .gonf* dirs and .gnome* dirs
<\sh> since then I can't use plain metacity anymore and somehow the menu icons are disappeared too
* \sh should reinstall gutsy on his laptop...
<seb128> that is very weird
<seb128> what icon theme do you use?
<\sh> seb128, default from human....
<seb128> does it work with a different user?
<\sh> seb128, it's not showing anything, but the menu text entries
<vprints> carlos, i checked, a bit old translations there in the upload, will it update itself automaticaaly after upload beign completed or not before you fix it in the code ?
<carlos> vprints: sorry, I don't understand what you mean...
<carlos> vprints: the only code I'm going to fix is to allow automatic translation updates based on the package build
<carlos> so I don't need to do it manually like we did today
<vprints> carlos, ok, i asked it cause i didn't understand exactly what pitti and you were talking about fixing the code =P
<carlos> vprints: is it clear now?
<vprints> Yes, thankyou
* carlos is not touching the application code
<carlos> :-)
<asac> pitti: any hints where to best place the metric tweak?
<asac> pitti: (about nm routing)
<pitti> asac: in the route invocation in ifupdown, I think
<asac> pitti: so the idea is to set cost of standard interfaces to 1, right?
<asac> (while nm gets 0 by default)
<pitti> asac: s/cost/metric/, yes
<pitti> it feels like a Gross Hack (TM) to me, though
<asac> any other ideas?
<pitti> asac: e. g. look at the 'route' output in feisty or newer; there are 'metric 1000' default routes for link-local
<pitti> asac: other ideas> unfortunately not; n-m and ifupdown will continue to mess with each other's configuration in either case
<asac> pitti: so it should just work?
<pitti> asac: in theory, with above approach, n-m can override ifupdown's default route
<asac> pitti: or does the default route also needs a tweaked metric?
<pitti> asac: from r-m? no, shouldn't (it defaults to 0)
<asac> oh nevermind
<pitti> cjwatson, Mithrandir: bug 125015 falls under feature freeze and I'm the assignee, so I don't want to judge myself; WDYT?
<ubotu> Launchpad bug 125015 in restricted-manager "Add support for sl-modem-daemon" [Wishlist,Triaged]  https://launchpad.net/bugs/125015
<pitti> cjwatson, Mithrandir: the code itself will be relatively simple, the question is more that we didn't extensively test sl-modem so far
<pitti> iwj_: ^ how much testing did sl-modem-daemon get so far?
<iwj_> pitti: Hi.
<pitti> hello Ian!
<pitti> IMHO it's good to add it; after all, it's not enabled by default, and once you enable it, you can disable it again if it doesn't work
<iwj_> I think it's pretty solid and not likely to make too much of a mess.
<pitti> iwj: sorry, this bug got dragged too long by me, no time for it yet
<iwj> I did some testing of sl-modem-daemon myself - you'll remember it from the distro sprint.
<pitti> right
<iwj> And I gave it another test at the last tribe.
<iwj> Err, the mythical tribe 6 I mean.
<cjwatson> pitti: I don't have a problem with it
<pitti> cjwatson: good, thanks
<mvo> iwj: did you got my mail about progress reporting and triggers
<iwj> Probably but I haven't read it yet ...
* iwj looks.
<iwj> In answer to your question, no, there is no way to know in advance how many trigger processing steps will be needed.
<iwj> Triggers can trigger other triggers, so even the number of outstanding triggers is no good as it can increase.
<pitti> iwj: do you have an idea how common it is that the snd_intel8x0m don't match, but /proc/asound/cards contains 'Modem'?
<pitti> iwj: that case (r-m handlers not attached to a kernel module) is not currently supported in the r-m architecture
<pitti> iwj: it's not too hard to add either, but if it's just an academic case, we might get away without hacking it in for gutsy
<iwj> There are other modules as well I think.
<pitti> ah, that way around; I see
<asac> wtf is noweb :/
<iwj> I think snd-intel8x0m is exactly that kind of modem.
<pitti> asac: you don't know Knuth's WEB?
<pitti> asac: http://en.wikipedia.org/wiki/WEB
<iwj> The sl-modem-daemon package has a list of modules is daftly messes with, one of which doesn't appear to exist at all, but IIRC I haven't been able to test any but intel8x0m.
<asac> pitti: well  now i know it ;)
<iwj> s/is daftly/it daftly/
<iwj> snd-via82xx-modem snd-atiixp-modem#
<pitti> ok, so I better add support for arbitrary 'is this hw available' methods (more than just modalias testing)
<iwj> I think that would probably be best, yes.
<Keybuk> mvo: unpatched version of mplayer is fine
<mvo> Keybuk: rock, thanks for testing
<baltix> hi all
<mhb> carlos: hi, is there a way to workaround the old daily langpacks in Gutsy and get the more recent version?
<baltix> who is responsible for daily builds of Ubuntu/Xubuntu/Kubuntu images ?
<carlos> mhb: that's a question for Pitti, he's the one producing the .deb packages you need, I only produce the tar.gz with the translations
<cjwatson> baltix: the CD image team (including me). What's up?
<pitti> mhb: unfortunately not, since everything relies on the 'current' symlinks
<pitti> mhb: once this is fixed, the cronjobs will upload recent stuff to gutsy again
<baltix> cjwatson: livecd-base isn't put in cdimage.ubuntu.com since April or March
<baltix> cjwatson: look at this log for example http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/livecd-base/gutsy/livecd-base-20070801.log
<mhb> pitti: could you perhaps take a guess on how long will it take? From now until the cronjobs upload it?
<pitti> carlos: ah, did you find out why the symlink wasn't updated?
<pitti> mhb: I trigger a run now; ETA an hour or so
<pitti> mhb: (however, that will not yet contain r-m translations)
<mhb> pitti: great, thanks! r-m translation can wait, I wanted to be able to check the missing translations in other apps
<carlos> pitti: I fixed it manually, although today, I don't think we will produce new ones, we are doing QA testing and the db mirror was not updated today
<baltix> also something wrong is with Ubuntu CD build logging system - last build log is more than 40 days old...
<baltix> look at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ubuntu/gutsy/?C=M;O=A
<cjwatson> baltix: thanks, working on all that
<mhb> carlos: by the way, I've seen that you plan to finally fix the support of KDE plural forms in LP 1.1.9. Would it be possible to trigger an upstream sync after the release, so there won't be BROKEN TRANSLATION all over Kubuntu Gutsy?
<carlos> mhb: danilo is working on it, we will try to fix it when possible
<carlos> Riddell: do you think would be possible to get a kde-i18n update for Gutsy at the end of this week ?
<baltix> cjwatson: btw, maybe you know why there are no daily builds in cdimage.ubuntu.com since friday ?
<mhb> carlos: okay, thanks.
<cjwatson> baltix: one at a time already
<carlos> mhb: btw, the code is already in our development server, if nothing bad happens during the QA testing, it should be deployed next Wednesday
<carlos> mhb: including native support for KDE context strings too
<mvo> iwj: would it be possible to pass something that trigger processing has started over the status-fd? then I could make the progress bar at least pulse
<iwj> NB that trigger processing might be interspersed with configuration.
<iwj> But I think you already ought to get a message about trigger processing.
<Riddell> carlos: unlikely, I am on holiday, why?
<carlos> Riddell: ok, let me rephrase it :-)
<mvo> iwj: I don't think so, I think only if it happens during the configure phase of a package, but not when dpkg processes the outstanding triggers
<carlos> Riddell: would be possible to get it done before Gutsy release?
<Riddell> cjwatson: where does isolinux.cfg and other files in isolinux/ on the CD get created?
<carlos> Riddell: not before Wednesday-Thursday
<Riddell> carlos: possibly, you think we should take an svn snapshot of KDE 3 translations?
<carlos> Riddell: we just added kde plural form support to launchpad so that's the easier way to get all plural form messages with format strings 'fixed'
<iwj> mvo: Let me check.
<carlos> Riddell: that would help to be more up to date with what KDE has right now
<carlos> so if that's not a problem for you as the packager, I'm fine with it
<Riddell> carlos: ok, that shold be possible after beta (two weeks)
<carlos> ok, thank you
<pitti> iwj: is there an easy way to detect whether the daemon is actually active and successfully found a modem? like testing for the presence of an 'slmodemd' process, if it will terminate if it didn't find an appropriate modem?
<iwj> It creates a /dev/modem symlink.
<iwj> (But I don't know if it removes it again.)
<StevenK> mvo: Have you seen bug 139791? I'm happy to fix it, I just need a pointer around aptitude's data structures.
<ubotu> Launchpad bug 139791 in aptitude "aptitude changelogs 404 when the source is in a different component to the binary package" [Undecided,New]  https://launchpad.net/bugs/139791
<iwj> Testing for the daemon running is probably reasonable too.
<cjwatson> baltix: livecd-base fixed, build logs fixed
<cjwatson> thanks for the reports
<StevenK> iwj: Won't udev also do the same thing?
<pitti> iwj: /dev/modem sounds great; it will disappear after a reboot anyway
<cjwatson> baltix: with regard to daily builds, the CD build system seems to be having trouble connecting to bazaar.launchpad.net for the seeds
<pitti> iwj: and r-m does not support immediate disabling anyway (you need a reboot to disable a module, too)
<cjwatson> Riddell: http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
<baltix> cjwatson: thank you very much
<cjwatson> Riddell: specifically tools/boot/gutsy/boot-*
<cjwatson> baltix: I believe I've installed a workaround for connecting to bazaar.launchpad.net; rerunning Ubuntu daily builds now
<Keybuk> seb128: random Q.  how do I search tracker ?
<pitti> seb128: deskbar applet or Applications -> Accessoires -> Tracker search
<iwj> pitti: I haven't tested this, note - eg, I don't know for sure that you might not have another /dev/modem.
<pitti> iwj: can I steal 5 minutes of your time to test the new sl-modem-daemon love in restricted-manager?
<Keybuk> OMG, that "Tracker Search Tool" should be purged for crimes to usability
<pitti> iwj: I ANDed the test with "sl-modem-daemon package is installed"; that should be close enough for now
<pitti> iwj: and I can always refine that later
<cjwatson> ssh: connect to host bazaar.launchpad.net port 22: Connection timed out
<cjwatson> argh
<pitti> iwj: new package is on http://people.ubuntu.com/~pitti/tmp/ (restricted-manager{,-core}
<StevenK> Smells like firewalling.
<StevenK> Or hosts.{allow,deny}
<cjwatson> obviously
<cjwatson> but cdimage shouldn't be using ssh to bazaar.launchpad.net in the first place
<pitti> iwj: I don't have such a modem anywhere, so I could only test it with some faking
<iwj> pitti: Eh ?  Not sure I follow how ANDing with the package being installed helps.
<StevenK> cjwatson: Ah. I will stop trying to second guess you, then. :-)
<pitti> iwj: it only avoids showing the driver as 'in use' when the package is not even installed, but the admin created another /dev/modem
<iwj> OIC
<iwj> OK.
<iwj> I'll give it a whirl.
<pitti> iwj: it doesn't help at all with asserting that /dev/modem is in fact the softmodem, of course
<pitti> iwj: thanks a lot!
* pitti fixes a typo in the rationale
<cjwatson> ah
<cjwatson> it just took ssh that long to time out from an earlier manual attempt, and it was running in the background forked by bzr ...
<Riddell> cjwatson: thanks
<pitti> yay, seb128 is back, 0wning -changes again :)
* pitti hugs seb
* seb128 hugs pitti
<seb128> Keybuk: fileselector, nautilus search, applications, accessoirtes, tracker
<seb128> Keybuk: I need to change deskbar to activate the tracker plugin by default also
<Keybuk> can you get to nautilus search from the desktop?
<seb128> ctrl-F
<orkid1> hi, I just installed gutsy from netboot, and I cannot run tasksel, it exits with an error.
<orkid1> can't use "audio creation and editing suite" as an array REF, while strict refs is in use.
<orkid1> at line 84.
<orkid1> Any ideas?
<soren> cjwatson: "There is no conspiracy"  <g>
<cjwatson> damnit orkid1 don't ask a question leave
<cjwatson> s/leave/and leave/
<Keybuk> seb128: that doesn't search evolution mails though?
<seb128> Keybuk: I'm not sure, doesn't look like
<Keybuk> :-(
<Keybuk> trackerd is spending the majority of its time indexing the tens of thousands of evo mails I get
<Keybuk> and I can't seem to find out how you search them :p
<torkel> using tracker-search or tracker-search-tool?
<seb128> Keybuk: the tracker search tools should do it
<pochu> Keybuk: do you have mail indexing enabled? System>Preferences>Indexing
<Keybuk> pochu: yes
<Keybuk> tracker-search-tool returns no results for "seb128"
<pochu> Keybuk: oh, there's a bug, which is fixed in svn trunk, I think
<cjwatson> soren: :-)
<pochu> Keybuk: bug 138778
<ubotu> Launchpad bug 138778 in tracker "tracker doesn't find results for email address" [Low,Incomplete]  https://launchpad.net/bugs/138778
<seb128> Keybuk: maybe tracker is still indexing or maybe you face a bug
<seb128> Keybuk: ask jamiemcc
<jamiemcc> keybuk: tracker-status
<Keybuk> Tracker daemon's status is Indexing.
<jamiemcc> bext wait then
<Keybuk> it's never NOT indexing
<Keybuk> it's been indexing since it was installed
<Keybuk> and it's still indexing now
<pochu> jamiemcc: looks like bug 138778
<ubotu> Launchpad bug 138778 in tracker "tracker doesn't find results for email address" [Low,Incomplete]  https://launchpad.net/bugs/138778
<jamiemcc> pochu: that fix is committed to svn
<orkid1> Is the current tasksel busted, or is it just my version that's giving me errors regarding 'strict' and DESC on line 84?
<soren> orkid1: Word of advice: Stick around for more than 2 minutes if you ask a question.
<orkid1> I couldn't before, since I was in recovery mode, and wanted to try regular mode again. was there any response?
<\sh> seb128, do you know if http://bugzilla.gnome.org/show_bug.cgi?id=459270 is fixed by your latest pygtk upload?
<ubotu> Gnome bug 459270 in win32 "opening sub-menus" [Normal,Unconfirmed] 
<seb128> \sh: looks like bug #121796 which is fixed with gtk 2.12.0
<ubotu> Launchpad bug 121796 in gtk+2.0 "submenu items selection doesn't work correctly" [High,Fix released]  https://launchpad.net/bugs/121796
<\sh> seb128, thx :)
<\sh> seb128, I'll test gajim...with latest gtk
<cjwatson> orkid1: I fixed tasksel yesterday
<cjwatson> orkid1: your mirror is probably just behind
<cjwatson> orkid1: see bug 139917
<ubotu> Launchpad bug 139917 in tasksel "Server installation failes on step 11" [Undecided,Fix released]  https://launchpad.net/bugs/139917
<orkid1> cjwatson: thanks
<cjwatson> orkid1: double-check: from tty2, chroot /target dpkg -l tasksel
<cjwatson> orkid1: what's the version in the output?
<orkid1> 2.67ubuntu5
<cjwatson> ok, 2.67ubuntu6 was the fix
<orkid1> thanks, i'll use another mirror.
<cjwatson> so give it a day for your mirror to catch up, or else ... what you said
<tepsipakki> cjwatson: the new tasksel is not in archive.u.c
<tepsipakki> s/in/on/
<BockBilbo> hello,hello
<cjwatson>    tasksel | 2.67ubuntu6 |         gutsy | source, all
<cjwatson> if it's not on archive then that's a mirroring problem
<cjwatson> and, indeed, it isn't
* cjwatson goes to prod sysadmin
<tepsipakki> thanks
<orkid1> so where can i get it (what mirror) ?
<cjwatson> orkid1: you can't
<cjwatson> wait :-)
<orkid1> ok, i guesss they all propagate from archive. thanks.
<cjwatson> archive.ubuntu.com is a mirror of a private machine to which only a very limited number of core developers have access
<orkid1> oh, k.
<orkid1> hopefully the sysadmin is online and available :)
<BockBilbo> ive just asked a question on #ubuntu+1 but no one answered, so im going to try it here because it's related to development: i've found a bug on a package related to asterisk on gutsy, what's the correct procedure to create a bug report on launchpad?
<cjwatson> at this time I should think one of the sysadmin team is around, yes
<cjwatson> BockBilbo: https://bugs.launchpad.net/ubuntu/+filebug, enter the package name
<BockBilbo> thanks cjwatson
<cjwatson> (well, enter the bug description first. basically just follow the instructions)
<BockBilbo> alrit
<BockBilbo> e
<BockBilbo> :)
<BockBilbo> though im going to see if i can find the solution first
<BockBilbo> :)
* orkid1 anxiously awaits update or archive.ubuntu.com, and wonders if it's a trivial fix that could be spelled out over irc.
<cjwatson> orkid1: give it an hour tops
<orkid1> cjwatson: thanks :)
<cjwatson> thank elmo
<orkid1> i will , hopefully in an hour :)
<\sh> jono, happy birthday, mr. young one ;)
<pitti> cjwatson: I'd like to update cups to 1.3.1 (http://www.cups.org/articles.php?L492); do you approve?
<ion_> mvo: Theres a source package of hardware-connected at https://edge.launchpad.net/~ion/+archive (and a binary package as soon as a PPA buildd gets around to it).
<mvo> ion_: thanks!
<jcastro> jono: dholbach: I am ready!
<jsgotangco> holy
<jsgotangco> itz da horzemaannn
<jcastro> heh
<Hobbsee> hi spam
<jsgotangco> hi
<jsgotangco> i guess its jorge's 1st day as Canonical drone?
<dholbach> jcastro: ROCK ON
<jsgotangco> bring on da bass
<zul> welcome back jcastro
<thom> jcastro: yay, welcome back
<jcastro> thanks!
<asac> pitti: who can review ifupdown patches? you?
<pitti> asac: I'm not terribly familiar with it, but I can have a look
<asac> pitti: i have added a patch to bug 139403
<ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [Undecided,Confirmed]  https://launchpad.net/bugs/139403
<asac> pitti: it works nice here
<pitti> asac: yay!
<asac> e.g. enable NM device -> route goes over NM
<mjg59> cjwatson: Yeah, as far as I can tell nothing I uploaded yesterday has hit archive yet
<asac> disable NM device -> route goes over ifupdown
<cjwatson> mjg59: it's fixed now
<mjg59> cjwatson: Fixed as in packages are there now, or fixed as in the next archive run will work?
<cjwatson> the former
<mjg59> Hm. I'm still seeing 0.14.6-0ubuntu7 of xserver-xorg-input-synaptics, though ubuntu8 is built
<asac> pitti: i intentionally didn't include a debdiff, because the deb source contain all generated .c/.h files ... so debdiff is unreadable
<asac> pitti: to test its just patch ... dch -i ... build
<pitti> asac: right, that's fine
<mjg59> cjwatson: Oh, wait, ignore me - it's there, I'm clearly just doing something stupid
<cjwatson> mjg59: gb.archive.ubuntu.com is still out of date - archive.ubuntu.com is fine
<mjg59> It would be really great if people with trackpads could test the settings functionality I've added to the mouse preferences
<cjwatson> I was planning to ;-) I assume I need to restart X?
<mjg59> Yeah
<mjg59> No way to unload/reload input drivers on the fly in our version
<ion_> benc: Hi. Have you had a chance to apply the patch to nvidia-supported yet?
<BenC> ion_: working on lum right now, but lrm is next on my list
<ion_> Alright :-)
<ion_> benc: Do you think youll let nvidia-new have the highest priority?
<BenC> ion_: are there any regressions for compiz in doing that?
<ion_> I dont know, actually.
<BenC> do you have non-8xxx nvidia hw to test compiz on with nvidia-glx and nvidia-glx-new?
<ion_> nvidia-new doesnt support my nvidia card at all.
<BenC> ion_: you have unsupported geforce?
<ion_> Its supported by nvidia-glx, but not nvidia-glx-new.
<TeTeT> latest update on gutsy crashes gnome-settings-daemon for me
<BenC> TeTeT: settings are for wimps :)
<_MMA_> BenC: I just popped in (so i dont totally know the issue) but I have a 7950GT.
<BenC> _MMA_: just wanting to see if nvidia-glx-new works just as well with compiz as nvidia-glx does
<IntuitiveNipple> I run nvidia-glx-new with a GeForce Go7600, been very pleased with it
<_MMA_> Im using -new now. Want me to try just -glx?
<ion_> Id guess wed have seen bug reports about compiz not working correctly with nvidia-glx-new already if that were the case, since im sure a lot of people install nvidia-glx-new if it supports their card.
<IntuitiveNipple> has something new come up then? The only big issue is the GLX crashing because of the xorg ABI change with nvidia drivers
<_MMA_> ion_: Looks like some other Gimp issues are coming down to using that small theme. Another bug someone else had was "fixed" by switching back to the bigger theme.
<ion_> benc: I packaged hardware-connected, theres a source package in <https://edge.launchpad.net/~ion/+archive>. It should be useful in the future if a single nvidia package is going to choose an appropriate driver at runtime.
<ion_> mma: Ok. Could you please mention that in the bug discussion?
<_MMA_> ion_: Bug 135650 and now Bug 131564.
<ubotu> Launchpad bug 135650 in ubuntulooks "GIMP crashes when trying to resize an image." [Undecided,New]  https://launchpad.net/bugs/135650
<ubotu> Launchpad bug 131564 in gimp "Gimp crashes after picking text tool options tab." [Undecided,New]  https://launchpad.net/bugs/131564
<_MMA_> Looks like its something with the use of the "small" theme.
<IntuitiveNipple> Hmmm...doesn't crash for me. Is there any more specific steps (text tool options) I can follow to be sure I'm doing the same thing?
<BenC> ion_: we'll never have that option without some really gross looking alternatives for libGL and friends
<ion_> benc: True
<BenC> I think we should be doing alternatives for it though
<ion_> Yes, probably.
<BenC> we should be able to install fglrx/nvidia/xorg-gl all at once
<BenC> but the real crazy part will be when xorg is zero-conf, we'll need to switch the alternatives at video detection
<saispo> hi BenC :)
<BenC> and on multi-head systems with competing GL needs, we'll be screwed (like we are now)
<BenC> saispo: hello
<saispo> BenC: two little question :)
<saispo> BenC: why xt_CONNMARK not include in the default config kernel ?
<ion_> benc: Perhaps there should be a link libGL.so.1.nvidia to libGL.so.1.nvidia-NNNN which would be updated automatically based on connected hardware, but a link from libGL.so.1 to libGL.so.1.nvidia would be made via alternatives.
<asac> siretart: hi, did you find some time to think about/look into wpasup timeout issues?
<BenC> saispo: no idea
<saispo> BenC: how can i manage to include it directly when i build with git ? :)
<Keybuk> bryce: around?
<BenC> saispo: that question is answered on the wiki quite thoroughly
<saispo> BenC: i suppose create a custom branch, modify the config in debian/, do a git-tar-tree and lauch the deb command ? :)
<BenC> saispo: https://wiki.ubuntu.com/KernelTeam
<saispo> BenC: yes but when i try to add it after with a make menuconfig, i have a build error...
<BenC> saispo: because you didn't read the wiki :)
<saispo> 10:08:38 < saispo> In file included from scripts/mod/file2alias.c:40:
<saispo> 10:08:38 < saispo> scripts/mod/../../include/linux/input.h:30: erreur: expected specifier-qualifier-list before __s32"
<hunger> What is that new -virtual kernel package meant for?
<saispo> have you already seen this ? :)
<BenC> saispo: no, read the wiki, you aren't going about this correctly
<Leon_home> can someone recommend me on good web development environment software like XAMPP that's support ubuntu 64 bit platform ?
<cjwatson> hunger: like the package description says, "Geared toward virtualised hardware."
<cjwatson> if you're running in a typical virtualised environment, then you don't need quite so much stuff in your kernel build as usual, and it may be worth trimming it down in order that your image is smaller
<torkel> Leon_home: please try in #ubuntu. This is not the right channel for that kind of questions
<Leon_home> ok thanks (sorry)
* lamont discovers the errors of setting udev into debug mode on dapper
<lamont> udevd-event[1035] : udev_rules_get_name: no node[17179603.360000]  Kernel panic - not syncing: Attempted to kill init!
<zul> lamont: oops
<pitti> anyone here with a WinModem who would like to test a new restricted-manager?
<TeTeT> pitti: we do have a couple winmodems in Montreal, though not a real line
<pitti> TeTeT: that should be good enough for testing, though
<pitti> oh, you need to have gutsy for that test
<TeTeT> pitti: no prob
<TeTeT> pitti: I can do some tomorrow, I'm not in the office today, also contact Shang for some tests
<sbalneav> pitti: Welcome back!
<pitti> hey sbalneav
<bddebian> w00t pitti
<pitti> I was here the entire last week, too :)
<bddebian> Heh
<saispo> BenC: it's an easy answer ;-)
<Kopfgeldjaeger> hi
<BenC> saispo: if it was an easy answer, I wouldn't have written a wiki page explaining it to avoid repeating it to everyone who asks :)
<pitti> mvo: can you please have a look at my last question in bug 47044?
<ubotu> Launchpad bug 47044 in apt "apt cant work with disable proxy" [Medium,Fix committed]  https://launchpad.net/bugs/47044
<pitti> bdmurray, mvo: any chance that you could verify bug 57445 and bug 58935? Those are my own updates, so I cannot verify them myself (I did test them, though, and added clear recipes, should not take more than 5 minutes)
<ubotu> Launchpad bug 57445 in cupsys "Printing not possible with line break or mis-interpreted encoding in job title" [Medium,Fix committed]  https://launchpad.net/bugs/57445
<ubotu> Launchpad bug 58935 in hal "two hald-addon-storage  processes per pooled device" [Medium,Fix committed]  https://launchpad.net/bugs/58935
<saispo> BenC: hmmm you're right ;-)
<hunger> cjwatson: Does that include the vmware drivers from open-vm-tools.sf.net?
<jdong> speaking of vmware, is vmware-server-kernel-modules going to be available in Gutsy?
<bddebian> seb128: You still aboot?
<seb128> bddebian: "aboot"?
<Spads> aboat
<bddebian> about, don't you speak Canadian? ;-P
<seb128> no ;)
<StevenK> But we removed aboot from Ubuntu...
<bddebian> heh
<cjwatson> hunger: no idea
<iwj> pitti: I installed those two restricted-manager debs on my winmodem test machine and now the r-m applet isn't there any more.  (Previously it was shown, but for other reasons.)
<bddebian> seb128: I got your first reply about the gaim packages but no response to my reply.  Did it even make it to the list?
<seb128> bddebian: I think so, I was on holidays for a week and I've quite some lag on mails
<bddebian> OK, sorry
<pitti> iwj: right, you usually call it from System -> Admin
<iwj> I'm not supposed to get a notification bubble etc. ?
<iwj> pitti: And the winmodem doesn't show up when I open it manually.
<pitti> iwj: hm, that's a bug
<seb128> bddebian: I think most of gaim packages have been ported to pidgin
<pitti> iwj: /proc/asound/cards does have "Modem"?
<iwj> No, but you only see that after you've loaded the module.
<seb128> bddebian: the one you listed probably need to be patched
<soren> Isn't there a release notes wiki page for gutsy yet?
<bddebian> seb128: Aye, but renamed?
<soren> ...or somewhere else where we brag about the fancy new stuff?
<seb128> bddebian: which is none of the options you listed
<seb128> bddebian: yes, but that's not a simple rebuild, it needs autotools and code changes to use pidgin and binary packages needs to be renamed
<iwj> pitti: I thought I'd written this down somewhere but I can't seem to find it right now.
<pitti> iwj: in bug 125015
<ubotu> Launchpad bug 125015 in restricted-manager "Add support for sl-modem-daemon" [Wishlist,Fix committed]  https://launchpad.net/bugs/125015
<bddebian> seb128: How do you mean then?
<seb128> bddebian: ?
<seb128> bddebian: what is not clear? code change? autotools? rename?
<pitti> iwj: oh, I see; so that's a circular test
<pitti> iwj: but with that version it still ought to work for the modaliases of snd_intel8x0m
<iwj> I just did modprobe snd-intel8x0m and the Modem appears now.
<bddebian> seb128: Sorry, your first suggestion that you say was none of my options (Sheesh, now I'm confusing myself)
<seb128> bddebian: in your mail you wrote "Just rebuild them against pidgin or
<seb128> actually create new binary packages such as foo-pidgin or pidgin-foo?"
<iwj> That bug report doesn't seem unreasonable but I don't remember all of the details clearly right now.
<seb128> bddebian: that's not that simple, you also need code changes
<pitti> iwj: oh, I bet I know; I'll think about it and give you another test version when I'm done
<iwj> OK
<bddebian> seb128: Ah, gotcha.  Well nothing is ever "easy" is it? :-)
<seb128> bddebian: sometimes ;)
<bddebian> Well maybe for you studly types, not morons like me :-)
<mathiaz> pitti: did you get a chance to review the MIR I wrote from new apparmor-utils dependencies ?
<pitti> mathiaz: not yet, but it's high on my list; probably today
<mathiaz> pitti: great ! Thanks.
<siretart> asac: keescook has written a patch for wpasupplicant 0.6, I've forwarded it upstream and I'm waiting for replies
<siretart> asac: I still need to test that patch on my machine
<siretart> asac: do you know what network-manager developers use for development? 0.5 or 0.6 branch?
<asac> siretart: 0.5
<asac> siretart: do you think that that patch resolves any of the TIMEOUT issues?
<mathiaz> keescook: did you push the latest version of apparmor in the ubuntu-core-dev branch ?
<pitti> cjwatson: ah, dapper-proposed CD building seems to work fine, I just generated http://cdimage.ubuntu.com/ubuntu-server/dapper/daily/20070917.1/
<pitti> cjwatson: thanks for setting it up
<cjwatson> cool
<pitti> cjwatson: not sure how to check for the correct d-i version from the .list files, though
<pitti> cjwatson: but in general it has versions from -proposed and -security
<siretart> asac: TBH, maybe some, but most likely not the majority
<asac> siretart: do you have the bug id again?
<asac> siretart: nm ... have it
<Mirv> pitti: would there be time to have language pack updates for feisty again? the last ones were in the beginning of June, and since then we've eg. had launchpad improvements (many erronous translations corrected back to what upstream uses) and gnome-app-install's codec dialog made translatable
<Keybuk> http://people.ubuntu.com/~scott/compiz.patch
<pitti> Mirv: that's on my list, yes
<pitti> cjwatson: hmmm: http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
<cjwatson> curious
<pitti> cjwatson: I recently got some cron mail about failed rsync from drescher to rookery; did you, too?
<cjwatson> oh, drescher's IP address changed
<keescook> mathiaz: Yes, it should be pushed.
<pitti> http://people.ubuntu.com/~ubuntu-archive/NBS/ is slightly behind, too
<pitti> cjwatson: ah, *headdesk*
<pitti> cjwatson: fixing...
<keescook> mathiaz: oops, pushed now.  *blush*
* cjwatson goes around changing authorized_keys files
<pitti> cjwatson: seems you beat me to it :)
<mjg59> cjwatson: Had a chance to test the synaptics thing?
<bryce> Keybuk: yeah
<cjwatson> mjg59: sorry, not yet, stuff keeps coming up
<mjg59> cjwatson: No problem
<cjwatson> pitti: it's happier now
<pitti> cjwatson: cheers
<cjwatson> mjg59: disabling tap-to-click in System -> Preferences -> Mouse seems to have done nothing useful
<cjwatson> (I commented out the MaxTapTime 0 I had in xorg.conf)
<mjg59> cjwatson: Does anything appear in /var/log/Xorg.0.log when you do that?
<Hobbsee> oh neat, kdar finally got removed from debian too
<cjwatson> mjg59: I get this when opening the mouse applet:
<cjwatson> ProcXCloseDevice to close or not ?
<cjwatson> Control Proc called
<cjwatson> ProcXCloseDevice to close or not ?
<cjwatson> Control Proc called
<cjwatson> but that's all
<mjg59> cjwatson: Sounds like the old synaptics driver
<cjwatson> mjg59: I see the new changelog
<mjg59> Let me look
<cjwatson> and I logged out, /etc/init.d/gdm restart, logged back in
<mjg59> Argh.
<mjg59> I seem to have uploaded the old code like some sort of ridiculous novice
<mjg59> Let me see if I still actually *have* a copy
<cjwatson> mjg59: if you do, throw me over a diff and I'll build it locally
<mjg59> No. Arse.
<mjg59> Oh well, not too hard to regenerate
<pitti> mathiaz: libterm-readkey-perl approved and promoted; the xml-rpc perl thing is a more elaborate beast, though
* cjwatson keeps just about everything he has ever uploaded
<cjwatson> the disk space is cheap compared to the hassle of having to regenerate it later
<mjg59> cjwatson: Oh, I have what I uploaded :)
<cjwatson> hah
<mjg59> Just not what I meant to upload...
<mathiaz> pitti: ok. We've disabled the rpc code in the utilities.
<pitti> mathiaz: oh, I am not saying that I reject it, just that it needs some deeper review
<mathiaz> pitti: libterm-readkey-perl is the most important package.
<pitti> mathiaz: but if you don't actually need it, I wouldn't be worried :)
<pitti> mathiaz: out of interest, what's it used for?
<mathiaz> pitti: ok. That's fine for now.
<mathiaz> pitti: to access the profile repository.
<mathiaz> pitti: upstream has set up an infrastructure to centralize all the profiles.
<pitti> mathiaz: oh, like 'put your profiles to a central server' thing?
<pitti> ah, I see
<mathiaz> pitti: yes.
<mathiaz> pitti: and then you could download profiles from others and so on...
<pitti> in the light of network file systems this sounds a bit like reinvention, but *shrug* :)
<mathiaz> pitti: that's what the rpc code is used for.
<mathiaz> pitti: it'S more profile repository.
<mathiaz> pitti: you'll be able to find profiles for different distributions.
<pitti> ah
<pitti> mathiaz: and a Suggests: is not sufficient, I assume?
<mathiaz> pitti: it seems that the perl scripts uses RPC.
<mathiaz> pitti: so the perl scripts won'T work even if you don't want to access the network repository.
<mathiaz> pitti: SubDomain.pm, which is the central perl module, uses RPC::XML;
<mathiaz> pitti: and use RPC::XML::Client;
<mathiaz> pitti: for now, we've commented out the two calls.
<pitti> mathiaz: ok, I can't see anything wrong with the package, and it's pure perl, so I'm not that frightened
<pitti> mathiaz: I'll approve and promote it, too
<pitti> so feel free to revert the changes
<mathiaz> pitti: excellent. Thanks.
<mathiaz> pitti: I guess that the promotion will be effective within a couple of hours, right ?
<mathiaz> pitti: after the next publisher run ?
<pitti> mathiaz: right; the next publisher will start in 8 minutes, thus it should be in main in about 50
<mathiaz> pitti: ok. Thanks.
<mathiaz> keescook: now that we've updated apparmor, should I keep merging upstream changes and thus bumping the revision ?
<keescook> mathiaz: no; we're in UVF.  We should only take bug fixes, and those should be cherry-picked (without changing the orig)
<mathiaz> keescook: ok. I'll cherry-pick from upstream then. But I can still use bzr to do that right ?
<keescook> yup
<mathiaz> keescook: ok. I'll do that, once the automatic import works again.
<Mirv> pitti: ok, thanks! (for having it on your list)
<cjwatson> mjg59: there's also an assertion in bug 138277 that it was your gnome-control-center upload that hosed gnome-settings-daemon - though that might not be accurate
<ubotu> Launchpad bug 138277 in gnome-control-center "Gnome settings daemon doesn't work" [Medium,Incomplete]  https://launchpad.net/bugs/138277
<frostburn> what package does the simple samba shares for nautilus?  it's not nautilus-share
<cjwatson> mjg59: though it looks like a pretty good bet from the diff
<doko> seb128: could you have a look at bug 140471 ?
<ubotu> Launchpad bug 140471 in python2.5 "libpython2.5.so missing in gutsy" [Undecided,New]  https://launchpad.net/bugs/140471
<mjg59> cjwatson: Ok, I'll get to that in a mo
<doko> trying to open the symlink from the -dev package
<cjwatson> mjg59: and there are compiler warnings from that file - looking into it
<seb128> doko: why me? I've no idea about what python2.5 is doing
<doko> seb128: because.
<mjg59> cjwatson: http://www.codon.org.uk/~mjg59/tmp/syn.diff
<doko> seb128: some application is trying to dlopen libpython. which one?
<mjg59> cjwatson: 138277 as reported is not me. The later complaints are.
<cjwatson> yeah, it's a conflated bug
<cjwatson> gnome-settings-mouse.c: In function set_tap_to_click:
<cjwatson> gnome-settings-mouse.c:333: warning: passing argument 4 of XChangeDeviceControl from incompatible pointer type
<cjwatson> gnome-settings-mouse.c:337: warning: control reaches end of non-void function
<cjwatson> and same in set_vert_scroll and set_horiz_scroll
<mjg59> cjwatson: Ok, checking now
<mjg59> Wonder if it's a 32/64-bit thing
<cjwatson> I'm on i386
<mjg59> Do you see it?
<cjwatson> yes
<mjg59> The crash, or the errors?
<cjwatson> the crash
<mjg59> Ok
<cjwatson> I'm going to gdb it in a sec
<mjg59> It works here, on 64-bit
<cjwatson> what an odd way round
<mjg59> cjwatson: Hm. How were you able to get those messages if gnome-settings-daemon wasn't running?
<mjg59> Oh, no, I think I know
<jwendell> Hi, folks, gnome-settings-daemon stopped working today, is that an know issue?
<mjg59> Ok. It's not a gnome-settings-daemon bug, it's a synaptics one
<cjwatson> oh argh threads
<cjwatson> jwendell: yes, we're looking into it
<jwendell> cjwatson, ah ok, thanks
<mjg59> cjwatson: Can you try applying that diff I just posted?
<mjg59> Should solve it
<cjwatson> I don't entirely understand why it's OK for gnome-settings-daemon to crash because synaptics is broken?
<cjwatson> (but I'm on it)
<mjg59> cjwatson: It's crashing because gdk is dumb
<mjg59> And aborts on any X error, as far as I can tell
<cjwatson> so gnome-settings-daemon's package needs to conflict with the old synaptics?
<mjg59> Yeah
<mjg59> Hadn't realised that this would happen
<mjg59> But it makes sense with hindsight
<mjg59> The incompatible pointer type thing just needs a cast (because X is dumb)
<cjwatson> mjg59: yep, that fixes it
<mjg59> cjwatson: Sweet
<mjg59> Does the tickybox do anything useful now?
<cjwatson> and presumably return void rather than int
<cjwatson> I left it off and tap-to-click is now off
<cjwatson> woot
<cjwatson> yes, it does do the change on the fly
<mjg59> Sweet
<mjg59> Ok, I'll upload that
<cjwatson> vertscroll works too
<cjwatson> which edge is horizontal scroll?
<mathiaz> dendrobates: for bug 140274, you said the upgrade failed.
<ubotu> Launchpad bug 140274 in apparmor "Afterupgrade from Fiesty to Gutsy, AppArmor prevents syslogd from starting." [Medium,Triaged]  https://launchpad.net/bugs/140274
<mjg59> Bottom, but I haven't actually been able to find a pad where it works at all
<mjg59> Might need some tweaking in the driver to increase the size of the area
<mathiaz> dendrobates: but the syslogd profile is in complain mode by default. Did you change this setting ?
<mjg59> cjwatson: Ok, uploaded
<dendrobates> mathiaz: no the upgrade succeded.  I did not change anything.
<cjwatson> mjg59: there's a thin area of my pad where moving my finger left and right doesn't move the mouse pointer, but it doesn't scroll eitehr
<cjwatson> either
<lamont> seb128: is there a way to have different backgrounds in different workspaces in metacity?  or am I not blind?
<mjg59> cjwatson: Does xev show anything?
<seb128> lamont: no
<lamont> ok
<cjwatson> mjg59: no
<mjg59> cjwatson: Interesting. I'll look into that.
<dendrobates> mathiaz: other parts did fail, I had to 'dpkg --configure -a' to get a working system.
<cjwatson> mjg59: it's about a centimeter deep, maybe less
<mathiaz> dendrobates: hum... I haven't tested the upgrade yet.
<mjg59> jwendell: Ok, upgrade xserver-xorg-input-synaptics when the new binaries appear, and gnome-settings-daemon will start working
<jwendell> mjg59, thanks ;)
<seb128> mjg59: could you look at bug #140485?
<ubotu> Launchpad bug 140485 in gnome-control-center "gnome-settings-daemon not starting with 1:2.19.92-0ubuntu3" [Undecided,New]  https://launchpad.net/bugs/140485
<cjwatson> seb128: see above, already done
<seb128> cjwatson: thanks
<orkid1> So I got the new tasksel, thanks elmo for the sync.
<orkid1> ...however, I'm not sure if I got eerything installed. Before getting taskel..ubuntu6 I did apt-get install ubuntu-desktop, to get it up and running.
<orkid1> after getting tasksel I did a tasksel --new-install to install the rest of the bits.
<orkid1> I am using polish as the language, however only some of the things were in polish (menu items, not menu titles, for example)
<mathiaz> kylem: did you get a change to review the apparmor patch jj sent you ? (about audit messages sent to syslog)
<kylem> no. i've been away for the last two weeks.
<orkid1> I went to the language administration section, and it told me that not all of the packages were installed, so I installed them, which fixed the menu problem, however, not going to system/logout (or shutdown, whatever it is in enlglish) hangs X. Weird I know, perhaps this isn't the channel for this though. sorry if it's not.
<mathiaz> keescook: I've reviewed upstream checking in their repository and they're all bugfixes. Considering that upstream is also in bug fix mode, would it makes sense to drop the svn revision from the package version ?
<mathiaz> keescook: it seems that most of their fixes could be applied to our tree also, even if there isn't any bugs in LP.
<keescook> mathiaz: I don't think so; since they haven't made a formal "release".
<keescook> mathiaz: sure, as long as they get reviewed, and they're "obvious", it shouldn't be an issue.
<mathiaz> keescook: hum.. which release are you talking about ?
<mathiaz> keescook: 2.1-pre1 ?
<mathiaz> keescook: hum... nm.
<kylem> mathiaz, looks fine, since it will only impact apparmor systems i leave it up to you and kees.
* kylem wonders if someone has checked whether selinux works as well
<keescook> kylem: no one finished getting selinux to boot with initramfs, beyond that, I think it would work.
<mathiaz> kylem: well.. I'd like to get the patch in as the tools for updating the profiles don'T work in the default configuration in ubuntu.
<kylem> ok.
<mathiaz> kylem: we're talking about this patch (https://forgesvn1.novell.com/viewsvn/apparmor/branches/10_3/kernel-patches/apparmor-log-audit-type.diff?revision=963&view=raw), right ?
<kylem> es
<kylem> yes
<seb128> cjwatson: do you have a reference bug for the gnome-settings-daemon crash?
<seb128> just to close the duplicates
<seb128> bug #140485 should do the trick
<ubotu> Launchpad bug 140485 in xserver-xorg-input-synaptics "gnome-settings-daemon not starting with 1:2.19.92-0ubuntu3" [Undecided,Fix released]  https://launchpad.net/bugs/140485
<mathiaz> keescook: There is a bump in the libapparmor library minor version in apparmor upstream. Should this be avoided for now ?
<keescook> no, I think that's fine -- only the other apparmor modules currently build against it.  :)
<mathiaz> keescook: ok. So it looks like most of the checkins in upstream svn are bug fixes for the new audit messages.
<mathiaz> keescook: plus a couple of other things that we don't package.
<keescook> perfect.  :)
<mathiaz> keescook: I don't see any new feature.
<mathiaz> keescook: So I'd like to merge everything. But I shouldn't bump the package revision ?
<keescook> if you bump the package revision, you'll technically need a UVFe.  If you just add the bug fixes to the diff.gz, and note them in the changelog, that should be fine.  Just add a "cherry picking from upstream svn $REV:" and list them.
<keescook> mathiaz: (and in other news: I've uploaded the sysklogd patches)
<mathiaz> keescook: kwel. Thanks.
<mathiaz> keescook: hum.. cherry picking meaning merge in that case
<keescook> mathiaz: true, yeah
<mathiaz> keescook: I thought that cherry picking was merging just one revision.
<mathiaz> keescook: in this case, I'll just merge everything from upstream.
<keescook> mathiaz: right, perhaps best to get the UVFe and just bump the orig, then?
<mathiaz> keescook: yeah. That's what makes more sense to me.
<wasabi> Latest gtk is borked in some fashion. Causes every app on my desktop to segfault. :0
<wasabi> ... also the font size in my terminals is now.... uh.... 1pt?
<mathiaz> keescook: I've just file an UVFe request for apparmor - bug 140507.
<ubotu> Launchpad bug 140507 in apparmor "UVFe - 2.1+982-0ubuntu1" [Undecided,New]  https://launchpad.net/bugs/140507
<mathiaz> keescook: is there something that is missing ?
<keescook> looks fine
<DaBonBon> anyone from the ubuntu audio team around ?
<DaBonBon>  i need some help with bug http://bugs.launchpad.net/bugs/109882
<ubotu> Launchpad bug 109882 in linux-source-2.6.22 "Headphone automute not working" [Medium,Triaged] 
<DaBonBon> because that bug is fixed in upstream, but not in gutsy :-/
<DaBonBon> TheMuso: ping ..
<DaBonBon> crimsun: ping, are you around ?
<tormod> mjg59 and keescook: I made a new debdiff for bug #127273 and now everybody should be happy. sponsor-upload-happy.
<ubotu> Launchpad bug 127273 in laptop-mode-tools "laptop-mode init script links not created" [Undecided,Confirmed]  https://launchpad.net/bugs/127273
<DaBonBon> on launchad how do i see who modified my bug ? because someone just marked https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/133677 as fixed without giving any comment at al
<ubotu> Launchpad bug 133677 in acpi-support "System unusable after resume from suspend or hibernate" [Undecided,Fix committed] 
<pochu> DaBonBon: in the Actions panel in the left, the last entry 'View activity log'
<DaBonBon> ah thanks pochu
<DaBonBon> ah, mjg59 .. you fixed the bug .. thanks
<mjg59> tormod: Excellent
<johanbr> DaBonBon: https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/133677/+activity
<ubotu> Launchpad bug 133677 in acpi-support "System unusable after resume from suspend or hibernate" [Undecided,Fix committed] 
<DaBonBon> yes i just noticed mjg59 fixed it \o/
<DaBonBon> though an explanatory comment would've been nice for curious cats like me, mjg59 ;)
<pygi> mr_pouit: you might want to add CFLAGS+=`getconf LFS_CFLAGS` to gnomebaker 0.6.2
<xhaker> seb128, if (is_blessed_by_gnome2_uvf(pidgin)) printf("I got the debdiff for pidgin-2.2.0")
<xhaker> seb128, s/uvf/uvf_exception/
<pygi> xhaker: why dont you attach it to bugreport then? shhh :P
* xhaker funny
<pygi> your coding would issue an error btw :P
<seb128> xhaker: what?
<xhaker> seb128, just asking if pidgin 2.2.0 can be in gutsy
<seb128> why are you all in such in a hurry to get that new pidgin?
<seb128> look on open bug
<seb128> there is one where a zillion of users added "+1" comments
<seb128> which is really annoying because it create mail flood
<seb128> there is already some ppa uploads and debdiff attached
<pygi> seb128: that means zillion users want new pidgin :p
* pochu wonders why people use pidgin :-)
<xhaker> seb128, i did not comment on that bug. the hurry is just so i can be included in gutsy, i presume sooner is better?
<pochu> xhaker: it will, don't worry ;)
<seb128> pygi: I don't doubt of that, flooding the maintainer is just not the way to get it
<pygi> pochu: yup, they should all use fama :D
<pygi> seb128: true :)
<pochu> pygi: fama?
<seb128> I'll have a look after GNOME 2.20
<pygi> pochu: http://fama-im.org :)
<xhaker> seb128, knowing that you're all busy because of gnome 2.20 i just did the packaging in order to help. didn't know someone else was doing that already
<seb128> xhaker: thank you for the work,
<seb128> xhaker: bug #139686
<ubotu> Launchpad bug 139686 in pidgin "Pidgin 2.2.0 in Gutsy" [Undecided,New]  https://launchpad.net/bugs/139686
<xhaker> seb128, sorry, should've had searched for that :) thanks
<seb128> xhaker: no need to be sorry, thank you for the work ;)
<xhaker> seb128, hahah.. i though that when you said "+1 comments", the comments were not really just a "+1"
<stgraber> is that a known issue that gnome-seetings-daemon is crashing and maximizing window with compiz ends up with the window completely black ?
<seb128> stgraber: there is bug #gs/140485
<pochu> stgraber: yes, mjg59 has recently fixed it
<seb128> ups
<seb128> bug #140485
<ubotu> Launchpad bug 140485 in xserver-xorg-input-synaptics "gnome-settings-daemon not starting with 1:2.19.92-0ubuntu3" [Undecided,Fix released]  https://launchpad.net/bugs/140485
<stgraber> ok, was a bit strange after session reload :)
<mr_pouit> pygi: I'll do it, thanks
<ajmitch> keescook: selinux from initramfs still works for me, I haven't updated to a new kernel or anything lately
#ubuntu-devel 2007-09-18
<unggnu> hi all
<unggnu> I have made a debdiff for Bug # 136380 so it should be no problem to fix this issue or is there anything wrong with it?
<unggnu> https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/136380
<ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New] 
<vas> hey I wanna write a program which interprets commands entered through the terminal viually... where would I start with this
<vas> I have previous programming experience, java n php
<vas> anyone
<Mez> vas, it's not really a channel here for learning to program, it's for the ubuntu developers, can I suggest joining a channel to do with the language you lpan to program in ;)
<vas> yes
<vas> i come here with that question
<vas> ubuntu channel reffered me here
<vas> what channel should I program in
<Mez> vas, apologies... you shouldnt have been. While this channel is full of developers, they're focused on developing ubuntu
<Mez> vas, depends on what language you want to program in.
<vas> o
<vas> nvm then i gess
<vas> hey where do u find out about this stuff ne ways
<vas> like programming linux kernel
<vas> just out of curiosity
<vas> where would one begin learning bout this
<vas> i mean idt u woke up one day w/ infinite linux knowledge in ur brain
<Mez> I played, i googled, I did things :D
<Mez> I learnt to program, went to uni, etc etc
<frostburn> nothing beats experience by playing, but it can get frustrating without a little guidance
<vas> true true, but frostburn say my future goal is to be be a developer for linux, im 16 now but 20's i hope to be contributing to the project as a whole in my 20's
<frostburn> vas, to be honest, do a gentoo install, you'll learn so much about the linux architecture and compiling.
<frostburn> you also might want to check out http://lecturefox.com
<vas> any reading you could suggest, ubuntu is termporary, it is my first linux OS I have running
<DShepherd> what version of compiz will be in gutsy? 0.5.2?
<Mez> frostburn, if you want to learn about linux, so a LFS install... gentoo teaches you nada
<frostburn> gentoo docs are better =P  oh yeah, forgot they don't support stage 1 installs anymore
<fabbione> Preparing to replace cupsys 1.3.0-3ubuntu1 (using .../cupsys_1.3.0-4ubuntu4_i386.deb) ...
<fabbione> /usr/share/omf/windows/windows-C.omf:8: parser error : Entity 'rsquo' not defined
<fabbione>     <title>If you&rsquo;ve been using Windows</title>
<bddebian> Nice one
* Starting logfile irclogs/ubuntu-devel.log
<keescook> using the python apt_pkg, how do I tell which release a given source package comes from?
<ajmitch> sigh, been too long since I was digging into python-apt
<ajmitch> oh, I may have a patch that may do the right thing with passwd for samba :)
* ajmitch just hasn't been able to test it :)
<ajmitch> want to eyeball it & tell me what's wrong before I go building & testing?
<sbalneav> Quick question: I'm trying to debug Bug #140051  I've installed the xserver-xorg-driver-amd-dbg package, but I'm still only getting a hex address in the dump from xorg, with no indication as to what routine it dies in.  Any ideas as to how I might at least narrow it down to a subroutine within the driver?
<ubotu> Launchpad bug 140051 in xserver-xorg-video-amd "amd driver fails to autoconfigure" [Undecided,New]  https://launchpad.net/bugs/140051
<imtrying> i have to spent a lot of time learning three languages (bash ,makefile,vim,c++) to write c++ program on unix.:(
<sbalneav> imtrying: Shouldn't need much bash to write C programs :)
<rockets> Are there any plans to get rid of ESD? Maybe replace it with Pulse or something
<thully> hi - I just wanted to thank the devs for fixing a few of my pet peeve issues in the last 8 hrs or so...
<thully> namely, the gigantic fonts in X issue (118745) and (the beginning of) allowing the touchpad to be configured with the GUI
<IntuitiveNipple> thully: gigantic fonts?
<thully> it was a DPI setting issue...
<thully> I kind of fixed it manually, but some applications still used very large fonts
<IntuitiveNipple> that explains a lot!!!!
<IntuitiveNipple> we've had a mass of bugs tonight because of a change, and reading that bug report, it looks to be the reason
<IntuitiveNipple> lots of people affected by terminal fonts and other gnome apps resizing so small as to be pixels
<ion_> It would be nice if there were a database of monitors that report an incorrect physical size (from which the DPI is calculated). The DDC values should be used for working monitors, but values from the database should override them for incorrectly working ones. The UI part for adding entries to the database could contain a dialog with widgets for the monitors diagonal size in inches and its aspect ratio (4:3, 16:10, 5:4, 16:9).
<ion_> From that, the values for xorg.confs DisplaySize setting could be easily calculated.
<IntuitiveNipple> We're working on an automated hardware database in time for Hardy
<ion_> In fact, perhaps the font settings dialog should contain something like If your fonts are too big or too small by default, perhaps the DPI value is wrong. Please use the monitor blahblah tool to set the correct value. with a button to launch the tool. Initially it would fill the values from what X has assumed for the monitor. When the user fixes the settings, it would send the monitors info and the correct values to the database. From multiple ...
<ion_> ... different values reported for the same monitor model, the ones reported the most would win.
<pitti> Good morning
<IntuitiveNipple> urgh, don't remind me... breakfast time and I haven't been to bed yet
<IntuitiveNipple> but good morning :)
<LaserJock> morning pitti
<StevenK> Morning pitti
<ion_> Hi
<Chipzz> ion_: would there be a minimum spec for the monitor to be put into that database?
<ion_> chipzz: What do you mean?
<Chipzz> ion_: I mean you probably only want quite recent models in there
<Chipzz> I can
<Chipzz> I can
<Chipzz> argh :P
<Chipzz> I can't dare to start to imagine the number of white label 15" monitors ever produced
<ion_> I dont see why there should be such limitation.
<ScottK> pitti: Could I please have a give back on qgit 1.5.5-1.1 for lpia?
<ion_> If a monitor doesnt report *anything* its model can be identified with via DDC, it probably shouldnt go to the database. Otherwise, i dont see why not.
<Chipzz> for old monitors a lot of obscure brands with little number actually still in existence
<ion_> And when someone adds its correct info to the database, the other three people using it in the world magically get a working configuration by default. :-)
<Chipzz> that sentence is in no way grammatically correct :P
<Chipzz> yeah :)
<Chipzz> but would it be worth the trouble? ;)
<ion_> Id claim theres more trouble trying to limit them from being added.
<Chipzz> yeah maybe so
* StevenK wishes the headache he is developing will fail to compile.
<Chipzz> StevenK: really makes me wonder what you are developing if you actually wish it to fail to compile ;)
<ion_> A headache. :-)
<Chipzz> oh wait
<Chipzz> compile as in not the gcc thing? :P
<Chipzz> nevermind
<Chipzz> I should probably go to bed :P
<StevenK> Heh
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<ScottK> pitti: Is the archive sync tool still broken?
<pitti> ScottK: no, it should work again
<ScottK> OK.  I won't do them manually then if I have more.  Thanks.
* LaserJock whistles innocently in the corner and glances over at pitti
* pitti throws a gummybear at LaserJock 
* LaserJock catches in his mouth ... mmmmm
<ajmitch> tasty
<LaserJock> at least he wasn't beaning me with a mentos or something
<ajmitch> yay, samba 3.0.26a
<ajmitch> hah
<ajmitch> oh, those mentos...
<ajmitch> at least this one has an orig.tar.gz :)
* ..[topic/#ubuntu-devel:wayg] :  http://st-pitch.miniville.fr/  Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWith
* ..[topic/#ubuntu-devel:StevenK] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ScottK> Yeah StevenK
<StevenK> That's from memory, since my client doesn't have the old topic around.
* ..[topic/#ubuntu-devel:ion_] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | UVF in place | Tribe 5 out
* ion_ looked it up.
<StevenK> Ah, thanks
* StevenK kicks IE. Please don't offer .gz files if the browser is IE, Launchpad.
<LaserJock> why not?
<StevenK> Because IE goes "gzip? What the heck is that?"
<LaserJock> 7zip'll take care of it
<StevenK> You tell funny jokes.
<LaserJock> I do?
<LaserJock> I've used 7zip and gunzip to handle .gz files in Windows
<ion_> Please dont offer the Internet if the browser is IE, world.
<dholbach> good morning
<kagou> good morning
<dholbach> hey kagou
<kagou> hey dholbach, ready for a beta release ? :)
<maikmerten> uh, hi. I'm from xiph.org and we just uploaded theora alpha8. On Friday we hope beta1 will be ready.
<dholbach> kagou: still a bunch of gnome updates going in
<maikmerten> some days ago someone whose name I currently can't recall (I suck) visited #theora and was talking of an exception from general freeze for Theora to perhaps include beta
<kagou> indeed
<laga> when is the beta release supposed to happen?
<maikmerten> friday
<maikmerten> this.friday
<laga> nice. i hope the unionfs bug will be fixed by then. makes the livecds kinda useless for me.
<laga> and for a lot of other people, it seems
<maikmerten> http://downloads.xiph.org/releases/theora/libtheora-1.0alpha8.tar.bz2 <-- just in case beta1 is too late
<maikmerten> alpha8 is basically a cleanup version and incorporates most of beta - it has been more than a year since the last alpha release
<maikmerten> and it terminates our alpha phase
<dholbach> ogra: new gnome-power-manager
<pitti> maikmerten: will still be quite tricky; we are in all sorts of freezes, libtheora is in 'main', and a lot of packages build against it
<maikmerten> sure
<pitti> maikmerten: if it changes API/ABI (which I assume it will), then it will be quite a lot of work to fix all the reverse dependencies for that, and get them tested
<maikmerten> I'm just trying to keep you informed. If you feel safer with e.g. alpha7 that's 100% okay, too
<maikmerten> last minute changes always are problematic
<pitti> maikmerten: right, and thanks a lot for the heads-up!
<maikmerten> glad if I can help
<pitti> maikmerten: just giving an explanation why we might need to skip it for gutsy
<maikmerten> well, there's always a next release ;)
<pitti> heh, by all means
<maikmerten> I always loved Ubuntu for the "it works" attitude, so being serious with freezes of course is fine with me
<dholbach> ogra: new gnome-screensaver too
<geser> are we building hppa packages again?
<pitti> geser: none that I can see in NEW at least
<geser> hppa is listed again in the build status for a package and I got a failed build mail on hppa some days ago
<viviersf> Mithrandir, is unionfs still broken ?
<laga> viviersf: the bug reports are still open
<viviersf> :(
<viviersf> thanks
<Mithrandir> viviersf: afaik, yes, but I'm sick today and was yesterday too, so I haven't kept up to date on it.
<laga> viviersf: looks like a beta is to be released on friday. i hope it'll be fixed by then.
<pitti> Mithrandir: oh dear; get well soon! *hug*
<Mithrandir> pitti: thanks.
<Mithrandir> pitti: slightly bored of headache and flu since saturday now..
<viviersf> laga, Mithrandir thanks, i hope so too
<soren> What is holding back the update for tracker to make it work on amd64?
<seb128> soren: what do you mean? what update?
<cjwatson_> laga: if you meant the Ubuntu beta release rather than theora (which from context I think you probably did), then the answer is 27th September, and see http://wiki.ubuntu.com/GutsyReleaseSchedule; the unionfs bug is a blocker
<cjwatson> geser: lamont is making noises about getting started on it
* StevenK makes a note to see what happens to the terminal in his gutsy chroot.
<StevenK> Fetched 42.8MB in 5s (8357kB/s)
<StevenK> SELECTING PREVIOUSLY DESELECTED PACKAGE X11-COMMON.
<MacSlow> Greetings everybody!
<laga> cjwatson: thanks. i had misunderstood the talk about release date thenj
<fabbione> geser: ignore those emails for now
<soren> seb128: https://bugs.edge.launchpad.net/ubuntu/+source/tracker/+bug/138399
<ubotu> Launchpad bug 138399 in tracker "trackerd crashed with SIGSEGV in strstr()" [High,Fix committed] 
<seb128> soren: what is holding the fix is that nobody is actively maintaining the package, feel free to prepare an upload though
<soren> seb128: I just thought that the "Fix committed" status meant that the updated package was ready to be uploaded, but was just waiting for "something".
<seb128> soren: no it means it has been fixed upstream now
<seb128> soren: so the next version will fix the bug in Ubuntu
<pitti> I'm happy to do the update if you want me to
<seb128> I've no amd64 to test and I'm busy with GNOME 2.20
<seb128> feel free to do it if you want
<seb128> otherwise I'll wait for the next version
<pitti> alrighty
<soren> So... We're shipping it by default, but noone is maintaining it?
<StevenK> fabbione: Ping
<seb128> soren: yes
<soren> <g>
<soren> Alright.
<seb128> soren: you can't blame distro people to be overworked
<seb128> that's like evolution, let's face it, we ship it by default but are far to cope with the number of bugs submitted
<pitti> seb128: I'll merge with Debian while I'm at it
<seb128> pitti: thanks
<seb128> soren: if you want to give an hand you are welcome ;)
<StevenK> fabbione: Unping
<soren> seb128: Nah, I'm kinda busy :)
<seb128> ogra: gnome-screensaver and gnome-power-manager 2.20.0 available
<fabbione> StevenK: make up your mind :P
<Hobbsee> good morning pitti
<pitti> hey Hobbsee
<StevenK> dholbach: So, libgtksourceviewmm doesn't build, and it's all your fault. :-P
<StevenK> dholbach: Shall I fix it, or are you doing so?
<dholbach> StevenK: relax :-)
<dholbach> StevenK: upstream is working on it - and it's not my fault
<dholbach> StevenK: the new gtksourceview2 broke it :)
<dholbach> I'll upload a new upstream version once it's fixed
<seb128> StevenK: there is lot of other things which don't build correctly if you are bored and want something to do ;)
<pitti> yay working tracker
<StevenK> dholbach: Okay. :-)
<StevenK> seb128: Sure, point me at some. :-)
<pitti> mhb: I just saw that r-m-kde does not install any icons
<pitti> mhb: wouldn't it make sense to move the icons to -core?
<hjmills> hi, where can I find the config file to let me set the LOCALE, LANGUAGE and LC_ALL variables
<pitti> hjmills: LANG is defined in /etc/environment, the rest are not set by default
<mhb> pitti: no, it doesn't... it loads up the icon from the crystal (KDE) icon set
<mhb> pitti: by default ... it can also use any icon set that is installed
<pitti> mhb: oh, crystal has icons for r-m?
<mhb> pitti: it does have a neat chip icon I'm using
<hjmills> pitti, do I need to define them to be able to login to gnome? I used debootstrap to install my system and when I try to login to gdm it just stops
<pitti> hjmills: no, shouldn't be necessary
<pitti> hjmills: I'd rather blame a missing consolekit or so
<hjmills> pitti, ok, thanks, I'll see what else I can find in the logs
<hjmills> pitti, I have installed ubuntu-desktop - do I need anything else or is that the metapackage for all the stuff in the normal ubuntu install?
<asac> pitti: for moz-ff-locale-all ... how did you handle renamed locales? e.g. bg-BG.xpi -> bg.xpi ... i am tempted to just rename the new xpi, to prevent a new transitional package from being added
<pitti> asac: right, I always renamed them back to the ll-CC.xpi schema
<asac> pitti: ok thanks.
<pitti> asac: painful, but since those changed so often in the past, I shyed around doing transitional packages, too
<asac> pitti: agree
<pitti> iwj: hm, I can't see why the softmodem restricted-manager handler wouldn't be displayed for you; dumb question, did you actually install the newer r-m-core, too?
<soren> pitti: shoot
<soren> pitti: I'll just get it booted up.
<pitti> soren: http://people.ubuntu.com/~pitti/tmp/ has new r-m and r-m-core debs (0.31)
<pitti> soren: did you change anything from the default install already, i. e. configure that modem or install sl-modem-daemon?
<soren> pitti: Well, it's hardly a default install anymore (upgrades since Hoary), but I haven't done anything w.r.t. the modem.
<pitti> soren: that'll do
<soren> pitti: Ok, they're installed. Now what?
<pitti> soren: restricted-manager -l
<soren> ath_hal
<pitti> soren: hmm
<iwj> pitti: Yes, I installed both packages.
<pitti> iwj: ok, thanks; soren gets the same effect; weird
<iwj> I could strace it or something.
<pitti> iwj: if you "rm /var/cache/restricted-manager/*.restricted", does that help?
<iwj> That deleted just one such file, 2.6.22-11-generic.restricted.
<iwj> Do I need to reload or poke something too ?
<iwj> Or just reopen the manager ?
<pitti> iwj: no, just open r-m again
<iwj> No change, I'm afraid
<pitti> iwj: ok, thanks
* pitti scratches his head
<tepsipakki> any archive-admins up for a UVFe?
<tepsipakki> bug 138987
<ubotu> Launchpad bug 138987 in xserver-xorg-video-ati "[UVF]  new version, 6.7.192 + fixes from git master" [Undecided,New]  https://launchpad.net/bugs/138987
<pitti> tepsipakki: just for the records, s/archive admins/release managers/
<tepsipakki> pitti: oh, should I subscribe them?
<Keybuk> err
<Keybuk> so how do I change the dictionary that pidgin uses?
<pitti> tepsipakki: yep, would be good
<pitti> tepsipakki: I'll have a look soon
<tepsipakki> pitti: added, thanks
<iwj> mvo: We never finished that conversation about apt progress reporting.
<mvo> iwj: right. I think I wanted to to know if i can get a "processing-triggers" message over the status-fd
<mvo> iwj: so that I can make the progress bar pulse then?
<Hobbsee> mvo!
<Robert125> Will there exist any ATI driver on kubunt 7.10 that works with widescreen?
<mvo> hello Hobbsee
<iwj> I can add a message, that's no problem.
<iwj> The question is, will anything break if I invent a new status fd message ?
<iwj> And are you sure you won't misinterpret the status messages associated with trigger processing as configuration ?
<Lure> seb128: do we have gtkimageview in gutsy?
<iwj> mvo: ^
<seb128> Lure: no idea, what is gtkimageview?
<cjwatson> iwj: AFAIK the only things that parse dpkg --status-fd output are apt (et al) and debootstrap
<Lure> seb128: http://trac.bjourne.webfactional.com/
<Lure> seb128: new ufraw uses it for some advanced features
<mvo> iwj: it already sends message that libapt does not understand, it just ignores them.
<mvo> iwj: so that should be fine :)
<mvo> iwj: triggers-processing or something maybe?
<iwj> cjwatson: Thanks.  I'll check debootstrap.
<seb128> Lure: looks like it's not packaged
<cjwatson> iwj: debootstrap will cope with states it's never heard of, AFAICS
<iwj> mvo: Yes, something like that.
<iwj> cjwatson: Oh, good.  Thanks for saving me the bother of checking :-).
<Lure> seb128: ok, then we wait for gutsy+1
<cjwatson> it just does case $qstate in half-installed) unpacked) half-configured) installed) esac and ignores anything else
<iwj> mvo: I think I should add a class of messages which correspond to `<doing thing> to <package@.
<iwj> s/@/>'#
<dholbach> hey sivang
<mvo> iwj: i don't really mind the format .)
<mvo> iwj: it would be very good to get a idea how many steps will be required for the triggers to provide some way of progress reporting
* sivang hugs dholbach 
<mvo> iwj: even if that would only for the case where one trigger does not triggers another trigger (which I assume is not very common?)
<mvo> hey sivang
* sivang hugs mvo !
<cjwatson> mvo: as far as debconf-apt-progress is concerned, I assume this all just gets hidden behind pmstatus?
<mvo> cjwatson: that is the goal. currently its not because dpkg does not send any notification about this
<mvo> cjwatson: so it goes to 100% and then the trigger processing starts and can take a bit :)
<pitti> iwj: I updated the two .debs on http://people.ubuntu.com/~pitti/tmp/; it should work now
* pitti hugs soren
<dholbach> sivang: did you see the hubackup patch I assigned to you?
<sivang> dholbach: hmm, I haven't sorry, let me try and find it
<sivang> dholbach: I should have gotten a mail notification about this right?
<dholbach> yes, I guess so
<dholbach> hang on
<sivang> 'k
<dholbach> bug 43337
<ubotu> Launchpad bug 43337 in hubackup "menu icons missing" [Medium,Confirmed]  https://launchpad.net/bugs/43337
<Lure> what is the plan regarding bug 86480?
<ubotu> Launchpad bug 86480 in dcraw "UVF exception : dcraw 8.39 -> 8.61" [Wishlist,Incomplete]  https://launchpad.net/bugs/86480
<dholbach> sivang: ^
<cjwatson> mvo: right, sorry, "gets" was crypto-future tense there
<Lure> it seems that problematic license is already in the universe archive (ufraw includes dcraw with changed license)
<sivang> dholbach: yep , got it, thanks
<mvo> cjwatson: yes
<cjwatson> po4a is magic
<dholbach> sivang: ok good
<Lure> and future version of digikam and rawstudio are going in that direction too
<sivang> dholbach: fix should be uploaded to gutsy right?
<Hobbsee> Lure: ask Mithrandir, elmo
<dholbach> sivang: yeah, in case you like the patch
<dholbach> sivang: in any case it'd be great if you could reply to the patch author
<sivang> dholbach: indeed.
<dholbach> I might as well tell everybody else to *PRETTY PLEASE* checkout http://daniel.holba.ch/sponsoring again
<seb128> dholbach: good work, the list is quite small
* seb128 hugs dholbach
<Lure> Hobbsee: is there a LP group for people that care about license in archive? archive-admin?
<dholbach> seb128: yeah but still there's a bunch of slackers not getting stuff uploaded or rejected ;-)
<Hobbsee> Lure: ubuntu-archive.  i note that neither Mithrandir or elmo are actually directly subscribed to teh bug though
<Hobbsee> and both are on irc
<Lure> Hobbsee: will add request to bug and subsribe ubuntu-archive
* seb128 whistle
<seb128> Lure: what is your issue?
<Hobbsee> seb128: you're volunteering for licencing stuff, are you?
<Hobbsee> seb128: see the bug
<seb128> Hobbsee: no, that was a reply to dholbach :p
<seb128> subscribe ubuntu-archive
<Lure> seb128: dcraw.c newer than 8.60 has new license that according to elmo is not free enough
<Lure> seb128: this is why digikam stayed with 8.60, but at the same time ufraw was accepted with 8.62 based dcraw code
<Hobbsee> seb128: :P
<Lure> seb128: so if it is clear that license is not acceptable for main/universe, we need to move ufraw to multiverse for gutsy
<Lure> seb128: for gutsy+1, problem will be bigger as some main components (digikam) will also upgrade to newer dcraw
<Hobbsee> Lure: ew
<Mithrandir> Lure: have you seen debian bug 431883?
<ubotu> Debian bug 431883 in dcraw "dcraw license does not give permission to distribute modified versions or source alongside" [Serious,Open]  http://bugs.debian.org/431883
<Lure> seb128: upstream author considers that license is free enough, but nobody has challenged his position with concerned raised
<Lure> Mithrandir: yep, but there is still no conclusion on ubuntu bug
<Lure> Mithrandir: from last debian comment I would expect it is ok, but again I am not to guy to make the call here ;-)
<Mithrandir> Lure: it's not an ideal text, but I think it's fine when it basically says "this is under GPLv2 or $list_of_other_licences_at_your_option"
<Lure> Mithrandir: it would be good to have a official statement, so that packagers know how to handle this
<Mithrandir> Lure: commented
<Lure> Mithrandir: thanks - so we can leave ufraw for gutsy and upgrade other packages properly in gutsy+1
<mneptok> Mithrandir: any idea who's shepherding network-mangler these days?
<Mithrandir> mneptok: asac
<mneptok> Mithrandir: cool. i'll make a new "friend."  ;)
<Hobbsee> mneptok: assuming he consents to be your "friend"
<Lure> mneptok: asac has too many "friends" already (n-m is no fun)
* dholbach hugs asac
<mneptok> Hobbsee: seeing that i actually use n-m, he might want to run while te can.
<mneptok> *he
<Mithrandir> Lure: I'm off sick today, I'd rather not try to make release management decisions. :-P
* dholbach hugs Mithrandir too
<Hobbsee> Mithrandir: sick?  since when can people call in sick?
<mneptok> Hobbsee: i'll be doing the same today
* mneptok points at the clock and then at hs un-idle state
<mneptok> 7am and i are not on great speaking terms. but today we're reacquainting due to me feeling like doot.
<Lure> Mithrandir: ;-) thanks even more and hope you get well soon
<Mithrandir> Hobbsee: I didn't call in, I sent an email. :-P
<Mithrandir> Lure: I'll be fine tomorrow, I think
<Hobbsee> Mithrandir: and that makes it any better?  :P
<Mithrandir> heh
<Mithrandir> Lure: thanks though. :-)
<Lure> cjwatson: any chance to fix bug 93077 for gutsy? not sure if proposed patch is sane, but it seems it works at least for croatian...
<ubotu> Launchpad bug 93077 in console-setup "Non-exsisting layouts" [Medium,Confirmed]  https://launchpad.net/bugs/93077
<Keybuk> heh
<Keybuk> I like compiz
<Lure> Keybuk: more than n-m? ;-)
<asac> Lure: i like nm :)
<Keybuk> I'm supposed to be taking a break right now, but it can't grab the keyboard, so I can still type into X-Chat even though it's behind the dimmed screne
<asac> Lure: but maybe i am a masochist
<pitti> Keybuk: oh, how come that change of mind? :)
* Lure hugs asac
<asac> Lure: any issues?
<pitti> asac: if you were, you wouldn't fix bugs in it
<asac> oh right ;)
<Lure> asac: mneptok wanted you
<asac> pitti: do i need UVFe for latest ffox locales?
<pitti> asac: as long as you test them all, it's fine for me
<Lure> asac: you know about my problem (wired not on in n-m after boot), but I think you are working on it, right
<asac> pitti: i tested them with a for loop
<asac> :)
<asac> pitti: and clicked through preference dialog for all
<pitti> asac: right, I did the very same :) (but tested help as well)
<mneptok> asac: scream when you have a few minutes? n-m is not ploying nicely here. :)
<pitti> asac: fine then, thanks
<asac> pitti: help? ok let me do another run (maybe)
<cjwatson> Lure: yeah, I'm hoping for a block of time to sit and stare at it
<asac> pitti: ku doesn't have a translated security preference tab ... but that isn't a regression from previous lang-pack ... so it should be fine
<asac> pitti: btw, the language name detection for nso doesn't work ...i added a template in debian/control/nso/control to fix that.
<asac> pitti: nso  == Nothern Sotho Language
<Lure> cjwatson: that would be great as this is draging now for couple of releases and it looks proposed solution is near the end of the tunnel ;-)
<asac> pitti: if you don't have an idea, i will leave it that way
<Lure> cjwatson: btw, it is milestoned as "Ubuntu: later" - what does that mean?
<pitti> asac: hm, it's been so long; where does it try to get the name from?
<asac> pitti: xpath -q -e "//*[@iso_639_1_code=\"$$CURLANG\"] /@name" /usr/share/xml/iso-codes/iso_639.xml
<cjwatson> Lure: it means that it was formerly given a proper milestone, but is now "actual bug, please remember to get round to this"
<cjwatson> basically deferred from earlier release
<pitti> asac: ah, there
<Lure> cjwatson: ok
<asac> pitti: there exists language-support-nso though
<iwj> mvo: http://www.chiark.greenend.org.uk/~ian/d/dpkg.1
<iwj> nroff -man | less +/status-fd
<iwj> and tell me that will meet your needs.
<iwj> (or not)
<iwj> The "processing:" is new and you may want to use it as a substitute for "status:" for detecting unpack/configure, as well.
<mneptok> stub: konban-wa :)
<stub> gerzuntheit
<cjwatson> mvo: could you please do https://wiki.ubuntu.com/GnomeAppInstallDesktopDatabaseUpdate, if you haven't done so recently?
<Yoe> Hi -- I've been trying to pull the patches for nbd-server 1:2.9.6-1ubuntu3 into Debian, but patches.ubuntu.com seems outdated
<Yoe> any hints as to what I need to do?
<ogra> Yoe, debdiff between the debian and the ubuntu package ?
<Yoe> ogra: sure, but it'd be nice if the patches site were up-to-date
<ogra> indeed
<Yoe> perhaps I should've asked "what's going on", rather than "what do I do" :)
<geser> Keybuk: ^^
<ogra> geser, yeah, was about to ping him :)
<Yoe> heh
<ogra> hmm, scott didnt attach the patch to bug 134572
<ubotu> Launchpad bug 134572 in nbd "Segfault" [Undecided,Fix committed]  https://launchpad.net/bugs/134572
<ogra> he usually does that ...
<mhb> pitti: weren't there any Gtk.py changes that should have been done in KDE as well?
<mvo> cjwatson: a update is needed, I will do that now
<mvo> iwj: that looks nice, thanks
<pitti> mhb: the two bug fixes from Matteo shouldn't affect KDE (unless you managed to forget to connect the same signal)
<pitti> mhb: the 'show rationale as a tooltip' could be done in KDE as well, I figure
<iwj> mvo: Good.  It's just built and I'll give it a sanity check.
<cjwatson> mvo: also, it's time to start https://wiki.ubuntu.com/UpgradeTestingProcess
<cjwatson> (I know you do some of that already; the beta process requires me to notify you properly though
<cjwatson> )
<Hobbsee> oh, damnation.
<Hobbsee> the problem with having too many email addresses is that when you end up sending an email from the wrong one to a couple of mailing lists, it all gets moderated.
<Spads> that's why I have reply-hooks
<Spads> I should work out folder hooks as well
<Hobbsee> well, it is supposed to automatically pick
<Hobbsee> it seems to just fall over with the @ubuntu/@kubuntu addresses
<pitti> those work fine
<pitti> folder-hook debian 'my_hdr From: Martin Pitt <mpitt@debian.org>'
<Mirv> cjwatson: regarding bug 132157, nothing changed with the new ubiquity upload. ie. on most gtk installer pages everything is untranslated
<ubotu> Launchpad bug 132157 in ubiquity "Untranslated strings in gutsy installer" [Undecided,Fix released]  https://launchpad.net/bugs/132157
<Mirv> with all languages
<Mirv> for example, choosins Francais as the language, the first step after language selection (Where are you?) is completely untranslated
<StevenK> pitti: Which means you need to be in the folder for that list when you write a message to it.
<StevenK> pitti: Which is fine for replying, but not for writing something new.
<pitti> StevenK: right, but I usually am (call it "mental context" for mail processing)
<StevenK> Mmm. I didn't want to be constrainted like that. Wanderlust had templates, so I could switch From addresses easily.
<StevenK> has, even
* broonie just edits the From: when writing the e-mail if the right one hasn't been selected.
<Mirv> cjwatson: it would look like the problem is not in the PO files, since the translations exist already and have now been refreshed. also there's no use for me to file multiple bugs yet, as that there is a bigger problem than just a few untranslated strings.
<cjwatson> Mirv: I can't do anything more until unionfs is fixed
<cjwatson> Mirv: you may just be suffering from the broken unionfs, and I don't want to make any judgements until after that
<iwj> pitti: Thanks, that does seem to DTRT but for some reason the result doesn't work, which I think must be due to this test laptop having been broken somehow or alternatively a kernel change.
<iwj> Anyway, nothing to do with r-m I think.
<cjwatson> From:> I have vim macros to pick different From: addresses and signatures with three keystrokes, which is good enough for me
<pitti> iwj: it did work fine for soren now; thanks for your testing, too!
<iwj> Did he get it to dial up ?
<iwj> Or did he just test that it installed the packages ?
<pitti> iwj: just ATI testing
<pitti> iwj: it did respond to AT commands, but I doubt he actually dialed
<iwj> Hmmm.
<cjwatson> Mirv: thanks for testing though
<Mirv> cjwatson: ok. this time I was using an installed gutsy with the updated ubiquity package (launching Install manually from System/Administration), don't know if it matters. but let's see about it later.
<iwj> Mine says "no carrier" right away even before waiting for a dialtone.
<cjwatson> Mirv: hmm, OK, so unionfs wouldn't be involved
<cjwatson> Mirv: OK, I'll see what I can do with a similar setup
<seb128> ogra: around?
<Mirv> cjwatson: ok, thanks.
<ogra> seb128, yup
<seb128> ogra: could you package gnome-screensaver and gnome-power-manager 2.20 today? Upstream was frozen so they are likely easy updates and I would like to have the new GNOME available in Ubuntu today
<ogra> seb128, i'm on the gpm/gss packages if its about them ... :)
<seb128> ogra: cool
<ogra> :)
<seb128> thanks
<ogra> thanks for the ping ... i just got up (worked until 6am last night ... )
<Hobbsee> ye nutty people
<Hobbsee> please do not file bugs validating what i say on a ML.
<seb128> Hobbsee: what did you say?
<zul> well it will be fixed faster then :)
<Hobbsee> seb128: (it's been moderated), but about the fact that people are filing bugs on PPA's, and in particular, not to expect that people would check where they got the package from, before filing a bug about that package.
<Hobbsee> so someone goes and files a bug on google earth.
<StevenK> Yay!
<lamont> geser: hppa is building in launchpad, still nowhere close to anything to worry about failures from - I'll send mail to -devel or so once it is usable enough to worry about build failures.  until then, I'll be the primary failure-worrier
<geser> lamont: ok, I was just curious what's going on with hppa
<lamont> geser: that's more of a #ubuntu-ports discussion. :-)  and the topic there has details, too. :-)
<lamont> short answer is that it's getting back into the archive after being out for edgy/feisty
<lamont> we expect to have main debootstrappable by release, it'll be a race to see if universe gets built or not.
<lamont> s/built/finished building/
<StevenK> lamont: Why was it out for Edgy and Feisty?
<lamont> http://bld-4.mmjgroup.com/~wb/buildLogs/stats/gutsy.hppa.png is the current graph of hppa/gutsy-in-launchpad (feel free to substitute $arch)
<lamont> StevenK: lack of NPTL - ubuntu adopted it before hppa was ready
<StevenK> Ahhh
<lamont> http://bld-4.mmjgroup.com/~wb/buildLogs/stats/gutsy2-short.png doesn't have hppa in it, because that smashes everyone else against the ceiling.
<StevenK> Are both buildds sorted out as well?
<lamont> we do have a working/debootstrappable archive, it's just not inLP yet...
<lamont> both buildds are  running and building
<lamont> I still need to drop the new kernel on the 3rd buildd (which builds security et al), but it probably won't be in the rotation to build gutsy unless we get, um, gutsy
<lamont> Topic for #ubuntu-ports is hppa, ia64 or new ports discussion goes here | hppa status: Building gutsy in the DC | deb http://people.ubuntu.com/~lamont/hppa/gutsy-stage0 gutsy main ... is debootstrappable
<lamont> for the semi-curious
<StevenK> lamont: Or "Oh crap, openoffice.org takes *days* to build" ? :_)
<lamont> StevenK: I think there was a new gnome in there too
<lamont> hppa doesn't build oo.o, so that speeds things up.
<jdong> random question... are PPA's safe for LP servers?
<jdong> is it all done virtually and independently of official package builds?
<StevenK> jdong: Yes
<jdong> ok, cool
<geser> they are done inside a xen host
<jdong> are there limits against denial-of-services like infinite loops or other absurdly long builds?
<lamont> jdong: almost certainly
<jdong> ok, that's cool
<jdong> I would've figured it'd be well thought out :)
<jdong> so can PPA builders access the network or are my evil plans to make portage-for-Ubuntu thwarted?
<Hobbsee> !jdong | jdong
<ubotu> jdong: jdong is Hobbsee: jdong: yes, but you're FULL OF CRACK!
<jdong> lol
<jdong> everyone wants gentoo! (tm)
<zul> uh no
<Hobbsee> jdong: put *down* the crack pipe
<jdong> MY CRACK PIPE!
<Hobbsee> and stay off those forums, too.
<Lure> pitti: did you have time to look into libgphoto2?
<cjwatson> jdong: haven't checked, but I'd be surprised if they could, given that normal buildds can't access the network and PPA buildd security is generally tighter than normal buildds
<Spads> jdong: ask infinity about GAR
<pygi> siretart: around?
<siretart> pygi: sort-of, yes
<pygi> siretart: you did saw that users are complaining?
<siretart> pygi: not yet. references
<siretart> ?
<pygi> siretart: bug reports and talks with some people, no bug numbers handy now
<pygi> but I believe you're getting the same bug reports as I do, so that might fire up an alarm at least
<lucas> complaining about what?
<siretart> I thought I would get them.. hmmmm
<pygi> lucas: how hard is it to guess? :)
<lucas> well, they could complain about a small detail, or about something more global, or about the weather, etc :)
<pygi> they wouldn't complain in this way about it ;)
<siretart> pygi: please send me references to complaints
* pygi searches his mail
<pygi> siretart: what will you do ? Talking won't bring you any good
<pygi> with you know who
<siretart> I just had another telefone talk with him.
<pygi> well, seems like that isn't helping much :-P
<siretart> lol. 'you know how'. we all are harry potter fans, *G*
<pygi> s/how/who * :-P
<pygi> hehe :D
<pygi> ergh, too much bug mail
<pygi> siretart: https://bugs.launchpad.net/bugs/6493
<ubotu> Launchpad bug 6493 in cdrtools "cdda2wav - cannot cope with accents in CDDB data" [Wishlist,Invalid] 
<pygi> here's one :)
<stgraber> mjg59: You are the one who fixed the Badvalue thing right ?
<pygi> but trust me, this is just a little thing
<stgraber> mjg59: one of my teacher still has even with the latest packages
<siretart> ok, I'm aware of that bug, and I agree with him here
<pygi> with who?
<pygi> Jorg?
<siretart> he is a bit harsh, indeed. the user isn't too helpful either ehre
<siretart> jupp
<pygi> it doesn't matter whetever you, I, or somebody else agree
<pygi> it's important how users see that
<siretart> pygi: when did you set a contact address for ubuntu-burning
<siretart> without telling me that? ;) - I was wondering where that bugmail went...
<pygi> siretart:  :D
<pygi> thought you knew it :-P
<pygi> well, consider yourself lucky :D
<siretart> no
<siretart> naj, I have to import mail now :/
<pygi> mhmh, so you aren't subscribed to the list?
<siretart> not yet
<pygi> I think contact adress was there from the start? :-P
<pygi> not sure I even have the power to do that now, since I've transfered ownership to you, remember? ;)
<siretart> waaah
<atlas95> hello
<atlas95> automount don't work for me and you?
<geser> I'm looking on an upload to Debian which should get synced to gutsy. The last upload changed b-d from libdb4.3-dev to libdb4.6-dev. Is this change ok or should it be undone for gutsy?
<iwj> mvo: dpkg_1.14.5ubuntu13, just uploaded.
<sivang> hmm, I got the gusty deboostrap and still getting "no script" error
<cjwatson> sivang: you've probably not installed it right then
<sivang> I'll reinstall
<cjwatson> if gutsy's debootstrap were broken we *really* would notice ...
<iwj> mvo: As an example package for something with triggers, install volumeid.
<mvo> iwj: thanks
<iwj> mvo: I don't suppose you fancy turning off compiz's crazy windows sliding up and down effect (for raise/lower) ?  (As I request in bug 134234.)  I showed it to a couple of my friends and they all said WTF!
<ubotu> Launchpad bug 134234 in compiz "bouncing windows effect for raise/lower" [Low,Triaged]  https://launchpad.net/bugs/134234
<StevenK> iwj: The proper name is Focus Effect: Dodge
<mvo> iwj: I did that with the upload of yesterday
<iwj> mvo: Yay, thanks.
<iwj> (not updated yet, here)
<ion_> mvo: Oh, i was meaning to congratulate about that choice. :-)
* iwj fixes the bug state.
<mvo> ion_: heh :)
<cjwatson> Mirv: aha, got it. Try applying http://codebrowse.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/cjwatson%40canonical.com-20070918135724-iyu7khlincjlbckw?start_revid=cjwatson%40canonical.com-20070918135724-iyu7khlincjlbckw to your local copy
<cjwatson> Mirv: works for me now
<Kopfgeldjaeger> hi
<bddebian> Heya
<asac> mneptok: there?
<pitti> evand: gobuntu seems to seed linux-image-2.6.22-11-rt; is this deliberate? it's in universe, and traditionally, -rt has been unsupported
<evand> gah
<evand> pitti: no, I imagine not
* evand -> investigates
<pitti> evand: if we need it, we can discuss it, of course
<cjwatson> pitti: ... it does?
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/seeds/gobuntu.gutsy>$ grep -- -rt *
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/seeds/gobuntu.gutsy>$ grep linux-meta *
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/seeds/gobuntu.gutsy>$
<pitti> hm, then anastacia is lying
<cjwatson> pitti: I bet it's a Provides thing
<pitti> o linux-image-2.6.22-11-rt linux-image-2.6.22-11-xen    {linux-source-2.6.22}
<pitti>    [Reverse-Depends: Gobuntu.Gutsy ship seed] 
<pitti> ah, maybe
<pitti> evand: sorry for the noise then
<evand> no problem, thanks for keeping an eye out for such issues
<pitti> cjwatson: probably similar to why libfile-temp-perl appears on the output (provided by perl-modules)
<cjwatson> ah, my fault, I assumed that the linux-image metapackage existed just like linux does
<cjwatson> maybe it should?
<Artemis3> has anyone edited tzdata files to compile with zic?
<cjwatson> I think in general linux should have linux-image parallels, since conceptually linux == linux-image + linux-restricted-modules
* Keybuk shakes his fist at seb128 and dholbach 
<Keybuk> every time I update today, I get MORE GNOME!
<bddebian> Doh
<cjwatson> pitti: if you agree, I'll change linux-meta
<pitti> Keybuk: feel teh love!
<dholbach> Keybuk: it's 2.20.0 :-)
<pitti> cjwatson: thanks, please do
<soren> I forget... Why are we replacing beagle with tracker?
<geser> I'm looking on an upload to Debian which should get synced to gutsy. The last upload changed b-d from libdb4.3-dev to libdb4.6-dev. Is this change ok or should it be undone for gutsy?
<soren> Mono?
<StevenK> soren: Apparently.
<soren> StevenK: I see.
<evand> soren: wasn't it a performance issue at the design level?
<StevenK> geser: universe or main?
<soren> evand: Possibly.
<geser> universe, skktools
<StevenK> geser: Fine, leave it
<jdong> soren: probably because of resource footprint....
<jdong> soren: many people report large memory footprint of beagle....
<jdong> tracker's significantly smaller, though my personal experience shows terrible IO performance with large home directories
<soren> jdong: Sounds sane enough, then.
<pochu> jdong: it's a bug, which will be fixed this week :)
<jamiemcc> jdong: we are working on the io issue but it means using more meory
<jamiemcc> so that we flush less often
<jdong> jamiemcc: I'd gladly trade memory for not having 35 minutes of grindy disks at night :)
<jamiemcc> me too :)
<jdong> but I'm thrilled to see it being fixed :)
<jdong> tracker otherwise rocks
<ion_> Tracker also offers the whole metadata database thing, which will be freaking awesome in the long run.
<jamiemcc> jdong : 30 mb ram is needed to completley eliminate disk io
<ion_> That is, when programs begin to use it to its full extent.
<jdong> jamiemcc: isn't that still 90MB less than beagle?
* jdong ducks
<jamiemcc> lol
<jdong> jamiemcc: I think according to Ubuntu's system recommendations, 30MB can easily be spared
<soren> jamiemcc: Uh? By using 30 MB of RAM, you don't have to look at the disk to know what's on it?
<jamiemcc> yeah gutsy is for 512mb systems
<jamiemcc> soren: by keeping it in cache
<jamiemcc> the bottlenect is seeking and saving the word index
<jamiemcc> reallocationsa s hit array grows really kills IO
<soren> Um, ok.
<soren> jamiemcc: Is there some sort of design document for tracker?
<jamiemcc> wnope which part are you interested in?
<soren> jamiemcc: The cache design for one thing..
<jamiemcc> the cache is just a hash table
<jamiemcc> when it grow to a certain size we flush it to disk
<soren> jamiemcc: Well, that's why we have virtual memory, isn't it?
<jamiemcc> no we dont want to swap :)
<cjwatson> where does this 512mb thing come from?
<cjwatson> we still have lots of people trying to use 256mb and I'd like to cater for them in Ubuntu proper
<jamiemcc> cjwatson: we have a low memory mode in tracker for them
<jamiemcc> the specs for gutsy machine is 512mb ram minimum
<cjwatson> where is that stated?
<jamiemcc> in tracker-preferences
<cjwatson> huh? that's not gutsy's specifications
<ion_> Perhaps tracker should choose the low memory mode automatically if theres less than 512 MiB.
<cjwatson> I mean what Ubuntu documentation told you that gutsy's minimum memory requirement is supposed to be 512 MB?
<soren> jamiemcc: http://varnish.projects.linpro.no/wiki/ArchitectNotes  explains things pretty well.
<jamiemcc> cjwatson: im hunting for it
<cjwatson> jamiemcc: because whatever it is I don't remember it going through me, and I'd have expected it to
<soren> cjwatson: What would you believe it is? 192
<soren> ?
<soren> The memory requirment of gutsy, that is.
<jamiemcc> cjwatson: I thought the ubuntu release of latest ubuntu is average for a 2 year old computer
<mvo> is someone here runing a feist lowlatency kernel? if so, could you please let me know what "uname -r" outputs?
<cjwatson> soren: the last figure I have is 256, though I am aware that it won't actually work in that at the moment. However I think that should be considered a bug and not "oh, but those are gutsy's requirements so that's OK".
<cjwatson> jamiemcc: that's only Scott's personal opinion, AFAIK
<jamiemcc> ok
<jamiemcc> would 30mb be excessive for firt time index only (>6mb thereafter)?
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [-b %*!*@88.203.73.158]  by Hobbsee
<cjwatson> I have no real opinion there, the only bit I was arguing with was the invocation of gutsy's specifications
<jamiemcc> ok
<agoliveira> mvo: 2.6.20-16-lowlatency
<mvo> agoliveira: thanks a lot!
<agoliveira> mvo: My pleasure ;)
* mode/#ubuntu-devel [+b %eagles0513875!*@*]  by Hobbsee
<cjwatson> BenC: gah, now I have to dig through opensuse's repository again
<cjwatson> the least navigable system on god's earth
<StevenK> Haha
* Hobbsee curses dynamic IP's.
<cjwatson> iwj: would it be worth turning off the "ldconfig: wrapper deferring update (trigger activated)" message, or making it subject to a debugging environment variable, or something? I find it rather noisy in updates
<BenC> cjwatson: glad to be of help :)
<cjwatson> BenC: not seeing this patch though, unless it's in the syslinux hooks
<BenC> cjwatson: not sure exactly where it is, but there's an off chance this is a bug in kvm...some is checking into it, so maybe hold off today on it
<iwj> cjwatson: Yes, it might well.
<ogra> seb128, if ./configure says --enable-pam is auto and i depend on libpam0g-dev, shouldnt "ldd /usr/bin/gnome-screensaver|grep pam" return something ?
<ogra> (it doesnt )
<iwj> cjwatson: I think it's been hammered enough now that it's time to take the message out.
<pitti> BenC: will you need kexec-tools in main for gutsy? it wants to go to universe for a long time already
* ogra wonders if he has to force it to yes or something)
<BenC> pitti: it's not required, but it will be in gutsy+1
<pitti> mathiaz, keescook: will you upload a new AA with the re-added libterm-readkey-perl/librpc-xml-perl today? or is that obsolete?
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<pitti> BenC: right; just pondering whether we should explicitly seed it or demote for gutsy
<keescook> pitti: I never dropped readkey, but I can re-enable librpc-xml
<pitti> BenC: it has an approved MIR, so we can quickly promote it whenever we need to
<BenC> pitti: ok
<pitti> keescook: hm, readkey appears in http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt, so I guess it was dropped?
<pitti> BenC: is it useful on its own for something that we want to support?
<pitti> cjwatson: I am not sure about partman-crypto-loop; will that eventually be used in gutsy's d-i?
<ion_> soren: Good article. Depending on the purpose, it indeed sounds reasonable to consider disk to be the main storage and RAM to be cache, and let the kernel take care of moving data between them.
<BenC> pitti: it could be used for fast reboots on kernel upgrades (avoids hw reset)
<pitti> BenC: so if our kernels support it, and you are happy with it, I'll seed it
<BenC> pitti: yeah, sounds good to me
<geser> keescook: Hi, could you ACK bug #140665? it fixes CVE-2007-4033.
<ubotu> Launchpad bug 140665 in t1lib "[Sync request]  Sync t1lib (5.1.0-3) from Debian unstable main" [Undecided,New]  https://launchpad.net/bugs/140665
<pitti> keescook: good morning
<pitti> keescook: nothing AppArmorish in apt-cache rdepends libterm-readkey-perl
<cjwatson> pitti: I wasn't planning to include partman-crypto-loop. I didn't intentionally promote it, only -dm
<cjwatson> pitti: I think Soyuz just hates us
<cjwatson> iwj: want a bug?
<pitti> cjwatson: might be from the time when change-override was b0rked; I'll demote it, thanks
<Hobbsee> cjwatson: news at 11.
<cjwatson> I should probably test crypto now that it's supposed to be in
<keescook> pitti: perhaps it is missing an automatic perl-depends scan?
<keescook> geser: sure, one sec
<iwj> cjwatson: If I haven't fixed it by the end of tomorrow, file a bug :-).
<pitti> keescook: shouldn't it be a package dependency?
<cjwatson> ok :)
<keescook> pitti: it should, yes, but it wasn't realized.  are those needed explicitly, or is there some dh magic that can be used?
<pitti> Hobbsee: curious, where does this 'news at 11' aphorism come from?
<cjwatson> pitti: http://en.wikipedia.org/wiki/Film_at_eleven
<Hobbsee> pitti: unsure exactly.  but the long form is "soyuz hates us, news at 11."
<pitti> keescook: dh_perl should actually do it (with ${perl:Depends}
<mathiaz> pitti: did you have a look at the UVFe I've filed for apparmor ? (140507)
<mathiaz> pitti: I've added the dependency in my branch.
<pitti> mathiaz: no, I didn't even see it; did you subscribe ~ubuntu-release? /me looks
<Hobbsee> cjwatson: way cool - i didnt know it had a wiki page too
<mathiaz> pitti: yop
<cjwatson> Hobbsee: everything has a wikipedia page
<Hobbsee> cjwatson: i dont have a wiki page, last i checked.
<Hobbsee> cjwatson: clearly they dont make wiki pages for green aliens.
<cjwatson> I did say every*thing*
<Hobbsee> cjwatson: green aliens are not a thing?
<soren> ion_: Yeah. It's actually pretty good at doing just that :)
<geser> Hobbsee: http://en.wikipedia.org/wiki/Little_green_men
<geser> :)
<pitti> mathiaz: ah, only 12 minutes ago; I'm not that fast with syncing mail :)
<ion_> soren: It better be. :-)
<Hobbsee> geser: they dont mention those of us who turn purple :)
<MacSlow> seb128, so the N:M workspace-layout mapping from metacity to compiz works now
<dholbach> MacSlow: kickass!
<mathiaz> pitti: hum.. I subscribed ubuntu-release yesterday
<MacSlow> seb128, as good as it is possible with the sick "design-issue" of num_rows being not a metacity-property but a workspace-switcher-applet
<mathiaz> pitti: but I did update the bug about 12 minutes ago
<MacSlow> seb128, so you're 3x3 layout will cleanly migrate from metacity to compiz
<pitti> mathiaz: oh, does -profiles ship its own cupsd profile now? We need to make sure that they do not conflict
<dholbach> pitti: nemiver and glom will build cleanly against the new libgtksourceviewmm
<dholbach> pitti: preparing nemiver rebuild upload
<pitti> dholbach: yay you
<MacSlow> dholbach, the whole issue is really nasty... I'll offer vuntz my help after gutsy release to make the whole issue get a clean solution for gnome 2.22
<dholbach> nice
<mathiaz> pitti: hum.. It came from upstream. I should remove for the package.
<mathiaz> pitti: it's in extra, so it ends in /usr/share/doc
<pitti> mathiaz, keescook: bug 140507 approved
<ubotu> Launchpad bug 140507 in apparmor "UVFe - 2.1+993-0ubuntu1" [Undecided,New]  https://launchpad.net/bugs/140507
<pitti> mathiaz: ah, that's fine
<soren> ion_: pkl also usually knows his stuff.
<keescook> mathiaz: cool, your tree is bumped already?  Should I pull it and then undo the RPC::XML changes I made?
<hunger> Hmmm... apt-get coredumps now. Same for aptitude.
<hunger> dpkg
<hunger> seems to work fine, but messes up the terminal.
<Hobbsee> hunger: what the heck did you do?
<hunger> Hobbsee: Update.
<Hobbsee> erk
<geser> here too :(
<geser> Setting up dpkg (1.14.5ubuntu13) ...
<geser> Segmentation fault (core dumped)
<pitti> new dpkg with --status-fd update?
<hunger> I read that somebody changed the fd related code. I guess it does send some wiered junk on to the apps now.
<_MMA_> geser: Me too. :(
<pitti> downgrading dpkg helps, I assume?
<geser> Program received signal SIGSEGV, Segmentation fault.
<geser> 0x00002b82007e8a51 in _strstrip () from /usr/lib/libapt-pkg-libc6.6-6.so.4.5
<hunger> pitti: Downgrading helps.
<cjwatson> iwj: awooga
<mathiaz> keescook: you can pull my tree. I've already undone the RPC:XML change.
<keescook> mathiaz: ah!  fantastic.
<geser> pitti: yes, downgrading dpkg to ubuntu12 helps
<Keybuk> seb128: you know mlind's freetype/cairo/xft patches to make the font rendering prettier?  Any particular reason we don't use those after than "scary legal issues" ?
* keescook makes sure not to update dpkg
<cjwatson> perhaps we should nobble dpkg on the mirrors so that people don't download it?
<ogra> Keybuk, did you see Yoe's question before ?
<Keybuk> ogra: no?
<ogra> Keybuk, he wanted to merge patches from us back, seems patches.ubuntu.com is quite outdated atm
<ogra> (was abou nbd, for which i can confirm two ubuntu revisions are missing)
* Keybuk checks casey
<Keybuk> IOError: ('http error', 302, 'Found', <httplib.HTTPMessage instance at
<Keybuk> +0x2aaaadcc5950>)
<Keybuk> weird
<ScottK> Note to self: Read IRC before updating, not after. (goes to downgrade dpkg)...
<iwj> cjwatson: Oops.
<cjwatson> though it sounds like it's apt that's breaking not dpkg ... but still
<iwj> mvo: AYT?
<mvo> iwj: yes
<iwj> mvo: See above.  You told me it would be OK :-).
<mvo> geser: do you have a crash file
<geser> mvo: yes
<mvo> geser: could you file a bug with this ?
<mvo> geser: I would like to look at this
<geser> sure
<iwj> mvo:   Breaks: apt (<= 0.7.6ubuntu9)    ?
<mvo> iwj: not sure yet let me see the crash file please
<cjwatson> will that help? it's the running apt that segfaults
<iwj> cjwatson: That'll stop new people from getting the update.
<iwj> And we can fix it later.
<cjwatson> if that's the aim, we can ask IS to nobble the mirrors
<cjwatson> i.e. chmod 000
<ScottK> mvo: Do you want more than one crash file?
<iwj> cjwatson: If that's an approved route then yes, we should do that.
<mvo> iwj: yes, I think that is the problem, let me fix apt
<cjwatson> iwj: if it isn't going to impede you and mvo fixing the problem, I think it's a plan
<cjwatson> mvo: confirm?
<iwj> cjwatson: Go for it.
<mvo> cjwatson: yes
<iwj> mvo: When you have an idea what the problem is please let me know and I may be able to make the output something that the old apt won't mind.
<iwj> (And test this fact, this time.)
<geser> mvo: bug #140737
<ubotu> Bug 140737 on http://launchpad.net/bugs/140737 is private
<mvo> iwj: the problem is a bug in the parser, if you just send a ":" at the end it should no longer crash
<cjwatson> iwj,mvo: <elmo> done
<geser> pitti: could you give back nautilus on amd64? thanks
* ..[topic/#ubuntu-devel:cjwatson] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | FF in place | dpkg downloads blocked due to critical bug
<iwj> mvo: Can I send a : between the two words ?
<mvo> iwj: yes
<iwj> OK, will try that.
<Keybuk> ogra: the Debian mirror we're using is broken
<ogra> oh, ok
<Keybuk> elmo: what's a good mirror?
<elmo> Keybuk: err?
<elmo> Keybuk: define good?
<Keybuk> elmo: one that isn't broken
<Keybuk> using ftp.se and it returns 302 found for the first package
<keescook> pitti: looking at the source, dh_perl doesn't seem to actually add perl module depends -- it's just for the perl depend itself.
<cjwatson> right, that's been known for a long time, you have to do perl module deps yourself
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=49287
<ubotu> Debian bug 49287 in debhelper "debhelper: dh_perl should work the same magic lintian does" [Wishlist,Open] 
<cjwatson> (tagged wontfix)
<keescook> cjwatson: ah, bummer.
<iwj> mvo, cjwatson: 1.14.5ubuntu14 on the way
<cjwatson> iwj: I'll accelerate the publisher
<Hobbsee> cjwatson: does the topic mean that now the new dpkg upload has been pulled?  or just that people should avoid it?
<iwj> I tested it the old apt and it obligingly dumped core, and this dpkg fixed it.
<iwj> Hobbsee: Both.  The pulling may not take effect instantaneously everywhere.
<cjwatson> Hobbsee: $ wget http://archive.ubuntu.com/ubuntu/pool/main/d/dpkg/dpkg_1.14.5ubuntu13_i386.deb
<cjwatson> 17:27:15 ERROR 403: Forbidden.
<Hobbsee> cjwatson: rock on.
<cjwatson> it won't affect mirrors that have already mirrored it, but hopefully not many have, and it will prevent further mirroring
<Hobbsee> true
<cjwatson> it's the thing we use for busted stable updates
<Hobbsee> yeah - i just didnt realise what in particular you were doing to it
<mvo> iwj: thanks a lot and sorry for this :( I have a fixed apt now that is robust against this
<iwj> NP
<iwj> OMG 3 bugs already ...
<Nafallo> I wonder why...
<Nafallo> :-P
<dholbach> ogra: will you update gnome-screensaver too?
<keescook> pitti, mathiaz: apparmor_2.1+993-0ubuntu1 pushed and published.
* Nafallo downgraders
<pitti> yay
<ogra> dholbach, yes, i was just looking into some pam issues with it (ther were non exisiting actually, since i looked at the wrong binary) ... its ready for upload
<ogra> s/ther/they/
<dholbach> ogra: rock on
<ogra> uploading ...
<ogra> :)
<dholbach> keescook: can you take a look at bug 138247?
<ubotu> Launchpad bug 138247 in lirc "Lirc doesn't support Home-brew serial-port driver Igor Cesko's variation" [Undecided,In progress]  https://launchpad.net/bugs/138247
<cjwatson> iwj: hmm. I do hope that the buildds won't attempt to upgrade dpkg while building dpkg ...
<iwj> *snort*
<cjwatson> they normally try
<cjwatson> bugger
<Hobbsee> ....wow
<alex-weej> man, APT is buggered
<Hobbsee> i would have thought there'd be a check against that now?
<Hobbsee> alex-weej: /topic, by any chance?
<Hobbsee> it's about time we had segfaulting apt, though.
<Hobbsee> seeing as we havent since dapper or so
<song> so much people.
<alex-weej> ooo
<keescook> dholbach: yup, I was waiting on feedback from superman1 about it.
<cjwatson> Hobbsee: the buildds upgrade the whole base system before starting, which is normally the right thing to do
<Mirv> cjwatson: ber-great! (ubiguity-gtk) works for me with the patch, too! so, it's now as good i18n-wise (maybe little better) as feisty was. I will, though, file bugs of the remaining issues still, namely most of manual partitioning and advanced dialogs (including "advanced" button) plus there's the existing bug about the last step's "Install" button.
<Hobbsee> cjwatson: exactly - but you'd have thought there would be a check in there to not try to upgrade what it was about to build.
<iwj> I've not had a build fail email yet.
<dholbach> keescook: thanks a lot - shall I subscribe you to it?
<cjwatson> Mirv: excellent. strange, I thought I'd fixed the partitioning and advanced stuff in my last changes
<keescook> dholbach: I'm already a package contact for lirc  :)
<cjwatson> iwj: it's not got that far, no build records yet
<dholbach> keescook: ok I'll shut up then - just wanted to know if you're on it
<cjwatson> https://launchpad.net/ubuntu/+source/dpkg/1.14.5ubuntu14
<keescook> dholbach: I am, yup.  thanks for checking on it.
<cjwatson> I've asked infinity on IRC for help
<cjwatson> Hobbsee: such a check wouldn't be universally correct
<mathiaz> keescook: great ! Thanks.
<cjwatson> Hobbsee: in fact I'd guess it's more often correct to upgrade than not
<Hobbsee> cjwatson: i was thinking of packages at a particular priority, maybe.  unsure.
<Hobbsee> cjwatson: it's gone 2am.  do you expect me to be logical?
<cjwatson> :-)
<Amaranth> gone 2am?
<song> hello everyone
<Hobbsee> Amaranth: yes.  i'm australian.
<song> i'm Chinese
<Hobbsee> Amaranth: (thank goodness for holidays)
<desrt> i'm canadian
<desrt> a/s/l?
<desrt> anyone wanna cyber?
<cjwatson> ok (while I know desrt is joking) this is not a chat channel
<desrt> cjwatson doesn't want to cyber :(
<Hobbsee> poor desrt
<song> i'm sorry but this channel have 246 peoples
<Mirv> cjwatson: ok, apparently not yet completely. column titles and "New partition table" untranslated, pop-contest + window title + "Install boot loader" in advanced. but if you only now marked them translatable, the new strings should probably be put to Rosetta?
* mode/#ubuntu-devel [+o cjwatson]  by ChanServ
<cjwatson> song: which is why it is important that people exercise self-restraint and try to keep discussion to Ubuntu development
* mode/#ubuntu-devel [-o cjwatson]  by cjwatson
<cjwatson> Mirv: oh, those are probably just waiting for a cycle through Rosetta - most of them should be automatically translated due to matching strings in the rest of d-i
<cjwatson> I'll ask for an updated import
<cjwatson> Mirv: popularity-contest is a genuine changed string
<cjwatson> (removed question mark)
<Mirv> cjwatson: yep, thanks, great. it'll leave the final "Install" button. for those languages I know, it's fine with the string on the desktop / Administration menu, but if it's not sure if the same "Install" string can be used for all languages, I'm not sure how to resolve that problem
<cjwatson> I'll have to do the [ ]  po-debconf trick I think
<Mirv> okay... anyway, thanks for everything, it's great to have mostly localized installer for the beta
<cjwatson> thanks for noticing the breakage and hassling us until it got fixed :)
<alex-weej> desrt: 12cybr?
<Hobbsee> alex-weej: ...if you hadnt noticed, cjwatson's not in a happy mood today.
<desrt> alex-weej; ya.  maybe elsewhere :)
<alex-weej> #gnome-hackers, where we can "express" ourselves... hmph!
<alex-weej> ok i stfu now
<mathiaz> pitti: I've updated cupsys apparmor profile and attached it to bug 139665.
<ubotu> Launchpad bug 139665 in cupsys "apparmor profile error messages" [Undecided,New]  https://launchpad.net/bugs/139665
<wolfe> so many bugs :/
<bddebian> No kidding :-(
<pitti> mathiaz: eek, I was specifically trying to avoid dac_override and dac_read_search
<pitti> mathiaz: and I don't see why cupsd would need /dev/tty* access; I simply ignored those messages
<mathiaz> pitti: apparently it's needed with cup-pdf
<geser> pitti: could you give back nautilus on amd64? thanks
<mathiaz> pitti: hum.. I see your point.
<mathiaz> pitti: OTOH it will keep showing in the logs.
<pitti> mathiaz: I fixed /etc/papersize access yesterday
<pitti> +  /etc/password m,
<pitti> mathiaz: ^ that's "passwd", I take it?
<pitti> geser: done
<mathiaz> pitti: at some point, I'd like to package the gnome applet
<mathiaz> pitti: yes it's /etc/passwd
<pitti> mathiaz: I'd rather patch the cupsys source to not fiddle with /dev/tty in the first place, I think
<mathiaz> pitti: so if we ignore messages, they'll keep showing up in the applet
* agoliveira was not-so-kindly reminded the last couple days that code done != code working
<mathiaz> pitti: ok. WFM.
<pitti> mathiaz: is there any way to find out which particular file operation triggered the need for DAC overriding?
* Hobbsee cheers at stupid bugs
<mathiaz> pitti: hum... Not that I know of.
<cjwatson> Mithrandir: re bug 139583, since I'm in linux-meta anyway - do you want linux-lpia to depend on the restricted modules on lpia? they seem to exist at least
<ubotu> Launchpad bug 139583 in linux-meta "linux doesn't depend on lum on lpia" [High,New]  https://launchpad.net/bugs/139583
<cjwatson> hmm, though empty
<cjwatson> I guess I'll do it then, can't hurt
<Mithrandir> cjwatson: yes, please.
<pitti> keescook, mathiaz: didn't we agree to having a list of 'upstream microreleases are ok' exceptions for SRU?
<pitti> keescook, mathiaz: I can't find it on https://wiki.ubuntu.com/StableReleaseUpdates
<pitti> there are new postgresql microreleases I'd like to get to -proposed
<mathiaz> pitti: https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<pitti> mathiaz: ah, thanks! I'll link it to the main SRU page
<cjwatson> pitti: I'm sure I saw that linked already
<cjwatson> 60 2007-08-20 22:02:40 10163 ( )( ) KeesCook            link to microreleaseexceptions                                                     view raw print
<pitti> ah, it's in step 2
<mathiaz> pitti: yeah.. it's burried in the text.
<mathiaz> pitti: maybe linking to it from the When section would help
<mathiaz> ajmitch: as you're working on a new samba for gutsy, would you consider fixing bug 133932 ?
<ubotu> Launchpad bug 133932 in samba "Samba is not configured for using CUPS by default" [Medium,Confirmed]  https://launchpad.net/bugs/133932
<pitti> mathiaz: I thought about linking from the 'exceptions' section
<pitti> mathiaz: but that's good enough
<mathiaz> ajmitch: it's milestoned for the beta release.
<pitti> mathiaz: I was just looking for a policy to justify my new psql :)
<mathiaz> pitti: well... The way I found it is because I was searching StableRelease in the wiki
<mathiaz> pitti: and it showed up in the results
<pitti> alright
<pitti> thanks, bbl
<cjwatson> iwj: hmm, I guess we got lucky, dpkg built successfully despite upgrading to the broken version
<cjwatson> (which it could get at because it upgrades from the master machine rather than archive.u.c)
<cjwatson> publishing new dpkg now
<cjwatson> (binaries)
<Treenaks> ooh.. I was just going to grep my logs to see why it broke :)
<siretart> when is ftp-admin days?
<Riddell> siretart: https://wiki.kubuntu.org/ArchiveAdministration
<siretart> uuh, kubuntu.org?
<siretart> thanks Riddell
<Riddell> but it's not necessarily accurate, e.g. I'm on holiday and Mithrandir is usually too busy and admins may not do all of admin tasks on their day
<siretart> oh
<siretart> I was just about to ask you to remove 'fai-kernels' and 'xine-extracodecs' from gutsy, but not when you're on holyday ;)
<Riddell> I've never deleted packages before, I should read up on it
<seb128> ogra: not sure about the pam option
<seb128> MacSlow: cool
<Riddell> siretart: got bug numbers for those requests?
<siretart> Riddell: not yet, that's why I wanted ot ask when archive days are first
<MacSlow> seb128, and we found a tiny bug in libcompizconfig
<seb128> MacSlow: and fixed it? ;)
<ogra> seb128, ogra@laptop:~$ ldd /usr/lib/gnome-screensaver/gnome-screensaver-dialog |grep pam        libpam.so.0 => /lib/libpam.so.0 (0xb7b2d000)
<ogra> i was just looking at the wrong binary :)
<seb128> good
<MacSlow> seb128, not yet... but I'll do it... or Dennis
<Riddell> siretart: I can delete them now if you tell me why they should go and if it's source and binary which should go
<\sh> I think fai-kernels is obsolete, because it works now with the default kernels, right?
* \sh restarts his gnome session...brb
<siretart> Riddell: fai-kernels is obsolete and not needed anymore with fai 3.2. it contained old, unsupportable ancient kernel versions
<siretart> Riddell: xine-extracodecs contained was is now in libxine1-ffmpeg. it is terribly outdated and abandoned. just junk lying around, not usable by anyone
<Riddell> siretart: both gone
<siretart> yay. thanks! :)
* siretart hugs Riddell 
<sladen> groovy, NetworkManager *doesn't even start* now
<pochu> jdong: could you please take a look at bug 135171? It has tried to backport tracker for 3 times, all of which it has failed because it tries to install old packages...
<ubotu> Launchpad bug 135171 in feisty-backports "Please backport tracker 0.6.1-0ubuntu1 from Gutsy to Feisty" [Undecided,New]  https://launchpad.net/bugs/135171
<jdong> pochu: ok, pbuilder needs updating love, will deal with it
<pochu> jdong: thanks :) and if you can retry the backport... ;)
<jdong> k
<elmo> ogra: what's the default screensaver for gutsy?
<ogra> elmo, should be the floating ubuntu logo
<ogra> i didnt change anything vs feisty
<elmo> ogra: hmm, seems to be blank in this vanilla gutsy install I did on this laptop
<ogra> do you see it in the preview if you select it there explicitly ?
<elmo> ogra: yes
<ogra> hmm, weird, i`ll inspect that ... thanks for the pointer
<ogra> elmo, can you: grep Float /usr/share/gconf/defaults/10_gnome-screensaver ?
<elmo> /apps/gnome-screensaver/theme "Floating Ubuntu"
<ogra> looks sane ... must be mneptok's fault then, its his patch :P
<ogra> elmo, ah, seems gss changed the theme handling internally the name must be screensaver-<basename of .desktop file> now (screensaver-ubuntu_theme in this case), thanks again, will fix now
<mlind_> hi, could one of the buildd admins trigger rebuilds of previously FTBFS packages in the archive which are described in https://bugs.launchpad.net/ubuntu/+bug/102037/comments/7. thanks.
<ubotu> Launchpad bug 102037 in debian "[New Package Freeze Upstream]  maven2-2.0.7" [Unknown,Fix released] 
<Keybuk> Rejected:
<Keybuk> No copyright file found.
<Keybuk> ?
<Keybuk> Soyuz bug?
<evand> Just out of curiosity, what's the plan for nvidia systems with the black windows (memory exhaustion) bug?
<seb128> Keybuk: bug #134567
<ubotu> Launchpad bug 134567 in soyuz "having a debian/copyright should not be a requirement" [High,Fix committed]  https://launchpad.net/bugs/134567
<DexterF> hi
<elmo> should tracker-utils be installed by default?
<seb128> elmo: it's not at the moment no, but it's small enough, do you think that would be nicer for standard desktop users?
<seb128> Keybuk: dunno about those better rendering patches but I see that you uploaded a patched cairo, good ;)
<DexterF> if anyone cares: feisty comes with xfe 0.88 (file manager). that one compiles against fox 1.4 and doesn't support unicode which is kinda bogus on a utf8 based distro. besides, it regularly complains about /var/shm/run.lock or so not responding. deosn't do that on debian etch or slackware 11/12
<Keybuk> seb128: is just the trio of freetype patches that mlind already packaged
<elmo> seb128: I dunno maybe not - I was just curious about the 'is tracker still indexing thing?' and the default answer appears to be 'run tracker-status'
<elmo> seb128: maybe that's not something a normal desktop user should/would care about
<Keybuk> one to cairo, one to freetype (that iirc just changes a #define to use the cairo bits) and one to xft
<seb128> elmo: right, ideally tracker-utils should not be required and things should just work, but it can be handy to know what's going on
<lamzaks> I hawe one question about ubuntu server eddition
<elmo> also, Documents appears in 'Places' twice in this fairly fresh gutsy install
<sladen> elmo: and in this upgrade
<cjwatson> seb128: though the sorts of things in tracker-utils seem like roughly the kind of thing you'd want in order to implement locate on top of tracker
<elmo> should I file a bug about the Places thing?  if, so any hint as to on which package?
<seb128> cjwatson: locate on top of tracker doesn't seem easy to do with the current design since tracker only index the files for your user
<seb128> elmo: that's a known issue and it's on the gutsy beta list, I'll try to fix it when GNOME 2.20 is fully packaged (which should be soon now)
<seb128> elmo: bug #122602
<ubotu> Launchpad bug 122602 in gnome-panel "Duplicated entries in Places Menu" [Medium,Triaged]  https://launchpad.net/bugs/122602
<elmo> seb128: ah, ok, thanks
<cjwatson> seb128: and also /usr/share/applications and /usr/share/*/applications apparently
<cjwatson> but OK, it would be quite a bit of per-user data
<hjmills> what do I need to install after debootstrapping to get a normal ubuntu desktop? I already have ubuntu-desktop, grub and a kernel. Is there anything else?
<cjwatson> ubuntu-standard as well
<EvanCarroll> the lang pack i don't think is included in ubuntu-desktop
<cjwatson> and any appropriate language packs (language-pack-* and language-support-*)
<cjwatson> otherwise that should be about it
<hjmills> cjwatson, thanks
<hjmills> EvanCarroll, thanks
<hjmills> does ubuntu-standard just get you to a command line system?
<EvanCarroll> yep.
<EvanCarroll> ubuntu-standard is the new ubuntu-base and ubuntu-minimal iirc
<hjmills> my cd drive is on the way out so installs are dodgy so I'm planning to setup a partition with ubuntu so I can get web access and debootstrap the other partitions when I need to upgrade
<hjmills> EvanCarroll, thanks
<EvanCarroll> which are used as the servers ubuntu-desktop of sort. meta packages that kill the basics
<gnomefreak> is there a known problem with dpkg seg faulting on upgrade to gutsy?
<ogra> gnomefreak, /topic
<gnomefreak> oh god right when i format :(
<gnomefreak> ty ogra
<ScottK> ubuntu14 is out and fixes it (at least for me) though.
<gnomefreak> ScottK: dpkg?
<ScottK> Yes
<gnomefreak> i still have ubuntu13 here
<cjwatson> EvanCarroll: ubuntu-base was split into ubuntu-minimal and ubuntu-standard
<ScottK> I guess wait for your mirror to update than.
<ScottK> than/then
<cjwatson> in order that debootstrap was smaller
* gnomefreak is making sure its up to date
<cjwatson> gnomefreak: wget http://archive.ubuntu.com/ubuntu/pool/main/d/dpkg/dpkg_1.14.5ubuntu14_i386.deb && sudo dpkg -i dpkg_1.14.5ubuntu14_i386.deb
<gnomefreak> cjwatson: ty
<soren> wtf...
<soren> My sbuild's output is in all uppercase?
<soren> UNPACKING ESOUND-COMMON (FROM .../ESOUND-COMMON_0.2.38-0UBUNTU3_ALL.DEB) ...
<EvanCarroll> soren: don't log in with caps.
<soren> EvanCarroll: I'm not.
<ogra> pull out the earplugs ?
<soren> ogra: :p
<ogra> so your machine doesnt think it needs to shout at you
<gnomefreak> cjwatson: ScottK works like a charm ty
<ion_> ti110220 < StevenK> SELECTING PREVIOUSLY DESELECTED PACKAGE X11-COMMON.
<ion_> Youre not alone.
<LaserJock> soren: it *really* wants you to know what it's doing
<soren> That is really.. odd.
<soren> It's like something "stty olcuc"'ed it.
<soren> Hmm.... The build log is in uppercase, too.
<soren> Now, *that* is weird.
<ogra> kernel i guess then
<ogra> we had such things before ... at least on tty consoles
<soren> No, that's not right.
<soren> sbuild acts normally until it's done fetching packages with apt-get. As soon as it starts installing the first package, it switches to uppercase.
<soren> When it leaves sbuild againt, it switches back to lowercase.
<soren> No, actually, it goes back to lowercase as soon as apt-get finishes.
<mvo> cjwatson: the app-install-data package got updated and upload, thanks for your earlier reminder
<soren> StevenK: Did you figure out the odd upper case output stuff from apt-get?
<soren> StevenK: Well.. From dpkg, actually.
<mako> i tried to make a payment
<mako> wrong channel, sorry :)
<LaserJock> mako: you can send it to me, it'll work I asure you ;-)
<fbond> Hi, I have created a usplash theme, however, my pixmap appears offset down and to the right, rather than displaying flush against the upper-left corner.  Ideas?
<fbond> Nevermind, seems to be caused by the presence of a vga= kernel command-line option.
<tormod> mjg59: do you have time to look at (or just upload) 127273?
<TU> i've most definatly found a bug.
<TU> i added a preappend to the bottom of my dhcp3.conf file and it does add them to ALL the /etc/resolv.conf and lookups are STILL slow
<tormod> TU: please file a bug report
<TU> i don't want  to file a bug report i want a fix.
<TU> then i can file a bug report heh
<ion_> Huh?
<tormod> TU, please ask in #ubuntu instead
<TU> No. Look.
<TU> this is DEFINATLY a bug.
<TU> i've been screwing with this for a week
<TU> there is no way to fix it.
<TU> there seems to be NO WAY to change the DNS servers ubuntu is using
<TU> thats a problem.
<seb128> TU: this is not a support channel
<seb128> if you found a bug use launchpad to report it
<TU> fine.
<seb128> calc: do you know why openoffice is not upgradable on powerpc and if that will be fixed?
<calc> seb128: no don't know about that problem :(
<calc> seb128: i will try to look into it soon if there isn't a detailed bug about it yet
<seb128> <svu> seb128,  openoffice.org-common: Depends: openoffice.org-core (> 1:2.3.0~rc1) but 1:2.3.0~oog680m1-1ubuntu3 is to be installed
<calc> oh
<calc> probably rc1 never compiled on powerpc then
* calc looks at the build log
<calc> seb128: build failed due to timeout at 600min
<calc> seb128: not sure why it hung though
<calc> seb128: i'll see how it does when i upload 2.3.0 final soonish
<seb128> ok, thanks
<ogra> seb128, any idea why the gnome menu doesnt use the distributor-logo icon anymore ?
<seb128> it does?
<ogra> no it doesnt, but it did :)
<sbalneav> That's DEFINATLY a bug.
<ogra> currently i have the ubuntu logo in it
<seb128> the Ubuntu logo is correctly displayed there
<ogra> yeah
<seb128> which is correct? ;)
<ogra> thats my prob :)
<ogra> i want the edubuntu logo
<ogra> which is fine displayed in about ubuntu and about edubuntu (we wanted to fix that, need to talk about it in boston)
<ogra> the menu used to use the logo as well ...
<seb128> ogra: it uses the "start-here" icon
<ogra> aha
<ogra> will it follow links ?
<seb128> yes
<ogra> good :)
<ogra> thanks
<seb128> /usr/share/icons/Human/scalable/places/distributor-logo.svg -> start-here.svg
<seb128> we could use distributor-logo
<seb128> but I think it's better to update your icon theme
<ogra> we did that until feisty afaik
<seb128> right
<seb128> upstream changed
<ogra> ah, k
<ogra> lets go with upstream then :)
<seb128> start-here is probably the new naming spec convention
<ogra> ah, gartoon doesnt even have /places
<LaserJock> anybody try IBM's new office suite yet?
<J-diddy> if it's not openoffice with a different splash screen, let me know
<J-diddy> I'd love to give it a shot
<ogra> now my panel looks beautiful again :)
<LaserJock> J-diddy: the screenshots look a bit different, but I'm not sure how different it actually is
<J-diddy> cool
<TomaszD> can anyone be of any assistance? I'm really puzzled. Running gutsy current on a SiS630 laptop. When I try to run glxinfo it tells me that (I think) the SiS driver is outdated.
<TomaszD> SiS DRI driver expected DDX version 0-0.8.x but got version 0.7.1
<Nafallo> bryce
<bryce> TomaszD: sounds like you need a newer xserver-xorg-video-sis.
<TomaszD> bryce, sounds like it yes. This is a standard ubuntu gutsy distribution, so I guess this is a serious bug
<TomaszD> bryce, is there a launchpad group I could assing this bug to?
<bryce> xserver-xorg-video-sis
<TomaszD> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/118325
<ubotu> Launchpad bug 118325 in xserver-xorg-video-sis "sis dri DDX interface outdated" [Undecided,Confirmed] 
<bryce> doesn't look like they've fixed it upstream yet - http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-sis.git
<bryce> so no newer -sis is available
<bryce> TomaszD: what version of the -sis driver do you have installed?
<bryce> dpkg-query -l xserver-xorg-video-sis
<TomaszD> bryce, 1:0.9.3-2
<TomaszD> doh, this whole gutsy is a real downgrade for me if dri won't work. Of course it's not gutsy's fault, it's just a shame that not all the drivers have been updated for xorg 1.3 ...
<bryce> TomaszD: they have.  There is no newer version of -sis available beyond 0.9.3
<TomaszD> bryce, I meant the xorg developers, not you guys :]  You guys do an amazing job, it's not your fault
<TomaszD> it doesn't even seem that a current git version of the driver would work
<bryce> right
<bryce> what version of mesa do you have installed?  7.0.1?
<TomaszD> bryce, yes
<bryce> hrm
<TomaszD> bryce, ?
<bryce> oh, just wondering where the "libGL ... 0.7.1 sis" comes from
<bryce> TomaszD: sorry, I'm not certain what needs updated to get rid of that error.  If you discover something though, please let me know.
<bryce> I suspect something needs updated in mesa, but can't tell for sure
<tormod> keescook: remember that bug #127273? I am afraid mjg59 is too busy before beta to upload it, from what it seems. He basically said it was fine now though.
<ubotu> Launchpad bug 127273 in laptop-mode-tools "laptop-mode init script links not created" [Undecided,Confirmed]  https://launchpad.net/bugs/127273
<keescook> tormod: okay, I will get it uploaded in a bit.  Thanks for the reminder!
<tormod> keescook: thanks for taking care of it!
<keescook> tormod: doesn't dpkg naturally take care of removing those files?
<keescook> (or, why is the explicit remove needed?)
<mjg59> keescook: Conffiles
<tormod> keescook: for some reason they are not. yes conffiles I guess. The whole debian package is not perfect.
<keescook> mjg59: ah, so it'll leave them behind due to being in /etc?  Cool.  so mjg59, the new debdiff is okay?
<mjg59> Yeah, looks fine
<keescook> tormod: uploaded.  :)
<tormod> keescook: thanks
<tormod> mjg59: I know that shipping laptop-mode-tools as default is controversial, but now the package works more like it is supposed to at least.
<mjg59> tormod: Yeah
<mjg59> In the future there will be sanity
<mjg59> And robots
<keescook> though, ironically, the robots will probably be insane.
<mjg59> It's ok, they'll be running rtl8180s and we'll have accidently lost the driver
#ubuntu-devel 2007-09-19
<bryce> keescook: I've successfully booted ume with the fix to patch 132
<keescook> \o/
<bryce> keescook: I need to do one more test with the proprietary bits enabled (it's missing flash), to be absolutely sure, but I think we can go ahead with an upload.
<keescook> bryce: cool; let me know when you've got it ready, and I'll pull the lever
<bryce> keescook: I'm generating a .dsc presently, which will include both that and the cve, and will let you know when they're baked.
<bdmurray> keescook, bryce - you guys need to use the same analogy.  one of you seems to be in a factory the other in a bakery.
<bryce> :-)
<bryce> we be makin' loaves of steel here
<bryce> kees, ok flash added, and the home apps came up ok
<bryce> kees, mind uploading xorg-server from http://people.ubuntu.com/~bryce/Uploads/?
<keescook> bryce: sure, one sec, finishing another upload atm
<bryce> the xorg package there can upload too
<bryce> I just finished verifying it still generates valid xorg.conf files, but with the wacom entries disabled
<keescook> bryce: your changes file doesn't need the orig.tar.gz (you can leave off the -sa when building)
<bryce> oh yeah
<keescook> bryce: if you want 83860 to auto-close, the xorg changelog needs "LP: #83860" rather than "LP# 83860"
<keescook> (same goes for the xorg-server, I had intentially not used LP: #xxx in my ppa changelog due to the ppa-auto-close bug
<bryce> gota
<bryce> well, I'll manually close them then
<bryce> I need to search for other related bugs these close anyway
<ion_> Argh, blurry fonts. :-(
<ion_> (due to some new patch in freetype, i think)
<RAOF> Oooh, cool.  The subpixel rendering patch.
<ion_> It used to use subpixel rendering already. :-)
<ion_> Now full hinting isnt full hinting anymore.
<RAOF> Ugh, full hinting. :)
<ion_> Yeah, a.k.a. non-blurry fonts.
<RAOF> Or thin, anaemic looking strange fonts :).
<RAOF> Yay perception.
<Hobbsee> ooh, the fonts have even changed on kubuntu
<RAOF> I don't seem to notice a difference, but that's probably my 130DPI laptop LCD's fault.
<Hobbsee> well, in firefox on kubuntu
<Hobbsee> oh, damn
<Hobbsee> i forgot to stick my remote client back in last night.
<RAOF> Oh, tell a lie.  It seems emacs-snapshot looks better :)
<StevenK> Right. Someone remind me to hurt jdong for that nick change
<ajmitch> gladly
* jdong looks around :)
<jdong> just... returning to normal...
<jdong> if that's even possible for me.
<Hobbsee> !jdong | jdong
<ubotu> jdong: jdong is Hobbsee: jdong: yes, but you're FULL OF CRACK!
* RAOF was under the impression that trackerd wasn't supposed to halve my battery life.  Clearly this is not the case :(
<Hobbsee> silly jdong.
<jdong> :)
<Hobbsee> RAOF: it's a feature.
<ajmitch> RAOF: it's a feature
<jdong> ha
<jdong> jinx
<Hobbsee> ajmitch: ^5
<jdong> haha now you can't talk!
<jdong> or something like that
<ajmitch> :)
<jdong> awww, you broke the rules!
<jdong> I'm telling!
* jdong misses those days of life...
<jdong> before I discovered the computer...
<ion_> I miss those days of life *when* i discovered the computer.
<ajmitch> hi Burgundavia
<ajmitch> welcome back to the real world
<Burgundavia> hey ajmitch
* Hobbsee sighs at internet usage caps
<Burgundavia> Hobbsee: aren't they fun
<Hobbsee> no, they arent
<Hobbsee> and apparently we're at 46%, and the month started 12 days ago.
<Burgundavia> 18, actually
<ajmitch> ah yes, I hit 80% a couple of days ago
<ajmitch> but luckily the billing cycle is over in 4 days for me
<StevenK> Burgundavia: That would be a billing month
<Burgundavia> ahh
<Burgundavia> you poor aussies
<StevenK> Burgundavia: Which looks to be from the 7th - 7th
<Burgundavia> although I got a nasty taste of it in SA
<johanbr> Is it some sort of rule to have usage caps if you're in the southern hemisphere? The bits naturally flow to the north, or something?a
<Burgundavia> basically, yes
<Hobbsee> johanbr: likely - being further away and such
<ajmitch> johanbr: they have to swim further
<Burgundavia> all those lovely bits are on servers in the US and Europe
<StevenK> It's the nasty B word, and .au and .za don't have any
<ajmitch> StevenK: you forget the other tri-nations team
<StevenK> Oh, of course .nz
<ajmitch> we've been promised ADSL2+ for the last couple of years
<StevenK> It's slowly being picked up here.
<ajmitch> makes uploading to the archive real fun
<Burgundavia> I wish RB wasn't so crash-happy
<Hobbsee> ajmitch: upload from a remote host.  problem solved.
<ajmitch> got to get stuff to a remote host
<Hobbsee> ways and means.
* Hobbsee tends to use a couple of shortcuts, etc
<RAOF> Oh, man.  Look at all those bugs fixed in the new nvidia drivers.
<ion_> URL, please.
<johanbr> Is the "driver is closed source" bug fixed? :)
<ion_> :-)
<RAOF> johanbr: No.  But a lot of others are.
<RAOF> ion_: http://www.nvidia.com/object/linux_display_ia32_100.14.19.html
<ion_> Thanks
<RAOF> Supposedly fixes essentially all the nvidia+compiz bugs.
<Hobbsee> nice
* RAOF wonders if it's worth filing a wishlist bug against l-r-m for those drivers.
<ajmitch> I suspect they're already being looked at
<sbalneav> Out of curiousity, what happened to gnome-terminal?  I almost had a heart attack! :)
<Hobbsee> sbalneav: kde sabbotaged it.
<sbalneav> heh
<TheMuso> It was a fonts issue.
<TheMuso> Something to do with the dpi setting.
<sbalneav> One pixel fonts are awesome.
<ajmitch> Hobbsee: those evil, nasty kde people
<sbalneav> I had to break the glass on the front of the little box that holds /usr/bin/xterm, and put it back into service :)
<Hobbsee> ajmitch: indeed.
<Hobbsee> at least our systems actually work
<ajmitch> they do? that's a good change :)
* sbalneav grabs popcorn
<sbalneav> FIGHT FIGHT FIGHT FIGHT
<mjg59> Ok, that's less bad than I was expecting
<mjg59> Though the perception is certainly that the fonts are slightly more blurred than before
* Hobbsee throws large pieces of rock at sbalneav
<mjg59> (Well, the fonts /are/ slightly more blurred than before, but)
<sbalneav> <clunk>
<sbalneav> OW
<ScottK> Hobbsee: Thrown from that far away the impact velocity would be pretty interesting.
<mjg59> The spacing is clearly more consistent than it was before
<Hobbsee> ScottK: there are ways and means.
<sbalneav> SORDS
<sbalneav> Sub Orbital Rock Delivery System
<ScottK> Hobbsee: I wasn't doubting you, I was just going to enjoy the kinetic effects.
<Hobbsee> sbalneav: :)
<mjg59> The basic effect is that stuff that used to be white is now slightly dimmed in order to remove the harshness of the cutoff
<mjg59> It's interesting to compare them in xmag
<mjg59> Oh, I *see*
<mjg59> subpixel in terms of subpixel alignment, not subpixel in terms of subpixel rendering
<mjg59> That makes sense
<bryce> kees, btw I got xserver patched, built, and tested on my laptop.  It's good to go:  http://people.ubuntu.com/~bryce/Uploads/
<Hobbsee> bryce: does it break X?  :P
<bryce> :-P
<ajmitch> wouldn't that be fun, right before the beta release?
<bryce> this makes it so compiz works with -nvidia, and fixes a CVE
<ajmitch> fun
<Hobbsee> ajmitch: well, apt was segfaulting yesterday...
<ajmitch> Hobbsee: I know :)
* ..[topic/#ubuntu-devel:Hobbsee] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ajmitch> thankfully I didn't get that upgrade
<Hobbsee> so it's about the right time
* ajmitch has a samba upload to do as well
<ajmitch> I've put in all but 1 fix that's needed, so that should cause fun for people
* Hobbsee notes that removing stuff from ubuntu-release's buglist, and shoving it back to motu-uvf is suboptimal.
<ajmitch> Hobbsee: isn't that just delegation?
<Hobbsee> ajmitch: not when i'm on both teams.
<Hobbsee> <g>
<ajmitch> but you don't have to be the one to touch it, when you've got your slaves
<Hobbsee> this is true
<Hobbsee> bhale: did you have any opinion on the new beagle?
<calc> Hobbsee: hi! :)
<Hobbsee> hiya calc!
<ajmitch> hey calc
<Hobbsee> ajmitch: i dont have *enough* slaves :P
<calc> ajmitch: hi
<lifeless> mmmm slaves
<Hobbsee> grr.  why do people keep wnating stacks of new packages?
<lifeless> because
* Hobbsee checks the schedule
<ajmitch> there's all this cool stuff that would just make ubuntu so much better
<ajmitch> except we don't have time
<Hobbsee> ajmitch: indeed.
<Hobbsee> ScottK: FYI, i want to put a blanket NO to all new packages at this point - we're a month from release, and the release team is attempting to get a beta together.  the archive team is either working busily on the beta stuff, or is working busily on getting their fixes in.
<Hobbsee> bddebian: how well does awn actually work?  (https://bugs.edge.launchpad.net/ubuntu/+bug/118589)
<ubotu> Launchpad bug 118589 in ubuntu "[needs-packaging]  Avant Window Navigator" [Wishlist,Incomplete] 
<bddebian> me?
<StevenK> Hobbsee: Agreed.
<Hobbsee> bddebian: yes, you
<Hobbsee> StevenK: perhaps modulo the awn, as that's been requested a lot
<Hobbsee> StevenK: please look thru the bugs, if you can get the time off wokr :P
<StevenK> Hobbsee: I'll try.
<Hobbsee> StevenK: thanks
<bddebian> Hobbsee: How the heck would I know?
<Hobbsee> bddebian: you advocated it.
<bddebian> I did? Hmm
<StevenK> Ha!
<StevenK> Hobbsee: Note, let's not +1 anything bddebian touched.
<StevenK> :-P
<bddebian>  "I was not able to do an install or execution test so I cant comment on that portion. Thanks for your contribution!"
<bddebian> I had no Gutsy box at that point, I merely advocated the packaging itself
* Hobbsee marks one as WONTFIX
<Hobbsee> bddebian: ok, then please test it in a gutsy box now then :)
<ajmitch> Hobbsee: so I'm not allowed to dump some new packages in a week before release?
<ajmitch> how unfair
<LaserJock> Hobbsee: what are you WONTFIX'ing
<LaserJock> ?
<Hobbsee> LaserJock: a bug that wants to sync ~5 packages, add more, and do a whole stack fo rebuilds
<Hobbsee> ajmitch: :P
<ajmitch> hey LaserJock
<Hobbsee> StevenK: can you ack https://bugs.edge.launchpad.net/debian/+source/youtube-dl/+bug/137350 as well please?
<ubotu> Launchpad bug 137350 in youtube-dl "Please sync youtube-dl (universe) from Debian unstable (main)" [Undecided,New] 
<LaserJock> Hobbsee: you can't wishlist?
<bddebian> Aye, why are we looking at/considering new packages?
<Hobbsee> LaserJock: it's already a wishlist.  i'm doing this with my motu-uvf hat on.
<LaserJock> oh, it's a UVF
<Hobbsee> bddebian: because people are attemtping to file new package freeze exceptions for them
<bddebian> OK, let me rebuild and test
<Hobbsee> bddebian: if you care about it at all, that is
<bddebian> No more or less than any of the other worthless work I do :-)
<StevenK> Hobbsee: Done.
<Hobbsee> StevenK: great, thanks
<ScottK> Hobbsee: Agreed on New packages.  The only exception I think we should consider is the lightening lanuage packs as translation is something that's supposed to be being done right now.
* Hobbsee WONTFIX's another
<Hobbsee> ScottK: modulo anything of great importance, yes.
* StevenK nods.
<Hobbsee> ScottK: i'm thinking of the random crack on there, which i'm slowly going thru.
<ScottK> Hobbsee: Agreed.
<bddebian> So look at awn or no?
<Hobbsee> bddebian: if you care enough.  it's a reasonably wanted package - if it works, then i'm inclined to think about accepting it
<Hobbsee> (from teh forums, anyway)
* Hobbsee acks enigmail langpacks
<Hobbsee> ScottK: any objection to me shunting the ddclient bug to dholbach to decide on?  he wants kmos to contribute, and i dont have the motivation to audit the code, when i've seen the previous incarnations of the bug.
<Hobbsee> it's either that, or i'll mark it as wontfix, for the above reason.
<Hobbsee> StevenK: ^ ?
<ScottK> Hobbsee: I've gone to great lengths to avoid thinking about that bug.
<ScottK> I intend to continue.
<Hobbsee> ScottK: hehe :)
<ScottK> If someone wants to look into it and ack it, I've no objections.
<ScottK> His other one should be won't fixed.
* ajmitch could look at it, but not ack it
<Hobbsee> ajmitch: i'm happy to delegate it to you, if you want it.
<Hobbsee> ajmitch: i just dont want to touch the damned thing.
<StevenK> Hobbsee: Throw ddclient at dholbach
<Hobbsee> StevenK: yes, i think that's a good idea.  he's trying to get kmos to contribute again, so...
* Hobbsee does
<ajmitch> I keep getting other bugs for me to fix thrown at me anyway
* ScottK is not in favor of encouraging that kind of behaviour, but whatever....
<ScottK> ajmitch: Did you get your FAI UVFe approved?
<ScottK> I don't recall.
<ajmitch> ScottK: that was siretart
<Hobbsee> ScottK: yeah, well.
<ScottK> Ah.  Sorry.
<ajmitch> I haven't been touching universe much
<ajmitch> thought I need to file a sync requst for phpgw, which you approved on irc
* ajmitch does so now
<Hobbsee> ScottK: here you go, https://bugs.edge.launchpad.net/ubuntu/+source/ddclient/+bug/132694/
<ubotu> Launchpad bug 132694 in ddclient "Please merge ddclient (3.7.3-2) from Debian unstable" [Undecided,New] 
<bddebian> So leave psi broken eh? :-)
<Hobbsee> bddebian: qca is still messed.
<Hobbsee> afaik
<ScottK> Hobbsee: Why do I want to click on that link?
<Hobbsee> ScottK: to see my last comment.
<bddebian> Hobbsee: Wouldn't surprise me :-)
<ScottK> Ah
* ScottK looks, but the edge links are a real PITA.
<Hobbsee> sorry, i'm defaulting to edge atm.
<ScottK> Hobbsee: I'm good with your comment.
<Hobbsee> ScottK: :D
<Hobbsee> ScottK: 4th incarnation.  quite good, really
<ScottK> Yes.
<ScottK> I definitely lack confidence in that being correct, so yes.  A good comment.
<Hobbsee> ScottK: fine to WONTFIX https://bugs.edge.launchpad.net/ubuntu/+bug/134504 ?
<ubotu> Launchpad bug 134504 in debian "[needs-packaging]  tapioca-glib" [Unknown,Fix released] 
<bddebian> Gah, awn needs compiz
<bddebian> will compiz --replace work for just this session or permanently replace?
<ajmitch> Hobbsee: it's a sync request, but could you note on https://bugs.edge.launchpad.net/ubuntu/+source/phpgroupware/+bug/140859 that it was approved for UVFe on irc? :)
<ubotu> Launchpad bug 140859 in phpgroupware "Please sync phpgroupware (universe) from Debian unstable (main)" [Undecided,Confirmed] 
<Hobbsee> ajmitch: done
<Hobbsee> Tapioca is a library that abstracts away the D-Bus details and presents
<Hobbsee> the developer a native object structure, very similar to its Telepathy
<Hobbsee> counter-parts. The D-Bus mechanism of request-reply is presented as
<Hobbsee> methods and callbacks in the local language/toolkit used.
<Hobbsee> hum.
<ajmitch> Hobbsee: thanks
<Hobbsee> ajmitch: no problem.
* ajmitch has heard of tapioca
<ajmitch> does it fall under the ubuntu mobile area?
<Hobbsee> ajmitch: i'm presuming the world wont break by me declining it?
<Hobbsee> ajmitch: i have no idea.  Mithrandir didnt mention it.
<Hobbsee> so i dont think so
<Hobbsee> besides, it's new to ubuntu, and a u-m person hastn filed it.
<YokoZar_> hehe https://bugs.launchpad.net/ubuntu/+source/gnome-games/+bug/140862
<ubotu> Launchpad bug 140862 in gnome-games "Nibbles with more than 1 human player causes invincible zombie worms" [Undecided,New] 
<bddebian> OK, awn seems to work, though I don't see anything great about it
<Burgundavia> Hobbsee: tapioca is used by the QT/KDE wierdos for Telepathy stuff
<Burgundavia> :)
<ajmitch> Hobbsee: I don't know enough about it to comment :)
<Hobbsee> Burgundavia: heh.  so, seeing as claerly nothing uses it now...
<ajmitch> Hobbsee: depends, what's the bug?
<ajmitch> we already have some tapioca stuff in the archive
<Hobbsee> ajmitch: https://bugs.edge.launchpad.net/ubuntu/+bug/134504
<ubotu> Launchpad bug 134504 in debian "[needs-packaging]  tapioca-glib" [Unknown,Fix released] 
<ajmitch> right, and he's been doing much of the telepathy-related stuff lately, I think
<Hobbsee> bddebian: be useful and upload https://bugs.edge.launchpad.net/ubuntu/+source/xournal/+bug/137934 please (check the code first, etc)
<ubotu> Launchpad bug 137934 in xournal "Please sponsor xournal 0.4.1" [Undecided,Confirmed] 
<bddebian> Hobbsee: When/if this boson build ever finishes, I'll be glad to
<Hobbsee> StevenK: ScottK: after the discussions, what's your opinion on https://bugs.edge.launchpad.net/ubuntu/+source/libtelepathy/+bug/137953 and https://bugs.edge.launchpad.net/ubuntu/+source/telepathy-gabble/+bug/137955
<ubotu> Launchpad bug 137953 in libtelepathy "[UVFe]  Please sync libtelepathy from debian (main)" [Undecided,Incomplete] 
<Hobbsee> (and yes, i will write that mail eventually)
<Hobbsee> calc: ooo 2.3 is already in gutsy, no?
<Hobbsee> some nutter has filed a bug for it, and subscribed motu-uvf - and hasnt touched the packaging.
<ajmitch> hehe
<ajmitch> they're at least trying to follow the process :)
<Hobbsee> oh, still the rc1 in gutsy
<Hobbsee> ajmitch: they've missed the lesson on main and universe, though.
* ajmitch wonders who this nutter is
<Hobbsee> ajmitch: https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/140703
<ubotu> Launchpad bug 140703 in openoffice.org "UVF exception:  OpenOffice.org 2.3.0 (gutsy)" [Undecided,New] 
<ajmitch> did they attach a build log? :)
<Hobbsee> nope
<Hobbsee> didnt even attach a diffstat
<ajmitch> that's a shame
* Hobbsee ponders rejecting it
<ScottK> Hobbsee: The telepathy packages have a blanket UME handwave according to some as yet (AFAIK) undocumented release team decision.  Who am I to have an opinion.
<ScottK> Hobbsee: I'd say assign it to calc and unsub motu-uvf.
<Hobbsee> ScottK: or just say "we're tracking this in other ways" and mark as invalid.
<ScottK> Whatever.
<ScottK> Assign to calc will make the reporter feel better about their contribution.
<Hobbsee> oh, sigh.  are you more bitter at the release team or LP now?
<ajmitch> or just plain bitter?
<ScottK> Depending on who it is, that woulc be good or bad.
<ScottK> I'm more bitter at LP.
<bddebian> heh
<ajmitch> that's a surprise
<ScottK> I do think it a substantial process failure that there is still no documentation of a general waiver of a whole raft of packages.
<ScottK> The release team thing will pass.  LP is a long term bitter.
<Hobbsee> ScottK: well, the release manager is changing.  wait a bit, and hopefully it'll all start making more sense. :P
* ScottK just wanted it written down so I could know I didn't have to deal with the telepathy packages.
<ScottK> Hobbsee: Since you were in on the release team thing, I'd suggest you mark them approved.
<bddebian> Uhm, where am I getting xournal 0.4.1 from?
<Hobbsee> done
<ScottK> Hobbsee: I'm leaning no on the mod-wsgi thing.
<ScottK> Said so in the bug.
<ScottK> It's gonna be a big thing someday isn't a great rationale at this point IMO.
<Hobbsee> ScottK: noted, please mark as wontfix.
<ScottK> DOne
<Hobbsee> cool
<ScottK> Hobbsee, StevenK, zul, soren: Any objection to me won't fixing Bug #118589
<ubotu> Launchpad bug 118589 in ubuntu "[needs-packaging]  Avant Window Navigator" [Wishlist,Incomplete]  https://launchpad.net/bugs/118589
<bddebian> Hobbsee: Where is xournal supposed to come from?  I'm not following that bug and I don't see a 0.4.1 on his ppa
<StevenK> ScottK: Fixing it how?
<ScottK> StevenK: "Won't Fix"ing it.
<Hobbsee> bddebian: i thought it was there.
<ScottK> As it we won't include it in Gutsy.
<Hobbsee> ScottK: only that a lot of people want it.  but, it hasnt been approved, and the arhcive admins have only got 4 weeks.
<ScottK> They can get it from his PPA.
* ScottK isn't a fan of PPA in general, but this is the kind of thing it's useful for.
<bddebian> Hobbsee: His 0.4.0.1 is there.  Am I missing something?
<StevenK> Is Avant Window Navigator related to what bddebian is looking at for Hobbsee?
<ScottK> Hobbsee and bddebian: IIRC, bluekaja was going to take care of that one.
<ScottK> StevenK: No
<Hobbsee> StevenK: no, althouhg i'd asked him to before.
<bddebian> ScottK: xournal?
<ScottK> Yeah
<bddebian> Ah, OK
<bddebian> StevenK: I built and ran it earlier.  Seems to work, though nothing special to me but what the hell do I know? :-)
<bddebian> Though i do think it should probably depend or at least suggest compiz
<LaserJock> ScottK, Hobbsee: are the bugs you're WONTFIX'ing specifically FFe bugs?
<ScottK> LaserJock: Yes.
<ScottK> UVFe or New package exception
<LaserJock> so you're leaving the "needs-packaging" bug?
<ScottK> It's the same bug.  Not sure what else to to.
<LaserJock> I think we should do it differently
* ScottK notes for the record that trying to track packaging status in needs packaging bugs is keeping track of stuff in two places and a real PITA.
<LaserJock> a WONTFIX on a "needs-packaging" bug indicates that we aren't going to include it *ever*
* ScottK might have mentioned that before.
<LaserJock> there should be a different bug files for the FFe or UVFe
<Hobbsee> LaserJock: i'm wontfixing the uvfe bugs, and tryign to remember to just unsub the n-p bugs.
<Hobbsee> LaserJock: but i think i missed a couple.
<LaserJock> k
<LaserJock> I just don't think we should WONTFIX stuff that's just "won't fix for gutsy"
<Hobbsee> LaserJock: yeah, just hte uvfe's.  or at least, that's hte plan
* Hobbsee has gone more or less thru 2 queues today.
<LaserJock> that makes sense since you're dealing with a specific exception request
<RAOF> bddebian: It doesn't actually *need* compiz.  It (should) work with xcompmgr, too.  And kwin.
<bddebian> Ah, I didn't look that closely, just noticed that when it failed to run it said it wanted compiz :-)
<RAOF> Yeah.  Because compiz is obviously the only composite manager around :(.
* Hobbsee whines at the next 7 hours.
<bddebian> heh
<ajmitch> Hobbsee: more fun at uni?
<Hobbsee> ajmitch: no, it's uni break.  work.
<ajmitch> ah, unfortunate
<Hobbsee> ajmitch: so i'm using this time to figure out what i want to step down from, ubuntu-wise, and will likely put that into action after the break.
<Hobbsee> ajmitch: very much so - regional high up manager is in tomorrow, so it all has to be perfect.  *shudder*
<bddebian> Nooo :-(
<ajmitch> ouch :(
<Hobbsee> ajmitch: probably other important people too, due to the takeover
<bddebian> Hobbsee: You aren't allowed to step down from anything :-(
<ajmitch> you're working for a different company now?
<LaserJock> some days I do like being a career student ;-)
<Hobbsee> ajmitch: we're under as coles - we now have lots of coles stuff - but wesfarmers is buying otu coles.
<ajmitch> hehe
<Hobbsee> hm.  maroon != black.
<ajmitch> close enough
<Hobbsee> yeah, well.  that tends to work better if i'm the highest person in the store, or the second highest, where the highest doesnt give a damn.
<Hobbsee> (there was no customers anyway, it was late at night)
<Hobbsee> bddebian: tough.  i'm working a fair bit, and i need to concentrate on uni.
<bddebian> Sheesh, none of you are any fun anymore :-)
<Hobbsee> and i actually need reasonable amounts of sleep, etc.
<ajmitch> bddebian: I think it's a good idea for people to step back when necessary
<bddebian> I'm kidding for gosh sakes, it's just not the same these days
<ajmitch> Hobbsee: I expect that after exams you'll be around a bit more
<ajmitch> unless you're planning to do stuff at uni over summer?
<Hobbsee> ajmitch: now there's a good question.
<Hobbsee> ajmitch: i have no idea
<Hobbsee> bddebian: i was saying all of that with a :P, btw.
* Hobbsee --> gone.
<ajmitch> bye Hobbsee
<pitti> Good morning
<StevenK> Morning pitti
<ajmitch> morning pitti
<LaserJock> morning pitti
* LaserJock throws pitti a bag of gummybears
<pitti> yummy!
<ajmitch> pitti: opinions on whether enabling the cups options in the [globals]  section is a good thing? details on bug 133932
<ubotu> Launchpad bug 133932 in samba "Samba is not configured for using CUPS by default" [Medium,Confirmed]  https://launchpad.net/bugs/133932
<slangasek> ajmitch: as opposed to removing the Debian-specific patch that disables CUPS by default?
<ajmitch> slangasek: figures that there'd be something like that
<pitti> hey slangasek
<slangasek> (which I think we should probably drop for lenny too, fwiw, the only question there is whether cups will swap priorities with lpr)
<slangasek> pitti: hi-ho
<pitti> ajmitch: makes me a little nervous TBH (FF and all that)
<pitti> ajmitch: one question is: how does samba printer configuration look nowadays?
<pitti> ajmitch: i. e. is there anything we can break in the first place? :)
<ajmitch> heh
<ajmitch> it's reported to work - I don't have a printer attached so I can't really give an answer there
<slangasek> well, there are some behavior differences when using the cups support, last time I used it there was some raciness on startup because cups would accept connections and provide printer lists to smbd queries before it had finished loading its own list of printers
<slangasek> but that was years ago, I have no idea if that's a current issue or if there are other issues taking its place
<dholbach> good morning
<pitti> slangasek: speaking about cups, WDYT about bug 140877?
<ubotu> Launchpad bug 140877 in cupsys "new upstream bugfix release 1.3.2 available" [Undecided,New]  https://launchpad.net/bugs/140877
<dholbach> tracker is still slowing the machine down too much :-(
<slangasek> pitti: do either of the microreleases fix my bug? ;D
<pitti> slangasek: nope, I didn't report it upstream yet
<slangasek> aw
<pitti> but they fix mines :)
<pitti> mine, even
<dholbach> slangasek: can you change the importance of bugs already?
<slangasek> dholbach: I think so, haven't tried it yet :)
<dholbach> you're not on the ubuntu-qa team, that's why I thought you might not be able to
<dholbach> I can tell heno and/or bdmurray to add you to that team
<slangasek> ok, no I can't
<dholbach> bdmurray: can you add slangasek to ubuntu-qa?
<slangasek> pitti: this change looks like it might need a closer look?: cupsLangDefault() did not attempt to return a language that was supported by the calling application.
<StevenK> slangasek: Hey. Why the non-vorlon nick?
<slangasek> StevenK: I'm incognito
<StevenK> Not very, since I was able to pick you out of the lineup. :-)
<slangasek> :-)
<pitti> slangasek: just checked this; it only touches appleLangDefault() which we do not even compile
<slangasek> pitti: ok then :)
<pitti> slangasek: version is running happily here, BTW (I am just uploading it to Debian)
<pitti> slangasek: can you please write your formal ack to the bug?
<pitti> (or further questions)
<linuxemacs> does anyone have the typing in caps characters problem?(ubuntu 7.04). i couldn't type caps characters in tty mode.
<linuxemacs> the caps lock led is light, but i couldn't type caps characters.
<linuxemacs> is it a bug of ubuntu 7.04?
<linuxemacs> does anyone can help me?
<dholbach> linuxemacs: I guess you better try #ubuntu+1
<dholbach> hey thekorn!
<linuxemacs> thx though
<thekorn> hi dholbach
<StevenK> dholbach: Why, it's 7.04...
<dholbach> StevenK: good point
<dholbach> linuxemacs: maybe try #ubuntu too
* dholbach didn't sleep enough last night
<kagou> Good morning
<linuxemacs> thanks:)
* pitti gives bzr-svn a big hug
<pitti> wow, the new font rendering after dist-upgrade looks really "wow!"
<StevenK> Wow, bad, or wow, good?
<pitti> good
<pitti> hey seb128
<dholbach> heya seb128
<TomaszD> pitti, hi, carlos told me there's a new URL for gutsy daily language packs, however I cannot find any information on it, could you tell me the URL?
<pitti> TomaszD: they are uploaded straight into gutsy proper
<TomaszD> pitti, ah, thanks.
<carlos> pitti: TomaszD just told me that restricted-manager needs an update in rosetta given that it just changed a string with its latest update
<TomaszD> not *a* string, a hell lot of strings :] 
<seb128> pitti: is that ok if we update libthai 0.1.8 to 0.1.9 (the new version is already in Debian)? The new pango1.0 configure requires 0.1.9
<pitti> seb128: upstream changelog?
<seb128> pitti: I didn't look yet, let me get the version, changelog, debdiff, etc
<pitti> TomaszD, carlos: last r-m did not change any string
<seb128> pitti: I just know that pango can't be updated and that Debian has the new version
<seb128> I'll do that later when I'm done with GNOME 2.20
<carlos> pitti: so the update we did on Monday included already those changes?
<TomaszD> pitti, so why do I have r-m completely in English apart from the deskop entry
<TomaszD> maybe it's just a langpack delay
<carlos> TomaszD: I guess that, yes
<TomaszD> but if the strings haven't changed a bit...
<TomaszD> I don't get it at all now
<TomaszD> is there a public place where I can look up the next langpack upload date?
<pitti> TomaszD: gutsy is auto-updated every Sunday and Wednesday
<pitti> right, current langpacks don't have r-m strings
<TomaszD> Wednesday you say, so today, alright, we'll see if the update contains r-m
<TomaszD> ahh, something to do with main -> restricted move pitti right?
<pitti> yes, that gave some trouble
<TomaszD> this is a serious issue :P
<pitti> oh, bleh
<pitti> rosetta-gutsy-updates.tar.gz -> rosetta-gutsy-2007-09-14.tar.gz
<pitti> carlos: ^
<pitti> carlos: it should point to -18
<TomaszD> doh!
<pitti> carlos: however, rosetta-gutsy-2007-09-18.tar.gz does not have restricted-manager either
<carlos> isn't it still updating the link?
<carlos> :-(
<carlos> grr...
<TomaszD> :[
<TomaszD> well at least you know where the issue is lying
<carlos> ok, I will review it today and make sure it includes that
<TomaszD> another day saved by carlos and pitti, my heroes!
* TomaszD hugs them both
<TomaszD> bbl
<ion_> channel.find_all {|user| user.pirate? }.each {|user| user.yarr! }
<StevenK> ion_: Yarr, walk the plank, ye landlubbing varmit!
<StevenK> *cough* Or something
<maikmerten> (this pirate movie was rated "ARRRRRR!!!")
<StevenK> maikmerten: Booo, hiss!
<maikmerten> :)
<pitti> Keybuk: mmmm new smooth fonts :)
<ion_> Ew! Ew! Ew!
<ion_> Blurry fonts. :-(
<ion_> The full hinting setting isnt respected anymore.
<Keybuk> ion_: check /etc/fonts/conf.d to make sure you haven't hard-nailed it anywhere
<ion_> keybuk: The setting in my Font settings should override that, shouldnt it? Its set to full
<ion_> The fonts looked perfect until last nights updates.
<Keybuk> ion_: not that I know of
<Keybuk> afaik, the conf.d overrides everything
<ion_> Anyway, i havent modified anything in /etc/fonts
<Keybuk> check your dpi is right, set sub-pixel (LCD) and either Full or Slight hinting, depending on personal preference
<ion_> All of that should be correctly set. And if i set hinting off, the change from the current state to no hinting is clearly visible.
<Keybuk> can you nopaste me an ls of /etc/fonts/conf.d
<ion_> Currently it seems like hinting is full using subpixel boundaries, instead of pixel boundaries. Thus, fonts are more blurry than before.
<Keybuk> ion_: that sounds like Subpixel smoothing to me?
<Keybuk> for me, when Subpixel (LCDs) is selected, each of the Hinting options (None thru Full) looks different from the other
<ion_> I definitely agree with using subpixel antialiasing, but not with subpixel hinting.
<pitti> right, here too; they are much smoother, but a bit blurry
<Keybuk> and each looks different from when Smoothing = none
<Keybuk> ion_: uh, there's no such thing as Subpixel hinting
<hunger> Any progress on the open-vm-tools front? It would rock for me to have ubuntu work in a VMware VM out of the box with all the additional magic;-)
<soren> hunger: I've started on the packaging, but there's still a bit of work to do.
<soren> hunger: It's too late for gutsy anyway.
<hunger> soren: I know you started, I am using your debs:-)
<ion_> keybuk: http://pastebin.ca/703001
<soren> hunger: Oh, right :)
<hunger> soren: The modules are missing, but that was to be expected:-)
<soren> hunger: Yes, that's the bit I'm missing.
<soren> hunger: It's waaay to late to build them into l-u-m, but some module-assistant goodness would be a good start.
<Keybuk> ion_: can you take screenshots of the font appearance dialog with each of the options selected for comparison?
* hunger sighs. Having them installed would seriously rock.
<ion_> keybuk: Heres a screenshot of the current fonts: http://heh.fi/tmp/fonts
<soren> hunger: Indeed it would. vmware should stop releasing such things so late in our development cycle :)
<Keybuk> ion_: that looks right to me?
<Keybuk> ion_: the fonts look well-rounded and subpixel anti-aliased
<hunger> soren: Any chance of fixing the xorg-config thingy wrt. the mouse driver? It does set up the display driver properly already.
<Keybuk> with an order of RGB
<ion_> keybuk: When zooming to that, its obvious vertical lines arent distorted to pixel boundaries.
<Keybuk> ion_: ?  zooming in on the L I see
<Keybuk>   <slight red> <black> <slight blue>
<ion_> They bleed to the adjacent subpixels.
<ion_> Thus, blurriness.
<hunger> And the vmmouse driver is already shipped with ubuntu for ages.
<ion_> Ineed. There should be just <black>
<Keybuk> no
<ion_> indeed
<ion_> Thats how it was yesterday.
<Keybuk> there should be what you see
<soren> hunger: I have no clue about that.
<Keybuk> if you want just <black>, you should select greyscale instead
<Keybuk> what you've got there is what subpixel is *supposed* to look like
<ion_> No, i definitely want diagonal and round lines be subpixel antialiased.
<soren> hunger: I've spent very little time on it. If you want to help out, you can start by creating man pages for the binaries in the package.
<hunger> soren: I'll file a bugreport and see what will happen:-)
* soren obeys update-manager and goes for a reboot
<ion_> Horizontal and vertical lines should contain *no* pixels with slight colors.
<ion_> Thats full hinting.
<Keybuk> ion_: that's not what the papers on font hinting says
<Keybuk> http://en.wikipedia.org/wiki/ClearType
<Keybuk> esp. see "The word 'Wikipedia' rendered using ClearType"
<Keybuk> note that it as the same lines either side as you suggest
<ion_> Ive always liked what Linux had much more than ClearType.
<ion_> ClearType used to look more blurry.
<hunger> What package should I report a bug against when my xorg.conf is suboptimal?
<Keybuk> ion_: *shrug* Linux rendered fonts wrong before :p
<hunger> Keybuk: The annoying thing is not that the fonts are rendered wrong, but that ubuntu keeps changing the wrongness all the time;-)
<Keybuk> ion_: you actually really probably just want greyscale
<ion_> I definitely dont want that.
<Keybuk> you do
<ion_> No. :-)
<soren> I have to agree with ion_.. My terminal fonts look slightly blurrier after my reboot. Everything else looks great, though.
<ion_> Horizontal and vertical lines were fully distorted to pixel boundaries, thus there was no blurriness since there were no slight pixels or subpixels between the background and the foreground. Diagonal and curved lines were rendered using subpixel antialiasing. Best of both worlds.
<ion_> Id just like to have a setting to get that back. I dont care if its the default.
<Keybuk> ion_: for a personal preference value of "Best"
<ion_> Indeed.
<Keybuk> we evaluated this by comparing the rendering with other font renderers (ie. PC and Mac)
<ion_> Thus, this is a regression in my personal preference.
<pitti> soren: I tend to agree; however, in terminals I usually prefer 'pixelized and sharp' over 'smooth and blurry', whereas in apps I prefer smooth; but I might just be weird :)
<ion_> The fonts in MacOSX are abominable.
<Keybuk> this now makes fonts look like what they're supposed to look like
<Keybuk> it's not a Terminal so much
<Keybuk> it seems to particularly affect the default Monospace font
<Keybuk> which I agree looks a little too smudged
<pitti> firefox looks absolutely awesome now
<ion_> I really dont care about what a paper says about what fonts are supposed to look like. Id like to have a setting to get the font rendering i had yesterday, thats all.
<Keybuk> adding a setting is almost impossible, since that's a *massive* API change
<ion_> :-(
<soren> pitti: You'd rather be entirely without antialiasing in your terminal?
<ion_> Hopefully someone implements the former rendering algorithm with the new API.
<pitti> soren: I'm not sure, I'm a font noob
<soren> pitti: :)
<pitti> soren: I just know which fonts strain my eyes and which don't
<Mithrandir> soren: my terminal is perfectly happy with pure bitmap fonts.
<Mithrandir> -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 is nice
<ion_> On TFTs, using yesterdays font rendering algorithm is actually sharper than using no antialiasing, since it uses subpixel rendering.
<pitti> and slightly pixelized and sharp seems to be less straining for me
<pitti> when I look at the terminal font now, I have the impression to see red/green glow
<soren> Mithrandir: Which xterm variant do you use?
<Mithrandir> soren: pterm
<soren> Mithrandir: Oh, I see.
<soren> Mithrandir: And that deals well enough with utf8?
<cjwatson> linuxemacs: known bug unfortunately; run 'sudo setupcon' at a virtual console and that will fix it until the next reboot
<Mithrandir> soren: yes.  iso10646-1
<cjwatson> linuxemacs: should be fixed in gutsy
<soren> Mithrandir: Oh, right.
<Mithrandir> soren: I switched from Eterm to pterm partially because the latter dealt with utf8 and the former didn't.
<cjwatson> somebody needs to figure out pterm font handling in the gtk2 branch though
<cjwatson> ideally it would be possible to use both server-side and client-side fonts
<ion_> In this image, its obvious horizontal lines are as sharp as when using no antialiasing, but vertical lines are blurry. http://en.wikipedia.org/wiki/Image:ClearTypePixels.svg
<soren> Mithrandir: I just remember back when I was experimenting with different terms, I found a few that actually rendered them just fine, but most messed up when deleting them again (i.e. removed a byte at a time rather than a character at a time).
<ion_> Diagonal and curved lines are as they should be.
<Keybuk> ion_: random question; did you try changing the subpixel order to match your laptop screen? :p
<pitti> hi tkamppeter
<ion_> keybuk: Its correct.
<cjwatson> linuxemacs: bug 84156
<ubotu> Launchpad bug 84156 in console-setup "Caps Lock not working on TTYs/terminals" [Undecided,Fix released]  https://launchpad.net/bugs/84156
<hunger> Keybuk: How do you find out which order is the proper one?
<Keybuk> hunger: magnifying glass is a good trick
<pitti> mvo: yay, I just (more or less accidentally) enabled compiz again; although it still destroyed my workspace layout, it now at least allows me to manually restore it as I want. That's progress :)
<hunger> Keybuk: My screen has 130dpi... even with a magnifying glass it is pretty hard to detect the proper order;-) So I just turned the whole thing off;-)
<mvo> pitti: oh, what gnome-control-center versin do you have?
<Keybuk> ion_: that image explains quite nicely *why* subpixel smoothing has the lines either side of the black line :p
<mvo> pitti: the 2.20 version should include a patch to get it correct when the apperance capplet is used
<pitti> mvo: 1:2.20.0-0ubuntu1
<ion_> keybuk: In real life, there are thin black bars around pixels. That image doesnt show it.
<pitti> mvo: eek, except that it seems to have killed my custom starter in the panel ('offlineimap' -> '-e')
<ion_> Id guess that emphasizes the blurriness.
<pitti> mvo: s/killed/broke/
<mvo> pitti: could you please comment on #116806 on the layout issue? it is supposed to do the right thing now
<mvo> pitti: like what layout you had before and what after :)
<mvo> pitti: eh, it does not do anyhting with panel launchers, in what way did it break?
<pitti> mvo: that's not the same thing
<pitti> mvo: I had 4 workspaces before and after the switch, but when enabling compiz, all my apps are moved to space 1 and I manually have to move them back
<mvo> pitti: but the layout is preserved?
<Keybuk> ion_: having the dpi set wrong also does; if your screen is 117, 125 or higher dpi and you have it set to 96, for example
<tkamppeter> hi pitti
<ion_> keybuk: My screens DPI is set correctly using the DisplaySize setting in xorg.conf.
<pitti> mvo: the position within the workspace, yes
<Keybuk> ion_: what's it set to?
<ion_>         DisplaySize     472 295
<ion_> (**) NVIDIA(0): DPI set to (90, 90); computed from "DisplaySize" Monitor
<Keybuk> you have an 18.6" monitor?
<ion_> % units 'sqrt((472mm)^2+(295mm)^2)' inch * 21.913578
<ubotu> valid types: mass, length, time, scheduling, temperature, temp. diff., current, charge, potential, resistance, conductance, capacitance, magn. flux, inductance, flux density, molecular qty, size of a mol, lum. intens., luminous flux, illuminance, luminance, angle, solid angle, data, data transfer, quantity, interest rate, concentration, force, area, volume, velocity, rot. velocity, fluid flow, gas flow, pressure, (1 more message)
<ion_> Whoops, irssi merged the lines. * 21.913578 was the output.
<Keybuk> that's still an odd size <g>
<ion_> 22?
<mvo> pitti: ok, thanks. we currently do not support preserving the workspace on switching from metacity<->compiz
<Keybuk> LCD are usually exactly the right size <g>
<pitti> mvo: hmkay
<pitti> mvo: as long as session saving etc. still works, that's good enough
<Keybuk> ion_: so you're using a res of 1600x1000 ?
<mvo> pitti: yeah, session-saving workspaces/viewport layout should all be good now
<ion_> 16801050
<mvo> pitti: but testing is welcome of course :) its just the initial switch that causes this behvaiour, from then on it should be fine
<Keybuk> close enough
<pitti> mvo: hm, my firefox scrollbar (maximized window) does not work
<Keybuk> *shrug*
<pitti> mvo: or, rather, if I grab it on the right hand side (at the edge of the screen) it doesn't
<pitti> that's quite disturbing
<mvo> pitti: but if you have a tiny bit away from the side it does work?
<ion_> keybuk: Just adding one or two millimeters to both measurements makes it 22. There could easily have been such a measurement error.
<ion_> That shouldnt really matter.
<pitti> mvo: not a tiny bit, but if I grab it on the left part of the scrollbar, it works
<pitti> mvo: hm, 5 pixels maybe
<pitti> mvo: i. e. "move mouse to the right", "move it left until the ends of the scrollbars turn orange"
<pitti> mvo: we had a similar bug with the top edge and the Applications menu, didn't we?
<mvo> pitti: oh, that is interessting. out of curiosity, can you reproduce if you login again (so that no metacity->compiz siwthc happend before)?
<pitti> trying
<mvo> pitti: we had a problem that a one pixel area of the screen was always eating events, but that got fixed some weeks ago
<pitti> mvo: it didn't restore my desktop completely (all the terminals are missing)
<pitti> mvo: eek, and resizing windows now neither shows the content (only a blue rectangle) nor snap to borders
<mvo> pitti: the blue rectangle is a feature
<pitti> ??
<pitti> pidgin wasn't restored from the session either
<mvo> pitti: it eliminates a lot of repaint events
<pitti> mvo: ok, the panel starter iz gtk bug (I cannot start mutt with Alt+F2 in a terminal any more either)
<pitti> mvo: but resizing worked just right with metacity
<mvo> pitti:  hm, let me test that session-managment stuff
<pitti> mvo: I'll do a gnome-session-save and check again
<mvo> pitti: it does work under compiz too (resize) but it is slow on some systems
<pitti> mvo: right, on mine for example :) (I filed a bug about that)
<pitti> mvo: no, sorry
<pitti> mvo: after another gnome-session-save, *both* the workspace *and* the positions are wrecked
* ion_ added deborphan support to apt-mark-sync.
<mvo> pitti: I'm back, I just tested it and I can reproduce session save problems
<pitti> mvo: did you get my scrollback?
<pitti> <pitti> mvo: after another gnome-session-save, *both* the workspace *and* the positions are wrecked
<pitti> mvo: and the major problem with resizing windows with just the blue border instead of the window itself is that I cannot see through the original window to see where I should move it to (when making windows smaller)
<ion_> Perhaps the window should be translucent while resizing with the border.
<pitti> that would help
<pitti> and I really miss window/desktop edge snapping
<ion_> Me, too.
<TomaszD> can anyone tell me what else can I do in order to push this bug down the pipe https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/92806 ?
<ubotu> Launchpad bug 92806 in linux-source-2.6.20 "N340S8 laptop needs to have ACPI enabled" [Undecided,Confirmed] 
<TomaszD> I've given all the required information
<TomaszD> maybe I should assign a person who is responsible for acpi, but then I don't know who that may be
<mvo> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/140913
<ubotu> Launchpad bug 140913 in compiz "session save/restore does not work" [High,Confirmed] 
<pitti> mvo: ah, thanks
<pitti> mvo: ah, seb told me why my starter and alt+f2 is broken now, compiz unsets the 'terminal emulator' gconf key; I file a bug
<pitti> mvo: bug 140917
<ubotu> Launchpad bug 140917 in compiz "enabling compiz unsets the "terminal emulator" gconf key" [Undecided,New]  https://launchpad.net/bugs/140917
* pitti hugs mvo for his stamina with fighting this beast
<mvo> pitti: thanks, its a roller coaster ride
<seb128> pitti: ah, you found it ;)
<seb128> ah, no, you opened a new bug
<pitti> seb128: I didn't find an existing one, I'm happy to make mine a dup
<seb128> pitti: bug #135484
<ubotu> Launchpad bug 135484 in compiz "Failed to execute child process "-x" (No such file or directory)" [Medium,New]  https://launchpad.net/bugs/135484
<seb128> pitti: I knew there was one ;)
<seb128> mvo already commented on it
<mvo> seb128: I think I said "meeehhhh"
* seb128 hugs mvo
<pitti> mvo: ok, that looks like a dup indeed; I'll dup mine
<pitti> however, I never deliberately fiddled with the settings; 135484 sounds a bit diffenent, but it's most likely the same cause
<seb128> pitti: already duped it ;)
<seb128> pitti: the guy didn't change his setting neither, he basically says to unset those to be back to a stock config, enable compiz and stop it
<seb128> or it looks like the steps are basically doing that
<seb128> anyway iz compiz bog ;)
<Keybuk> seb128: happily, iz compiz sprint too :)
<seb128> ;)
<siretart> seb128: hi
<seb128> hey siretart
<siretart> seb128: I don't understand the bugtrails correctly. Did you sync live-{helper,initramfs}?
<cjwatson> wah, that's not a good plan
<cjwatson> live-initramfs is casper renamed for no reason. the changes should be merged back into casper
<cjwatson> (where appropriate)
<siretart> cjwatson: I talked to daniel, and he dropped the 'casper' package
<cjwatson> nevertheless, it's duplication
<siretart> so there should be no problem packaging wise
<siretart> cjwatson: err, we had this discussion a few months ago, you remember?
<Keybuk> cjwatson: well, casper does only really exist in spirit now
<cjwatson> there should not be two things in the archive that are basically the same
<seb128> siretart: no, you ask for versions which have replaced since
<seb128> siretart: does the request still stand for the new versions?
<cjwatson> Keybuk: casper still has a lot of code in it. it's totally different from what it used to be, but it's still significant
<cjwatson> siretart: and I never really agreed with you then
<siretart> cjwatson: well, fai does not work with casper. I have been working for over a week testing fai in ubuntu, and that version really needs live-initramfs
<cjwatson> so merge the relevant changes back into casper ...
<cjwatson> live-initramfs is not supported on Ubuntu
<siretart> cjwatson: I agree with you that the 2 branches should be merged. however daniel told me that he didn't find anyone intereted on the ubuntu side to work with
<siretart> cjwatson: last time you agreed to talk to him
<cjwatson> you seem to be interested, and you're in ubuntu-core-dev
<cjwatson> I have no time
<siretart> right
<siretart> and I won't have enough time to do that for gutsy.
<cjwatson> but you have time to create duplication that will be confusing and create an upgrade problem later
<siretart> O'
<siretart> err
<cjwatson> what happens when some other feature works in casper but not in live-initramfs?
<siretart> I'm using packages which are tested and working in debian
<cjwatson> for example, I bet live-initramfs doesn't deal with certain changes that were made in gutsy and required workarounds in casper
<siretart> cjwatson: right. daniel has basically stripped out the ubiquity hooks
<siretart> because he is not interested in that. he focuses  on live-helper
<siretart> a reimplementation of root-live, becuase it was not available
* soren blushes at pitti's kind words to the tb
<siretart> cjwatson: how do you envision collaboration with daniel?
<cjwatson> siretart: I envision somebody who isn't me but who is in ubuntu-core-dev becoming interested
<siretart> in the past, he complained that nobody was answereing him, so he list interest
<cjwatson> at least, somebody who is having trouble with the split ought to help out by merging at least some of the relevant changes
<siretart> cjwatson: I have not really a clue about the inner works of caser/live-initramfs. I'd prefer to focus on fai, which uses what is in debian.
<cjwatson> that's the obvious starting point
<pitti> soren: I think I didn't exaggerate (much)
<cjwatson> I'm afraid I think it is utterly wrong to have live-initramfs in Ubuntu at this point, because it's such clear duplication
<siretart> you are now preventing me from doing fai work in ubuntu :(
<cjwatson> no, I am not
<cjwatson> I'm asking you not to do something that's wrong
<siretart> look,
<cjwatson> please don't make this out as me blocking a specific project
<siretart> I have fai packages ready, which work with newer versions of live-initramfs
<cjwatson> (and in any case I am but one archive admin and not really speaking as one; I'm speaking as a casper hacker)
<soren> pitti: :)
<siretart> I'd like to share my work of the last 2 weeks with our users
<siretart> now you say that I need to work on casper as well, because of code duplication
<cjwatson> I understand, but I would like to avoid a situation where some users have to use casper and some have to use live-initramfs and neither really works properly
<cjwatson> that seems just obviously wrong
<siretart> this means that fai won't be ready in time for gutsy
* Keybuk notices the date
<StevenK> Hum. Does the installer (on sparc) default to serial console?
<siretart> cjwatson: would you accept the following compromise: let's have a FAI bof in boston, where we discuss casper/live-initramfs matters. for gutsy, lets accept the duplication with the intention to fix that for hardy
<cjwatson> siretart: if live-initramfs goes into Ubuntu, a critical bug should be filed on it saying that it shouldn't exist
<soren> Keybuk: hm?
<cjwatson> siretart: on the condition that live-initramfs doesn't go into main
<siretart> cjwatson: that's fine for me, as long we don't need to fix it for gutsy
<cjwatson> ok
<siretart> cjwatson: of course
<siretart> cjwatson: fai is universe only anyway
<cjwatson> ok
<Keybuk> soren: Yarr, it be talk like a pirate day
<soren> Shiver me timbers, so it is. Yarr..
<siretart> seb128: can't you sync from snapshot.debian.net then?
<siretart> or from the morgue mirror on merkel?
<cjwatson> we can sync from anything
<seb128> siretart: we can sync from anything, I was asking if you want to the new version or the old one
<seb128> siretart: if you want the old one please provide a url to the dsc
<siretart> seb128: I'm pretty confident that the newer version in unstable still work
<cjwatson> StevenK: AIUI (and the installation guide agrees) the kernel's normally supposed to autodetect serial console presence, but if you also have a normal console attached you might have to pass console=ttyS0 to the kernel
<siretart> so I'd vote for getting the currently up-to-date versions. it's just that I haven't tested them, but the diffs look sane to me
<cjwatson> or maybe ttya or ttyb
<StevenK> cjwatson: Ah. I don't want it to use serial console - OpenBoot and 'boot cdrom' works with the screen and keyboard, but as soon as the kernel boots, the monitor goes into standby mode, which makes me suspicious.
<cjwatson> StevenK: I'm not sure what the reverse override is
<siretart> seb128: would you agree to sync the up-to-date versions? I promise to look after breakages
<seb128> siretart: well, we are in UVF period now, I would prefer to have pitti to approve those
<seb128> or somebody else from r-t
<siretart> seb128: both are universe, and I have exception from the motu-uvf team
<seb128> ok, good enough then
<StevenK> cjwatson: Appending 'console=tty0' had no effect, either. :-/
<cjwatson> Riddell: I'm rebuilding some CDs now to cope with some mirror sync lock failures
<seb128> siretart: can you add a comment on the bug saying we should sync the new version?
<siretart> seb128: done
<seb128> siretart: thanks
<siretart> seb128: thank you for syncing them!
<cjwatson> asac: bug 139403> so this is agreed to be the best route? how are we handling upgrades?
<ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [High,Confirmed]  https://launchpad.net/bugs/139403
<asac> cjwatson: its in the bug
<asac> cjwatson: i discussed with mvo
<asac> cjwatson: the most reasonable practice appears to be to assume that users that had network-manager installed with auto dhcp interfaces
<asac> cjwatson: want those interfaces to be managed through nm
<cjwatson> asac: commenting out the iface lines seems like an odd approach; that means you can no longer work around n-m problems using ifup/ifdown by hand
<cjwatson> why not comment out the auto lines instead?
<mjg59> Riddell: What's supposed to handle brightness changes in Kubuntu?
<asac> cjwatson: because then those interfaces are not nm managed
<asac> cjwatson: we could have that by just migrating nothing
<tkamppeter> pitti, seems that Mike Sweet has replaced my perfectly working workaround by a totally broken fix (bug 140887)
<ubotu> Launchpad bug 140887 in cupsys "system-config-printer.py crashed with ValueError in reinit()" [High,Confirmed]  https://launchpad.net/bugs/140887
<asac> cjwatson: but that would be a regression for all users that currently use the auto line + nm combination
<pitti> tkamppeter: is the fix itself not working? or is it just causing the s-c-p crash?
<asac> cjwatson: imo its the most unintrusive migration path we can provide ... its a damn good point to assume that people with network manager + auto dhcp lines currently use nm for those interfaces successfully
<fabbione> cjwatson: what's the perl equivalent for if [ -d /boot ] ; then.... ?
<cjwatson> asac: hmm, well, we can try it out for beta and see how many people scream
<cjwatson> fabbione: if (-d "/boot") { ... }
<fabbione> cjwatson: thanks a lot
<cjwatson> asac: so, just to be sure, I should not write out either auto lines or iface stanzas for things that are going to be auto dhcp?
<asac> right ... installs that come up with network-manager installed by default should stop shipping those
<cjwatson> ah yes, hmm, that's the slightly tricky bit
<cjwatson> should be possible though
<tkamppeter> pitti, the fix itself I did not test. I am now making a new cupsys package with the fix unrolled and my workaround put back. Then I will try whether it works.
<Riddell> mjg59: nothing.  kmilo is our special key handler but it doesn't have anything for
<Riddell> brightness
<pitti> hi Riddell
<Riddell> hi pitti, are you doing release management?
<cjwatson> asac: netcfg (in d-i) asks for the wireless ESSID; I guess all that does now is influence what happens during the installer, and then it gets discarded
<cjwatson> asac: how about if netcfg has asked for a WEP key?
<cjwatson> does the user just have to re-enter that later?
<cjwatson> 11:51 <cjwatson> asac: netcfg (in d-i) asks for the wireless ESSID; I guess all that does now is influence what happens during the installer, and then it gets discarded
<cjwatson> 11:51 <cjwatson> asac: how about if netcfg has asked for a WEP key?
<cjwatson> 11:51 <cjwatson> does the user just have to re-enter that later?
<mjg59> Riddell: Ok. That kind of needs fixing.
<pitti> Riddell: together with slangasek for beta
<asac> cjwatson: yes ... unless you are smart and add that info to gconf ;)
<mjg59> Riddell: Lots of machines won't do anything without an agent handling that
<Riddell> mjg59: what happens in gnome?
<Riddell> pitti: is dapper.2 happening?
<asac> cjwatson: but i am not sure if we want this ;)
<cjwatson> sounds nasty
<mjg59> Riddell: gnome-power-manager handles it
<pitti> Riddell: -> /query
<Riddell> mjg59: are you coming to UDS?  can we spec it there?
<mjg59> Riddell: Yeah, but it's going to be broken for people in gutsy
<asac> cjwatson: i think adding the essid together with the key would make nm autoconnect to that network when its available
<asac> (to gconf)
<cjwatson> asac: actually, if you put that ifblacklist_migrate script in network-manager, I could just have the installer run it
<cjwatson> which would do the job in d-i without having to rewrite all that code
<cjwatson> thing is I can't easily tell at the point when /etc/network/interfaces is first being written whether network-manager is going to be installed
<Riddell> mjg59: but not more so than in past releases presumably
<cjwatson> so I basically have to do a migration anyway
<mjg59> Riddell: Yeah, due to (a) more machines now implementing the ACPI video extension, and (b) us no longer changing it automatically in-kernel (because that just ends up breaking things in stupid ways)
<asac> cjwatson: ok, thats sane.
<cjwatson> asac: can I rely on /usr/lib/network-manager/ifblacklist_migrate.sh?
<asac> cjwatson: however if you add an option to the interface entry, the script will not comment it
<asac> e.g. for wep-key case
<cjwatson> or indeed essid
<asac> cjwatson: otherwise your script should be as simple as commenting out every line ;)
<asac> cjwatson: if you want i can provide that ;)
<StevenK> Hum, bugger.
<cjwatson> that will be present for all installs where wireless was the primary interface
<cjwatson> so I think you need to handle that anyway ...
<cjwatson> maybe *you* need to do the gconf migration :-)
<asac> ouch :) ... but please not for beta
<StevenK> console=tty0 has no effect
<cjwatson> asac: I think I'll just call ifblacklist_migrate.sh and you can deal with further migrations as necessary
<cjwatson> ubiquity will just leave out the stanzas entirely, or only write them out commented out
<cjwatson> so it won't affect desktop CD installs
<asac> cjwatson: ok ... please set an env INSTALLER_MODE or something
<cjwatson> asac: I'll set NETCFG=1
<cjwatson> since that's the name of the installer component
<asac> ok fine.
<cjwatson> asac: why 'sh /usr/lib/network-manager/ifblacklist_migrate.sh'? Why not just make it executable?
<asac> cjwatson: well :) ... its not ment for public use, so i didn't bother about that
<asac> cjwatson: do you want it executable?
<cjwatson> asac: don't mind, just seems like an obvious thing to do
<cjwatson> I generally think programs shouldn't have implementation-specific extensions and shouldn't be called with explicit interpreters, so that if you want to rewrite them in another language then you can
<asac> cjwatson: yeah ... if i make it executable i should also drop .sh
<cjwatson> asac: hang on, I just realised I don't need to do anything at all in d-i
<asac> huh?
<asac> yes right :) ... i can use NETCFG
<cjwatson> asac: we copy /etc/network/interfaces in before the base system install starts; you run ifblacklist_migrate on network-manager configure with a condition that includes being installed from scratch
<asac> cool
<cjwatson> no, netcfg doesn't need to change at all
<cjwatson> you just do it all yourself, which is exactly how I like packages to behave
<asac> cjwatson: yes, thats the INSTALLER_MODE env i referred to above
<cjwatson> nope
<cjwatson> don't need that either
<cjwatson> if you need anything like that, just check whether you're being installed from scratch
<asac> cjwatson: you mean if no version was installed before?
<cjwatson> dpkg --compare-versions "$2" "<<" 0.6.5-0ubuntu12 is true in the installer because no version was previously installed
<cjwatson> so network-manager will run ifblacklist_migrate.sh all by itself
<asac> cjwatson: maybe thats a bug ... i don't know if thats what we want ... if people install network-manager later it shouldn't touch /e/n/i
<asac> cjwatson: don't you thinks so?
<jsgotangco> aarrrrr mateys
* Riddell remembers he's on holiday and goes to the beach to hunt pirates
<mvo> have fun Riddell
<asac> cjwatson: i just want to migrate people away from buggy behaviour ... not force network-manager on previously configured devices.
<cjwatson> asac: hmm, well, if you need to check whether the installer is running, maybe check whether the MENU environment variable is set?
<asac> hmm ... that env sounds a bit ambiguous ;)
<asac> no idea if any other application uses
<soren> cjwatson: Does ubuntu-seeds.pl from tasksel not support multi-lined extended descriptions?
<asac> cjwatson: any other env var available ;)? otherwise i would go for MENU now. is that available in both: alternate and ubiquity?
<cjwatson> soren: doubt it, feel free to make it
<cjwatson> asac: ubiquity isn't relevant; network-manager's postinst is not called by ubiquity
<soren> cjwatson: Theme of the day, it seems :)
<mvo> ogra: you have a ati 200m or something, right?
<mvo> ogra: I would need some compiz testing on this .) ?
<asac> cjwatson: ok so this discussion is just about alternate?
<cjwatson> asac: problem is that most of the other relevant ones are also used by debconf
<cjwatson> asac: yeah
<cjwatson> ubiquity's easy, not concerned about that
<asac> cjwatson: any ideas for ubiquity install?
<asac> cjwatson: oh ok.
<asac> cjwatson: can you give a hint so i can summarize our findings in the bug?
<cjwatson> asac: I mean, you could check [ "$DEBIAN_FRONTEND" = passthrough ] , but that's not really terribly accurate
<asac> cjwatson: maybe we can set a more distinct env? or do you consider that too much for _just_ network-manager tweakage?
<cjwatson> I sort of dislike the notion of postinsts knowing they're running in the installer
<cjwatson> it opens up possibilities of difficult-to-reproduce behaviour
<asac> thats true, then back to square 1 ;)
<cjwatson> ok, how about you change that << to lt-nl then, and I make netcfg call ifblacklist_migrate.sh
<ion_> Back to 1
<asac> cjwatson: ok ... so i test for NETCFG?
<cjwatson> what are you going to do within that test that isn't appropriate for general use?
<asac> cjwatson: what do you mean by general use?
<cjwatson> being run on upgrades
<ogra> mvo, oki, give me some time to finish here (guessing i need to log out
<ogra> )
<asac> cjwatson: i disable auto dhcp interfaces?
<cjwatson> err, but don't you do that anyway on upgrades?
<cjwatson> asac: I think there may be some confusion about what's happening when
<asac> cjwatson: i only migrate when upgrading from a version that managed auto dhcp
<cjwatson> asac: my proposal is that your postinst is changed to only run the migrate script on upgrades, not on fresh installs; then at a *later* point in the installer I separately run the migrate script
<asac> ok
<cjwatson> so you only need to have a special test if the migrate script is going to do something different on fresh installs than on upgrades
<cjwatson> not for whether it's to be called at all
<asac> yes, thats what i understood from: "change that << to lt-nl"
<cjwatson> asac: ok, so given that we arrange for the migrate script to be called in both cases, does it need to act differently on fresh installs than on upgrades
<cjwatson> ?
<asac> oh ... right ;)
<asac> yes, just postinst is changed to not run it on fresh installs
<asac> cjwatson: 1. use lt-nl in postinst to test whether to run script; 2. run migrate script in netcfg -> done.
<asac> cjwatson: is that what you mean?
<ion_> Whee, a new version of openoffice.org-voikko in the updates. Its postinst actually succeeded. :-)
<cjwatson> asac: exactly. This is the netcfg change: http://codebrowse.launchpad.net/~ubuntu-core-dev/netcfg/ubuntu/revision/606?start_revid=605
<Keybuk> grr, silly network
<cjwatson> (except you need to click through to see the new finish-install script)
* Keybuk shakes a fist at elmo and his ESSID-per-desk policy
<cjwatson> http://codebrowse.launchpad.net/~ubuntu-core-dev/netcfg/ubuntu/annotate/606?file_id=finishinstall-20070919112720-34axn8w2kk8li73w-1
<asac> cjwatson: for now that would be fine ... only point is see is that i might want to do something special during install for essid/wepkey ... like discussed above
<cjwatson> asac: ok, I'll set NETCFG=1 in that finish-install script then
<asac> cjwatson: but actually i can do the negative test. e.g. postinst script sets a special environment ... not the installer
<asac> cjwatson: so no need to set NETCFG=1 if its not set anyway.
<cjwatson> well, I just committed it ...
<asac> ;)
<cjwatson> but I can revert it if you prefer it that way :)
<cjwatson> TBH I think you should probably do the ESSID/WEPkey thing on upgrade too
<cjwatson> it seems obviously useful
<asac> cjwatson: why? people that have that atm, don't use network manager for those interfaces
<asac> just migrating them to network-manager would be a regression imo
<cjwatson> hmm, ok
<cjwatson> I'll just upload this with NETCFG=1 in; if you prefer to set an environment variable in your postinst, please just do that and let me know
<asac> ok thanks.
<asac> cjwatson: fyi, when this is done, we can finally fix bug 128316 in a clean fashion
<ubotu> Launchpad bug 128316 in network-manager "n-m should not tear down interfaces during shutdown" [Medium,Triaged]  https://launchpad.net/bugs/128316
<ogra> pitti, ping
<pitti> hey ogra
<tkamppeter> pitti, I have made new CUPS packages now where I went back to my workaround. See bug 140887
<ubotu> Launchpad bug 140887 in cupsys "system-config-printer.py crashed with ValueError in reinit()" [High,In progress]  https://launchpad.net/bugs/140887
<pitti> tkamppeter: oh, if you think that's the best solution?
<seb128> pitti: http://people.ubuntu.com/~seb128/libthai.debdiff http://people.ubuntu.com/~seb128/libthai.diffstat http://people.ubuntu.com/~seb128/libthai.ChangeLog
<pitti> tkamppeter: certainly good for me as a workaround, but Tim's plan sounds better to me in the long run
<seb128> pitti: the package has already migrated to testing in Debian
<seb128> pitti: and pango wants 0.1.9
<cjwatson> asac: all my bits of it are uploaded now
<tkamppeter> pitti, yes, assuming that Mike's change is really correct. And independent of this Tim's changes will stabilize systemn-config-printer against possible inconsistencies in CUPS.
<pitti> tkamppeter: I agree, it's a good enough workaround for gutsy
<ogra> mvo, so what do you need from me ?
* ogra has edubuntu meeting starting i 5min
<mvo> ogra: the .xsession-erros output of it if you try to start compiz
<mvo> ogra: compiz --replace
<mvo> ogra: the output of this
<mvo> ogra: but its not urgent, you can do it after the meeting of course
<pitti> seb128: looks quite intrusive, but since saying 'no' is not really an option, we should rather test it before; ArneGoetje, asac, you use libthai in your projects, right?
<tkamppeter> pitti, my new CUPS package also contains another fix. The HP LaserJet 2600n was not discovered. As it is a cheapo color laser it does not support SNMP, only mDNS/DNS-SD/Zeroconf.
<tkamppeter> I have written a little Perl program which discovers such printers scanning via DNS-SD. I have added it to my new cupsys packages and now the CLJ 2600n gets discovered perfectly.
<ogra> mvo, http://paste.ubuntu-nl.org/37898/
<pitti> tkamppeter: just keep in mind that we are in feature freeze :)
<mvo> ogra: could you please also pastebin the output of lspci?
<mvo> ogra: that looks good btw :)
<pitti> seb128: Debian PTS looks reasonable though, so please go ahead and sync it
<mvo> ogra: and lspci -n
<seb128> pitti: thanks
<tkamppeter> The backend should not break anything, as it is only run when creating a new queue, not when printing. And the old SNMP backend I did not disable, just in case there is an old printer with SNMP but without DNS-SD.
<ogra> mvo, http://paste.ubuntu-nl.org/37899/
<ogra> mvo, it behaves like it should
<mvo> ogra: thanks a lot, that makes me happy
<ogra> me too :)
* asac hugs cjwatson 
<ogra> i only saw it misbehaving very recently before one of the last upgrades ... beyond that i didnt have probs for the whole release :)
<asac> pitti: seb128 whats the case with libthai?
<pitti> asac: we need the new version from unstable/testing
<pitti> asac: 0.1.9
<pitti> asac: so it would be nice if you could give this a test (you needed it for tbird AFAIR?)
<seb128> asac: libpango 1.18.2 requires 0.1.9 and we have 0.1.8 at the moment
<asac> pitti: ffox needs it
<TomaszD> bryce, remember me yesterday with the sis driver issue? I noticed that there was the same *exact* issue when moving from... wait for it... hoary to breezy!
<TomaszD> http://ubuntuforums.org/showthread.php?t=95771
<asac> seb128: ok ... i will take a look
<pitti> asac: thanks
<seb128> asac: thanks
<pitti> tkamppeter: ok for the replacement of the patch, but dnssd is too much of a new feature for my taste
<TomaszD> "SiS DRI driver expected DDX version 0-0.8.x but got version 0.7.0", now it's 0.7.1
<pitti> tkamppeter: I'm happy to commit the change to Debian, though, so that it doesn't get lost
<TomaszD> I really wish this would work ...
<bigon> hi, are build attempts with the Chroot problem status tried again later?
<mvo> pitti: I think I have a patch for the gnome-terminal problem thing, if you can still reproduce it, I would be happy if you could test a new pacakge
<pitti> mvo: off for lunch, but I'm happy to give it a try when I'm back *hug*
<tkamppeter_> pitti, so take only the DNS-SD stuff into Debian, and leave the patch rollback alone. For DNS-SD discovery in Ubuntu Gutsy it is too late. Let's see whether Mike has a solution in 6 months (CUPS 1.4?) and if not, how my scripts is working in all the other distros which will come out and put all this experience in. Perhaps we will even have to look into a hybrid "network" backend taking together all network scanning methods to avoid du
<tkamppeter_> plicate entries in the output.
<pitti> tkamppeter_: sounds like a plan
* pitti -> slightly longer lunch break, bbl
<tkamppeter_> pitti, Tim Waugh has already done the fix on the s-c-p side and I will package this now. For Ubuntu consider cupsys-1.3.2-1ubuntu1 as final-
<asac> pitti: seb128: appears to be compatible as a drop-in replacement (ABI) ... will do a rebuild of firefox with the new -dev to be sure; but looks good so far.
<seb128> asac: cool, thanks
<asac> seb128: ok ... its building ... so after lunch i will have results ;)
<Kopfgeldjaeger> hi
<cjwatson> bigon: they need to be given back by hand, but typically buildd admins sort this out on their own, yes
<bigon> cjwatson: thx
<TomaszD> bryce, I'm currently compiling the git version of the driver and we'll see how it goes from there
<cjwatson> argh libgcrypt pain and suffering
* cjwatson beats it into not linking against libnsl on Linux
<TomaszD> bryce, current git version of xorg-video-sis fixes the issue, I have working DRI in gutsy now
<TomaszD> sweet
<asac> seb128: pitti: libthai 0.1.9 looks good here
<bddebian> Heya
<bddebian> seb128: Thanks for the syncs
<Lure> mjg59: what is missing for brightness in kde? I could look into it, but do not have HW for testing
<bddebian> seb128: For toshutils though, I was just trying to get the FTBFS fixed without bringing over a new version this close to release.  Do I need to bring over the new version? Thx
<soren> cjwatson: My perl-fu is weak. Could you take a peek at http://people.ubuntu.com/~soren/multiline-ext-desc.diff ?
<siretart> cjwatson: ok, I've just had a phone conversation with daniel about a potential casper/live-initramfs merge
<siretart> cjwatson: he is willing to cooperate, but is strongly suggesting to merge casper into live-initramfs, becuase of several issues
<cjwatson> soren: looks fine to me
<cjwatson> siretart: we can't possibly do that for gutsy, and I still object to the spurious renaming
<siretart> cjwatson: I'll investigate his arguments and will compare the two packages
<siretart> cjwatson: then we can consider which way we want to go for hardy
<cjwatson> ok
<siretart> cjwatson: of course, I'm talking about hardy, not gutsy
<soren> soren: Alright, I'll assume that's what we'll do then in the tasks I'm finalising right now. Will you roll the patch into the next tasksel upload? (Don't bother with it just yet, as I hope to add some tasks later today.)
<siretart> .oO( soren talking to himself? )
<soren> arh, fsck
<siretart> ;)
<soren> cjwatson: Alright, I'll assume that's what we'll do then in the tasks I'm finalising right now. Will you roll the patch into the next tasksel upload? (Don't bother with it just yet, as I hope to add some tasks later today.)
<soren> siretart: Too much stuff going on :)
<cjwatson> soren: sure, will do
<soren> cjwatson: rock, thanks.
<cjwatson> just testing it
<pitti> asac: libthai> thanks for testing
<superm1_> mvo, during an update-manager -d -c, have you considered exporting a noninteractive debian frontend?
<superm1_> on a fresh feisty install, its appearing like several items wanted input in the "terminal" part of the dist-upgrade window
<soren> cjwatson: I've used it here: http://codebrowse.launchpad.net/~shawarma/ubuntu-seeds/ubuntu.gutsy.server-tasks/annotate/soren%40ubuntu.com-20070919131654-yctbc5zs972cc1eu?file_id=postgresqlserver-20070919110454-e6hey8hrnau5s8g0-1
<soren> loggerhead url's for the lose :(
<cjwatson> you can replace the ids by revision numbers by hand and it still works
<cjwatson> the problem is that it doesn't use them by default
<Kano_ubuntu> hi, just found a simple workaround for my X700 SE card. the ati driver does not work for it, but you could add a line to use radeon directly
<soren> cjwatson: oic
<Kano_ubuntu> 01:00.0 0300: 1002:5e4f
<Kano_ubuntu> ATI Technologies Inc RV410 [Radeon X700
<Kano_ubuntu> the pci.ids is not fully correct, it is X700 SE
<Kano_ubuntu>         10025e4f        video   Server:XFree86(ati)     RV410 [Radeon X700] 
<Kano_ubuntu> change this to radeon please
<Kano_ubuntu> discover1-data, pci.lst
<tormod> Kano_ubuntu: that would be a bug in the ati driver
<mvo> superm1_: no, I export gnome as the frontend
<superm1_> mvo, that's odd, i'll have to file a bug.  it was for sure coming as a dialog frontend
<mvo> superm1_: ok, please do that I would like to investigate that
<superm1_> mvo, one more thing: i noticed that the app i was looking for from that previous email to you (mythbuntu-control-centre) got added to the list in g-a-i, but so did an unwanted app (ubiquity-frontend-mythbuntu).  how can I get that off the list in there?
<hunger> Would you please keep tracker a recommends? It gets started in addition to strigi in a kubuntu system with ubuntu-desktop added and running two search thingies is really expensive.
<mvo> superm1_: that was a oversight by me, I can fix that now
<hunger> And I can no longer just uninstall it:-(
<superm1_> mvo, okay cool thanks.  i'm going to let this dist-upgrade finish with the dialog issue before filing a bug.  any particular logs you're looking for?
<Kano> btw. why dont you switch to aufs? your last daily amd64 live from kubuntu is fully broken
<mvo> superm1_: generally everything that is in /var/log/dist-upgrade/*
* superm1_ nods.  okay thanks mvo :)
<mvo> superm1_: thanks, ubiquity-mythbuntu.desktop  removed now
<hunger> Hmmm... why are all the libs I updated since yesterday all of a sudden marked as manually installed in aptitude?
<tkamppeter> pitti, I have now packaged Tim's fixes for bug 140887
<ubotu> Launchpad bug 140887 in system-config-printer "system-config-printer.py crashed with ValueError in reinit()" [High,Fix committed]  https://launchpad.net/bugs/140887
<asac> pitti: found some time to verify ifupdown?
<pitti> tkamppeter: ah, great! I'll look at it and sponsor it
<pitti> asac: oh, right; will do
<cjwatson> soren: committed your tasksel patch
* Keybuk tries to figure out how to print a test page
<pitti> Keybuk: system -> printing should offer you one
<pitti> Keybuk: alternatively, cups' web interface
<Keybuk> it doesn't
<pitti> uh?
<Keybuk> in fact, system -> printing doesn't exist
<pitti> well, system -> admin -> printing
<ogra> it exists for me
<pitti> aka system-config-printer
<Keybuk> that gives me a tree on the left with three options
<ogra> but i dont get any details about my tw configured printers
<Keybuk>   Server Settings
<ogra> *two
<Keybuk>   + Local Printers
<Keybuk>     WorkCentre-7245
<Keybuk> on the right is a pane with "Basic Server Settings"
<Keybuk> clicking on anything in the tree on the left seems to have no effect
<ogra> right, same here
<pitti> Keybuk: right; the printer should be selected by default, and there should be a "test page" button
<Keybuk> nope
<Keybuk> server settings was selected by default
<ogra> not here either
<ogra> navigating the treeview has no effect at all
<pitti> tkamppeter: ^ hmm
<ogra> should anything in the server settings be checked ?
<ogra> i have not one checkmark
<pitti> it works just fine here
<pitti> ogra: not by default
<ogra> ok
<pitti> ogra: but I enabled sharing/browsing here
<ogra> ugh
<ogra> now it crashed
<pitti> http://people.ubuntu.com/~pitti/tmp/scp.png
<pitti> Keybuk: ^ that's what I see when I start s-c-p
<ogra> if i check the first option "Zeige freigegebene Drucker anderer systeme"
<ogra> is that browsing ?
<ogra> if i check that and click apply it crashes
<pitti> ogra: right
<pitti> well, I have the very latest cups/s-c-p/python-cups crack here
<Keybuk> pitti: that's not what I see
<pitti> the previous s-c-p just crashes right on start, due to a slightly changed behaviour of cups
<tkamppeter> pitti, what do you mean with your last message to me?
<ogra> i updated my system when mvo asked for compiz tests
<pitti> tkamppeter: have you ever heard this behaviour?
<pitti> ogra, Keybuk: do you have cups 1.3.0 or 1.3.2?
<Keybuk> pitti: http://people.ubuntu.com/~scott/scp.png
<ogra> (two hours ago according to the backlog)
<Keybuk> pitti: 1.3.2
<tkamppeter> pitti, I will test this one.
<ogra> ah, this time it didnt crash
<seb128> asac: thanks
<seb128> bddebian: what?
<Keybuk> pitti: 1.3.0 got upgraded today?
<pitti> Keybuk: can you please test with the new python-cups and s-c-p on http://people.ubuntu.com/~pitti/tmp/ ?
<ogra> hmm, trying to disable it crashes again
<Keybuk> I haven't logged out or rebooted since then
<pitti> Keybuk: cups was upgraded yesterday
<tkamppeter> And note that there is the Printing Summit next week, so stop finding bugs in s-c-p until the end of this week. I will also meet Mike Sweet on the Summit, and hope this does not make CUPS-1.3.2-debugging Summit out of it.
<davmor2> pitti: Keybuk ogra I just logged on to say it is broke completely here s-c-p
<pitti> Keybuk: no need to reboot or logout
<Keybuk> pitti: I mean to say that I *got* the update today
<pitti> davmor2: known, bug 140887
<ubotu> Launchpad bug 140887 in system-config-printer "system-config-printer.py crashed with ValueError in reinit()" [High,Fix released]  https://launchpad.net/bugs/140887
<pitti> davmor2: (I assume)
<Keybuk> pitti: I cannot test the python-cups at that URL
<pitti> Keybuk: hm, i386?
<Keybuk> aye
<pitti> http://www.linux-foundation.org/~till/tmp/ubuntu/gutsy/python-cups/binary/python-cups_1.9.27-0ubuntu1_i386.deb
<davmor2> pitti: different traceback but certainly sounds the same
<davmor2> I'm on 64bit
<pitti> davmor2: feel free to test above packages, too
<pitti> tkamppeter: stop finding bugs> we'll do our best :)
<ogra> pitti, works
<pitti> ogra: \o/
<ogra> :)
<pitti> tkamppeter: anyway, if we find something small, s-c-p is not exactly hard code; I think I can manage
<ogra> i still find the UI scary though
<davmor2> pitti: is there a 64 bit version there too?
<Keybuk> pitti: new packages worked
<pitti> davmor2: http://people.ubuntu.com/~pitti/tmp/
<Keybuk> though the default selection was still Server Settings
<Keybuk> but clicking on the printer gave me a useful right pane this time
<pitti> davmor2: python-cups_1.9.27-0ubuntu1_amd64.deb  and system-config-printer_0.7.75+svn1557-0ubuntu1_all.deb
<pitti> Keybuk: hm, can you please file a bug about the default selection, with your /etc/cups/printers.conf? it's supposed to work
<Keybuk> pitti: ok
<davmor2> pitti: That's working :)
<pitti> awesome
<tkamppeter> pitti, for me the newest s-c-p and your cupsys 1.3.2-1ubuntu1 work perfectly together. My default printer (on a remote server, broadcasted to my local box) is selected and clicking on a printer I get immediately the printer properties on the right. I also do not get crashes when changing the server settings.
<pitti> tkamppeter: likewise here
<davmor2> pitti: My wife's feisty machine still can't locate the printer.  I've checked on my gutsy laptop too and it's not showing up there either
<pitti> davmor2: but you did enable the sharing/
<pitti> ?
<davmor2> Yes do I need to re-enable it the tick boxes are all ticked
<pitti> davmor2: all? really? that's a bit much
<davmor2> just switch some of them off :) I was just making sure that I covered all the bases
<pitti> asac: ifupdown> quite a complex change; it isn't enough to hardwire the '100' default somewhere?
<pitti> davmor2: the first two should be enabled, the others are crack
<asac> pitti: its not that complex ... it just honours if you have metric manually configured
<davmor2> pitti: done
<pitti> asac: right, but the code for that should already be there surely?
<pitti> asac: after all, 'metric 500' should work with the current version?
<asac> pitti: unfortunately not
<asac> pitti: there is no default mechanism
<asac> pitti: in code ... so i tried to implement that as unintrusive as possible (e.g. going through all set options and see if a metric is configured)
<davmor2> pitti right got it now :)#
<asac> pitti: what do you mean with metric 500?
<pitti> asac: I mean, there is certainly code to set the metric if it is explicitly set, and I assume it uses a variable; can't we just pre-set this variable?
<pitti> asac: metric 500> just an example of a nonstandard setting in /e/n/i
<davmor2> pitti: will that updated package make it in before beta testing starts?
<pitti> davmor2: sure, I uploaded it 30 minutes ago
<davmor2> pitti: cool
<asac> pitti: the option parsing is generated by perl ... we would need to extend that in a general fashion (e.g. allow to configure default options) ... which is currently not implemente
<pitti> asac: ooh, I see
<asac> pitti: so in the end the change i do is less-intrusive imo
<pitti> asac: right, just trying to understand the approach; it looks good, I was just curious whether it's possible to simplify it
<pitti> dhclient3 [[-e IF_METRIC=%metric%] ] 
<asac> pitti: but granted, i am not a web guru ... but it parses the perl parses option description
<pitti> asac: what does that syntax do?
<asac> from what i understand it will omit that block if %metric% is not set
<davmor2> pitti: what exactly does the refresh button do?  I had to restart cups from cli for it to register.
<asac> pitti: same as for the static variant
<pitti> davmor2: not 100% sure, but I guess it re-queries cups for new printers and manually changed options
<davmor2> pitti: right so it doesn't refresh the server then?  It is a little odd it being next to the server button then :(
<pitti> davmor2: no, it just reloads the values in s-c-p from the server; "apply changes" reloads the server
<davmor2> pitti: in that case it isn't as soon as I did sudo /etc/init.d/cups restart the printer showed up on the laptops until then nothing.
<davmor2> pitti: or does it update the server without restarting it?
<pitti> davmor2: it does, it uses the equivalent of /etc/init.d/cupsys reload
<pitti> davmor2: NB that printers are only broadcast out every 30 seconds, so it might take a while
<bryce> tormod: I ran across a similar issue yesterday - the problem was blamed on mixing packages from Ubuntu with ones locally compiled
<pitti> 0.0.0.0         10.28.130.1     0.0.0.0         UG    100    0        0 eth0
<pitti> asac: ^ yay
<asac> pitti: you have a wireless in proximity?
<pitti> asac: not on my desktop
<asac> so you can test how well it takes over your route, while you are still connected?
<asac> oh ok
<pitti> asac: let me build this stuff on my laptop and try it there with wifi+eth
<asac> yep
<tkamppeter> pitti, the "Apply" button on the server settings page sends an IPP request for the option changes to the CUPS server, the same as the cupsctl command does. The scheduler changes the options in the config files then and re-initializes itself.
<pitti> asac: unfortunately I can't get wired and wireless at the same place :/ (signal is too weak at my desk)
<asac> pitti: is obvious ... for now keep some bogus option or static for eth ... so its not nm managed ;)
<asac> pitti: hmm
<tkamppeter> The "Refresh" button simply re-reads the server options and the list of available printers.
<pitti> asac: ah, right, and set a gateway there
<asac> pitti: you can use iface eth0 inet dhcp
<asac>    bogusoption
<asac> as well
<tkamppeter> To be allowed to use the "cupsctl" command or to change the server settings with s-c-p it is enough to be in the "lpadmin" group.
<davmor2> pitti: Right okay thanks again
<pitti> asac: 'metric 499' in /e/n/i also works fine here
<seb128> pitti: so we can sync libthai, right?
<pitti> seb128: yep
<seb128> thanks
<asac> seb128: for me its ok
<seb128> asac: thanks for testing
<tormod> bryce, what issue? sorry I lost the context
<adnarim> hi
<bryce> tormod: ah sorry, that was for TomaszD; bad tab complete.  nevermind.
<adnarim> is any Ubuntu-developer here? especially kernel division?
<jdong> adnarim: #ubuntu-kernel
<adnarim> thx jdong
<tormod> bryce, anyway, we continued the discussion with TomaszD on #ubuntu-x
<cjwatson> pitti: what's happening with libterm-readkey-perl? it's in universe and blocking apparmor-utils installation
<cjwatson> pitti: but the source is in main so it looks like it may be in universe by accident?
<adnarim> noone in ubuntu-kernel is answering so I hope somene here can or at least point me to a place where I can find the answer to my problem:
<adnarim>  I searched the whole net but couldn't find any answers about this. Is the Ubuntu-kernel not supporting the syscall macros? they should be in unistd.h but are not there !?!
<iwj> cjwatson: I decided I should test that ldconfig wrapper script change (even though it's trivial) so I have to wait for a glibc build.
<adnarim> they are important for accessing syscalls within C like described here: http://www.ibm.com/developerworks/linux/library/l-system-calls/
<pitti> cjwatson: it's supposed to be in main; change-override.py might have fooled me again
<pitti> cjwatson: moved again *hopes for the best*
<pitti> cjwatson: hm, it was in main on hppa and lpia; yay
<seb128> pitti: is change-override buggy?
<pitti> seb128: sometimes I have that feeling...
<seb128> pitti: looks like it doesn't change outdated versions, no?
<seb128> libgbf-1-dev |    0.1.2-4 | gutsy/universe | hppa
<seb128> libgbf-1-dev |    0.1.7-1 | gutsy/universe | amd64, i386, ia64, lpia, powerpc, sparc
<pitti> seb128: that might be it, yes
<Hobbsee> pitti: was it you doing the archive run?
<pitti> Hobbsee: define archive run?
<Hobbsee> pitti: sync requests
<pitti> Hobbsee: seb
<Hobbsee> pitti: right, thanks.
* pitti hugs seb128
<Hobbsee> seb128: when it's a sponsored upload, are you intending to put the name of the approver, rather than the name of the sync filer, in the maintainer field of the changes mail?
<seb128> Hobbsee: we had a discussion about that this morning, I usually put the name of whoever I feel should be responsive for issues on the upload
<seb128> I usually put the approver
<Hobbsee> seb128: oh right.  i'm presuming you're going to write a mail to u-d & u-motu to actually tell us this.
<Hobbsee> seb128: imo, the person who has done the work should be listed as the maintainer - who is the one who has done the merge request, etc.
<seb128> Hobbsee: I'm not going to mail anybody
<Hobbsee> right then.
<seb128> Hobbsee: I'm not sure what is your issue
<seb128> sorry if I picked your name for a sync of a bug you approved
<Hobbsee> seb128: oh, i just thought it was misdirected credit - they who does the work should surely get the credit.
<Hobbsee> seb128: and also, if i'm now responsible for any issues of the upload - for everything that i happen to sponsor...that's sticking a whole bunch of extra load on me, or anyone else going thru the sponsorship queue.
<seb128> Hobbsee: right
<Hobbsee> as in, i still dont know the codebase in particular, beyond knowing tha tthere's nothing of crack in the diff
<Hobbsee> as for bug fixing from the upload - i would have thought that was still the responsibility of the diffmaker - even though the uploader has some responsibility.
<Hobbsee> but the primary point of contact for anything wrong?  i think that's a bit much
<seb128> Hobbsee: well, the uploader information is mainly administrative detail at the moment
<pitti> asac: works just fine here
<Hobbsee> (particularly as the primary point of contact will usually be mailed about anything wrong with the package, not just the diff they uploaded)
<seb128> Hobbsee: the mail on -changes is from Ubuntu Installer
<geser> who gets the mail for failed builds?
<asac> pitti: thanks
<Hobbsee> seb128: true, but it mirrors to LP, iirc
<seb128> Hobbsee: and that doesn't subscribe you to the package or anything
<Hobbsee> geser: i got one for failed upload
<asac> lets keep our eyes open during freeze then
<asac> will upload
<pitti> asac: bug updated
<Hobbsee> seb128: true - but it does give the expectation that you are.
<seb128> geser, Hobbsee: the question is also to know if some random people come, goes through sponsoring, get its upload processed and vanish, who should be responsive?
<Hobbsee> imo, at least.
<Hobbsee> seb128: that's a good question.
<seb128> geser, Hobbsee: ideally whoever did the work, but the approver sponsor is also somewhat responsive since he authorized the upload
<Hobbsee> seb128: i suspect it becomes a case of "the uploader becomes responsible if they who did the work does not respond"
<seb128> right
<asac> pitti: gratias
<Hobbsee> seb128: and beyond that, the MOTU team in general, as it's team packaging.
<Hobbsee> for telepathy*, it becomes the telepathy team, i suspec.t
<pitti> asac: great work! let's just hope it doesn't introduce strange regressions
<seb128> Hobbsee: I would be happy enough to use whoever did the work if he's known (core dev, motu, etc) or the approver if that's a new comer
<seb128> Hobbsee: would that work?
<Hobbsee> seb128: conversely, we're not debian.  packages are broken, and we dont have resources to fix them all - so there will be some level of breakage.  of course, us adding to it is not good.
<Hobbsee> seb128: sec.
<seb128> Hobbsee: well that's for freezes, whoever grant a freeze breakage approval should know about consequences
<seb128> Hobbsee: no?
* Hobbsee waits for LP to load.
<Hobbsee> seb128: no, that doesnt work.
<geser> yeah, motu-uvf will be responsible then for all broken uvfe
<Hobbsee> seb128: one of the ways we look for contributions to packaging is looking at hte person's +packaging page on LP.  if you put me as the maintainer, they go to mine, not the newcommers
<Hobbsee> seb128: which is...inconvenient, to say the least.
<Hobbsee> seb128: i know there's a back issue here - who's responsible, if no one has particular time to do everything they want, plus fix any and all regressions for anything they sponsor.
<asac> pitti: pressing-thumbs ;)
<Hobbsee> seb128: MOTU is almost all volunteer run, and such.
<seb128> Hobbsee: ok, I'm busy enough with GNOME 2.20 for now, let's have that rant^Wconversation later
<Hobbsee> seb128: ah, thought you'd got that built.  good luck with it :)
<seb128> beta freeze is tomorrow and I've work to get done
<seb128> Hobbsee: almost but I've to chase some build issue, ask for some retries, etc
<Hobbsee> seb128: right.  do you want me to find another archive admin to deal with some sync-script breakage?
<seb128> Hobbsee: you have a fair point about the syncs, I'll use the person who did the work for the next ones
<Hobbsee> seb128: thanks.
<seb128> Hobbsee: that's not a breakage, looks like other archive admin usually use whoever did the work
<geser> btw is there some list of packages FTBFS on LP (or somewhere else)? looking on the ftbfs in the buildd's history isn't feasible
* Hobbsee thought the sync script would use -sa by default - gotten an error about no .orig.tar.gz
<Hobbsee> Rejected:
<Hobbsee> Unable to find libtelepathy_0.0.57.orig.tar.gz in upload or distribution.
<Hobbsee> Files specified in DSC are broken or missing, skipping package unpack verification.
<cjwatson> it should do ...
<Hobbsee> seb128: ^ looks like sync script borkage?
<seb128> Hobbsee: looks like
<Hobbsee> (tentative guess, as i've only heard references to the script in question)
<tkamppeter> pitti, I have a little Apport problem. See bug 135321
<ubotu> Launchpad bug 135321 in system-config-printer "system-config-printer.py crashed with SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/135321
<tkamppeter> There is no useful info and asking for a retrace does not work. Tim Waugh is asking whether there are things like debuginfo packages (would need especially one for python-cups.
<pitti> tkamppeter: yes, we have debug symbol pacakges
<tkamppeter> How to proceed to get more info to solve bug 135321?
<ubotu> Launchpad bug 135321 in system-config-printer "system-config-printer.py crashed with SIGSEGV" [Medium,Confirmed]  https://launchpad.net/bugs/135321
<mathiaz> keescook: About bug 140626, are you running x86-64 ?
<ubotu> Launchpad bug 140626 in apparmor "apparmor Segmentation fault" [Undecided,Incomplete]  https://launchpad.net/bugs/140626
<pitti> tkamppeter: I'll have a look later, busy ATM
<keescook> mathiaz: I do run x86-64, yeah.  I haven't seen that.  However, I haven't rebooted in a while.  I can try it.
<geser> mathiaz: I've tried to reproduce the bug but no success (apparmor and apparmor-profiles 2.1+993-0ubuntu1)
<geser> doesn't segfault here (amd64)
<mathiaz> geser: thanks.
<ion_> mvo: In compiz-manager, theres 8086:29a12 listed in the PCI IDs. Thats probably a typo.
<mvo> ion_: yes, thanks! we just noticed
<ion_> mvo: Btw, does it look like hw-connected isnt going to be used? I noticed that the mention of it at the compiz sprint wiki page had been moved under resolved issues.
* ogra wonders why his fonts are so horribly blurry since the last upgrade
<mjg59> ogra: Freetype
<ogra> yeah, indeed
<ion_> ogra: Some paper says its the right way to render fonts, so seems like thats what we have to tolerate from now on.
<ogra> eek
<ogra> really ?
<ion_> ogra: I was told the API change is so big that it isnt possible to offer both rendering methods as settings.
<ogra> gah
<ogra> but tat looks crappy on LCDs
<ogra> *that
<ogra> at leats on the two i have tried it yet
<ion_> ogra: Yes, it does. Horizontal lines arent hinted to pixel boundaries, so there are faint subpixel lines around the lines which cause blurriness.
<mvo> ion_: we now use the compiz-manager script that is part of upstream git and upstream does not (currently) want to depend on hw-connected as its not yet widely available
<ion_> ogra: And a paper says its the right way, so thats what we have to obey.
<ion_> mvo: Alright.
<ogra> ion_, well, it worked before ....
<ion_> ogra: It did, but a paper says what it did before is wrong, thus we have to obey.
<ogra> tel that to my optician :P
<ogra> what it did before worked ...
<ogra> what it does now doesnt
<ogra> and given the amount of LCD displays out there thats a very bad move imho
<ion_> mvo: Im fine with any decision, but id still like to point out that since hw-connected is a small C program and its dependencies are installed in every Linux box, it wouldnt be a big impact even to include it in the compiz source for now.
<cjwatson> may I suggest talking to the people who made the change rather than speculating?
<\sh> hmm...X is not coming up again...
<ion_> mvo: (The only hard dependency is libc. It only needs /sbin/modinfo if the -m parameter is used.)
<\sh> oh god...something is really strange here...
<Ng> firefox does some interesting things in the new font order, selecting text in a multi-line edit box makes the glyphs change shape, so the lines move around
<\sh> anyone saw not correct installed binaries, who are segfaulting, and then after apt-get --reinstall install <package> it works again?
<bryce> sh, X issues?
<\sh> bryce, I don't think so..but it looks like that something happens to my XFS fs...it's sometimes not installing the whole package, or just some bits of a binary...
<ion_> XFS... nuff said. ;-)
<\sh> those binaries segfaulting now, and --reinstalling helps
<\sh> ion_, well, I'm running XFS on several hundreds servers, and nothing went wrong
<\sh> I wonder if it's the laptop itself (broken disk or ram or cpu or whatever can change the data on disk or in memory)
<jdong> \sh: have you ever had a hard hang or unclean shutdown on the filesystem?
<jdong> that is like a 75% death sentence to data integrity on XFS... :(
<ion_> Yeah, as long as the hardware works *perfectly*, XFS is fine.
<Skif> A co-worker pointed this out to me: there are several GUI packages that deliver menu files, but not .desktop files.  This is confusing, because sometimes when you install a package, it shows up in your menus, and other times, it doesn't, and there is no obvious (to the user) reason why.
<jdong> ion_: that's my epxerience too
<\sh> jdong, yepp...and until today...I'm happy that nothing disappeared or was broken...I had all the time problems with reiser3 or ext3...
<Skif> I have written a quick script that greps through Contents.gz, and tells which packages have menu files, but not desktop files.  Is this appropriate for a mass bug filing?
<dholbach> pitti: can you wave through gutsy-wallpapers?
<Skif> So far I have 403 packages for main, and 2909 total (including main, multiverse, universe)
<\sh> Skif, file the bugs with the .desktop file attached :)
<jdong> \sh: I'm 100% confident that one of those unclean dismounts is to blame.... There's a reason I do weekly xfsdumps on my XFS drive...
<Skif> \sh for < 100, I might. :)
<dholbach> pitti: I'll make ubuntu-artwork depends on it
<pitti> dholbach: looking
<Skif> \sh: seriously, you know of an automatic converter?  I'd be happy to.
<\sh> jdong, oh you mean now? no...the laptop is all the time shutdowned correctly
* dholbach hugs pitti
* Skif has a feeling that would be... um... slow, though :)
<LaserJock> Skif: please feel free to send a list to the ubuntu-devel mailing list
<Skif> LaserJock: Sure, no problem.
* Skif is happy to have found something (sort-of) useful to report.
<\sh> Skif, much better when you can divide the list for all sections (main, universe,multiverse) and send it in CC to ubuntu-motu@l.u.c
<Skif> \sh: that's pretty trivial, thanks to grep.
<mhb> hi folks, sorry to bother with translation-related matters ... does anyone know how to integrate fresh d-i translations into ubiquity so one can test the fresh translations?
<Skif> I don't have to be subscribed to ubuntu-motu, to CC: it, do I?
<LaserJock> Skif: I think it'll just get moderated
<Skif> Ah, no problem, then.
<LaserJock> Skif: but you want to be subscribed to ubuntu-motu anyway ;-)
<Skif> LJ: Right, because disk space on my mailhost is free. :)
<pitti> dholbach: gutsy-wallpapers> warty-final-ubuntu.png ??
<dholbach> pitti: don't ask
<dholbach> pitti: that's the filename we have in there for ages
* pitti hugs the Warty Warthog, may it rest in peace
<dholbach> to 'automatically update to the next wallpapers vision'
<ogra> pitti, rest ?
<dholbach> I'll leave that for somebody else to fix in next release
<ogra> mine is still pretty busy :)
<pitti> dholbach: ok, NEWed
<dholbach> pitti: thanks a lot
<dholbach> pitti: ubuntu-artwork is uploaded which will depends on it
<pitti> dholbach: please poke someone else for binary NEW (or wait until tomorrow morning), since I am about to leave
<dholbach> pitti: I'll leave soon too
<dholbach> pitti: thanks for doing that
* dholbach hugs pitti
* pitti hugs dholback
<dholbach> hehe
<charlieS> 67307 - USB devices don't work for non-local users since edgy. Has anyone seen this? :)
<seb128> infinity, lamont, Mithrandir: could you give a buildd retry to gedit on amd64?
<lamont> seb128: on it
<seb128> lamont: thanks
<lamont> seb128: and I retried sparc/ia64 as well, just for giggles.
<seb128> lamont: thanks
<elmo> is it known that some gnome tools are still searching for esd?
<seb128> elmo: they should display a message about it once and that's about it
<torkel> elmo: I think they use esd if it is installed, but fallback to aplay
<elmo> seb128: ok
<Halcy0n> What would be the most sane way for me to generate a nightly package?  I'd like the version to contain a date string, but I don't like the idea of having to put them all into the changelog.  Is there any way I can override it, or fake it?
<seb128> lamont: can you also give a retry to gnome-applets on sparc powerpc hppa?
<seb128> lamont: same for gtkhtml3.14
<tormod> Halcy0n: maybe take a look at "man dch"
<lamont> gnome-applets, gtkhtml3.14 done
<lamont> (hppa sparc ppc lpia)
<cjwatson> lamont: could you take 137837, please?
<cjwatson> bug 137837
<ubotu> Launchpad bug 137837 in expect "expect ftbfs on ia64" [High,Confirmed]  https://launchpad.net/bugs/137837
<lamont> cjwatson: yeah
<cjwatson> thanks, assigned to you
<seb128> lamont: could you give a buildd retry to gnome-system-monitor epiphany-browser epiphany-extensions on amd64 (and the other arches that didn't build maybe)?
<lamont> seb128: ok.
<seb128> thanks
<lamont> dear launchpad.  could I please have something less than 2 buttons to reschedule a single build/arch?  kthxbye>?
<lamont> s/>?$/./
<lamont> dear expect, there are include files to define libc functions for a reason.
<lamont> cjwatson: it'll require iteration - I'll hack on it tonight
<lamont> seb128: I'm not bothering to score these high, so they might take a bit before they build... OTOH, most archs are rather idle mostly
<slangasek> cjwatson: I talked to pitti about 137837 earlier, he said it also shouldn't be milestoned because it's ia64, is that right?
<cjwatson> slangasek: it shouldn't have Canonical resources assigned to it, at any rate, and it's top of the list for deferral
<seb128> lamont: ok
<lamont> slangasek: if it's milestoned, I'm more likely to notice, especially since cjwatson will thwap me with it
<cjwatson> slangasek: it may certainly make sense to unmilestone it in order to make your list manageable
<slangasek> ok :)
<slangasek> lamont: well, my plan had been to thwap you with it and then un-milestone it :)
<cjwatson> :-)
<lamont> that'll work.  please at least assign them to me when you unmilestone them. thwapping optional
<lamont> seb128: gsm amd64, eb amd64/sparc
<cjwatson> bug 131209 - shit, I should finish that
<ubotu> Launchpad bug 131209 in casper "kubuntu verify CD just boots live system" [Medium,Triaged]  https://launchpad.net/bugs/131209
<lamont> seb128: and ee amd64/sparc
<seb128> lamont: thanks
<elmo> sweet
<elmo> my /var/lib/dpkg/status is corrupt
<ion_> How about status-old?
<jdong> that's always a joy, elmo :)
<elmo> that's fine
<elmo> well, as in , doesn't have this particular corruption
<lamont> cjwatson: 137837 - I suppose you care if I want to go to -13.1 after I NMU debian, right?  (it's -11 in gutsy)
<lamont> s/cjwatson/slangasek/
<lamont> heh.  -12 and -13 are ijw patches
<lamont> cool.  -13 == -11ubuntu1
<slangasek> lamont: ok, then feel free to bump the version number when uploading :)
<mathiaz> kylem: did you get a chance to merge the apparmor patch for the audit messages ?
<lamont> slangasek: heh
<kylem> mathiaz, no, oops.
<mathiaz> kylem: will there be a new upload of l-u-m before beta ?
<kylem> unlikely before beta.
<kylem> but check with Ben.
<mathiaz> kylem: ok. Thanks.
<kylem> lum is short to build, i imagine it's not too much trouble to respin.
<mathiaz> kylem: the current situation with apparmor is that the tools used to parse the audit messages don't work correctly.
<mathiaz> kylem: so the profiles cannot be updated with the tools.
<mathiaz> kylem: but it doesn't break apparmor itself.
<elmo> so, my /var/lib/dpkg/status lost it's ^@ corruption on reboot.  s2ram FTW \o/
<mjg59> elmo: What sata driver?
<ion_> elmo: XFS?
<elmo> mjg59: looks like ahci?
<Halcy0n> Anyone here that has access to the upload queue?
<elmo> ion_: ha  ha ha.  no.
<mjg59> Hrm.
<jdong> 17:37 < elmo> ion_: ha  ha ha.  no.
* jdong hugs elmo....
<jdong> best response I've heard
<elmo> mjg59: it was like 2-4 bytes in one file too, very specific
<elmo> (well, in one file, that I know about ...)
<elmo> mjg59: (also, I'd just done a dist-upgrade prior to sleeping, so it may relatively reproducible)
<cjwatson> Halcy0n: what's up?
<IntuitiveNipple> Any ETA on fixing the unionfs BUG - I've not even been able to install Gutsy for testing on the Vaio notebooks as a result... time is pressing :)
<cjwatson> IntuitiveNipple: no ETA, sorry, only my word that it's the highest priority
<cjwatson> a kernel developer is working on it (AFAIK) full-time
<IntuitiveNipple> lol no problems!
<IntuitiveNipple> cjwatson: btw I'm the "TJ" that reported the GID issue... fully debugged and explained in Bug #141067
<ubotu> Launchpad bug 141067 in shadow "Group GIDs 1-99 not shown in Groups Settings dialog" [Undecided,New]  https://launchpad.net/bugs/141067
<cjwatson> IntuitiveNipple: yep, I recognised you - thanks
<cjwatson> IntuitiveNipple: I commented - I think the shadow task ought to be rejected
<IntuitiveNipple> ahh ok... thanks
<IntuitiveNipple> I put that up to make clear the two points of contact at issue
<cjwatson> Not replacing deleted config file /etc/papersize
<cjwatson> hah, that explains a lot
<ion_> Is there a VCS branch for linux-restricted-modules?
<IntuitiveNipple> So I guess I should open a task against system-tools-backend then
#ubuntu-devel 2007-09-20
<slangasek> cjwatson: but any indication yet what's deleting /etc/papersize?
<cjwatson> slangasek: that would be ubiquity
<cjwatson> I knew about *that* bit
<slangasek> oh, ok
<cjwatson> the question was why it wasn't getting restored, but it turns out the libpaper maintainer switched everything over to use ucf and I didn't notice] 
<cjwatson> and ucf honours config file deletions
<mathiaz> is the samba package installed on the livecd ?
<cjwatson> mathiaz: http://cdimage.ubuntu.com/daily-live/current/ see the manifest files
<mathiaz> cjwatson: thanks
<cjwatson> slangasek: (ubiquity is just taking a preconfigured live filesystem and copying it, so it has to resort to some pretty nasty hacks to get everything properly configured afterwards)
<slangasek> cjwatson: so the earlier behavior was that libpaper would recreate /etc/papersize unconditionally?
<cjwatson> slangasek: right
<cjwatson> the new behaviour is clearly more correct, or at any rate more consistent with dpkg
<LaserJock> cjwatson: how long has this bug been around?
<slangasek> well, libpaper1 seems to have been using ucf since etch at least
<cjwatson> not entirely sure, just going to check
<cjwatson> it's been using ucf for ages, but differently
<slangasek> ok
<cjwatson> in fact, I only wrote the code in ubiquity to configure /etc/papersize at all in early gutsy, so it can't have been long
<cjwatson> and I know it worked then
<LaserJock> what's the bug # for this, I got a few MOTU Science bugs that sound like dups
<cjwatson> except I may have been on steaming crack, because the postinst hasn't changed since feisty
<cjwatson> anyway, feisty didn't fiddle with papersize at all in desktop CD installs, so it can't have been any worse than that there
<cjwatson> LaserJock: bug 104160 for feisty's lack of configuration; bug 128258 for the bug in how I did it in gutsy
<ubotu> Launchpad bug 104160 in ubiquity "/etc/papersize incorrecly configured" [Medium,Fix released]  https://launchpad.net/bugs/104160
<ubotu> Launchpad bug 128258 in ubiquity "/etc/papersize is not created" [High,Fix committed]  https://launchpad.net/bugs/128258
<LaserJock> man these indexing services sure do chew up disk space. strigi is taking up 25% of my ~/
<sladen> ...and only 75% of your CPU
<ajmitch> that's a bit much
<ion_> mvo: compiz fails to start now: Comparing resolution (1680x1050) to maximum 3D texture size (512): Failed.
<ion_> Whoops, hes gone.
<calc> anyone seen this happen recently?
<calc> Unpacking liba52-0.7.4 (from .../liba52-0.7.4_0.7.4-11_amd64.deb) ...
<calc> Segmentation fault (core dumped)
<calc> it seems to segfault on unpacking for any package
<zul> uh...yeah i think there was a change to dpkg yesterday or something
<calc> ah yea it was a bad apt version apparently
<calc> i manually dpkg installed ubuntu10 and it fixed the issue
<mjg59> Hm. The DVD playback experience is astonishingly poor.
<mjg59> 1) Insert DVD
<mjg59> 2) Get obscure error
<mjg59> 3) Try playing it again
<mjg59> 4) Get link to website that tells me to install codecs I already have installed
<mjg59> Even running totem --debug doesn't give me any feedback
<pkern> Hi there. Does anyone know if encrypted filesystems got implemented into gutsy's d-i?
<cjwatson_> pkern: yeah, it's basically there, just needs a few more bug fixes; I only fixed cryptsetup to actually have the right library linkage for d-i today so I haven't had time to QA partman-crypto
<cjwatson> and by today, I mean since the last daily build
<pkern> cjwatson: So it's broken in current tribe but will be fixed for Gutsy?
<cjwatson> yes to the former, probably to the latter
<pkern> cjwatson: Current build is 20070919.1. So from your side only QA on partman-crypto is lacking and it's possible that it works? If so I will try it out later.
<cjwatson> pkern: I'm aware of what the current build is, since I built it
<cjwatson> pkern: tomorrow's build should be interesting to test
<pkern> cjwatson: Sorry, I thought they get built automatically. (:
<cjwatson> they do except when they fail and one of us admins goes and pokes them
<cjwatson> we had some network fun with cdimage's private archive mirror
<pkern> cjwatson: Is the `.1' extension coming from the manual build?
<cjwatson> yes, second and subsequent builds on any given day get that
<cjwatson> the first build failed but we don't reuse the number because it corresponds to the log file
<cjwatson> (sometimes I cheat and forcibly reuse numbers when I know they really don't matter, but I didn't bother in this case)
<pkern> Ok, so I jigdo the current build and wait for the one built tomorrow?
<pkern> (Or as in `later today'.)
<pkern> (It's a bit bad that they are oversized as I want to try them out on a real machine.)
<cjwatson> about six hours I guess
<cjwatson> there are fixes for (at least most of) the oversizing in the pipeline
<lamont> slangasek: btw, expect is very ugly code.  just FYI and all that.
* lamont heads home, afk for an hour
<slangasek> lamont: yes, I've seen that it build-depends on tcl8.4, no need to tell me :)
<cjwatson> hmm, that's an interesting idea
<cjwatson> Vista's alt-tab handler includes the desktop as one of the "windows", and alt-tabbing to that minimises everything else
<kylem> cjwatson, they probably patented that.
* jdong laughs
<jdong> and the pessimistic-outlook-on-features award goes to.... :)
<mneptok> kylem: no, they just patented key combinations and went with the umbrella strategy
<johanbr> I'm going to patent the concept of "bug". After that, Microsoft will be in for a world of hurt.
<jdong> but anyway, yeah, cjwatson, that was one of the cooler things I noticed about vista too
<jdong> apart from having an amazingly rock-solid filesystem against even the worst hard-reset scenarios.
<mneptok> uh.
<mneptok> it's NTFS, right?
<kylem> transactional ntfs, yes.
<jdong> yes
<jdong> transational ntfs
* jdong whines... when is linux gonna get an atomic filesystem?
<mjg59> atomicity is difficult if you want a filesystem that's actually useful
<mneptok> jdong: hint: a cow with a bra and eyliner is not a supermodel.
<jdong> mneptok: you promised to lay down on the Oprah jokes....
<jdong> back on topic, shows my ignorance then... I guess I just want something that stands up better to rough treatment
<mneptok> jdong: i made no promises vis-a-vis Starr Jones
<shaya> any good reason why deskbar forces tracker to be installed?
<shaya> one can want deskbar w/o the desktop search elements.  For instance, tracker is killing my PM-1.8ghz 2GB laptop
<shaya> nevermind, I see what happened
<shaya> it can be uninstalled
<shaya> w/o removing deskbar applet
<poningru> lol
<loopylouie> wassup
* DShepherd cheers on the ubuntu devs 
<DShepherd> Just felt like saying thanks for all the hardwork you guys (and girls) do
<DShepherd> no.. back to work!! :-)
<DShepherd> now*
<mjg59> I've reverted the freetype, xft and cairo changes - the results were clearly worse than originally, and the code is basically unnecssary given the bytecode interpreter (which we use)
<desrt> mjg59; know anything about synaptic touchpads?
<mjg59> desrt: Yes. Why?
<desrt> i want to get a raw dump of events from the kernel... i only care about the hardware button
<desrt> but since the touchpad is in software mode nothing is showing on the event devices
<mjg59> You can't get a raw dump
<desrt> crud :(
<mjg59> Why do you want to?
<desrt> i have this odd bug where ButtonRelease events often don't get delivered until the next mouse event
<desrt> trying to decide what kind of an issue it is
<mjg59> On Apple?
<desrt> ya
<mjg59> That's not a synaptics pad
<desrt> oh.  ok
<mjg59> Check the appletouch driver
<desrt> well, [generic software pad] 
<mjg59> I suspect the problem is it failing to sync the input events properly until it receives another event
<desrt> ah... like the driver has it in its queue and is looking to match it up with another
* desrt guessed it was occasionally dropping interrupts
<mjg59> Yeah
* desrt tries to find debugging support
<mjg59> There's an input_sync() function that needs to be called
<desrt> this appears to operate outside of the normal input device framework, though
<desrt> it's not generating anything on /dev/input/event*
<mjg59> No, it's a perfectly normal input device
<desrt> not even anything on /dev/input/mice ...
<desrt> ok.  i can see the events if i kill X.  i guess it's eating up all the events before i can get to them or something
<desrt> it's not an X bug in any case
<desrt> the place where it reports the button press is followed immediately by a sync
<mjg59> Then maybe it's not getting the button up event for some reason?
<desrt> if or if not the left button is pressed appears to be decided by a bit that is always sent on every event
<desrt> so even if no explicit "button release" was sent it would still give a button release event as a matter of course as part of the next event
<mjg59> If you haven't touched it for a while, we make it stop sending events
<desrt> so it may not be like something getting stuck in the queue so much as disappearing
<desrt> do you guys do that usb-autosuspend thing these days?
<mjg59> No
<desrt> the autosuspend file has '2' in it
<mjg59> Possibly the logic in the pad reset is wrong
<desrt> in any case it makes no difference... i still get it even when it is 0
<mjg59> Oh, yeah, it's in the current binaries
<mjg59> I suspect that you want to look at the idlecount block
<mjg59> And not go into that if the mouse button is currently held down
<desrt> the schedule_work thing?
<mjg59> The block surrounding that, yes
<desrt> tricky
<mjg59> The current logic is "If we haven't had an x or y event for 10 packets, ask the pad to stop sending"
<desrt> ok.  lemme hammer out a patch
<desrt> brb
<mjg59> Which probably ought to be "If we haven't had an x or y event and the button isn't down, ask the pad to stop sending"
<sladen> ...might be more robust
<desrt> mjg59; ok.  fixed
<desrt> take a look at https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/141132
<ubotu> Launchpad bug 141132 in linux-source-2.6.22 "[gutsy]  strange freeze-up until mouse moves" [Undecided,New] 
<desrt> tbh: not really sure why i decided to keep button_down as state... would probably work the other way, too
<mjg59> desrt: Hm, I don't think that's quite right
<desrt> too much conditionalised?
<mjg59> We want to stop reporting the fingers even if the button is pressed
<desrt> right
<desrt> think i should get rid of the state in the struct atp too?
<mjg59> Yeah, easier to just check the bit
<desrt> btw: idlecount is never reset to 0 except in the reinit handler
<mjg59> I think just add the button check to the                 if (atp_is_geyser_3(dev)) {
<desrt> is that a bug?
<mjg59> Right, that's arguably a bug :)
<desrt> k.  i'll fix that too :p
<mjg59> Sleep now.
<desrt> nite
<dholbach> good morning
<dholbach> can somebody get gutsy-wallpapers out of new?
<pitti> Good morning
<pitti> dholbach: o/
* dholbach hugs pitti
<dholbach> ROCK ON :)
<StevenK> Morning pitti
<pitti> hey StevenK
<dholbach> hey StevenK
<ajmitch> hey dholbach, pitti
<dholbach> heya ajmitch
<dholbach> ArneGoetje: are you all set with the uploads you wanted to make?
* ion_ thanks mjg59 from the heart.
<Mithrandir> *sigh*, why does trackerd run when I've checked "disable indexing" and "disable watching"?
* Hobbsee tries to figure out which switches to use rsync with, when rsyncing a daily iso
<Mithrandir> Hobbsee: -a --progress -v
<ion_> mithrandir: It still provides the generic metadata database. Unfortunately, programs have yet to begin to use it.
<ArneGoetje> dholbach: it's currently on the way
<Hobbsee> Mithrandir: you rock.
<dholbach> ArneGoetje: ok great
<ArneGoetje> dholbach: pitti is sposoring
* Hobbsee hugs Mithrandir
<Mithrandir> ion_: so there's no way to tell it to stay away and not come back short of removing the package or chmod 0-ing the binary?
<ion_> mithrandir: You could disable the autostart from gnome settings.
<ion_> It probably would still be started by dbus when someone queries it, though.
<ion_> Uh. Something.
<Mithrandir> *sigh*
<Mithrandir> that's fairly broken.
<ion_> If you dont want it, why not uninstall it?
<Mithrandir> because this might not be a single-user machine?
<Mithrandir> a user should be able to disable something like tracker without having root access.
<LaserJock> yep
<minghua> ArneGoetje: Thanks for fixing scim.
<Treenaks> Mithrandir: the same happens with vino.. I have remote desktop access disabled, but still vino-session is running
<ArneGoetje> minghua: just the quick and dirty fix...
<ArneGoetje> minghua: need to discuss with Riddell about the future of those package changes
<minghua> ArneGoetje: Yeah, I really hope that library file move patch can be dropped.
<minghua> ArneGoetje: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438647 is my take on the issue if you are interested.
<ubotu> Debian bug 438647 in scim "[whislist]  how about move scim-helper-* from scim" [Wishlist,Open] 
<ArneGoetje> minghua: well, as far as I understood him, the issue is that skim currently depends on gtk... any way to rewrite that library that it supports both, gtk and qt?
<Mithrandir> Treenaks: well, same bug.  We should strive to fix those bugs, really.
<Treenaks> Mithrandir: is there already a report, or should I open one?
<minghua> ArneGoetje: No rewriting is needed, just repackaging.  But that needs better investigation and testing, not just blindly throwing two files to a different package.
<minghua> ArneGoetje: Even in Ubuntu, skim still depends on scim nowadays, so that patch doesn't achieve anything.
<Mithrandir> Treenaks: I'm reporting one for tracker now
<Mithrandir> or actually, it's bug 132320
<ubotu> Launchpad bug 132320 in tracker "Tracker consumes more then 90% of CPU even when indexing is disabled" [Critical,Fix committed]  https://launchpad.net/bugs/132320
<Treenaks> Mithrandir: it'll probably still be running
<ArneGoetje> minghua: ok... so, this is a deeper issue. I will take a look into your approach
<Treenaks> Mithrandir: (not doing anything else... except consume memory etc.)
<Treenaks> Mithrandir: that bug only addresses CPU usage
<minghua> ArneGoetje: Yeah, please follow up in Debian #438647.
<ubotu> Debian bug 438647 in scim "[whislist]  how about move scim-helper-* from scim" [Wishlist,Open]  http://bugs.debian.org/438647
<ArneGoetje> ok
<pitti> asac: eek, problem: you introduced a new mozilla-firefox-locale-he without C/R/P'ing mozilla-firefox-locale-he-il
<pitti> asac: preferably we just continue to use the old name
<pitti> asac: same for -ka-ge -> -ka
<pitti> asac: and -ro-ro
<lucky_lucas> Anyone from the xorg team ?
<pitti> asac: fixing...
<bryce> lucky_lucas: yep
<lucky_lucas> Is the ati driver v. ubuntu4 meant to resolve xorg rash while using compiz ?
<lucky_lucas> crash
<bryce> xorg-server 12ubuntu5 has a fix for a crash when using -nvidia or -fglrx with compiz, if that's what you mean
<lucky_lucas> bryce: No I'm talking about the package xorg-server-video-ati 6.7.192 ubuntu4
<bryce> the -ati driver update was to enable xrandr (multi-display) capabilities.
<lucky_lucas> Ok
<Treenaks> Is there any news on the 30 second delay when logging in when using a composite window manager
<Treenaks> bryce: but it broke dpi :)
<bryce> Treenaks: what?
<lucky_lucas> bryce: So the compiz failure was caused by xorg-server itself and not by the drivers, sweet
<bryce> afaik, upgrading to xorg-server 1.3 is what broke dpi, not driver upgrades.
<Treenaks> bryce: Well, 6.7.192 thinks my display is 50x31cm, while it's 33x21cm
<Treenaks> bryce: oh.. because adding DisplaySize doesn't help either
<bryce> lucky_lucas: if it's the crash I was focusing on fixing, it was caused by ABI changes in xserver which caused failures with binary video drivers
<lucky_lucas> B
<lucky_lucas> bryce: which bug is it ?
<bryce> Treenaks: the -ati update did not cause that breakage; that's due to the xserver upgrade from 1.2 to 1.3.  but it should be fixed now.
<lucky_lucas> I have filled this bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/134578
<ubotu> Launchpad bug 134578 in xserver-xorg-video-ati "Open source ati driver freeze with compiz" [Undecided,Confirmed] 
<bryce> I also independently changed the default dpi in xserver from 75 to 100, around xserver 12ubuntu4 or 5
<pitti> asac: new m-f-l-all uploaded
<lucky_lucas> Bellow I said, that the failure happens also with nvidia-glx, so maybe your fix, resoled this too
<lucky_lucas> I will try this afternoon
<Treenaks> bryce: I have 2:1.3.0.0.dfsg-12ubuntu5 and my 150dpi screen reports as 96x96
* RAOF admires Treenaks' LCD
<bryce> lucky_lucas: unfortunately when people simply report "it freezes" that really isn't enough info to go on
<Treenaks> RAOF: LaptopTestingTeam \o/
<bryce> what really helps is to have logs, error messages, stack traces, etc.
<RAOF> Treenaks: You get shiny, shiny laptops?  Cool.
<Treenaks> RAOF: got
<lucky_lucas> In fact I thought you were aware of something because when I installed, the tribe 5 the ati was blacklisted to use with compiz. After the update the blacklist was off and compiz is running, so I concluded that the problem was officially solved
<bryce> heh, ati has a seemingly limitless number of bugs
<bryce> lucky_lucas: actually I don't deal with the compiz blacklist
<lucky_lucas> Anyone does it ?
<LaserJock> hmm, has mvo been around?
<dholbach> LaserJock: not yet, it's 9:24 in germany and I think he's just come back from a trip in London, so it might take a while until he's here
<LaserJock> dholbach: ah, thanks
<pitti> hey seb128
<seb128> hello pitti
<dholbach> hey seb128!
<seb128> hello dholbach
<siretart> hey folks!
* pitti hugs siretart 
* siretart hugs pitti back :)
<siretart> seb128: have there been any further problems regarding live-{initramfs,helper}?
<seb128> siretart: no, I've just been busy with GNOME 2.20 and didn't do archive admin work again yesterday, I'll do that this morning
<siretart> seb128: no problem. was just curious
<seb128> anybody from MOTU uvf team willing to accept that we sync louie as a new package from Debian? Rhythmbox upnp plugin requires it
<Whoopie> seb128: Hi, I now got 3 verifications that my nautlilus-sendto patch for thunderbird works.
<seb128> Whoopie: hi, yeah I read the mails, I'll have a look again if I understand what it does
<Hobbsee> seb128: hmm?
<seb128> Whoopie: http://launchpadlibrarian.net/9194969/nautilus-sendto-0.12-thunderbird-2.patch <- this one?
<Whoopie> seb128: yes
<seb128> it's easier than the previous version ;)
<Whoopie> hehe, yes
<Whoopie> it's just escaping fixes.
<Whoopie> seb128: it's easier because I could skip the file-roller check. In feisty, this was needed, but not in gutsy.
<seb128> Whoopie: I'm not convinced by the patch
<seb128> asac: do you know what is the correct way to send several attachments using thunderbird?
<seb128> thunderbird -compose to=email,attachment=file:///path/to/file,file:///path/to/anotherfile is correct?
<gnomefreak> seb128: hes sleeping but that looks right im just not sure if its , or ;
<gnomefreak> i havent used tbird from cli in a long time
<seb128> gnomefreak: it's 10am local time it should be around the time he wakes up no? ;)
<seb128> gnomefreak: is that correct to put the list attachments between ' '?
<seb128> or " "?
<gnomefreak> give him another hour or 2 and hell be up ;)
<gnomefreak> that im not sure of
<gnomefreak> i wanna say ' '
* gnomefreak wonders something let me see if i cant find out real fast
<pitti> moquist, ogra: https://wiki.ubuntu.com/MainInclusionReportMoodle approved and promoted; with protest, but *shrug*, business goals and everything
* Mithrandir waits for somebody to go on a trigger-rampage over texlive.
<pitti> ogra: please seed it appropriately
<pitti> doko: gcj-4.1 wants to go to universe, is that ok?
<doko> \o/
<pitti> doko: I take that as a 'yes' :-)
<StevenK> has
<gnomefreak> seb128: its attachment='file:///c:/test.txt'
<StevenK> Interesting. How did 'has' get into my cut buffer?
<seb128> gnomefreak: and if you have several attachments?
<gnomefreak> it doesnt say
<seb128> gnomefreak: 'attachment','attachment'?
<ion_> stevenk: Sorry, i wont do that again.
<gnomefreak> give me another minute to see if i can find
<seb128> gnomefreak: and should the path be escaped?
<doko> hmm, the last upgrade did break fonts in gnome-terminal, ridiculous small now ... just seeing a dot as prompt
<Hobbsee> doko: and then got subsequently fixed...
<gnomefreak> seb128: this is all ive found so far http://www.mozilla.org/docs/command-line-args.html#how
<Hobbsee> unless it got broken again
<seb128> gnomefreak: thanks
<seb128> Hobbsee: hey
<seb128> Hobbsee: <seb128> anybody from MOTU uvf team willing to accept that we sync louie as a new package from Debian? Rhythmbox upnp plugin requires it
<gnomefreak> seb128: yw i wish it had more info though
<Hobbsee> seb128: were you going to promote it?
<Hobbsee> seb128: fine by me, assuming you've got time to review.
<Hobbsee> seb128: at this point, we've stuck a blanket deny on any new packages, unless they're really important or interesting
<seb128> Hobbsee: I don't think so, just have it available to universe so people stop whining about the upnp plugin not working
<Hobbsee> seb128: fair enough
<seb128> thanks
<Hobbsee> seb128: which mdz then hijacked, but that's beside the point.
<seb128> right
<dholbach> doko: the last libgnome2 update fixed it, you need to re-login
<doko> dholbach: thanks, can't dist-upgrade currently
<dholbach> doko: then upgrade libgnome2 only
<asac> seb128: i cannot find it atm i think its like: thunderbird mailto:seb128@ubuntu.com?subject="hello seb"&attachment="file:.."&attachment=...
<seb128> asac: ok, thanks
<gnomefreak> asac: the link showed using ' for attachments
<asac> yeah ... might be true
<tkamppeter> hi doko
<Whoopie> seb128: thunderbird -compose to=email,"attachment='file:///path/to/file,file:///path/to/anotherfile'"
<seb128> Whoopie: why the " before attachment?
<evand> Anyone willing to sponsor an 11th hour upload of migration-assistant to main?
<evand> http://people.ubuntu.com/~evand/upload/migration-assistant_0.5.0.dsc if you're interested
<seb128> Whoopie: why not attachment="PATH"&attachment="OTHERPATH"?
<evand> and thanks in advance
<dholbach> evand: looking into it
<Whoopie> seb128: http://www.mozilla.org/docs/command-line-args.html#Syntax_Rules
<Whoopie> seb128: so, they also escape the to field with "
<seb128> Whoopie: they put the " before the to
<seb128> Whoopie: not before attachment
<Whoopie> seb128: if we want to support more mail addresses, we need to escape the to values by '
<dholbach> evand: uploaded
<Whoopie> seb128: thunderbird -compose "to='test1@test.de,test2@test.de'","attachment='file:///path/to/file,file:///path/to/anotherfile'"
<evand> dholbach: thanks a ton!
<seb128> Whoopie: ok, seems to make sense
<seb128> Whoopie: see that's why I asked you to explain in the bug so I can look what the patch is doing now ;)
<dholbach> evand: de rien
<Whoopie> seb128: sorry, it's:  thunderbird -compose "to='test1@test.de,test2@test.de',attachment='file:///path/to/file,file:///path/to/anotherfile'"
<Whoopie> seb128: " for all values, and ' for the values inside the fields
<seb128> Whoopie: ok
<tormod> what's up with the daily live cds? filesystem.squashfs is 2 days old.
<pitti> dholbach: do we need libgtksourceviewmm-2.0-1 & friends in main at alll?
<tkamppeter> hi pitti
<pitti> hi tkamppeter
<tkamppeter> pitti, have you already looked into my gutenprint and foomatic-db updates?
<Hobbsee> tormod: on !i386, i take it?
<tormod> Hobbsee: yes
<Hobbsee> tormod: livefses wont be building.
<Hobbsee> ubuntu-desktop is not installable.
<Hobbsee> (from http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html )
<pitti> tkamppeter: not yet, no time yet; will those 27 new drivers increase package sizes on CDs?
<pitti> dholbach: ah, apparently not, nevermind
<dholbach> pitti: no, we don't need them
<tormod> Hobbsee: thanks. #ubuntu+1 should be warned in topic maybe.
<tkamppeter> pitti, no, the PPDs are in openprinting.org-ppds-extra which is not part of the CDs, so it probably influences only DVDs.
<pitti> tkamppeter: ah, ok
<kagou> hi tkamppeter
<Hobbsee> tormod: people usually dont try them - and it has various warnings about gutsy being broken
<seb128> Whoopie: I've uploaded a new nautilus-sendto with your patch, thanks
<tkamppeter> The changes in gutenprint should not add size, they add two new models and correct a third and thanks to PPD auto-generation there should be no visible size increase.
<tkamppeter> hi kagou
<Hobbsee> tormod: the main reason that it would be requiring someone to check every day, and update the topic as appropriate -and that people have better things to do - and more useful bugs to put there
<ogra> whats the openssh-server seed ???
<kagou> tkamppeter, last s-c-p is working great :)
<tormod> Hobbsee: I am not sure I agree that people don't try them. Since tribe6 fell out we have been encouraged to use them. The issue now is that a new daily seems to have been made, until you look at the contents...
<Hobbsee> tormod: true - i've no idea why they get made, if the livefses fail - surely you hsould have no builds for the day.
<baltix> hello
<pitti> tormod: FWIW, I'm currently rebuilding *-meta, and then I'll trigger new CD builds; my goal today is to fix the oversizedness and get them generally installable (modulo the unionfs bug, of course)
<Hobbsee> pitti: how long will that take?
* Hobbsee wants to rsync in the next 5 hours.
<pitti> Hobbsee: I'll spread it out over the day; I have no intention of staring at it all the time
<baltix> pitti: I can tell you how to fix oversizing problems without removing any software :)
<pitti> Hobbsee: 5 hours should be doable
<Hobbsee> pitti: yay, ok
<pitti> baltix: "use DVDs"? :-)
<pitti> we have the new OO.o, and some font package reductions
<baltix> pitti: no
<pitti> let's see whether that already does the trick
<baltix> pitti: lots of space is eaten by localized help files from gnome applications
<pitti> baltix: right, that's on our long-term list, too
<baltix> pitti: look at this specification - https://blueprints.edge.launchpad.net/ubuntu/+spec/help-for-each-languages
<asac> network-manager needs to be given back on all but lpia/i386 ... who is in charge?
<pitti> asac: can do
<asac> pitti: thanks!
<pitti> asac: kicked
* asac hugs pitti
<soren> Could someone be pursuaded to merge this branch into the main one? https://code.edge.launchpad.net/~shawarma/ubuntu-seeds/ubuntu.gutsy.server-tasks
<pitti> soren: oh, good timing; I am just updating *-meta
<soren> pitti: \o/
<baltix> pitti: why excluding unneeded help files is only on long-term list ? It's very easy to do - just move subfolders by language names from /usr/share/gnome/help/ into separate packages - help-pack-gnome-pl, help-pack-gnome-fr, etc
<pitti> soren: hm, that changes quite a bit; does this have cjwatson's blessing? I'm not sure whether the STRUCTURE changes are correct
<baltix> you are doing almost the same job with translations (.mo files from /usr/share/locale/ subfolders)
<soren> pitti: Ah, I may have forgot to renmae the file-server thing in STRUCTURE.
<soren> pitti: Other than that, I pretty much just copied the openssh-server thing.
<pitti> soren: and shouldn't the packages in the new tasks be removed from the previous seed ('server' or so)?
<pitti> soren: server-ship doesn't mention postgresql-server and mail-server either; that's not intended, I take it?
<Hobbsee> heno!
<soren> pitti: Hm... Gimme a few minutes.
<heno> Hobbsee!
<Hobbsee> :)
<pitti> soren: hm, what about I upload *-meta now, you sort this out and get Colin's blessing, and then I merge and update again?
<pitti> soren: I want to get the other CDs in shape ASAP
<soren> pitti: Alright.
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | main frozen for Gutsy Beta release
<ion_> I take it the fix for nvidia_supported in l-r-m didnt make it to the beta?
<soren> pitti: Right, yes, that's entirely fine. I need Colin to do a new tasksel upload for this as well, so I have to bother him anyway :)
<soren> How much space does a default desktop installation of gutsy occupy?
<pitti> soren: something between 2 and 2.5 GB
<soren> pitti: thanks
* ogra hugs pitti 
<ogra> seeds changed, thanks a lot :)
<pitti> ogra: only supported? or ship/desktop?
<pitti> ogra: (I just updated *-meta)
* pitti sighs at http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html
<pitti> fabbione: do you happen to have an idea why sparc has so many uninstallable packages? autobuilders don't keep up, or a broken basic library?
<fabbione> pitti: no sorry. I haven't been a looking a sparc for ages. AFAIK pkl is supposed to do so
<pitti> ah, ok
<Riddell> thanks for the merge pitti
<ogra> pitti, -server
<lucas> are sync requests going to be processed before the release? I have a pending sync request than fixes a bug (UVFe already granted)
<pitti> ogra: I see; can you please update -meta again then when you are finished with the seeds?
<ogra> indeed :)
<baltix> btw, why foomatic-db-gutenprint was removed from main since edgy ? lots of printer's drivers now are missing in Ubuntu currently :(
<pitti> infinity: can we do a mass-giveback on sparc?
<Whoopie> seb128: I thank YOU.
<seb128> ;)
<pitti> seb128: ah, seems that libmetacity0 is a major source of uninstallability on amd64; giving back package
<seb128> pitti: might be, I looked yesterday to GNOME 2.20 builds and almost everything built, I asked some retries to lamont which seem to have worked correctly
<seb128> pitti: the metacity build issue was due to libgnomeui uploaded almost in the same time and arch all any installability
<Riddell> calc: is OO 2.3 going to get into beta? (I presume not)
<pitti> seb128: who can we blame for the beagle FTBFS? Do you still think we should keep it in main at all, now that we have tracker?
<seb128> pitti: there is a bzr branch which the new version which fixes the build issue
<seb128> https://bugs.edge.launchpad.net/ubuntu/+source/beagle/+bug/134341
<ubotu> Launchpad bug 134341 in beagle "beagle ftbfs" [High,Fix committed] 
<seb128> pitti: keeping it to main, yes, some people use it and nautilus can use it at runtime only if builds with libbeagle
<pitti> seb128: bzr fix> ah, cool
* pitti attacks http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_outdate.txt now
<seb128> pitti: Riddell gave the approvel for the new version but I didn't manage to upload before my holidays, I'll have a look today
<pitti> seb128: thanks
<pitti> Mithrandir: can you please fix the bluez-utils b-deps? we don't have libbluetooth-dev 3.19
<seb128> bah, freeze already in effect?
<Spads> Yep
<Spads> http://mid.gmane.org/20070920091544.GI6014@piware.de
<pkern> And the topic FWIW...
<seb128> that was not really a question
<seb128> rather a "doh, the freeze is already in effect"
<pitti> cjwatson: d-i on sparc failed with "sparc64: Unrecognized architecture"; any idea about that?
<seb128> I just read pitti's mail on the list
<cjwatson> pitti: util-linux bug I suspect
<pitti> cjwatson: lpia failed in an interesting way, too
<cjwatson> nothing relevant in d-i has changed
<cjwatson> lpia failures in debian-installer are not interesting :-)
<pitti> cjwatson: ah, fabbione mentioned an util-linux bug, but hmm
<cjwatson> pitti: I don't know if you saw, but fixes to the unionfs breakage are in git
<pitti> oooh
<cjwatson> and work for me
<cjwatson> just waiting for Ben to wake up and upload them
<cjwatson> soren: so, none of file-server, postgresql-server, and mail-server are going on the server CD, is that correct?
<cjwatson> soren: those seeds need to at least be inherited by supported
<cjwatson> fabbione: I don't believe we ever agreed that pkl would handle general sparc build failures. We agreed certain specific things that he would take over and according to e-mail that wasn't one of them
<cjwatson> General Sparc maintenance (to be spread amongst kernel, server and
<cjwatson> distro teams)
<pitti> mjg59: did you see the freetype FTBFS? will you fix it or should someone else care about it? (patch didn't apply)
<pitti> cjwatson: FWIW, I'm currently on a give-back sprint, working from the grounds up (libgnomevfs stalls a lot of things)
<Mithrandir> pitti: yes, I thought I uploaded bluez-libs too yesterday.  I'll fix it when I get into the office.
<pitti> cjwatson: can I pick your brain about seeds for a moment?
<pitti> cjwatson: component-mismatches has some troubles with Provides:, I think
<pitti> cjwatson: e. g. it wants to promote libfile-temp-perl, but that's provided by perl-modules
<pitti> cjwatson: similarly, links is provided by elinks
<pitti> cjwatson: is there an override I can apply to the seeds? like "we explicitly don't want this in main and know it's available otherwise"?
<cjwatson> pitti: you could try a ' * !libtemp-file-perl' entry to blacklist it though I'm not sure that'll do the right thing
<cjwatson> pitti: a better option might simply be to explicitly seed perl-modules somewhere
<pitti> cjwatson: oh, it does take provides from explicit seeds into account?
<cjwatson> if a dependency is already satisfied, it won't try to follow provides to satisfy it
<pitti> cjwatson: elinks is explicitly seeded, though
<cjwatson> it might be seeded further out than whatever is pulling in links
<cjwatson> the order is not entirely deterministic
<pitti> right, it's only in server-ship
<cjwatson> a blacklist might do the job
<pitti> cjwatson: I wouldn't like to put elinks into desktop just because dictionaries-common b-deps on it, so I favour the blacklist idea
<pitti> cjwatson: (alternatively, just ignoring it on the c-m output is a valid option for me, too)
<pitti> there's a lot more to ignore anyway
<pitti> hi Keybuk
<Keybuk> heya
<cjwatson> pitti: while catching up on mailing lists I noticed a discussion on debian-glibc about dpkg-preconfigure segfaulting when libc6 and libc6-i686 were upgraded out of sync
<cjwatson> pitti: and I was wondering if this might account for the mysterious debconf segfaults we've been seeing
* ogra is impressed, cjwatson you still read -users :)
* ogra thought he was alone there
<pitti> cjwatson: you mean libc6 and -i686 being out of sync, or prematurely upgrading both?
<cjwatson> ogra: I did a *lot* of mailing list catchup recently
<ogra> honeymoon leftover ? :)
<cjwatson> pitti: I think I mean the former but I was reading it at a seriously unpleasant time of the morning so take with pinch of salt
<pitti> hm, I would have expected a strict versioned dependency between them, but of course there's always a window in between
<soren> cjwatson: No, they belong on the server cd. I've just updated STRUCTURE to reflect this.
<pitti> cjwatson: however, the only solution that comes to my mind for this is to just merge the packages on i386, but that might be unpleasant for embedded, etc.
<cjwatson> libc6-i686 Pre-Depends: libc6 (= 2.6.1-1ubuntu4)
<cjwatson> I wonder if that's counterproductive - it widens the gap between the two being unpacked
<cjwatson> this is all just wild conjecture though
<ogra> is there any info anywhere what the openssh-server seed is supposed to do (apart from depending on openssh-server :) )
<cjwatson> ogra: task
<ogra> ah
<cjwatson> as you can tell from the way it has Task-* headers at the top
<pitti> Mithrandir: I put ubuntu-mobile-dev into universe for now, since it's uninstallable in main anyway
<Mithrandir> pitti: sure
<soren> cjwatson: Does the new STRUCTURE look better to you? pitti mentioned that the stuff in the new tasks should be removed from the server-ship seed, but I think I disagree. I can see why it logically makes sense, but the thing is that we in the tasks name specific binary packages, while server-ship refers to source packages, so if germinate can handle it, it's easier to manage this way.
<pitti> soren: s/should/might/, as I said, I'm not sure about your changes; it was just a suggestion to verify that
<soren> pitti: Right. Sorry :)
<elmo> where's the bug about compiz breaking the ability to change the number of workspaces?
<cjwatson> soren: what about mail-server?
<cjwatson> soren: but yeah, that's better
<iwj> pitti: Merging the packages just shortens the window of vulnerability.  dpkg can't update more than one file at a time since this is a filesystem not a transactional database.
<pitti> iwj: right, but there shouldn't be any debconf actions and the like in between?
<iwj> Well, yes, so you won't get the symptoms unless something goes wrong.
<cjwatson> I suspect it's really just a libc bug that installing disparate versions of libc6 and libc6-i686 breaks
<cjwatson> surely with all these versioned symbols and the like it can avoid that sort of thing
<cjwatson> soren: I think, as you say, it's OK to leave them in server-ship; germinate can certainly handle that
<iwj> Maybe I should write a robustness tester for essential packages, which does interrupted partial installs and then checks that the system still works.
<pitti> seb128: hm, http://launchpadlibrarian.net/9411808/buildlog_ubuntu-gutsy-i386.inkscape_0.45.1-1ubuntu4_FAILEDTOBUILD.txt.gz might be an intltool bug/regression/weird feature?
<pitti> seb128: did you happen to see this before by any chance?
<iwj> Merging the packages reduces the window of vulnerability, certainly.
<iwj> I should go and collect my bike now so I can have some lunch before the meeting.
<soren> cjwatson: Yes, mail-server should be there, too. That must have slipped somehow.
<Mithrandir> seb128: I have a weird bug with nautilus where it instist that all my icons must be on only one of my two screens.
<Mithrandir> seb128: is this a known bug or should I report it?
<ogra> pitti, can you approve e-meta ?
<pochu> some of my recent uploads have failed to build in some (but not all) archs, all of them because missing build-dependencies... is this expected to happen?
<ogra> hppa seems to miss some libs
<seb128> pitti: I think I know how to fix the inkscape build issue, let me have a try
<seb128> Mithrandir: not sure about the nautilus thing, there is some dualscreen bugs open but I tend to skip those usually since I don't have the setup to try
<Mithrandir> seb128: we should get C to buy you a second monitor, the
<Mithrandir> +n
<seb128> and a videocard ;)
<pitti> seb128: two 22" TFTs does sound kind of appealing :)
<seb128> pitti: right ;)
<Mithrandir> pitti: Lenovo is starting to ship some 22" ones with 1920x1200, for about 500
<ion_> mithrandir: Whoa, nice
<amitk> sweet
<Mithrandir> http://www.tcmagazine.com/comments.php?shownews=16091&catid=2
<pochu> could anybody retry a build of gcalctool on hppa please? should work now
<geser> pochu: afaik hppa needs some time till it's in a state you can start worrying about ftbfs there
<seb128> sparc and hppa seem to not cope with uploads at the moment
<pochu> geser: well, the wrong dependencies were libgconf2, and 2.20 built fine there
<pochu> geser: forget it, 2.19 built fine too
<seb128> build issues are due to arch all/any out of syncs due to too many uploads in a short time
<seb128> mainly
<seb128> I mean the GNOME build issues this week
<pitti> seb128: I'm doing massive sparc give-backs from the ground up (libraries to higher libs to apps)
<pitti> seb128: those fail mainly because of too lax build deps
<pitti> seb128: I think I can get it under control soon, though
<seb128> pitti: "too lax build deps"?
<seb128> pitti: good ;)
<seb128> I still get quite some build failure mails though
<pitti> seb128: yeah, I need several attempts sometimes
<pitti> seb128: I could figure it out more precisely, but that would cost me a lot of time
<pitti> seb128: sorry for the spam
* pitti wishes the publisher was faster :)
<seb128> that's alright
<Hobbsee> pitti: you forgot to feed it again!
* pitti pedals faster
<Keybuk> iwj, pitti, Mithrandir: ping
<pitti> eek, that
<pitti> Keybuk: #meeting?
<Keybuk> yup
<agoliveira> seb128: Hi. I have a question for you about my request to upload evince: why put the configure.ac patch on 03_hildon_interface.patch and not 02_autoconf.patch as it is now?
<seb128> agoliveira: autoconf as its name indicates is an autoconf run
<seb128> agoliveira: it has no source change
<seb128> agoliveira: the configure.ac changes are done in 01_lpi and 02_autoconf is a configure update by running autoconf
<agoliveira> seb128: One could argue that the autoconf run would depend on the changes on .ac but I understand your logic. Changes on the way.
<seb128> agoliveira: the autoconf run does depends of the configure.ac changes
<seb128> agoliveira: the idea is to have one patch having the source changes done manually and one which is done running autoconf which will likely conflict in new version
<agoliveira> seb128: Got it.
<seb128> agoliveira: that makes updates easier, usually the source changes apply or you want to fix conflicts
<seb128> and the autoconf update is something you don't need to bother about, just run autoconf, remove autom4te.cache and you have your update
<agoliveira> seb128: Another thing, you said that it don't install evince-hildon-ui.xml but it does.the data/Makefile.{in|am} patch selects between evince-ui.xml and evince-hildon-ui.xml deppending on the interface selected.
<seb128> agoliveira: so you changed the autoconf patch sementic to do something else than running autoconf without documenting it
<agoliveira> seb128: Agreed there.
<agoliveira> seb128: I'll comment it better.
<agoliveira> seb128: Thanks.
<seb128> Makefile.am changes are source modifications, they should not go in the autotools update one
<seb128> you're welcome
<iwj> soren: So the problem is that sl-modem-daemon has stopped working since tribe 5.
<TomaszD> BenC, hi. Do you plan to fix the ACX issue for gutsy? https://bugs.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/+bug/118539
<ubotu> Launchpad bug 118539 in linux-ubuntu-modules-2.6.22 "[regression]  acx does not load" [Medium,Confirmed] 
<soren> iwj: Right. NO CARRIER for the lose..
<TeTeT> iwj: yes, I'm around
<iwj> soren: Ah, you've actually tried it already ?
<soren> iwj: Yes, to see if pitti's restricted manager stuff worked.
<soren> It responds just fine to simple AT commands, but as soon as it actually needs the dsp, it seems to b0rk.
<iwj> TeTeT: The easiest test is probably to use cat.  Ie, get a current machine that's got one of the supported modems.
<iwj> Install sl-modem-daemon.  Then
<iwj>  cat /dev/modem &
<iwj>  cat >/dev/modem
<iwj> (in sudo).
<iwj> You should be able to type AT and get OK.
<iwj> Then (with no phone line connected) say  ATDT012345
<iwj> What it should do is sit there for a bit and they say NO DIALTONE.
<soren> I didn't spend much time on it, so I didn't instrument the code with more debug stuff, but it seemed to err out just after it asked the modem which codec's it supported.
<iwj> What it does for me is say NO CARRIER right away.
<TeTeT> iwj: works on my T40P
<iwj> soren: codecs ?  Um.  There are codecs in the card ?  I thought it was just an ADC.
<soren> iwj: No clue. That's just what the code said :)
<iwj> TeTeT: In current gutsy ?  Oh.  Lovely.
<TeTeT> iwj: the codec is needed for creating the sound for the modem
<iwj> TeTeT: I'm afraid I don't understand what that sentence means.
<iwj> Well, if it works on some hardware and not others then it's almost certainly a kernel regression.
<soren> TeTeT: Do you actually have it plugged into something?
<TeTeT> soren: not yet, but I can
<soren> TeTeT: Don't bother.
<TeTeT> iwj: let me walk over to the Toshiba M200 and test there
<soren> TeTeT: So your's waits for a while and then says "NO DIALTONE"?
<TeTeT> iwj: takes another two hours, the upgrade to gutsy is still running there
<TeTeT> soren: no, at is acknowledged with OK, atdt 1111 gives no carrier, as expected
<iwj> TeTeT: OIC, that was with some pre-gutsy.
<iwj> TeTeT: "no carrier" means it isn't working.
<soren> Ah, "NO CARRIER" immediately means it *doesn't* work.
<iwj> It should wait.  After all, it's supposed to be waiting for dialtone.
<soren> TeTeT: Could you try plugging it in and trying again?
<soren> It's unlikely, but not impossible, that it actually does check if it's plugged in before doing anything at all.
<soren> ...in which case, everything might be working fine anyhow.
<TeTeT> what's the hayes syntax for waiting for a dial tone? I need to dial 9, then the number
<IntuitiveNipple> ATD,
<IntuitiveNipple> the comma
<soren> W
<IntuitiveNipple> ATD9,num usually
<soren> Comma waits. W waits for a new dialtone.
<IntuitiveNipple> ahhh, ok, slight difference :)
<jdong> ATDW
<soren> Either will probably work, yes :)
<TeTeT> soren + iwj: atd9,15146597735 => NO CARRIER, ERROR
<soren> Alright.
<TeTeT> so broken it is - if you need me for another test, ping or call the number above :)
<soren> :)
<cjwatson> iwj: at least some level of encrypted filesystem support in d-i may be in gutsy; I spent some time over the last few days fixing up cryptsetup-udeb so that it might actually work
<soren> iwj: From l-u-m changelog:   * revert to stock snd-hda-intel code
<cjwatson> oh. I've been meaning to check into that as it breaks sound on my laptop; I'm sure there was a reason for it
<iwj> cjwatson: That's good to hear.
<cjwatson> kylem: do you have a reference for the reversion of snd-hda-intel?
<iwj> soren: Hmm.  that may be relevant.
<iwj> TeTeT: Thanks.
<tepsipakki> pitti: I have a new x-x-v-ati (6.7.193) ready for upload
<pitti> tepsipakki: ah, I remember that approval bug
<tepsipakki> pitti: yes, but it was for .192, this is new :)
<pitti> tepsipakki: ah; bug#?
<kylem> cjwatson, yes, it broke other hw.
<cjwatson> I figured
<kylem> s/broke/regressed
<tepsipakki> pitti: bug 138987
<ubotu> Launchpad bug 138987 in xserver-xorg-video-ati "[UVF]  new version, 6.7.192 + fixes from git master" [High,Fix released]  https://launchpad.net/bugs/138987
<tepsipakki> oh
<tepsipakki> I didn't file a new one
<tepsipakki> pitti: it's merged with debian, only the xserver-xorg-dev build-dep is lower because we have 1.3.0.0 not 1.4
<pitti> tepsipakki: just point me to a diff, that's enough for me
<linuxemacs> hi all
<soren> kylem: If I'm not much mistaken, crimsun had added a substantial amount of quirks to that particular driver.. Was any effort made to implement those?
<tepsipakki> pitti: http://users.tkk.fi/~tjaalton/dpkg/ati/ati.debdiff
<pitti> tepsipakki: oh, this time I meant the "current gutsy - your version" debdiff
<tepsipakki> ah, right
<tepsipakki> a sec
<tepsipakki> pitti: ok, url refreshed
<pitti> tepsipakki: why the removal of the ConstantDPI option? doesn't that potentially break upgrades?
<lamont> cjwatson: could you remove sysvinit/hppa from gutsy?
<pitti> lamont: can do, but that sounds a bit disruptive?
<lamont> I thought it was replaced, no?
* lamont does a little background work before saying more
<tepsipakki> pitti: well, mergedfb isn't supported anymore, so it's related to that ("Remove more mergedfb cruft")
<cjwatson> lamont: it's still there for all other architectures, so no
<tepsipakki> pitti: because of randr-1.2 -support
<pitti> lamont: btw, any idea about https://launchpad.net/ubuntu/+source/debian-installer/20070308ubuntu13/+build/385413? I was told that this is due to a recent util-linux regression
<lamont> ah.  that was it.  hppa has dapper sysvinit == essential which plays havoc with dist-upgrades of the chroot atm.  and no build record for hppa/gutsy, so...  I could re-upload it, or we could just remove it for hppa for the time being (iz not fatal to the effort, because of -stage0)
<pitti> tepsipakki: ok, go ahead
<tepsipakki> pitti: thanks!
<lamont> pitti: -5ubuntu1 fixed the ftbfs on sparc... sigh
* lamont looks at the sparc64 binary
<pitti> lamont: oh, great; /me tries a give-back then
<lamont> pitti: it _SHOULD_ work with a give back.  if not, thwap me and I'll stare at it until I produce -6ubuntu1
<cjwatson> lamont: we must have avoided this on every other architecture?
<pitti> lamont: cheers
<lamont> cjwatson: you built edgy and feisty on every other architecture
<pitti> cjwatson: oops, sorry for the spam; I accidentally gave back d-i lpia, too
<lamont> cjwatson: and the missing build records? see adam
<cjwatson> it's only the seventh time that's tried to build
<lamont> cjwatson: and here I thought third time was supposed to be the charm...
<lamont> cjwatson: building the current sysvinit on hppa would fix the problem.  sadly, launchpad won't do that right now.
<cjwatson> that needs to be fixed anyway, so ...
<lamont> cjwatson: right. and it's on cprov's plate
<lamont> which was being full of 1.1.9 signoff last I heard.
<cjwatson> that should finish soon
<pitti> seb128: hm, the pygtk FTBFS on sparc causes quite a few followup problems/ any idea about it?
<seb128> pitti: looking
<seb128> pitti: could you approve my inkscape upload? it fixes the ftbfs
<pitti> seb128: ooh, thanks! sure
<seb128> danke
* seb128 hugs pitti
<pitti> gnome-keyring-manager?
<seb128> pitti: that's a contributor patch to make it uses launchpad integration, should be safe to accept
<seb128> pitti: ok, so pygtk ftbfs is due to pygobject
<seb128> pitti: quick summary
<seb128> pygobject builds a -doc and a -dev in Ubuntu (and no -doc in Debian)
<seb128> we had a bug which make that the -doc was empty, I fixed it
<seb128> but the .xsl installed there are required to build the pygtk documentations
<seb128> so the options are
<seb128> - drop the -doc like Debian
<pitti> hm, and that breaks the tests on sparc?
<seb128> - install the .xsl in the -dev
<seb128> or make pygtk Build-Depends on python-gobject-doc
<seb128> I think that would break on any arch
<seb128> other arches built before the pygtk "fix"
<pitti> make[4] : *** No rule to make target `/usr/share/gtk-doc/html/pygobject/style.css', needed by `all-am'.  Stop.
<pitti> oh, I was misreading the log; you are right of course
<pitti> seb128: right, so we should fix it soon; build dep doesn't sound too bad, what do you prefer?
<seb128> well, build dep would work fine
<seb128> I was just considering if that was worth merging the -dev and -doc like Debian is doing
<pitti> .css into -dev is the most elegant probably
<pitti> but for beta we should prefer foolproof and easy solutions; lots of other bugs to work on, I figure
<seb128> right
<pitti> seb128: if we agree on merging the debian change (-doc -> -dev) in hardy, would that be too bad?
<seb128> I did the merge yesterday but didn't upload
<seb128> one issue is that python-gtk2-doc Depends on python-gobject-doc
<seb128> pitti: let's upload pygtk with a Build-Depends on python-gobject-doc for now
<seb128> I've it ready
<pitti> seb128: you rock
<pitti> darn, just too late for the publisher, but *shrug*
<seb128> pitti: uploaded
<pkern> Will 20070920.1 be able to install itself? And is cryptsetup/partman-crypto possibly fixed?
<pitti> pkern: unsure, untested; it's still too big, I still need to sort that out
<pitti> siretart: here?
<siretart> pitti: howdy!
<cjwatson> pkern: cryptsetup might be, I was just about to test that myself
<pitti> siretart: cdrkit trouble - see http://launchpadlibrarian.net/9412163/buildlog_ubuntu-gutsy-sparc.debian-installer_20070308ubuntu13_MANUALDEPWAIT.txt.gz
<pitti> siretart: (happens on all arches)
<siretart> yay. cryptsetup in main/the installer :)
<pkern> pitti: Will there be a reasonably sized build available later today?
<pitti> siretart: packages build-depending on mkisofs are unbuildable now :(
<pitti> pkern: I hope so
<pkern> cjwatson: Ok.
* siretart looks
<pitti> pkern: we need to find something big to throw out
<ogra_> firefox ?
<cjwatson> pitti: I can make d-i build-depend on genisoimage in my next upload, though obviously it's crap that it's unbuildable as it is
<pitti> siretart: the most correct fix, of course, is to change d-i to change the build dep and the command name, but I don't know how intrusive that is; cjwatson?
<cjwatson> it's not that bad
<siretart> pitti: according to apt, there are 2 packages build depending on mkisofs: debian-installer and etherboot
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/debian-installer/debian-installer-20070308ubuntu14>$ wcgrep mkisofs | wc -l
<siretart> pitti: I'd say let's fix them to use genisoiamge
<cjwatson> 12
<pitti> siretart: hm, might be easier at that point, yes
<pitti> I'm going to fix etherboot
<Kopfgeldjaeger> hi
<cjwatson> pitti: done in my tree
<ogra_> pitti: shouldnt the fonts together with oo.o being fixed gain us enough ?
<pitti> ogra_: apparently not, at least not for ubuntu; 20.1 already has those changes
<siretart> pitti: I'm already on it
<cjwatson> I'm waiting for new linux-ubuntu-modules first
<siretart> etherbot
<pitti> siretart: hm, so am I...
* ogra_ looks
<pitti> siretart: ok, I leave it to you; thanks!
* ajmitch waits for pitti to suggest to throw out f-spot :)
<siretart> currently testbuilding, will upload in a minute
<pitti> I'm afraid OO.o as a whole grew quite much in one of the last uploads, when java got enabled again
<ogra_> meh alternate 14M oversized ?
<Fujitsu> What percentage of the desktop CD is OOo?
* ogra_ fears for edubuntu
<cjwatson> pitti: current daily-live doesn't have the fixed ooo deps
<pitti> cjwatson: no, that's because -desktop was uninstallable for the last days, and I didn't manually rebuild live yet
<jdong> lzma time! :D
<pitti> cjwatson: should be installable again, but there's no point in rebuilding before I found something to throw out
<cjwatson> pitti: nor does it have the fixed fonts
<cjwatson> so I think there is absolutely a point in rebuilding to see where we start
<cjwatson> stand
<pitti> ok, *shrug*, triggering build
<iwj> pitti: I've just uploaded glibc 2.6.1-1ubuntu6 which I think ought to be approved.  It's a cosmetic change which I've carefully inspected, debdiffed, and tested.
* ogra_ is courious too, especially with the moodle stuff added now
<moquist> pitti: thanks (re: Moodle approval)
<pitti> ogra_: oh, want new edubuntus?
<ogra_> if meta -42 is there already
<pitti> ogra_: yes, it is
<pitti> ogra_: 43 not, though, but that's just moodle; easy enough to mentally add to the size, I guess
<pitti> ogra_: (and server CDs are fast to build)
<elmo> could we pretty please fix the getaddrinfo() before beta?
<pitti> bug#?
<elmo> LP #138466
<ubotu> Launchpad bug 138466 in glibc "getaddrinfo() sorts result - breaks round robin DNS" [Undecided,New]  https://launchpad.net/bugs/138466
<ogra_> pitti: err 43, sorry
<elmo> it should be possible to just change the default in /etc/gai.conf, tho I haven't confirmed that
<siretart> pitti: genisoimage testbuilt and uploaded
<pitti> siretart: genisoimage? I thought etherboot?
<siretart> s/genisoimage/etherboot/ of course
<pitti> elmo: any chance you could give this a try?
<pitti> we could sneak it into iwj's upload to avoid two new glibc
<pitti> ... uploads
<elmo> pitti: well, there's a demo program in the bug report, but err, yeah, I guess I could
<pitti> elmo: ah, cool
<pitti> iwj: ^ do you have some minutes to take a look at this, and if it's easy game, sneak it in?
<cjwatson> I think iwj is already familiar with the issue, judging by my debian-glibc mail folder ;-)
<pitti> seb128: I have a beagle in unapproved, but it's a new version and lots of changes; is this the one which won't ftbfs? did you sponsor this for Kevin?
<iwj> pitti: Ah, that.
<seb128> pitti: right, I did sponsor it
<iwj> I think I'm willing to do that.
<seb128> pitti: as said it was approved some time ago, if you think that's too late we will need to fix it by some other way
<seb128> pitti: but since beagle is not used anyway, only libbeagle is triggered by nautilus that would be easier to just accept it
<pitti> iwj: thanks; I keep your glibc upload in unapproved then and reject it when appropriate
<ogra_> cjwatson: remember we talked about squashing up /cdrom/pool in london ? it cuts off 15M
<iwj> pitti: If that's more convenient for you.
<ogra_> not really a big win
<pitti> seb128: if you are fine with it, I am, too
<seb128> mjg59: could you comment on http://bugzilla.gnome.org/show_bug.cgi?id=154029 and maybe attach the patch you used for Ubuntu if they are different?
<ubotu> Gnome bug 154029 in mouse "Add configuration support for touchpads (synaptics)" [Enhancement,New] 
<seb128> pitti: cool
<elmo> iwj/piiti: oh, we apparently don't have a new enough glibc, to pull in the gai.conf option :(
<pitti> iwj: just to avoid two consecutive uploads and builds
<iwj> The difficulty with any glibc change is that builds take an age.
<iwj> Are you happy to have this new one late today or even tomorrow ?
<iwj> elmo: Oh, damn.
<pitti> iwj: I am, yes
<elmo> iwj: use ronne?
<cjwatson> ogra_: sorry, remind me?
<Mithrandir> iwj: uh, they take an age?  They shouldn't take more than 20 minutes or so?
<Mithrandir> which while is a bit isn't glacial in any way.
<iwj> Mithrandir: IME takes 2h with fully primed ccache and everything in RAM.
<ogra_> cjwatson: making pool on the CD a squashfs image
<ogra_> and loop mounting it from d-i
<pitti> iwj: the current change looks good, so when I hear a "no dice with the dns sorting bug" from you, I'll accept it
<iwj> pitti: Thanks, I'll get back to you.
<cjwatson> ogra_: interesting though I'm concerned about decreased reliability
<Mithrandir> iwj: 2:30 on the buildds, it seems.  I tend to build on faster machines. ;-)
<iwj> elmo: Do you have any more references about that sorting bug ?  Is there a patch I can import ?
<cjwatson> by necessity, squashfs blows up less recoverably when there are small errors on the CD
<ogra_> cjwatson: well, i had hoped for more than 15M :)
<iwj> You'll have seen from my Debian TC contributions that I have a strong view on this question ...
<cjwatson> in d-i, you might well be able to get by anyway if you don't need the broken bits
<cjwatson> ogra_: yeah, I don't think it really justifies it
<elmo> iwj: 2.6.1-2 in Debian, introduced any/submitted-rfc3484-sortv4.diff which AIUI allows for a toggle swich in /etc/gai.conf to restore sane behaviour
* ogra_ shrieks 
<iwj> elmo: Investigating, thanks.
<ogra_> 757M
* ogra_ cries
<cjwatson> I see that having an add-on CD simply encourages bloat ;-)
<ogra_> well
<pitti> ogra_: hm, edubuntu-desktop is not installable on amd64 due to gobby, so the amd64 live CDs will be outdated (also size-wise); investigating...
<ogra_> the bloat comes from mesa
<cjwatson> (this is a semi-serious point actually. when your constraints are less tight, there's much more temptation to rush to fill them and then you have trouble later.)
<ogra_> (or part of it)
<cjwatson> shouldn't gobby be demoted again? IIRC there were never MIRs for its dependencies
<ogra_> huh ?
<ogra_> its fine in i386 since quite a while
<ogra_> and the deps had MIRs
<pitti> libobby-0.4-0 |    0.4.4-3 |         gutsy | i386, lpia
<pitti> libobby-0.4-0 |    0.4.4-3 | gutsy/universe | amd64, hppa, ia64, powerpc
<pitti> go, change-override
<cjwatson> ah
<cjwatson> ok, fair enough
<cjwatson> I need to produce a report for that inconsistency
<pitti> meh, it might be just me, but change-override.py is hideously inconsistent; if only I could see a pattern how it fails for a bug report
<pitti> ogra: hopefully fixed now
<ogra_> thanks
<cjwatson> pitti: yeah, I've had a nagging concern for a while
<AlinuxOS> Hello asac
<pkern> cjwatson: The MIRs for the deps were approved a year ago, but as Gobby wasn't in main and thus not seeded...
<cjwatson> on the contrary it's been seeded for a long time
<cjwatson> not in main does not imply not seeded
<cjwatson> though hmm, I might be wrong that it's been seeded for a long time, I don't see it in the history
<cjwatson> but at any rate not in main doesn't mean not seeded, because promotions are only done by hand, they're not automatic after seeding
<seb128> cjwatson: about bug #136665, do you know if there is a way to try this dialog easily from a "standard desktop"?
<ubotu> Launchpad bug 136665 in gtk+2.0 "Installer not navigable from keyboard" [Undecided,New]  https://launchpad.net/bugs/136665
<seb128> cjwatson: ok, looks like that installing ubiquity works fine ;)
<iwj> pitti: OK, I think that patch from elmo is good, and I've changed the default in it.  It'll probably be several hours building now, since my machine has been doing some other things since the last libc build.
<iwj> elmo: ^
<pitti> iwj: awesome, thanks
<elmo> iwj: use ronne? :)
<cjwatson> seb128: yeah, I was going to suggest exactly that
<pitti> elmo: btw, do you know what's wrong with artigas? https://launchpad.net/+builds complains about a socket timeout
* cjwatson once again giggles at the breezy goal "ExpandingUniverse"
<asac> pitti: i see that i missed the ro-RO and he-IL locales from unavail ... but where the hell was the ka-GE locale hidden?
<pitti> asac: xpi/ka.xpi -> xpi/ka-GE.xpi :)
<cjwatson> o/~ so pray that there's intelligent life somewhere out in space, 'cos there's bugger-all down here on earth o/~
<asac> its not in locales.list ... nor in unavail.
<asac> pitti: why?
<pitti> asac: because it has always been called like that
<asac> pitti: but it wasn't in the locales.list file
<pitti> asac: if you wnat to rename it, we need C/R/P and a transitional package, and I didn't think that was worth the effort
<elmo> pitti: fixed
<asac> pitti: no i don't want to rename
<iwj> elmo: Yes, yes, but the faff involved will be much faffier with added faff.
<pitti> elmo: cheers (I'm currently doing lots of give-backs on sparc to get it back into shape, so appreciated)
<asac> pitti: i want to know why its not in the locales.list file of 2.0.0.1... that i have here
<iwj> elmo: At least this way I can get on and do something else while the computer does the hard work.
<elmo> iwj: *shrug* k
<pitti> asac: they might have reintroduced the translations at some later time in 2.0.0.x?
<iwj> My DSL uplink isn't good enough so I'd have to mess about with rsync.  Oh for a good distributed filesystem etc.
<iwj> (rsync> or worse, patch)
<pitti> iwj: patch -p1 < debdiff FTW :)
<iwj> elmo: Do you have an easy setup where you could test my libc for me ?  Or a test case ?  There are some in that TC thread but I'm not sure I quite believe them.
<iwj> If you don't have anything then fine, I'll dig them out of that thread and review them.
<asac> pitti: thats really too strange for me to bother ... the version i have here is the version that was released before :/ ... 2.0.0.1ubuntu-1
<pitti> asac: hm, I never really pay attention to that .list file
<elmo> iwj: http://people.ubuntu.com/~james/tmp/test.c
<asac> pitti: to what do you pay attention? there is not even a ka-..xpi in the source i have here
<elmo> iwj: is what I'm using, it's from the bug report, and seems to demonstrate the broken behaviour on my gutsy laptop
<asac> pitti: oh i think i see the source of this confusion
<mjg59> seb128: Thanks for that
<mjg59> pitti: Hrmph. I'll look into it.
<pitti> asac: I just look at the files in xpi/, or rather, I look at the previous ones and rename them on-the-fly when downloading new ones
<asac> pitti: i did that
<asac> but ...
<asac> pitti: feisty  2.0.0.1ubuntu-1 was released on 2007-02-06 ... while gutsy  2.0.0.1ubuntu-1  on 2007-04-20
<asac> pitti: so it looks like you added more locales in the gutsy upload
<asac> but let me check ;)
<pitti> asac: no, I didn't add any new locales in today's upload
<iwj> elmo: Yep, thanks.
<iwj> (and adnshost proves to me my nameserver is doing the right thing)
<pitti> asac: I just renamed those three back to their previous names and removed the two now existing ones from unavail.txt
<asac> pitti: well thats fine ... lets not bother ... its just crazy that there is no sign of those locales here on my copy of 2.0.0.1ubuntu-1. thanks for fixing it.
<pitti> asac: np (btw, I just did another followup upload to rescue -nn-no)
<asac> ok
<pitti> yay, stuff on sparc starts to become buildable
<asac> pitti: i found that ka-ge was an unavail language ... but it wasn't in unavail.txt
<fabbione> cjwatson: ok well it was my understanding that pkl was going to take over. in any case somebody from distro should.
<fabbione> cjwatson: sorry if i misunderstood or I just don't remember it righjt
<cjwatson> fabbione: fortunately this was all carefully documented in e-mail :-)
<fabbione> right even
<cjwatson> my expectation was that this sort of thing would be absorbed as general distro work, not given to a single person
<fabbione> cjwatson: oh yeah.. it's all ok with me. again. sorry if i didn't remember it right
<pitti> mjg59: xft FTBFSed with patch apply failure, too
<cjwatson> just as we don't (any more) have a single person responsible for amd64 build failures
<mjg59> pitti: Sigh. I get confused by these patch systems.
<mjg59> pitti: Sorry about that, I'm on it now
* pitti hugs mjg59
<pitti> mjg59: yay quilt
<mjg59> That's odd. I seem to have fixed the cairo one. Maybe I uploaded the wrong package.
<alex-weej> mjg59: are you talking about the David Turner patches for LCD filtering in Xft/Freetype/Cairo?
<alex-weej> it improves unhinted rendering considerably
<alex-weej> on your ubuntu-devel post
<mjg59> alex-weej: That's fine, but if I enable sub-pixel rendering we default to full hinting
<mjg59> So the unhinted case is somewhat less interesting
<alex-weej> mjg59: well that's only because someone decided that "LCD" means "full hinting"
<ScottK> Is network-manager seizing control if interfaces it didn't configure on upgrade by design or a bug?
<alex-weej> if you actually configure hinting and AA settings individually it's definitely interesting
<alex-weej> see dpkg-reconfigure fontconfig-config :)
<mjg59> alex-weej: I'm concerned about the default case, not anything else
<alex-weej> mjg59: LCD isn't the default case, is it?
<alex-weej> "Best Shapes", no?
<mjg59> Most people with TFTs will enable it
<alex-weej> mjg59: i thought the technique was patented anyway
<mjg59> So's the bytecode interpreter, but.
<alex-weej> hence why we've traditionally had to install third party packages to get it
<alex-weej> hah!
<alex-weej> Karl was trying to convince me that Ubuntu didn't ship the BCI
<alex-weej> anyway...
<alex-weej> is UDS before release?
<towolf> mjg59: concerning your revert of the font patches,
<cjwatson> alex-weej: no
<Keybuk> what does the patch have to do with Hinting?
<mjg59> alex-weej: No
<towolf> I posted a comparison on the forums, that might illustrate the quality difference
<Keybuk> Hinting is aligning fonts to fit the appropriate grid for the display
<towolf> http://ubuntuforums.org/attachment.php?attachmentid=43910&d=1190296125
<alex-weej> towolf: let's see
<mjg59> towolf: It's unambiguously worse at rendering in a case we use by default
<Keybuk> sub-pixel makes the grid have a resolution three times higher
<towolf> the feisty rendering is on the right
<alex-weej> it's all about this, right? http://www.grc.com/cttech.htm
<Keybuk> mjg59: you're complaint is specifically about the look of Monospace fonts, no?
<mjg59> Keybuk: No, my complaint is about vertical glyphs no longer being pixel-aligned
<Keybuk> mjg59: that's because you turned on *sub*pixel hinting
<towolf> mjg59: so in my image you would prefer the right column?
<Keybuk> if you want them pixel-aligned, use a non-*sub*-pixel setting?
<mjg59> Keybuk: Argh. No. We don't have a UI mechanism for controlling whether hinting is sub-pixel or not.
<towolf> Keybuk: he seems to prefer "stem snapping"
<mjg59> We only have a UI mechanism for controlling whether rendering is sub-pixel or not.
<Keybuk> mjg59: hinting is irrelevant, this is about smoothing
<Keybuk> you want a UI option that provides sub-pixel smoothing based on hinting done at pixel resolution?
<mjg59> No, I want my fonts to work.
<Keybuk> (which provides incredibly out-of-shape results, but happens to make Monospace look quite crisp)
<towolf> Keybuk: when stems are snapped by the hinting mechanism, the filtering doesn't kick in on the stems
<towolf> that why they are plain black
<mjg59> Keybuk: So no, I haven't turned on subpixel hinting.
<mjg59> How could I?
<alex-weej> i don't even think there is such a thing
<Keybuk> mjg59: what I'm concerned about is that you've reverted a change because you don't happen to like it
<alex-weej> there is hinting, and there is subpixel AA
<alex-weej> Keybuk: hold on a second
<Keybuk> without any consideration to what effect is intended
<mjg59> Keybuk: It's not a matter of "liking". It's a regression in a common use case.
<mjg59> A week before beta
<Keybuk> mjg59: it's a regression that our font rendering now matches that of Windows XP/Vista and Mac OS X ?
<alex-weej> FWIW, subpixel AA looks terrible without Scott's patches, as curved edges (i.e. stems that can't be hinted) gain yellow tinges
<cjwatson> Keybuk: in fairness there were a lot of complaints here that didn't seem to be addressed by anyone who knew about them
<Keybuk> ie. a regression that we now have comparable font rendering to commerical products?
<cjwatson> #ubuntu-devel yesterday was full of "my fonts are broken"
<Keybuk> cjwatson: reviewing the logs, I saw one complaint by ion_
<mjg59> Keybuk: It's a regression that my fonts become less readable and give me a headache (for the first time in five years), yes
<cjwatson> hmm, I'm sure I remember a lot more than that
<Keybuk> cjwatson: it was a very long complaint, repeated often
<mjg59> Which is an indication that the change should actually be discussed, rather than uploaded at this short notice
<seb128> I didn't like the way they were yesterday
<seb128> they looked blurry
<Keybuk> seb128: that's what anti-aliasing does
<Keybuk> if you don't want blurred fonts, there's a "NO ANTI-ALIAS" option
<towolf> mjg59: it get's a lot more interesting for fonts other than vera/dejavu, i.e., where you don't have clean vertical stems.
<Keybuk> if you like a little bit of blur round the edges, there's a "Greyscale" option
<seb128> Keybuk: well, default setup should look good for sure no?
<towolf> mjg59: the old style is a hack, then
<alex-weej> the old style did no filtering
<towolf> mjg59: http://ubuntuforums.org/attachment.php?attachmentid=43911&d=1190296417
<Keybuk> seb128: yes, I agree; and every single person I tried the patches on said that the usual non-monospace fonts looked *much* better with the patches than without
<seb128> Keybuk: it's not easy to make a estimation of the number of people who like something or not
<mjg59> Keybuk: At the point where the code is intelligent enough not to have a significant reduction in quality on a common use case amongst our developers, I'm happy with it
<seb128> that needs some time for testing and some sort of pool to ask what users who tried prefer
<cjwatson> Keybuk: did you tell them which one was your change?
<Keybuk> the simple fact is that with the patches, the rendering of the fonts matches (to a few degrees anyway) the output on Mac OS X and Windows XP
<seb128> and should not be made just before a freeze like that I think
<cjwatson> (or indicate by non-verbal cues)
<Keybuk> cjwatson: no
<siretart> cprov: sorry, wrong channel, actually wanted to ask you here
<towolf> alex-weej: yes, it did, just not on the stems, which cover the biggest area of a glyph
<alex-weej> towolf: no, it did no *filtering* http://www.grc.com/cttech.htm
<Keybuk> perhaps we need a middle option for "broken sub-pixel hinting"
<cprov> siretart: np.
<alex-weej> Keybuk: it's this: http://www.grc.com/cttech.htm
<mjg59> Keybuk: Please don't imply that the behaviour I want is broken. It's unnecessarily emotive.
<Keybuk> mjg59: the behaviour you want is caused by code being #ifdef'd out :p
<mjg59> Keybuk: It's ifdefed out for a reason
<alex-weej> it's ifdef'd out because of patent reasons
<mjg59> alex-weej: It's ifdeffed out because cairo and xft upstream have not taken those patches yet
<siretart> cprov: thanks!
<alex-weej> it's the only way to equalise colour balance while maintaining subpixel positioning
<alex-weej> and hence why people always whinge that "linux font rendering is worse than Windows/OS X"
<alex-weej> you have an opportunity here to silence those people
<mjg59> Keybuk: Keith believes that the rendering example I showed him is broken
<mjg59> And he's Xft upstream
<alex-weej> the hinting algorithm is broken i guess
<Keybuk> mjg59: did you show keith the detailed papers explaining why it's rendered like that?
<towolf> alex-weej: you're a bit confused, the old lcd mode, it filters, but not the stems
<towolf> alex-weej: ftp://ftp.tuebingen.mpg.de/kyb/towolf/Bildschirmfoto-1.png
<alex-weej> towolf: what do you mean by "filters"?
<mjg59> Keybuk: I'm fundamentally uninterested in whether it's theoretically better or not. It quite clearly isn't in this case!
<asac> pitti: actually ka-ge is now again "Transitional package for unavailable language  "
<Keybuk> mjg59: to me it's incredibly clearly better
<mjg59> Keybuk: I'm talking about once very specific case here
<asac> pitti: in 2.0.0.7+1-0ubuntu1 (m-f-l-all)
* ogra_ trusts his eyes and they tell me they see blurry fonts on all LCDs around now
<alex-weej> towolf: what do you mean by "old", too? :P
<Keybuk> what is the very specifc case?
<mjg59> Keybuk: The case I end up using for most of the day, which is a small monospaced font
<pitti> asac: really? not here...
<towolf> alex-weej: the pre-patch era LCD filtering code in Xft and Cairo
* alex-weej is being selfish and would like to not have to use third-party debs to get balanced subpixel AA
<asac> pitti: https://edge.launchpad.net/ubuntu/+source/mozilla-firefox-locale-all/2.0.0.7+1-0ubuntu1
<Keybuk> mjg59: I said right at the top, the only case I've ever seen where people have a complaint is a small monospaced font :p
<Keybuk> <Keybuk> mjg59: you're complaint is specifically about the look of Monospace fonts, no?
<pkern> Monospace AA on OS X is disgusting... so please don't put that up as an example. ;)
<pitti> asac: I think that's a LP bug; apt-cache show DTRT here
<mjg59> Keybuk: Right. And, in this specific case, the change is clearly a regression in functionality.
<Keybuk> mjg59: so we could tackle this quite simply, with a fonts.conf adjusting the hinting for monospace fonts, no?
<alex-weej> pkern: everyone has their opinions
<alex-weej> Keybuk: it has nothing to do with just monospace fonts
<Keybuk> alex-weej: do you think non-monospace look worst?
<mjg59> Keybuk: My /perception/ is that the other fonts have better shaping but lower readability now
<alex-weej> Keybuk: any hinted text looks terrible to me.
<ogra_> for me its all fonts
<mjg59> But I spend much less time looking at that than the monospace case, so I haven't tried to quantify that in any way
<alex-weej> http://img363.imageshack.us/img363/9960/screenshotfreenodeubuntno7.png
<towolf> mjg59: what's the problem, you know you can always enable BCI hinting without any AA?
<towolf> like in the good old days.
<mjg59> towolf: Because I want sub-pixel AA. It makes my fonts look nicer.
<Keybuk> mjg59: you have proper sub-pixel AA now though
<alex-weej> mjg59: do you have a rendering of how it was when it was "nicer"?
<mjg59> Keybuk: No, I now have sub-pixel AA plus sub-pixel positioning
<Keybuk> you want sub-pixel anti-aliasing with hinting done on a pixel grid?
<mjg59> Previously, a fully hinted font would align to pixel boundaries. Now that's not the case.
<towolf> mjg59: but it means we will go back to the right column in this screenshot: http://ubuntuforums.org/attachment.php?attachmentid=43911&d=1190296417
<Keybuk> (the difficulty there is you then need another option, None/Slight/Medium/Full Hinting and [ ]  Hint on sub-pixel alignment)
<alex-weej> towolf: btw earlier were you suggesting that the filter somehow doesn't apply to "stems"?
<alex-weej> mjg59: can you see the yellow tinges everywhere on the right column?
<towolf> alex-weej: because xft and cairo activated snapping since the filter code was so broken that it leads to intense color fringing.
<alex-weej> that's because there's no colour balancing
<towolf> alex-weej: as you can see in the Cambria screenshot above
<alex-weej> towolf: do you actually know what i am talking about when i say "filter"?
<towolf> alex-weej: nowaqdays with the turner patch we do not need the stem quantization anymore
<alex-weej> towolf: i mean the thing that spreads pixel intensity into 3 or 5 pixels around it
<towolf> alex-weej: yes
<bddebian> Heya
<alex-weej> towolf: where did you get that test app from?
<towolf> alex-weej: its "ftdiff" from freetype-demos
<alex-weej> cheers
* ogra_ would just like to have fonts again that dont make his eyes tear after 20min of work, no matter what theories/techniques are involved
<towolf> alex-weej: when the source glyph does not cover fractional pixels (it's blown up originally) then there is nothing to filter. and quantizaiton does this.
<pitti> seb128: yay, pygtk built; I have a list of the ~ 15 rdepends which I'll give back on sparc once this gets published; thanks again
<seb128> pitti: you're welcome
<alex-weej> towolf: ok, sounds interesting but wrong as it sort of modulates a blur -- parts of your font look more blurry than others
<Ng> aren't small fonts generally supposed to be excluded from AA anyway?
<alex-weej> but I use unhinted anyway
<alex-weej> Ng: on Windows XP.
<alex-weej> by default. (ugly)
<mjg59> Ng: No
<mjg59> AA can do a huge amount to improve the readability of small fonts
<Keybuk> Ng: depends who you ask
<ogra_> you could force that once in fontconfig iirc
<Keybuk> (arguably small fonts benefit more from sub-pixel hinting since there's three times as much resolution available :p)
<ogra_> (no AA for small fonts)
<Keybuk> ogra_: yeah, I thought there was a conf.avail for that, but I can't see it right now
<Keybuk> it exists for certain fonts, but not globally
<Keybuk> (Bitstream Vera, notably)
<alex-weej> towolf: how did you activate the "legacy LCD filter"?
<Keybuk> uh, sorry, that's hinting it disables
<alex-weej> Keybuk: use dpkg-reconfigure fontconfig-config
<alex-weej> oh wait sorry, it doesn't have an option for what you said nm
<Keybuk> alex-weej: the debconf stuff symlinks from /etc/fonts/conf.avail to conf.d
<towolf> alex-weej: "l" key
<towolf> alex-weej:  "legacy LCD filter" is unpatched freetype, cairo and xft
<alex-weej> yeah it looks bad
<towolf> alex-weej: yes.
<alex-weej> not quite as bad as unfiltered though
<alex-weej> tbh that's be owned -- i didn't even know there was a legacy filter -- i thought it was unfiltered heh
<towolf> err, on anytghing else than sanserif fonts it certainly does
<ScottK> pitti: Would you please give poker-network 1.2.0-1ubuntu1 a push out the door.
<towolf> and on fonts that don't have massive hinting tables
<towolf> manual hinting tables
<alex-weej> towolf: LCD filtering != hinting though, right?
<towolf> alex-weej: yeah
<alex-weej> so what do you mean?
<towolf> alex-weej: it's two separate mechanisms
<alex-weej> yes i know
<towolf> alex-weej: that have to harmonize
<alex-weej> wow
<alex-weej> for hinted text it looks really bad actually
<alex-weej> everything goes greenish
<towolf> alex-weej: full (hint_strong), normal (hint_medium), do not go well with the turner patches
<towolf> alex-weej: slight is best, IMO
<alex-weej> i think my monitor's gamma is fubared though
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<alex-weej> for hinted vera @ 10pt/96dpi i can't tell the difference between light and default
<alex-weej> nor the difference between legacy and unfiltered
<towolf> alex-weej: and, that's the crucial point: when GNOME's prefs are set to "slight", the autohinter with all it's splendor is activated automatically in hint_light mode
<alex-weej> ew
<alex-weej> autohinter is terrible
<alex-weej> it fucks up our ligatures big style
<towolf> alex-weej: the prefs dialog in "Appearance" is just badly designed.
<Keybuk> isn't the autohinter supposed to be not-as-good as the bytecode intepreter?
<alex-weej> towolf: +1
<alex-weej> Keybuk: the autohinter is much more subtle with what it does
<towolf> Keybuk: wrong, terribly wrong.
<alex-weej> towolf: !?
<Keybuk> I understood that the bytecode intepreter followed the instructions in the font files
<pitti> mjg59: thanks for the fixes, accepted; I leave the eventual decision which renderer to use to the discussion between Keybuk and you, though :)
<towolf> Keybuk:  the autohinter si a lot less aggressive  than the old win95 days manual hints.
<towolf> Keybuk: say, arial, timesnewroman, etc
<mjg59> pitti: Thanks
<alex-weej> so FT quite clearly has an option for choosing a filtering type
<alex-weej> as i am toggling it with ftdiff
<towolf> Keybuk: they were made with monochrome rendering in mind.
<Ng> fwiw, after using the cleartype-style rendering for a day, I think it's superior. Interestingly, I think it makes the most difference for my little monospace fonts (lucida typewriter 6.5pt @105dpi)
<towolf> Keybuk: how windows looked for years.
<towolf> Keybuk: nowadays both windows (wpf) and osx disregard the bci hints completely
<alex-weej> towolf: that's a different argument, though. people get VERY attached to their way of font rendering
<ion_> keybuk: I wasnt the only one complaining.
<towolf> Keybuk: i'll make a waterfall example for you
<towolf> alex-weej: yes, the old-school blur haters
<alex-weej> towolf: you don't mind a tiny drop in contrast for increased readability, but you still use the autohinter?
<towolf> alex-weej: light autohinter with turner-style filtering is a very good middle-ground actually
<towolf> alex-weej: OSX is really muddy
<alex-weej> towolf: maybe. the autohinter screws up ligatures though and renders f differently to ff
<towolf> alex-weej: what?
<towolf> alex-weej: ligatures are perfect, here
<mjg59> As I said, I'm not fundamentally opposed to the change. What I am opposed to is making a user-visible change of this magnitude with no discussion amongst the development community, shortly before release
<Keybuk> mjg59: I made it shortly before *BETA*
<mjg59> These patches aren't new. There's no reason for it to be done this late.
<Keybuk> it's not a API or ABI change, so is less relevant to the development community
<mjg59> Keybuk: So well after feature freeze
<Keybuk> it's a visual change, which is more relevant to get opinion from the user community
<Keybuk> Beta is the first release which our users tend to see
<Keybuk> so this seems to be a perfect time to make the change
<Keybuk> since there's still plenty of time to revert it before Release if our user opinion is overwhemlingly negative
<Keybuk> (artwork, also visual, is rarely ready before Beta)
<mjg59> And the immediate reaction is "It causes regressions"
<alex-weej> mjg59: i'd guess a vocal minority
<Keybuk> mjg59: really?  so far I'd say that there's a minority reaction against it
<mjg59> I'm happy to admit that the developer base is likely to have a different view of this than our naive users
<alex-weej> put it this way, those who really REALLY care about their fonts don't already use Ubuntu
<Keybuk> mjg59: making this change at the beginning of the release cycle, or FF, wouldn't make a difference
<towolf> mjg59: we have a history of mutlipage forum threads offering patched debs, to great acclaim, since edgy
<Keybuk> since we'd still have to wait until after Beta to make the decision
<mjg59> Keybuk: Which would give us plenty of time before beta to get it into a state where the developers aren't unhappy
<towolf> mjg59: mlind has been providing those debs since then , and they've been welcomed by many
<alex-weej> including me!
<alex-weej> mlind is a god
<mjg59> These fonts are genuinely giving me a headache right now
<towolf> alex-weej: err, he is a deb compiler
<alex-weej> towolf: same thing :P
<alex-weej> mjg59: perhaps too much thinking about them is giving you a headache? :P
<Kopfgeldjaeger> if, lets say, kernel 2.6.23 will be finished in 1 hour, will it get it into gutsy or is the KernelFreeze meant for the current *.22 kernel?
<Keybuk> mjg59: ok, that counts as one negative vote ... 7,999,999 votes to go? :p
<mjg59> Keybuk: No
<towolf> mjg59: that might be because the vera fonta suck balls.
<alex-weej> ask mr. shuttleworth, that's what it comes down to in the end, right?
<mjg59> Ergh. Sorry.
<mjg59> Kopfgeldjaeger: No.
<mjg59> towolf: They're what we ship by default.
<towolf> *fonts
<towolf> mjg59: :-)
<mjg59> So, that's the case we have to work with
<cjwatson> alex-weej: no, the technical board. note that this is two members of the TB having an argument ...
<Trewas> one users option about the font issue here: IMO the "new" cleartype-like font rendering is clearly worse than the old and I noticed the blur immediately... fwiw, at home I am using XP and feisty on the same computer and feisty has clearly better font rendering than xp's cleartype (though I am using microsoft fonts in feisty, not the default bitstream fonts, if that changes something)
<Keybuk> mjg59: I argue that we keep these patches in for Beta, and evaluate at the first opportunity immediately after what the public reaction is to the fonts
<towolf> mjg59: better fontconfig default will help, though.
<Keybuk> (which was my plan)
<towolf> mjg59: just patching with adjustments is not enough, and
<cjwatson> Kopfgeldjaeger: we're shipping 2.6.22, it's far too late to move to a new upstream
<towolf> mjg59: that is likely the source of your headache
<Keybuk> I was also half way through a mail to ubuntu-devel explaining with screenshots the differences between the two when you reverted them <g>
<alex-weej> it's already been reverted?
<towolf> *without
<alex-weej> oh yay, status freaking quo
<mjg59> Keybuk: It's absolutely undeniable that this change reduces the legibility of a common (admittedly not the most common) font use case.
* Hobbsee has found that whether it's good or bad depends entirely on the font.
<Keybuk> mjg59: disagree, for me it improves the monospace font
<Keybuk> it makes it quite a bit more readable for me
<Keybuk> I can actually see "m" now, it's not a filled-in block :p
<mjg59> Keybuk: No, there really isn't any argument over this. It reduces the definition and contrast.
<ogra_>  Keat what resolution ?
<Keybuk> mjg59: see also "anti-aliasing"
<ogra_> Keybuk: at what resolution ?
<Keybuk> for definition and contrast, see "no anti-aliasing"
<Keybuk> ogra_: 125dpi
<mjg59> Keybuk: No, you're introducing a false dichotomy.
<towolf> Hobbsee: that's true
<cjwatson> mjg59: I think arguing that there is no argument when you're busy having one is perhaps a little disingenuous
<ogra_> it makes them blurry and badly readable on 1024x768 at 96 or 100 dpi
<ogra_> for me
<Keybuk> (and can we stop using words like "blurry" :p  anti-aliasing *is* blurring to fool the eye to think there's a curve there)
<mjg59> Keybuk: Vertical lines are now blurred.
<ogra_> it produces a quite visible blur which i didnt have before the update
<Keybuk> mjg59: no, vertical lines now include a sub-pixel component either side in many cases
<towolf> Luxi is a nice series, too bad it's in non-free.
<mjg59> Keybuk: Right. They're blurred.
<Keybuk> I don't think we're going to win any "pro" vs. "con" arguments here
<Keybuk> the real decision is whether we use Beta as a time to get a wider opinion than yours and mine
<mjg59> Keybuk: Anti-aliasing also introduces blurring, but it does so with the aim of introducing information that wasn't there before
<towolf> Keybuk: when the outline of the glyph says it whould be as wide as it should be.
<towolf> Keybuk: which gains us actual proportions between bold and non-bold
<towolf> and not jumpy, either 1px wide or 3 px wide rendering
<towolf> err, 2px too
<towolf> mjg59: AA and lcd-AA is the same thing with more sophistication
<mjg59> towolf: This isn't about AA.
<Keybuk> for me, "m" is now rendered as brown-blue-red-blue-orange-blue
<towolf> mjg59: did you know that aa is lcd rendering with R=G=B, nowadays?
<Keybuk> before it was rendered as black-dark grey-black-black-dark grey
<Keybuk> so I utterly reject your assertion that this doesn't introduce information that wasn't there before
<mjg59> Keybuk: That's not the behaviour I saw. My ms have always been rendered using sub-pixel information around the cruves.
<Keybuk> mjg59: around the curves yes, not between the downward strokes of the "m"
<Keybuk> which made it look like a shaded block with a bit of a bump on top
<mjg59> Keybuk: Hang on, let me find a machine without this update.
<towolf> Keybuk: just enable full hinting and you will get this quantization effect back.
<Keybuk> towolf: ?
<mjg59> Keybuk: Ok. The effect I have with ms on the old code was "white, black, white, black"
<alex-weej> 2 stems?
<mjg59> With the new code I have "Blue, pale blue, purple, pale blue, purple, pale blue"
<alex-weej> mjg59: right, but that = positional information
<alex-weej> as it goes through your RGB grid
<Keybuk> http://people.ubuntu.com/~scott/Terminal-1.png
<Keybuk> vs
<Keybuk> http://people.ubuntu.com/~scott/Terminal-2.png
<alex-weej> looks like -2 is unhinted...?
<Keybuk> alex-weej: probably, since the sizes reduce
<Keybuk> and meh, those came out really small; oops
<mjg59> Keybuk: What size font are you using, and what's your DPI set to?
<towolf> Keybuk: the stronger the hinting the less fractional positional info is present, and hence less "color".
<towolf> Keybuk: hinting is a quantizing process.
<cjwatson> iwj: do you have a list of targets for adding trigger support?
<dholbach> is somebody looking at getting DKMS out of NEW?
<pitti> dholbach: what's the excuse for it?
<iwj> cjwatson: What, a list of postinst thingumies to triggerise ?
<iwj> No.
<Hobbsee> pitti: dell stuff
<Keybuk> sorry, regenerated the pngs
<Keybuk> I took them in the wrong terminal mode
<dholbach> pitti: the kernel team wants it, it will make things easier wrt building kernel modules and soname bumps of the kernel
<cjwatson> iwj: ok, I had been wondering if fc-cache was on it, but I guess that answers that question
<Keybuk> mjg59: I think that we've clearly established that both of us have different opinions about the readability of the resulting output
<Keybuk> the true argument should be when is not appropriate to test them?
* ogra_ simply belives his eyes that start hurting pretty fast 
<Keybuk> (and thus gain a wider, and thus more balanced, opinion on the results)
<pitti> I thought so yesterday, too, but today I actually got used to it
<mjg59> Keybuk: Uh. These terminals don't seem to be the same size?
<cjwatson> Keybuk: it looks like the font you're using in Terminal-2 is bigger
<mjg59> Or is one of them just clipped?
<Keybuk> mjg59: they should both have a character size of 8px
<cjwatson> the 'i's look distinctly different in size
<Keybuk> cjwatson: it's smaller in point size actually
<alex-weej> mjg59, Keybuk, FT config is telling it not to hint at that small size on the older configuration
<mjg59> Keybuk: No, they're not the same size
<Keybuk> (they were taken on different machines, so it's not an entirely fair test)
<mjg59> Look at the height of the characters
<alex-weej> er... on the newer
<mjg59> Keybuk: The 's' in scott is five pixels tall on one, four pixels on the other
<Keybuk> I propose the following:
* Hobbsee is greatful that most of her apps are kde - so only the webbrowser and email are a problem - but with a different font, it's not so bad.
<Keybuk>  - ship with the patches in Beta
<Keybuk>  - evaluate the opinion afterwards to be one of
<Keybuk>    1) overwhemlingly positive (keep)
<Keybuk>    2) overwhelmingly negative (reject)
<Keybuk>    3) largely positive but with issues (remove, and defer to Hardy for more testing)
<cjwatson> 'i's are 5 pixels vs. 7 pixels
<Keybuk> that way we at least know whether to consider the patches for hardy if there are continuous issues with more than a very vocal minority
<cjwatson> Hobbsee: I thought this was all xft and freetype and the like, so common to both desktops
<Keybuk> (I myself found the monospace output wrong for about the first 6 hours of using them, now it looks perfect)
<Hobbsee> cjwatson: that's what i thought, too.  until i saw one lot of apps looking dramatically different from the other (where i think i'd played with the kde hinting before)
<mjg59> cjwatson: We default to full hinting if you enable sub-pixel anti-aliasing, and we have the byte-code interpreter enabled. As a result, the behaviour will differ between fonts
<cjwatson> mjg59: what comment of mine are you replying to?
<mjg59> cjwatson: Whether it'd be common to both desktops. It depends on the default fonts used for both
<cjwatson> ah
<siretart> seb128: did you notice the reject of live-initramfs due to missing orig.tar.gz?
<seb128> siretart: no, looks like sync-source is broken, I'm not sure of what I can do
<seb128> pitti, cjwatson: ^
<seb128> any idea?
<pitti> seb128: *again*?
<pitti> *sigh*
<seb128> looks like other syncs I did yesterday got the same issue
<pitti> oh, it's just for that particular package
<pitti> seb128: hm, can you please talk to cprov in #soyuz directly? he made some cherrypick changes to unbreak it at least for the non-orig.tar.gz syncs
<seb128> ok, thanks
<pitti> seb128: no idea how to fix that, sorry
<pitti> seb128: except for asking people to sync it manually with http://people.ubuntu.com/~pitti/scripts/syncpackage
<Keybuk> mjg59: do you have an argument why not to follow my proposal?
<alex-weej> mjg59: btw you posted the thread to ubuntu-devel, which is moderated.
<mjg59> Keybuk: Yes. It appears to give equal weight to all providers of feedback.
<Keybuk> mjg59: why should we not give equal weight?
<mjg59> Keybuk: If we lose 50% of our average users, we lose 50% of our market share. If we lose 50% of our developers, we lose ~100% of our market share.
<cjwatson> alex-weej: good
<mjg59> This is clearly inflated, but some users are more important to us than others
<cjwatson> the fact that ubuntu-devel is moderated is precisely a reason to hold discussions there that might get heated
<Keybuk> mjg59: I think that case is covered by (3) in my proposal; if we see issues of concern among more than just one or two people, then we defer
<mjg59> Keybuk: Well, we've already got three here
<alex-weej> cjwatson: in light of what mjg59 just said i guess it makes sense.
<Keybuk> note that there are quite notable developers in here who seem to prefer the change
<Keybuk> I do not agree that we can judge the issue with a few hours between upload and a reversion
<mjg59> Keybuk: It would be helpful if you could generate before and after images to show the issue you're describing, because I simply can't reproduce it here
<Keybuk> the issue is that our font rendering sucks
<Keybuk> it does not compare with commercial operating systems
<Keybuk> these patches give us rendering very comparable to those operating systems
<mjg59> Keybuk: Yes. I contend that for the case I'm most concerned about, the new code sucks significantly more.
<Keybuk> the fact you prefer the older rendering is not for argument, since it's apparent :)
<Keybuk> the argument should be about the right way to find out what is better
<mjg59> But I can also demonstrate /why/ the new code produces what I believe to be less readable results
<mjg59> And upstream agrees with me about that
<Keybuk> it's clear that we're not going to reach a conclusion here
<Keybuk> keith has different issues with the patches according to mailing list archives
<Keybuk> and a member upstream *wrote* the patches!
<Keybuk> so that's irrelevant
<mjg59> Keybuk: No, that's freetype upstream, not xft upstream
<mjg59> It's the xft case I'm concerned about
<Keybuk> ?
<mjg59> xft is responsible for actually getting these glyphs onto the screen with X
<mdz> Hobbsee: pardon?
<mdz> Hobbsee: "upstream version freeze" has, by definition, never applied to new packages
<Hobbsee> mdz: no, bu t new package freeze certainly does.
<Hobbsee> (which is what bryce actually meant in the bug report)
<mdz> Hobbsee: I am not prepared to remark on what he may have meant, only what he said
<cjwatson> seb128: I'm just going through old Ubuntu goals looking for things to polish in hardy, and ran across dapper-desktop-plan
<Hobbsee> ScottK: did you want to respond?  seeing as it was your complaint.
<cjwatson> seb128: I noticed that it called for "Main Menu" and "Menu Bar" in "Add to Panel..." to have visually distinct icons expressing the difference between them
<cjwatson> seb128: but that the current dialog just has an Ubuntu logo for both
<cjwatson> seb128: what happened to that?
* ScottK reads the backscroll.
<seb128> cjwatson: whoever was on charge of the artwork was supposed to do that (jdub?) didn't do it so nothing
<cjwatson> seb128: ok, so it should be on the list for polish
<seb128> right
<towolf> mjg59: may i provide a clean comparison of the use case you proposed?
<towolf> mjg59: it is Vera Sans Mono at 8pt: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot1.png
<ScottK> mdz: In MOTU we've been using the UVF exception process to cover both UVF exceptions and New package freeze exceptions, so asking for a UVFe for the new package was consistent with what we've been doing.
<towolf> the right side is after your revert, the left side is before the revert, but with suboptimal settings. center is authinter light mode.
<ScottK> Hobbsee and mdz: It's not clear to me from the backscroll what Hobbsee said that you were responding to.
<Hobbsee> ScottK: the ati bug that you were complaining about earlier?
<ScottK> Yes, but I was trying to get the exact context that led to "<mdz> Hobbsee: "upstream version freeze" has, by definition, never applied to new packages" and couldn't find it.
<mdz> ScottK: ok. I think that's a bit confusing, and suggest that we clarify this as part of pitti's work on consolidating freezes
<ScottK> mdz: I agree with it being confusing.
<ScottK> If we consolidate the freezes it would certainly make it easier.
<Hobbsee> ScottK: because there's no current version to compare the new upstream to, as it's new to ubuntu - so as mdz says, no possibility of regressions
<mdz> ScottK: I was responding to:
<mdz> <Hobbsee> seb128: at this point, we've stuck a blanket deny on any new packages, unless they're really important or interesting
<mdz> <Hobbsee> seb128: which mdz then hijacked, but that's beside the point.
<ScottK> Ah.
<ScottK> Yes.  The reasons for new package freeze are entirely different.
<mdz> Hobbsee: interestingly enough, NewPackagesFreezeUniverse is one of the minority of freeze states which lacks a rationale on https://wiki.ubuntu.com/UbuntuDevelopment
<ScottK> As I understand it, primarily because the archive admins have other stuff to do late in the release.
<alex-weej_> towolf: how do i log on to this ftp thing?
<Mithrandir> ScottK: actually not.  It was institutionalised at the request of MOTU as a way of forcing the MOTUs to concentrate on what was already in the archive.
<alex-weej_> ah it worked now, just took for-fucking-ever :P
<ScottK> Mithrandir: Ah.  That would make sense too.
<seb128> ScottK: the freeze period is not really the busy time for the archive admin work
<mjg59> towolf: Thanks, that looks like the comparison I see
<towolf> alex-weej_:  does it ask for a password?
<seb128> ScottK: there is an higher number of sync requests and new packages when there is no freeze in action ;)
<pitti> seb128: it's for me, anyway
<alex-weej_> tbh for hinted text the legacy filter looks better to me anyway
<towolf> mjg59: but which is best for your eyes? i'm curious.
<seb128> pitti: how so?
<alex-weej_> towolf: no it worked now
<pitti> seb128: cleaning up the archive and beat it into consistency is a huge task
<mjg59> towolf: Certainly not the middle one
<pitti> seb128: just because before releases this has to be done
<ScottK> seb128: Yes and that's even with the ones we said no about.
<Hobbsee> mdz: seems to be on https://wiki.ubuntu.com/NewPackagesFreezeUniverse (linked from your report), as much so as the others are.
<alex-weej_> the middle one is easily more readable than either of the others
<mjg59> towolf: The left hand one has clearly better shaping, but I find the right hand one to be more readable
<towolf> mjg59: okay, left or right?
<Hobbsee> mdz: but i recall you saying to me - never put down to maliciousness what you can to disorganisation.
<seb128> pitti: we sort of try to clean up for every milestone CD
<pitti> seb128: right
<towolf> mjg59: hmpf.
<pitti> seb128: but the amount of churn that piles up is amazing
<seb128> pitti: well we slacked on that during the rest of the cycle
<alex-weej_> towolf, Keybuk: what is the technical difference between the old and the new filters?
<alex-weej_> towolf: the new filter is doing nothing for hinted rendering other than making it blur with colour fringes
<seb128> pitti: try to not process NEW nor sync request for a month during the busy time of the cycle, I think the backlog would be quite impressive
<towolf> mjg59: comparisons at such point sizes are not realistic anyway.
<pkern> Right, middle, left, in order of preference.
<mjg59> towolf: I think the issue is accentuated with white on black, and I'm happy to admit that I really should get round to reconfiguring my applications to be black on white
<alex-weej_> pkern: look at the M rendering
<mdz> Hobbsee: what does?  that doesn't seem like a rationale.  I'm not questioning the usefulness of setting a deadline for new packages, but we should document the reason for it
<pitti> seb128: right, but if people stop packaging new crazy stuff and start concentrating on bug fixes, there shouldn't be NEW churn in the first place
<mdz> Hobbsee: also, that description merely says that new packages in the queue won't be accepted -- it doesn't say that they shouldn't be uploaded
<seb128> pitti: right
<mdz> Hobbsee: in which case, the sensible workflow would be upload -> request exception -> accept
<pkern> alex-weej_: I dislike the m rendering of the middle one and the M rendering on the right one. But considering that a looks weird too on the right, hm...
<Hobbsee> mdz: which then sticks more work on the archive admins, though.  and they have too much stuff to do as it is.
<towolf> alex-weej_: http://lists.nongnu.org/archive/html/freetype/2006-04/msg00012.html
<Hobbsee> mdz: the aim, from my POV, is to not let things even get thru to the archive admins without exceptions.  it's not their job to send it back, etc.
<alex-weej_> towolf: no i've seen this before, this is just a change to the hinting algorithm, no?
<mdz> Hobbsee: how does it create more work for the archive admins?
<mdz> Hobbsee: as I understand it, they'll just stop looking at the queue at the appropriate time
<alex-weej_> pkern: http://img529.imageshack.us/img529/6056/demott4.png
<Hobbsee> mdz: to have to check if exceptions are granted for everything that's in their queue
<Hobbsee> mdz: which makes them never deal with any exceptions, no?
<towolf> mjg59: well, not necessarily, I'm quite happy with white-on-black
<Hobbsee> mdz: then again, this is only for this release anyway.  who knows what will happen next release.
<pkern> alex-weej_: Gutsy one looks like OS X, which I dislike heavily.
<mdz> Hobbsee: presumably the archive admins are notified of exceptions, in which case they just accept the specific package which has been excepted. no need to look at anything else in the queue
<pkern> alex-weej_: I hate working in terminals which this AA behaviour.
<mjg59> towolf: The light blue blends into the white background much more readily than it does the black background
<pkern> s/which/with/
<towolf> alex-weej_: the difference is that turner implemented a several tap FIR filter
<mdz> Hobbsee: they would act based on the exceptions, not the packages (which should be much lower volume)
<towolf> mjg59: you forget that it is alpha blended
<alex-weej_> towolf: but what was the OLD filter?
<Hobbsee> mdz: currently, there's hte understanding that anything in the queue has an exception, so they dont need to check it.  however, your logic would work too.
<ScottK> Agreed it's sensible, just not how we've been doing it.
<pkern> alex-weej_: But it's personal preference, somehow. (:
<Hobbsee> mdz: (and conversely, that anything *not* in the queue does nto have an exception)
<mjg59> towolf: I see light blue aspects on the black backgrounds as well
<alex-weej> pkern: i don't see how there is any difference between the two on the left
<alex-weej> pkern: OS X doesn't hint
<pkern> alex-weej: Probably I should just try it out (as soon as the new daily builds are done)...
<cjwatson> Hobbsee: the archive team can't realistically act on the assumption that people are honouring all freeze states
<mdz> Hobbsee: ideally, folks would go ahead and upload, and if they don't get an exception, their upload should automatically be redirected to the next release when it opens
<pkern> alex-weej: You really don't see a difference between the two?
<Hobbsee> cjwatson: if they cant follow the rules, then why do they have upload rights?
<pkern> alex-weej: The chars all have green borders here.
<alex-weej> pkern: other than a green tinge because my monitor is uncalibrated
<Hobbsee> mdz: indeed, ideally.  although, then the changelog would be wrong, etc.
<cjwatson> Hobbsee: if everyone followed all the rules, we wouldn't need archive admins
<mdz> Hobbsee: "trust, but verify"
<Hobbsee> cjwatson: yeah, well.  there is that.
<mdz> Hobbsee: the changelog is already non-authoritative (e.g., syncs)
<sooth> Is Gutsy in beta freeze now?
<Hobbsee> mdz: true
<Hobbsee> sooth: /topic
<sooth> Hobbsee: Ah, sorry. Missed it.
<sooth> Hobbsee: Thanks
<cjwatson> mdz: although it's easy to tell in the case of syncs that it's non-authoritative, because the distribution doesn't match a valid Ubuntu one
<towolf> mjg59: a really big factor is the actual lcd in front of you, and how far you are seated away.
<mjg59> towolf: Right. I'm about a foot away from the screen, and can't really alter that
<towolf> mjg59: maybe be visual acuity, too ;-)
<cjwatson> mdz: with your proposal the property that if you see an Ubuntu release name then it probably means what it says would be greatly diluted
<pkern> alex-weej: You are right, unhinted looks more like OS X, I'm sorry. Some time has passed since I used it.
<mdz> cjwatson: I'd argue that with PPA that's unavoidable anyway
<mdz> the changelog has never been the right place for that information
<mdz> the destination of the upload is independent of its contents
<Hobbsee> mdz: s/ubuntu release name/ubuntu release name and ubuntu version/ then
<cjwatson> but it is awfully convenient as such
<towolf> mjg59: how about this snippet?
<towolf> mjg59: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot3.png
<cjwatson> I think PPA should be gutsy-ppa etc., in fact
<alex-weej> towolf: can you use imageshack or something? the FTP connection takes ages
<towolf> alex-weej: too lazy to put up with it.
<cjwatson> mdz: it slows investigation down greatly if one has to go to the network all the time
<mdz> cjwatson: what type of investigation?
<iwj> pitti: I'm going to want to dump a new dpkg on you I'm afraid.
<cjwatson> mdz: investigation of problems and roughly when they appeared, correlating with bug reports
<pitti> iwj: sure, what does it change?
<cjwatson> e.g. if a reporter says a problem appeared in feisty, you grep back for feisty in the changelog
<iwj> In bug 137191 someone reported dpkg randomly getting EBADF on some file.
<ubotu> Launchpad bug 137191 in update-manager "package update-manager 1:0.69 failed to install/upgrade: failed to fstat previous diversions file" [Undecided,Incomplete]  https://launchpad.net/bugs/137191
<mjg59> towolf: Hm. Sorry, your server suddenly seems unenthusiastic about talking to me
<Hobbsee> cjwatson: but hey, at least we've lost the binary mangling, i think.
<Hobbsee> cjwatson: (on ppa's)
<cjwatson> sure, I could go to Launchpad and ask for the exact versions, and sometimes I do that later
<cjwatson> but the changelog is an incredibly convenient local cache which is much faster to search
<iwj> I investigated and there were several error cases where an fd is closed twice, and worse during normal processing it closes the fsys archive pipe fd twice.
<iwj> If you're lucky the second close (which happens quite late) gets EBADF.
<lamont> pitti: et al: mind if I do a no-change upload of sysvinit to trigger the hppa build?
<cjwatson> and I think it is useful to put some effort into maintaining it for that purpose
<mdz> cjwatson: how about if the changelog for binary packages was generated at build to reflect where it was actually uploaded?
<iwj> If you're unlucky that fd is now used for something else and things can go badly wrong.
<pitti> lamont: fine for me
<towolf> mjg59 alex-weej:sorry for that: http://img338.imageshack.us/img338/1012/screenshot3ij8.png
<iwj> So I have a 200-line hard-to-review patch which fixes these things.
<cjwatson> mdz: when I'm doing this kind of investigation I usually already want to have the source package in hand, so no, I'm afraid I would just find that hopelessly confusin
<cjwatson> g
<iwj> I'm going to build it and test a biggish upgrade run with it.
<iwj> (tribe 5 -> current)
<alex-weej> towolf: the new filter only seems to use 3 taps
<mdz> cjwatson: I don't like the guessing game that folks have to play about whether the archive admins have time to process a new package
<mdz> there should be a clear cutoff, and packages which meet the cutoff should be processed
<Hobbsee> mdz: ..there is.
<pitti> iwj: sounds like fun
<cjwatson> mdz: I have no argument there, but I do not agree that the corollary of doing some weird automagic with whatever remains follows from that
<mdz> Hobbsee: https://wiki.ubuntu.com/NewPackagesFreezeUniverse
<Hobbsee> mdz: but there are exceptions for important stuff afterwards?
<mdz> Hobbsee: "Note: This means you should upload new packages in time for them to get reviewed by the archive admins and moved into the archive before this day."
<Hobbsee> mdz: yeah.  should.
<cjwatson> I think the short-term benefits to uploaders of doing that are more than offset by the long-term detriment of confusion
<alex-weej> towolf: i think if it used 5 taps it would be better
<mjg59> towolf: That appears to be a render of the pre-revert behaviour?
<Hobbsee> mdz: our sponsorship team isnt big enough to get everything reviewed ages before the freeze - particularly if we were to go thru sync requests, etc, by that time too.
<towolf> alex-weej: 5-tap is in lcd-light
<towolf> mjg59: yes
<alex-weej> towolf: ahhhh!
<mjg59> towolf: Ok, that precisely matches what I'm seeing
<Hobbsee> mdz: certain people like floodbombing the sync queue.
<towolf> mjg59: ok, then we hit the taste barrier. *discussion ends*
<mdz> Hobbsee: once the deadline has passed, the archive admins should clear out the backlog and not process any requests received after the deadline
<cjwatson> Hobbsee: in this case, I think the cutoff should be in terms of when the exception is granted and the package uploaded, not in terms of when it is processed
<towolf> mjg59: de gustibus ...
<iwj> pitti: Yers.
<Hobbsee> cjwatson: indeed - and when are you proposing this cutoff?
<Hobbsee> cjwatson: afaik, this already happens, for NPF.
<iwj> pitti: The new triggers code makes it more likely that it bits because it has some extra fds that it opens.
<iwj> s/bits/bites/
<cjwatson> Hobbsee: the point where the new package freeze currently sits is fine
<cjwatson> Hobbsee: it's just that the documentation makes it hopelessly unclear, and so we have to have the debate about what it means every release
<Hobbsee> cjwatson: so in that case, the one that mdz ack'd last night - that should never go in?
<Hobbsee> cjwatson: true.  hopefully it will get fixed near UDS>
<mdz> Hobbsee: no, we're not talking about changing the process for exceptions, only about what happens at the cutoff
<cjwatson> that sounds like an explicit exception granted by a member of the release team (or its superior, the technical board), to me
<mdz> things submitted before the cutoff shouldn't be rejected due to lack of time
<mdz> if there isn't enough time, the freeze should be moved earlier
<alex-weej> towolf: it does seem like something is wrong...
<Hobbsee> mdz: then more exceptions get filed about massively important packages (supposedly), and the problem is still there.
<mdz> cjwatson: what that was was a correction of terminology which was interpreted as an exception because the terminology used was consistent with what the release team apparently expect
<ScottK> Hobbsee: We just say no more then.
<towolf> alex-weej: what is wrong?
<Hobbsee> mdz: as far as i'm concerned, the NPF / UVF thing works fine.    it's just the number of exceptions that go thru.
<alex-weej> towolf: http://img509.imageshack.us/img509/5721/screenshotfreetypetextpji1.png
<ScottK> That and the undocumented exceptions.
<Hobbsee> mdz: (modulo syncbombs)
<cjwatson> Hobbsee: anyone in an exception-granting team who isn't comfortable saying no quickly shouldn't be in that team
<unggnu> hi all
<Hobbsee> cjwatson: indeed.  i dont think we have that problem
<lamont> no
<alex-weej> towolf: forgetting the fact that BCI sucks, in the event of a genuine 1 screen-pixel wide line, this is what we're getting
<lamont> :-)
* Hobbsee is starting to suspect that we're all arguing over different things.
<towolf> alex-weej: pathological cases
<unggnu> mjg59, Could you tell me what is wrong with the fix in this bug report https://bugs.launchpad.net/bugs/136380 please?
<ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New] 
<towolf> alex-weej: test with flowing, normal english text instead.
<lamont> Hobbsee: it sounded to me like you were grumbling about people mailbombing the sync queue
<alex-weej> towolf: that's not the point...
<alex-weej> towolf: actually what is very interestng
<alex-weej> is that if i make all the text unhinted
<ScottK> lamont: That happened.  We had 3 or 4 MOTUs working full time to clean up the mess left by one guy.
<Hobbsee> lamont: that was a side issue.
<lamont> pathological cases are _ALWAYS_ the more interesting
<alex-weej> the "legacy" filter becomes the green one
<Hobbsee> lamont: the guy has been roasted repeatedly, and if he dares to do it again next cycle....he's going to get officially roasted, or the sponsorship team will all stop processing things.  or something equally bad.
<towolf> alex-weej: ah, that's the effect david turner talked about in that stem quantization email.
<alex-weej> maybe i should read it again
<alex-weej> i think we're going to have to concede defeat though
<alex-weej> while people are using the BCI
<alex-weej> it is just going to look better without the FIR
<towolf> we should disable the BCI in LCD mode. simple.
<towolf> at least in the default.
<towolf> it is counterproductive
<alex-weej> and i agree with you
<alex-weej> but as i said earlier
<lamont> cjwatson: expect makes me vomit
<alex-weej> some people grow VERY attached to their font rendering
<towolf> this is not the 90s anymore.
<lamont> alex-weej: s/some/many/
<mdz> Hobbsee: so if you leave the freeze where it is, but the admins agree to process the backlog, you shouldn't get any additional exception requests, and the confusion would be resolved
<lamont> s/VERY/VIOLENTLY/
<alex-weej> lamont: including myself, apparently
<alex-weej> lol
<Keybuk> towolf: you mean a patch to change the default hinting to Light with Subpixel?
<towolf> alex-weej: ... the taste barrier
<alex-weej> or just do the OSX thing and use unhinted
<towolf> Keybuk: I have no idea how this fontconfig mess works.
<alex-weej> it's not fc
<lamont> towolf: to quote a friend "did they break fonts _AGAIN_ in [$distro] "
<alex-weej> it's some hardcoded settings in gnome font properties i think
* lamont pokes milli, just for giggles
<Hobbsee> mdz: should not, yes.  is it actually always motu-uvf's call about whether the exceptions get granted, or can ubuntu release team, and yourself step in and grant exceptions at will?
<Hobbsee> mdz: i think that's the real issue here
<ScottK> mdz: We'll certainly get requests.  We'll just say no in virtually all cases.
<towolf> Keybuk: The first step in gutsy+1 should be user interface changes in the preferences.
<alex-weej> i can work on thaty
<Keybuk> towolf: a patch for that was queued, but didn't get a chance before mjg59 reverted the others
<towolf> Keybuk: david turner proposed a redesign of the fialog here: http://article.gmane.org/gmane.comp.lib.cairo/9347
<ScottK> Hobbsee: I'd say that they can grant exceptions at will.  The question is more if they should.
<alex-weej> we should have "Windows-style", "OS X-style" and custom preferences
<cjwatson> Hobbsee: in the same way that ubuntu-core-dev can upload to universe and multiverse, the Ubuntu release team and technical board can make decisions about universe and multiverse (but will not normally do so since the routine practice is delegated)
<towolf> alex-weej: unhinted bleeds out too much, in my eyes.
<alex-weej> towolf: you got the number of taps ther wrong way around
* milli wiggles
<alex-weej> towolf: unhinted is the only way to scale reliably without having to re-layout
<alex-weej> zoomable UI baby
<Hobbsee> cjwatson: fair enough.  ScottK, i'd suggest you document that somewhere.
<ScottK> Hobbsee: Suggestions on where?
<ScottK> I agree with it too.
<Hobbsee> ScottK: motu ML, perhaps.
<mdz> Hobbsee: it's a motu decision (apparently delegated to motu-uvf), which could be appealed to the release team or ultimately the tech board if there is contention
<mdz> (or some other exceptional circumstances, like an urgent request when the right people are not available)
<alex-weej> "- there is no point in having a "monochrome" rendering mode, like we  do currently, it just looks ugly unless you have activated native  TrueType hints, so make this explicit in the interface." i disagree with that
<ScottK> Agree with that.  It just hasn't always happened that way.
<alex-weej> high DPI
<mdz> ScottK: it was not my intention to make a decision on the request; I was confused by the terminology
<milli> ScottK: fwiw, _I_ vehemently care about _non_-anti-aliased fonts.
<mdz> ScottK: which I think needs a lot of cleanup (hence my discussion with pitti about it)
<Hobbsee> mdz: would have thought you'd give it 24+ hours and such.  but OK.
<ScottK> mdz: Agreed on the fact that the current situation is confusing.
<pitti> still waiting for some answers on the ML before I actually change it
<Hobbsee> pitti: the freeze stuff?
<Hobbsee> yes, i need to reply to that.
<Hobbsee> (as the head of universe sponsorship queue
<Hobbsee> )
<ScottK> pitti: I also think that we need a documented spot for all of the distro release specific exceptions.
<pitti> ScottK: agreed, and that's the plan already
<pitti> ScottK: once we agree to the set of freezes, the links behind them will give details
<ScottK> OK.
<pitti> ScottK: and FreezeExceptionProcess, of course
<ScottK> In particular, there is a set of packages for UME that has a standing exception.  Which packages those are won't be clear to people not involved in UME.
<mathiaz> keescook: do you have testcases for avahi-daemon in your automatic testing suite ?
<keescook> mathiaz: nope :(
<keescook> wait
<keescook> yes, minimal.
<mathiaz> pitti: regarding the dhclient apparmor profile, I've got a minimal one but I still to test it more.
<keescook> it tests registration.  so, really it's an mdns test, not a link-local test.
<pitti> mathiaz: hm, I'm afraid it gets pretty late for that kind of change
<mathiaz> pitti: yeah. So I think we should defer the change for hardy.
<milli> alex-weej: fwiw, I have Feisty and use Monochrome, Smoothing = None, Hinting = Full, to get fonts to look _decent_
<alex-weej> milli: and you have truetype fonts with hints designed for bilevel rasterisation
<milli> I'll be very upset if monochrome disappears, or at least it's meaning, which is "don't anti-alias"
<alex-weej> milli: i assume Tahoma or something
<pitti> mathiaz: agreed
<milli> alex-weej: yes
<mathiaz> pitti: I've investigated the reason why the profile doesn't get applied on boot.
<mathiaz> pitti: it seems that it's due to start-stop-daemon.
<alex-weej> milli: i don't think it should disappear.
<milli> alex-weej: there has always been a disconnect between what FontConfig has for options and what's in the Gnome properties sheet
<alex-weej> totally
<milli> alex-weej: ah, you were quoting someone else?  (just noticed the "'s)
<alex-weej> hehe
<alex-weej> i disagree because on a hypothetical 500dpi screen, you probably don't want AA at all
<milli> Arial is the font I use pretty much everywhere
<alex-weej> like printers
<alex-weej> Arial's hinting is /aggressive/
<alex-weej> totally different font for every point size
<milli> I must say, and I've heard comments to this effect, if you can't render fonts _BEAUTIFULLY_, or at least up to par with Windows and OS X out of the box, it's an in-your-face kind of thing and a turn off.  It _will_ slow adoption of Linux on the desktop.  That has been the case for a long time.
<milli> That's my rant about fonts.  I was so disappointed with Edgy because no combination of fonts or settings looked good in OpenOffice and I couldn't believe it got released like that.
<alex-weej> OpenOffice does its own thing
<milli> But only a handful of people screamed about it.
<alex-weej> as does Gecko
<milli> yes, I have since found out.
<milli> and stopped screaming
<milli> alex-weej: w.r.t. AA, I find that all is does is make fonts look blurry, which gives me a headache.  It works for print media, not for screen IMHO.
<alex-weej> print doesn't AA...
<alex-weej> print draws at 720dpi :P
<Keybuk> at 600dpi, you kinda don't need too :p
<alex-weej> the real solution to all of this mess is to 1) stop doing hinting, 2) stop doing any form of anti-aliasing whatsoever, 3) render the entire desktop scene at 3nn oversampling, 4) filter the whole scene
<milli> what I mean then, is brochure ware stuff, etc, created with Photoshop (or GIMP) where the fonts are blended / anti-aliased on the page..
<alex-weej> fonts shouldn't be the only thing that get the benefit of subpixel positioning
<alex-weej> milli: if you're doing print media in photoshop then you suck
<milli> alex-weej: I'm not ;-)
<alex-weej> :P
* milli forgot what room he was in for sec
<IntuitiveNipple> alex-weej: I think someone's doing that - couple of bug reports today about 'fuzzy' icons in Clearlooks that I see as sharp as a knife :p
<milli> That should be ....  "GIMP (or Photoshop)"
<alex-weej> IntuitiveNipple: no that's because 24px icons are being sized at 22px
<IntuitiveNipple> alex-weej: I don't see the fuzzy ones and I've not changed anything - why would that be?
<alex-weej> IntuitiveNipple: icon theme
<alex-weej> Clearlooks mandates 22px toolbar icons
<alex-weej> including the stuff in the main menu
<IntuitiveNipple> I checked the theme based on what the bug-reporter said, and Clearview is using GNOME, and they are crisp and sharp with all today's updates.
<alex-weej> mjg59: i just read your email -- the positioning of stems is the same with both filters
<alex-weej> IntuitiveNipple: because GNOME Icon Theme is a tango-theme
<alex-weej> i.e. it has 22px icons
<alex-weej> Human, for example, has 24px
<IntuitiveNipple> alex-weej: ok, maybe I'm confused, but I understood from the bug-reporter that is icons in use there, and he/she is seeing them fuzzy.
<alex-weej> yes that's because they are being resampled, and 24 does not divide by 22
<IntuitiveNipple> alex-weej: I understand that; what I'm not clear on is why, if I've seemingly selected the same theme/Icons, why I appear to get a different result.
<cromo> hi. I dist-upgraded from perfectly working feisty to gutsy and now experience weird hang ups. It will hang up after about 10 minutes after logging in from gdm, but it can't work for hours under console (like now) without problems.
<alex-weej> maybe we're barking up the wrong tree, then.
<cromo> sys-rq keys seems to work sometimes, sometimes they don't
<alex-weej> cromo: graphics card overheating?
<cromo> doubt so
<cromo> it's radeon 9200
<IntuitiveNipple> alex-weej: I don't play with theme customisations at all so my system is whatever the default installs are, which is why I thought to compare when I saw the bug-report
<alex-weej> cromo: have you checked your kernel logs?
<cromo> and the mouse pointer works fine
<cromo> yes, nothing there
<cromo> for me it looks like scheduler problem
<alex-weej> tried a different driver?
<cromo> but the mouse works? I guess it's not the graphics then
<alex-weej> no
<cromo> I mean, I can move it, but can't click on anything
<alex-weej> have you tried vesa?
<cromo> also, it alwyas hangs when the cpu is at 100% usage
<cromo> I will
<cromo> but I doubt that it will help
* hunger grumbles. Now I have beagle, tracker and strigi installed... Could you please trim down the number of desktop searches a bit?
<alex-weej> bbl simpsons
<alex-weej> +food
<cromo> ok, I run X with vesa driver
<cromo> let's see...
<mathiaz> pitti: what about adding the dhcp client profile to the apparmor-profile package (which is in universe) ?
<cromo> btw, these lockups happened for bopt .192 and .193 radeon driver
<pitti> mathiaz: that's fine for me
<pitti> mathiaz: if the profile works for the derooted client, too?
<pitti> mathiaz: e. g. the derooted one needs cap_setuid
<towolf> mjg59: whoa, just read your email. your whole argument hinges on an example that would rarely occur in real life. go up 4pt and the story looks entirely different.
<mathiaz> pitti: that'S right.
<mathiaz> pitti: the profile is a little bit different (wrt the capabilities).
<towolf> mjg59:  8pt has always been a corner case in displaying fonts.
<mathiaz> pitti: but at least we can ship something and get it tested.
<towolf> mjg59: there's always xterm at your disposal. or MGT if you prefer tabs.
<mjg59> towolf: "Your use case doesn't matter" is a poor argument
<mjg59> Since it pretty clearly matters to me :)
<mjg59> The aim should be to find ways of introducing changes like this /without/ upsetting people
<mjg59> Which I believe to be achievable, just not in the amount of time we have
<towolf> mjg59: so you sit 30cm away from the creen because your fonts are at 8pt?
<towolf> mjg59: now i see ...
<towolf> *screen
<mjg59> towolf: No, I sit 30cm away from the screen because I use a laptop and work from bed
<unggnu> mjg59, hi, could you please say something to wrong sonybright.sh value range? https://bugs.launchpad.net/bugs/136380
<ubotu> Launchpad bug 136380 in acpi-support "[Gutsy]  sonybright.sh doesn't use the correct value range" [Undecided,New] 
<mjg59> unggnu: I haven't had time to test it
<unggnu> Ok, thanks.
<towolf> mjg59: my position would be: let's defer until a better GUI is available. freetype still ships with lcd_legacy in the code, and enabling it would better a matter of a drop-down combined with the proper fontconfig magic.
<towolf> mjg59: it's not either or, both styles are possible. (at the cost of confusion potential)
<mjg59> towolf: Right. Once we can handle these cases automatically, I've got no objection
<mjg59> But we're not going to be able to do that in time for release
<towolf> mjg59: i agree, but Keybuk's scheduling point had merit.
<mjg59> towolf: No, if we push it into the beta then it looks bad if we remove it again
<towolf> mjg59: and i can assure you that the patches would be a selling point of ubuntu. not a detractor.
<mjg59> Because people will write stories about how it's going to be in the release
<towolf> i see.
<mjg59> Whereas if we get it working at the start of a cycle, there's a much lower probability of us having to remove it
<mjg59> Is restarting NetworkManager on upgrade really necessary?
<Ng> mjg59: ooi, is your gnome DPI set to your real DPI? If I set mine to roughly what the real DPI of the screen is, the colour hints on vertical parts of glyphs are much harder to see (which I kinda get the feeling should be obvious, and that anything sub-pixel should depend on really knowing where the pixels are)
<mjg59> Ng: No, for an LCD running at native resolution the software knows where the pixels are regardless of what the DPI is
<mjg59> Altering the DPI is effectively just altering the physical size of your screen while keeping the resolution the same
<Ng> mjg59: but the gnome dpi setting demonstrably changes how freetype is rendering the fonts
<mjg59> Ng: Because it tries to keep the fonts the same physical size, regardless of the size of the screen
<towolf> Ng: could you demonstate that?
<mjg59> Which will alter the width of the strokes, and hence also the way the font is rendered
<mjg59> It's equivalent to just changing all your font sizes
<cromo> alex-weej: ok, it was the radeon driver it seems. vesa works fine.
<Ng> towolf: I'll see what I can knock up when I get home :)
<cjwatson> mjg59: how about coupling it with an announcement to u-d-a that this is an experimental change, we are soliciting feedback, and may well revert it before release?
<mjg59> cjwatson: I don't think that would help. People will review the beta without reading uda.
<cjwatson> or even a note in the fonts dialog
<Ng> either way my musings about DPI are irrelevant if we're going to hardcode everything to 96dpi :)
<cjwatson> though I have to say I'm not sure I care about reviews of beta which assume it's final
<mjg59> cjwatson: I don't think we should be putting anything in the beta unless we have no reason to think anything bad is going to happen
<towolf> Ng: i don't think freetype cares about anything but target size. this dpi has to be this and that is a myth. unless proven.
<mjg59> In this case, I think we have reason to feel that some users will be very unhappy with the change (and some users very happy)
<mjg59> Given that we know what the concerns are already, we should introduce the change at a point when we have time to address those concerns - rather than either dismissing them or removing the feature
<cjwatson> while I can see your point, I'm worried that it's the-perfect-is-the-enemy-of-the-good
<cjwatson> i.e. we never introduce any change until it's perfect
<mjg59> I'm happy introducing changes without them being perfect, as long as we think that they'll either be perfect or a decent approximation of it by the time we release the final product
<cjwatson> the thing that seems unclear here is whether this change is "the good"
<mjg59> We know that this change can't be perfect by release time
<cjwatson> we do? I didn't think we had enough information
<mjg59> There's nothing we can do to help the people it makes unhappy
<cjwatson> somebody suggested an extra fonts-dialog option
<cjwatson> modulo naming, would that work?
<mjg59> cjwatson: No, not really
<cjwatson> why not?
<mjg59> That would just give the choice of enabling it or disabling it at a system-wide level
<cjwatson> I think that's good enough
<mjg59> And would require code changes to freetype, cairo and xft
<Mithrandir> I think we are too trigger-happy about adding preferences at the moment, though that's slightly tangential.
<mjg59> Which haven't been written yet
<cjwatson> so does introducing or reverting the change
<cjwatson> (require code changes, albeit written)
<cjwatson> I would like to know how complicated those changes would be
<mjg59> The UI would be fairly easy, though working out a way of making it make sense to users would be much harder
<Keybuk> cjwatson: code easy, UI harder but possible
<mjg59> Our existing font configuration is over-complicated already
<Keybuk> though since this would appear under Advanced, that's less of an issue
<cjwatson> AIUI this change only negatively affects users who have already gone into that dialog
<cjwatson> is that true?
<mjg59> cjwatson: No
<cjwatson> doesn't it chiefly affect a mode which is not switched on by default?
<Keybuk> s/chiefly/only/
<mjg59> cjwatson: It affects anyone who's enabled sub-pixel anti-aliasing, which is not in the advanced dialog
<mjg59> And the fact that we're not enabling sub-pixel anti-aliasing by default on TFTs is a bug anyway, but still
<cjwatson> so why would this have to appear in Advanced?
<towolf> my experience is, touch anything font-related /anytime/, and a very vocal group will stand up and protest. loudly. this is not contingent on the time of release.
<cjwatson> there are already four options there
<cjwatson> five doesn't seem a big deal
<towolf> only options will appease linux font zelots.
<mjg59> cjwatson: Philosophically, because it's an option that shouldn't exist
<Mithrandir> if so, we should replace the monochrome one, I'd say.  *hides*
<mjg59> Realistically, because it's an option that nobody would understand
<cjwatson> huh? I don't understand the four different options there right now
<cjwatson> because I am not a font expert
<cjwatson> I can see that they look different
<cjwatson> and your precise concern is that they look different
<mjg59> Oh, right
<cjwatson> so I do not believe that that is a problem
<towolf> cjwatson: because it doens't make sense, nor reflect reality namingwise.
<mjg59> This option would be orthogonal to those four
<Mithrandir> cjwatson: but they don't look different at that font size anyway?  Or not very much so, at least?
<cjwatson> Mithrandir: different enough to see
<iwj> pitti: New dpkg and libc for your delectation, delight and disaster.
<towolf> mjg59: not orthogonal at all
<cjwatson> and also it's instant-applyu
<cjwatson> so you can simply see the effect on your desktop
<mjg59> towolf: Subpixel positioning is orthogonal to the anti-aliasing method
<cjwatson> so I entirely disagree that this would be incomprehensible
<Mithrandir> cjwatson: can you see the difference between "best contrast", "best shapes" and subpixel?
<towolf> mjg59: that sentence doesnt make sense to me.
<iwj> elmo: that rfc3484 rule 9 disablement ought to be in the beta at this rate; my libc built and tested fine and it's currently awaiting archive admin approval.
<cjwatson> Mithrandir: when it instant-applies to my desktop, yes
<towolf> mjg59: we do not have subpixel positioning at all, yet
<elmo> iwj: super, thanks
<slangasek> iwj: default gai.conf that disables it, or patched the code?
<iwj> slangasek: (b)
<slangasek> spiff
<iwj> slangasek: It's trivial; you just changed `no' to `yes' (or v.v) in the default config, and 0 to 1 (or was it v.v) in the code.
<mjg59> towolf: I thought the entire point of this code was that it altered the smoothing code to be more willing to align things to subpixel boundaries?
<iwj> s/changed/change/
<towolf> mjg59: no, yft and cairo don't allow that.
<towolf> that's futuristic stuff.
<towolf> *xft
<mjg59> Ok, so I've misunderstood what changes it actually makes. In that case, why does it reduce the level of pixel alignment?
<towolf> they just puzzle rectangles together
<towolf> because the rectangles change. but at 1px distances.
<towolf> turner has an algorithm in the pipeline that calculates better side bearings, but that's neither subpixel.
<towolf> the whole point of the patch is to improve shape while maintaining contrast.
<mjg59> towolf: But it improves shape without maintaining contrast
<towolf> the fun part of lcd filtering is that it tricks your visual apparatus, into veliving that.
<towolf> (or not, in your case)
<mjg59> It's turning what used to be white into grey - there's no way that that can improve contrast
<towolf> not improve, retain some/much of it.
<mjg59> Right. But it's a tradeoff - improved shapes at the cost of contrast
<towolf> with a good enough ratio
<mjg59> (and increased blurriness, but I'll admit that people make the same accusation against sub-pixel AA in general, so I'm not going to argue that one)
<mjg59> towolf: That's purely subjective
<towolf> see with increasing font sizes, the trongly hinted way can just flip from on pixel unit to the next
<towolf> it's so ugly.
<towolf> and 1995
<mjg59> With the reduced hinting example you showed, the contast is massively reduced
<towolf> at 8pt. no fair.
<mjg59> But we have people using 8 point fonts
<towolf> let them use xterm
<mjg59> No. That's not an option.
<mjg59> We don't break existing configurations.
<slangasek> the discussion seems to be backsliding, we're back to arguing the subjective merits of the options which isn't going to get us anywhere
<towolf> multi-gnome-terminal? my lab post-doc uses that
<mjg59> What we should be focusing on is providing a solution that works for a wider range of cases, even if it's somewhat heuristic
<Ng> towolf: that's gnome1 though, afaik :(
<slangasek> mjg59: but you don't think there's time to craft such a solution before release?
<towolf> you're right, we cannot change it just like that.
<towolf> they will come with pitchforks.
<mjg59> I agree that the new code is almost certainly a win at larger font sizes
<towolf> and torches.
<mjg59> slangasek: I suspect not
<towolf> say browsing the web. (most important task at a pc). it's ahuge improvement.
<mjg59> slangasek: I think it'd probably end up requiring quite a lot of tuning
<slangasek> right
<mjg59> Naively, we could just add fontconfig support to automatically disable this at low font sizes or for monospace fonts
<mjg59> I suspect that would deal with most of the issues, but we'd need someone to step forwards and commit to writing that code *now*
<Trewas> towolf: there are still very many low-dpi screens (like all 19" 1280x1024 lcds) where 8 pixel fonts are fine and needed to fit enough stuff to screen
<towolf> Trewas: it's not the issue, we have options for that case. it's jut that out of a hunch mjg59 prefers one combination that is achievable otherwise.
<mjg59> towolf: At the moment, we don't have options for that case
<towolf> in the shot you posted, in my eyes the left option was largely compatible with the right side.
<Trewas> towolf: anyway, shouldn't the new filtering method still retain sharpness (i.e. not be blurry) in fully hinted case?
<pkern> vorlon is called differently here... that feels strange. :)
<towolf> Trewas: yes, but there are some interactions that turn out not so great in the end.
<towolf> Trewas: it just works best with the autohinter.
<towolf> Trewas: the perception is the autohinter is inferior. that's not true.
<towolf> Trewas: apple is the holder of the truetype hinting patent. guess what, they abandoned the technology completely.
<towolf> there was a blog post by some luminary about safari on windows recently.
<towolf> it spawned a sizeable flame-war.
<towolf> this will happen with us, too.
<mjg59> towolf: The issue is that we're trying to apply a "one size fits all" mentality to this. This isn't going to work.
<Trewas> towolf: I read http://antigrain.com/research/font_rasterization/index.html and it seems that hinting is still a benefit with low-dpi screens, even if it is fine for high-dpi screens and scaling is easier
<towolf> mjg59: i agree ;-)
<mjg59> The requirements of a terminal application are very different to the requirements of a web browser. In one, precise definition of characters is more important than accurately depicting the character shapes. In the other, that's less true/
<towolf> Trewas: i agree.
<mjg59> My objection at the moment is that the change increases the aesthetics of the common case, but reduces the functionality of the corner case. I'm happy with one, but not the other
<towolf> Trewas: i propose some amount of hinting too.
<towolf> mjg59: i've been happily using the patch in my terminal usage since 2006. But my res is 129 dpi. and i use at least 12pt.
<towolf> mjg59: what you call aesthetics is readability for me.
<towolf> mjg59: for me it is significantly improved.
<seb128> siretart: the sync tool is confused because the orig already exists in your ppa archive, could you do a fake sync using http://people.ubuntu.com/~pitti/scripts/syncpackage?
<towolf> mjg59: if it weren't taseless i would cite a published study proving that (SR vs. monochrome)
<towolf> (hint: it's a microsoft typography study)
<slangasek> towolf: you don't appear to be arguing anything new or disputed though, you admit that you're using fonts >= 12pt which isn't the problem case?
<mjg59> towolf: I'm not using monochrome, and nor have I argued that doing so improves readability
<jwendell> seb128, a doubt: was the sound when we log in dropped along with splash screen too?
<towolf> strong hinting ~ monochrome (for sufficiently fuzzy values of ~)
<seb128> jwendell: no, splash screen is a gconf key change, the sound is due to upstream code changes
<jwendell> seb128, ok, i just wanted to know if this is a new 'feature' for gutsy or a bug :)
<towolf> slangasek: you can achieve readable fonts at 6pt with the new method. a size where all other methods are not readable at all)
<seb128> jwendell: a bug and upstream is on it I think
<towolf> slangasek: the issue is habituation.
<jwendell> seb128, btw did you understand that question about vino-session?
<seb128> jwendell: I don't really understand the vino session thing, why doesn't it register to the session the "normal" way?
<towolf> slangasek: and the dishabituation will take some time.
<seb128> jwendell: no
<slangasek> "doctor, I'm getting a headache from my computer screen" "must be your habituation" :)
<jwendell> seb128, indeed, there should be some way to run a executable by watching a gconf key
<towolf> slangasek: doctor: here have a transferral receipt to the therapeut, ...
<jwendell> seb128, d-bus is the right thing for 2.22
<towolf> slangasek: for your phantom pain.
<Trewas> towolf: in feisty full hinting with subpixel rendering seems very sharp (more so than non-antialiased case because curves are not blocky), with the new stuff in gutsy the same is quite blurry
<slangasek> towolf: um, except it's not phantom pain
<slangasek> actually, it's totally valid that one's expectations regarding the text appearance could contribute to greater eye strain
<ogra1> a bit gto visible for being a phantom :)
<ogra1> s/gto/to/
<towolf> Trewas: a result of Vera family with suboptimal settings. it's not enough to just patch the libs.
* towolf digs for the paper
<Trewas> towolf: I am using verdana/tahoma (never liked how vera fonts look)
<elmo> hey, all this talk about fonts is giving me a headache, who do I see about that?
<elmo> \o/
<ogra1> lol
<Nafallo> :-)
<towolf> the glyphologist
<slangasek> towolf: anyway, I don't see that much weight should be given to a claim that "this is the only option that makes 6pt fonts readable" from someone who isn't /using/ 6pt fonts
<towolf> slangasek: err, i tested this
<slangasek> towolf: but you're not /using/ them
<slangasek> which implies you don't actually find them desirable
<ogra1> or are forced to use them
<seb128> jwendell: well, there is this autostart spec, you just have to add a .desktop
<slangasek> so if it makes 6pt fonts legible, but at the same time makes it so no one /wants/ to use anything smaller than 10pt...
<seb128> jwendell: and you could make the vino server exit if the key is set
<Keybuk> slangasek: it doesn't just make 6pt fonts legible, it changes the appearance of fonts at all sizes
<Keybuk> (as is obvious from the fact people noticed the change <g>)
<jwendell> seb128, sure, but i mean, some executable must be running in order to watch that key
<jwendell> seb128, and who will run vino-server again?
<slangasek> Keybuk: yes, I'm aware.  But towolf is trying to assert that the new behavior is better even for smaller fonts -- fonts smaller than anything he actually uses
<Keybuk> the discussion should really just be about whether Beta is an appropriate time to test this on our users, or not
<towolf> slangasek: screenshots coming up.
<slangasek> towolf: then you're missing my point
<Keybuk> since we'll just descend into an argument of biblical proportions otherwise :p
<ogra1> towolf: screenshots totally dont matter, its a 100% subjective view if you lkike the change or not and if it bothers your eyes or not ... no paper or screenshots will change personal impression here
<towolf> slangasek: i don't use small fonts because i like to sit at my computer with a relaxed posture, and not squit.
<Keybuk> ogra1: it's also worth noting that people's views appear to change after a night's sleep
<Keybuk> (mine certainly did)
<cromo> alex-weej: disabling dri makes the ati driver work fine, too.
<ogra1> Keybuk: yes, mine didnt yet but i noticed the comments
<alex-weej> cromo: i'm sorry i didn't see what (if anything) you wrote before
<alex-weej> cromo: ah, vesa works
<alex-weej> cromo: ok, so have you filed a report on this?
<alex-weej> and are you using Compiz?
<seb128> jwendell: again? you have a .desktop it's run at every login
<towolf> ogra1: wasn't the point that the new way doesn't work with small type, and i wanted to disprove that FUD?
<seb128> jwendell: and you make vino-server exit on startup if the key is set
<seb128> jwendell: that's not starting vino-server, looking the key value and returning that will load your box
<mjg59> towolf: It depends what you mean by "work". It reduces contrast and definition, but improves the shaping.
<seb128> jwendell: I'm away for dinner, be back later
<ogra1> towolf: my personal as that my eyes start to tear after a while with these fonts ... no matter how big they are on my 1024x768 screen
<ogra1> s/personas as/personal concern was/
<Trewas> towolf: I think the new way makes smaller-than-usable fonts look legible (say 6 pixels) but actually hurts for small-but-still-usable case (say 8 pixels)
<towolf> ogra1: but you are seasoned unix users, you have been using those fonts since decades. a change will unequivocally be wrong to you.
<mjg59> towolf: No, that doesn't fit with me preferring the new code for the desktop applications
<ogra1> towolf: i even used fonts when there wqas no antialiasing ... that doesnt make them appear less blurry to me though
<towolf> ogra1: thanks for proving the point.
<towolf> anyhow, after two nautilus crashes: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot4.png
<towolf> ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot5.png
<mjg59> towolf: None of those are readable at my screen resolution
<towolf> for sufficiently small values of readable.
<mjg59> Expanding them, the middle one is more legible
<towolf> decipherable.
<mjg59> But that's not the setting we were proposing to ship
<slangasek> towolf: no, the point is that you, as someone who isn't using 8pt fonts, should not have more weight given to your opinion than the folks who are actually using fonts of that size, no matter how you try to bolster your opinion with screenshots or studies
<towolf> slangasek: but that's why Keybuk proposed to throw the stuff into the wild, to have /all/ ubuntu users have a go at it, right?
<slangasek> yes
<slangasek> but that's not the discussion you're continuing to have here :)
<towolf> slangasek: all includes my mom and dad, and of course ubuntu devs running terminals at 8pt.
<mjg59> Anyway. I suspect strongly that it would be helpful for someone to work on an implementation for ensuring that the choice of method can be chosen at runtime, and then adding fontconfig support for changing it based on font families or size
<mjg59> Is anyone going to volunteer to do that?
<towolf> slangasek: no, you guys dragged me into the "it doesn't work at 8pt" discussion
<ogra1> towolf: you shouldnt let your mom and dad run gutsy ;)
<alex-weej> cromo: did you answer my q? sorry, i crashed
<Keybuk> mjg59: if the guidelines of what people want are clear, I have no problem doing that
<towolf> mjg59: let's hope someone with a good sense of HIG and humanity.
<alex-weej> crashed loading towolf's links
<Keybuk> having reviewed the code quite heavily already, I know where the bits need to go
<mjg59> towolf: I suspect that it can be done without appearing in the user interface at all
<towolf> mjg59: whoa, be careful with one-size fits all.
<towolf> mjg59: the proposal by david turner on the cairo list i cited earlier seemed very reasonable.
<mjg59> towolf: I agree that it's impossible to make everyone happy. The aim is to make enough people happy that a sufficiently small number of people want to change the option that there's no need to put it in the UI
<towolf> mjg59: it explicitely contained a truetype optimized option.
<towolf> mjg59: and a deactivate aa below x-pt.
<towolf> don't assume a point size to do that.
<mjg59> Keybuk: My handwavy assertion is that, by default, we should automatically use the old method on monospace fonts below 9 points
<mjg59> This is assuming that we stick to the current defaults, ie sub-pixel defaults to full hinting
<Keybuk> 9pt at which dpi?  9pt at 200dpi is a somewhat larger glyph than at 96?
<mjg59> 9pt is 9pt
<Keybuk> the existing fontconfig checks seem to be based on pixel size
<mjg59> Ok. If it's pixel-sized, then that's easier
<Keybuk> 9pt is 0.125" on the screen :)
<mjg59> A quick play suggests 12 pixels would leave me happy
<mjg59> Keybuk: Just to clarify - by "old method" I mean "the old sub-pixel colour filtering" and not "monochrome"
<Keybuk> this would appear to mean setting the filter to "legacy" correct?
<mjg59> Yes
<mjg59> At least, that's my understanding
<towolf> mjg59: we should not stick to full hinting. (saying this seems futile)
<towolf> Keybuk: correct
<mjg59> towolf: There's a sufficient decrease in contrast that reducing hinting for terminals is not a good idea
<Keybuk> mjg59: depending on terminal colour?
<mjg59> Keybuk: My /impression/ is that the new filter is perfectly reasonable at 10 pixels on non-monospace
<towolf> i realized that you never posted a screenshot of your terminal, without magnification.
<mjg59> towolf: It looked pretty much identical to the one you posted
<towolf> okay
<mjg59> towolf: Am I right in thinking that that used full hinting?
<towolf> the one in your email?
<mjg59> No
<towolf> the white-on-black one?
<mjg59> screenshot3
<mjg59> Yes
<towolf> no, didn't use full hinting.
<towolf> would have entailed killing my x
<mjg59> Ok, interesting. My fully hinted one looked almsot identical.
* towolf thinks compiz is cool because the zoom is instant
<towolf> mjg59: see? you're getting there. ..
<mjg59> towolf: ftp://ftp.tuebingen.mpg.de/kyb/towolf/screenshot1.png clearly has reduced contrast on the unhinted version
<towolf> smaller font.
<towolf> smaller to a degree where the stems used a thickness of < 1px. below that the becvome gray.
<towolf> because there's no hinting involved to flip them back to 1px.
<mjg59> towolf: Right, exactly
<mjg59> For small fonts we probably want hinting in order to keep the contrast high
<mjg59> For larger fonts, the contrast will be good enough anyway and we can concentrate on shapes
<towolf> mjg59: 1. yes, that should be possible, 2. we is not defined here
<towolf> we as in "we"
<mjg59> For certain applications, contrast is more important than shaping
<towolf> because i am a lot more comfortable with reading the center in screenshot1.png
<Keybuk> mjg59: ok, that patch seems possible
<mjg59> Keybuk: Ok, I think that makes me massively happier
<Keybuk> it would be in the form of a fontconfig option to set the lcd filter
<mjg59> Yeah
<Keybuk> you'd drop something in conf.d to set hinting=legacy when pixelsize <= 8
<Keybuk> for example
<mjg59> Right
<Keybuk> (or 12 or whatever you like)
<mjg59> I think we want to ship one of those by default
<Keybuk> then cairo, xft, etc. would call FT_Library_SetLcdFilter with what fontconfig says, not FT_LCD_FILTER_DEFAULT
<mjg59> Yes, that sounds appropriate
<Keybuk> as you say, we can ship that by default maybe with a debconf option or something
<mjg59> As I said, I /think/ it's primarily an issue with monospace
<mjg59> So we could just default it there and leave the others
<mjg59> I suspect that will avoid upsetting console-oriented people, and make desktop-oriented people happy at the same time
<mjg59> Anyway -> shops
<mjg59> Back in 10
<Keybuk> mjg59: with that patch, you'd remove your objection to it being in beta?
<Keybuk> slangasek: would release team be happy with the patches going in for beta (including the patch proposed by mjg59?)
<towolf> mjg59: it's a problem with web browsers and all other apps too, actually.
<lamont> slangasek: expect_5.43.0-13.1 uploaded to debian, you want the sync request now, or once it is in the archive?
<towolf> mjg59: you're just more used to the terminal.
<lamont> and I missed today's dinstall run
<slangasek> Keybuk: as this resolves the main objection where we know ahead of time that some people are unhappy with the behavior change, yes
<slangasek> lamont: no preference
<Mithrandir> lamont: it won't be acted on until it's in the archive anyway. :-P
<mjg59> Keybuk: I think so, yes
<jamiemcc> seb128: any chance o3read could be promoted to main as its small and is needed by tracker to index openoffice files?
<Mithrandir> jamiemcc: it needs a main inclusion report.
<Mithrandir> https://wiki.ubuntu.com/MainInclusionProcess
<pkern> slangasek: So you joined Canonical very recently?
<jamiemcc> mithrandir: I know - but such decisions are discussed here?
<towolf> i was able to get through the pay wall to get the readability paper. it looks not really exciting apart from the difference when italics are used.
<towolf> did anyone mention that italics are a *lot* better with the new method?
<Mithrandir> jamiemcc: they're quite often not really discussed, just carried out
<jamiemcc> mithrandir: who does the inclusion reports?
<seb128> jamiemcc: pitti usually
<Mithrandir> whoever has an interest in getting the package into main writes it
<seb128> jamiemcc: the easier is to file the wiki page
<Mithrandir> it's reviewed by pitti and iwj
<seb128> jamiemcc: the wiki page has the informations required to make a decision
<evand> yay, the new nvidia driver potentially fixes the compiz black windows bug, finally.
<pochu> jamiemcc: I could help a bit with the report
<jamiemcc> seb128: ok should I write the report then?
<seb128> jamiemcc: either do it or convince somebody to do it for you ;)
<jamiemcc> thx - pochu are you familiar with the process?
<pochu> jamiemcc: tracker's report looks good to take as an example: https://wiki.ubuntu.com/MainInclusionReportTracker :)
<pochu> jamiemcc: I know how to do it, although I have never done it
<pochu> jamiemcc: but there's always a first time, isn't there? ;)
<jamiemcc> pochu: yeah - can you make a start on it? (im still fixing tracker bugs atm(
<pochu> jamiemcc: sure thing!
<jamiemcc> pochu: thx very much
<pochu> np
<slangasek> pkern: this week, yes
<pkern> slangasek: As Ubuntu RM?
<Keybuk> GTK+ font rendering is done through Cairo now, right?
<seb128> mjg59: could you look at bug #140485 some people still have gnome-settings-daemon crashing, might be due to the synaptic changes
<ubotu> Launchpad bug 140485 in xserver-xorg-input-synaptics "gnome-settings-daemon not starting with 1:2.19.92-0ubuntu3" [Medium,In progress]  https://launchpad.net/bugs/140485
<mjg59> seb128: Checking
<seb128> mjg59: I think there is not enough information to have a good idea of the issue but maybe you know what to ask
<mjg59> seb128: Hm, interesting. I have a suspicion.
<alex-weej> pitti: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/120957/
<ubotu> Launchpad bug 120957 in update-manager "UpdateManager fails to fetch dist-upgrade tarball" [High,Confirmed] 
<mjg59> seb128: It's possible that they're machines with a synaptics driver entry but no synaptics pad
<seb128> ok, if you could deal with it that would be nice ;)
<mjg59> I'll see if I can reproduce
<pochu> jamiemcc: could you check, specially point 5? I haven't touched that point (copy&paste from tracker report for it hehe) https://wiki.ubuntu.com/MainInclusionReportO3Read
<jamiemcc> pochu: I think the deb for o3read compies with debian policy (the rest looks irrelevant)
<bryce> where are the release notes for gutsy beta being compiled?  I've got an entry or two to add.
<alex-weej> pitti: oops sorry on the phone and that was a bit rude
<alex-weej> pitti: any ideas what's happening with that bug?
<pochu> jamiemcc: ok, editing
<MacSlow> hi Gman, bryce
<bryce> hi MacSlow
<Gman> hey MacSlow
<pochu> jamiemcc: the binary is lintian-clean, and the source has just a couple minor warnings, so I'd say it is
<pochu> jamiemcc: updated, what do you think?
<jamiemcc> pochu: looks good - thanks
<slangasek> pkern: yep
<pochu> jamiemcc: cool, adding to the queue now
<jamiemcc> pochu: thx
<pitti> iwj: dpkg> thanks, I'll have a look; how bad was the libc patch in the end?
<tepsipakki> Keybuk: I thought that cleartype is not used because of the MS patent?
<pitti> alex-weej: no problem, looking
<pitti> alex-weej: well, it says so in the bug, there are more imports needed
<mjg59> Hrm. Ok, doesn't /seem/ to be that
<Keybuk> tepsipakki: it wasn't used because we didn't know about it :)
<pitti> jamiemcc: MIR> I'll have a look if it is urgent/important, but I prefer to not have too many changes any more
<tepsipakki> Keybuk: right, ok :) I'm looking forward to that
<mjg59> Is there anyone here who's suffering from #140485 ?
<pochu> pitti: well, if it's ok to promote it, it isn't such a big change... :)
<jamiemcc> pitti: yeah although some people are compalining tracker does not index Openoffice files - I guess it improves the user experience and o3read is tiny
<pitti> jamiemcc: right
<pochu> pitti: see bug 117307
<ubotu> Launchpad bug 117307 in tracker "Tracker doesn't index openoffice.org files" [Undecided,Invalid]  https://launchpad.net/bugs/117307
<pitti> jamiemcc: well, just assume it would crash for some reason, then we would have this crash installed for every tester of beta, and so on
<pitti> pochu: that doesn't sound like 'invalid'
<jamiemcc> pitti: if it crashed it would be out of process so would not harm trackerd
<pochu> pitti: well, it's a recommends, and we install recommends by default... that's why I closed it
<pochu> pitti: when tracker wasn't in main yet
<pitti> pochu: ah, I see; but we don't install it as part of -desktop
* mjg59 fails to reproduce
<pochu> pitti: o3read? right, I guess the bug is valid now...
* pochu reopens it
<stgraber> iwj: You may have received two e-mails from the Ubuntu QA Tracker, you can ignore them. That was just test e-mails that shouldn't have left my server :)
<towolf> mjg59: i have the persistent gsd crasher with synaptics here.
<towolf> mjg59: i could test something
<mjg59> towolf: Could you do gdb /usr/bin/gnome-settings-daemon
<mjg59> break gdk_x_error
<mjg59> run --sync
<mjg59> and then, when it stops, do bt and give me the backtrace?
<towolf> mjg59: do i need something like -dbg?
<mjg59> towolf: We don't build a debug package for it sadly, so no
<mjg59> With luck there'll be enough information for me to get an idea about what's going on
<towolf> mjg59: at the start it spews: Function "gdk_x_error" not defined.
<mjg59> Yeah, that's fine
<towolf> mjg59: then: (no debugging symbols found)
<towolf> mjg59: (gdb) bt
<towolf> No stack.
<mjg59> Did it spit out the error?
<towolf> mjg59: the stderr is not interesting, is it?
<towolf> mjg59: no?
<towolf> mjg59: yes, the output of the program, yes.
<mjg59> towolf: You told it to make the breakpoint pending on future shared library load?
<towolf> mjg59: hold on
<towolf> mjg59: no stack, with y earlier.
<mjg59> What caused it to break?
<towolf> mjg59: and a couple times, "hit return to"
<mjg59> Hit return to what?
<towolf> mjg59: This?: Program exited with code 01.
<towolf> (no debugging symbols found)
<towolf> ---Type <return> to continue, or q <return> to quit---
<mjg59> Ok. In that case the breakpoint didn't work
<towolf> let's paste the entire thing somewhere
<seb128> mjg59: we do build dbgsym for everything no?
<mjg59> seb128: There doesn't seem to be a -dbg package for control-center
<seb128> mjg59: you don't know about https://wiki.ubuntu.com/DebuggingProgramCrash ?
<seb128> mjg59: deb http://people.ubuntu.com/~ubuntu-archive/ddebs gutsy main universe
<mjg59> Oh, yes.
<seb128> mjg59: that source should have -dbgsym for every binary built
<mjg59> Well, let's see if we can actually get a breakpoint first :)
<Keybuk> http://people.ubuntu.com/~scott/fontconfig.patch
<Keybuk>   (and libcairo.patch and xft.patch alongside)
<towolf> mjg59: http://en.pastebin.ca/705069
<towolf> mjg59: the Warnings are because i used to use evdev for my keyboard, but disabled it, just in case.
<mjg59> towolf: Hrm.
<mjg59> Try break gdk_x_error() ?
<mjg59> Though I don't /think/ that makes any difference
<pitti> iwj: your glibc upload doesn't mention the bug# in the changelog; you'll close it manually, I take it?
<towolf> nope
<mjg59> Sigh.
<towolf> reminds me of the old evdev mouse driver gsd crash.
<towolf> that was a pain to debug too
<Keybuk> mjg59: is that the kind of patch you were after?
<ScottK> pitti: I have a question about fixing the current FTBFS in sdl-mixer1.2.  There's a new Debian revision that solves the FTBFS plus other stuff.  At this point assuming both build (we're still testing), would you rather a sync or just the one patch: http://packages.debian.org/changelogs/pool/main/s/sdl-mixer1.2/sdl-mixer1.2_1.2.6-3/changelog
<mjg59> Keybuk: Looks promising, yup
<pitti> ScottK: judging by that changelog, I'd rather sync
<Keybuk> mjg59: my only concern is that this adds a fair amount of new API to several libraries
<ScottK> pitti: Thanks.  Assuming it tests out OK, we'll ask for a sync.
<mjg59> Keybuk: Several? Surely it's one API addition to Fontconfig?
<Keybuk> fontconfig gains the new lcdfilter option, yes
<Keybuk> xft just needs to use that, so no biggy
<Keybuk> though it does add an entry to an internal struct
<seb128> mjg59: you might need the dbgsym to break on a symbol, not sure if it can resolve with a stripped version
<Keybuk> cairo is the annoying one, since it has to grow cairo_lcd_filter_*
<Keybuk> yay for every library wrapping the functions of the libraries they use which are functions wrapping other wrapper functions
<towolf> seb128: installing dbgsym ...
<mjg59> towolf: You might need the gdk ones as well, in that case
<towolf> mjg59: package?
<seb128> towolf: iinstall libglib2.0-0-dbgsym libgtk2.0-0-dbgsym gnome-control-center-dbgsym
<mjg59> Keybuk: These are internal libraries?
<towolf> ok, broke(sic?) at gdk_x_error
<towolf> #0  gdk_x_error (display=0x808f100, error=0xbfb01608)
<towolf>     at /build/buildd/gtk+2.0-2.12.0/gdk/x11/gdkmain-x11.c:614
<towolf> #1  0xb714d655 in ?? () from /usr/lib/libbonoboui-2.so.0
<towolf> #2  0x0808f100 in ?? ()
<towolf> #3  0xbfb01608 in ?? ()
<towolf> #4  0x00000000 in ?? ()
<seb128> towolf: libbonoboui2-0-dbgsym
<towolf> #0  gdk_x_error (display=0x808f100, error=0xbfe6b178)
<towolf>     at /build/buildd/gtk+2.0-2.12.0/gdk/x11/gdkmain-x11.c:614
<towolf> #1  0xb7156655 in bonobo_x_error_handler (display=0x808f100, error=0xbfe6b178)
<towolf>     at bonobo-ui-main.c:58
<towolf> #2  0xb7f47f50 in xkl_process_error () from /usr/lib/libxklavier.so.11
<towolf> #3  0xb7837c4a in _XError () from /usr/lib/libX11.so.6
<towolf> #4  0xb7839714 in _XReply () from /usr/lib/libX11.so.6
<towolf> #5  0xb78f0b32 in XOpenDevice () from /usr/lib/libXi.so.6
<towolf> #6  0x0805dcbb in ?? ()
<towolf> #7  0x0808f100 in ?? ()
<towolf> #8  0x00000001 in ?? ()
<towolf> #9  0xbfe6b2c8 in ?? ()
<towolf> #10 0xb7e2d337 in gconf_client_get_bool () from /usr/lib/libgconf-2.so.4
<towolf> #11 0x0805ddb8 in ?? ()
<towolf> #12 0x080a4758 in ?? ()
<towolf> #13 0x0806ebdc in ?? ()
<mjg59> Keybuk: Hm. I may be misunderstanding this. libcairo doesn't seem to actually use those functions you've added?
<towolf> #14 0x00000000 in ?? ()
<mjg59> towolf: Are you sure you have gnome-control-center-dbgsym ?
<slangasek> Keybuk: so if it's an API addition to fontconfig, do you feel we should get buy-in from keithp before committing to that path?
<towolf> mjg59:  *** 1:2.20.0-0ubuntu1 0 from people.ubuntu.com
<seb128> towolf: you can use http://pastebin.ubuntu.com/ rather than the chan to copy backtraces
<mjg59> seb128: Hm. Any idea why those symbols aren't resolving?
<towolf> seb128: alright, what now?
<seb128> towolf: you might want to install libxi6-dbgsym libxklavier11-dbgsym
<towolf> seb128: on it.
<seb128> and libx11-6-dbgsym
<Keybuk> mjg59: it uses the set_lcd_filter one
<mjg59> Sorry, you're right
<seb128> mjg59: lacking dbgsym for some libraries like libx11, libxi, etc
<mjg59> seb128: Ah, ok
<mjg59> Keybuk: Hm. __ it?
<Keybuk> mjg59: :)
<slangasek> twitch
<Keybuk> it shows up in a size change to cairo_font_options_t
<mjg59> Oh, of course
<Keybuk> but the contents of that struct are hidden
<mjg59> Hmph.
<mjg59> Yeah, less of a problem then
<Keybuk> the headers only include a typedef for it
<mjg59> And that's only used internally?
<Keybuk> yeah
<towolf> seb128: http://en.pastebin.ca/705091
<mjg59> Still seem to be missing most of the symbols
<slangasek> well, part of the backtrace looks wonky too
<slangasek> #8  0x00000001 in ?? ()
<mjg59> Hm. Yeah.
<mjg59> All the symbols that /do/ turn up are plausible
<mjg59> I've got a pretty good idea of where it's falling over, I've just got no idea why
<Keybuk> mjg59: yup, works even if I make the function private
<mjg59> Ok. I suspect we can work around this by surrounding the entire block in gdk_error_trap_push()/gdk_error_trap_pop(), but I'd prefer to know /why/ it's happening
<josephpiche> sorry, i got disconnected. Is there a process for reviewing a spec/blueprint for decline?
<pitti> good night everyone
<seb128> towolf: can you "sudo apt-get install --reinstall gnome-control-center/gutsy"?
<seb128> towolf: did you do a local build or something?
<towolf> seb128: no
<towolf> seb128:  do i have to quit gdb everytime?
<seb128> yes
<towolf> or can i just .. ok
<seb128> "#6  0x0805dcbb in ?? ()" looks like something that should come from gnome-settings-daemon
<towolf> seb128: ah...
<seb128> I'm not sure why it has no debug information
<seb128> usually that's because the package and the dbgsym don't come from the same build
<towolf> seb128: whats this? You can only run one xsettings manager at a time; exiting
<seb128> like a local build against a buildd one
<towolf> seb128: shit, my bad
<towolf> seb128: nah, same thing
<towolf> seb128: only the numbers differ
<seb128> towolf: if you do
<seb128> $ gdb /usr/bin/gnome-settings-daemon
<seb128> symbol-file /usr/lib/debug/usr/lib/gnome-control-center/gnome-settings-daemon
<seb128> 
<seb128> does it work?
<towolf> seb128: oh.
<seb128> ?
<towolf> seb128: all this pasting takes a while. but there's more now. http://en.pastebin.ca/705105
<seb128> mjg59: ^
<seb128> here you go
<seb128> ;)
<mjg59> towolf: Can you type "up" until you're at the frame for set_tap_to_click ?
<seb128> weird that gdb didn't get the debug symbols automatically, gnome-settings-daemon seems to have a .gnu_debuglink
<towolf> mjg59: ang "bt"?
<towolf> *and
<mjg59> towolf: print devicelist[i] .name
<towolf> mjg59: lokks like this: (gdb) print devicelist[i] .name
<towolf> $1 = 0xb7fc8e73 "\203\024\211e\f"
<towolf> mjg59: gibberish?
<mjg59> Hm. That doesn't look right.
<mjg59> How many times does the phrase "Synaptics Touchpad" appear in your /etc/X11/xorg.conf ?
<seb128> towolf: you can try to "thread apply all bt full" to list also local variables in the backtrace
<towolf> seb128: restart first?
<seb128> yes
<seb128> hum
<seb128> no
<seb128> no need in fact for that ;)
<seb128> also maybe copy your xorg.conf somewhere
<towolf> a'ight: new bt: http://en.pastebin.ca/705114
<towolf> and xorg.conf: http://en.pastebin.ca/705115
<ant30> Hi, I has reported a bug to update-notifier with the solution . It is for upgrade from feisty to Gutsy
<towolf> mjg59: twice
<towolf> seb128: i'll be having a visitor in 10min, anything else i can do?
<towolf> mjg59: 
<mjg59> towolf: Looking at it, but not having much joy so far
<towolf> mjg59: i'm sorry for that ...
<mjg59> No problem
<seb128> towolf: maybe copy the backtrace and the xorg.conf on the bug
<seb128> towolf: thanks for the work on it
<ScottK> seb128: Do you ahve time to look at a sync that will fix a Main FTFBS?
<seb128> ScottK: yes
<ScottK> It's Bug #141351
<ubotu> Launchpad bug 141351 in sdl-mixer1.2 "Please sync sdl-mixer1.2_1.2.6-3 from debian unstable main" [Medium,New]  https://launchpad.net/bugs/141351
<ScottK> Thanks
<seb128> you're welcome
<YokoZar_> Do the package.install and package.dirs files respect architecture flags?  ie, can I have usr/lib32 [amd64]  in debian/package.dirs ?
<seb128> ScottK: I use your id for the sync, ok?
<ScottK> seb128: If you want
<ScottK> They guy that filed the bug did all the work.  I'm good either way.
<seb128> ScottK: do you know him?
<towolf> seb128:  done. signing off.
<seb128> ScottK: I just want to get somebody responsive notified if the build fails
<seb128> towolf: thanks
<ScottK> I'll do for that then.
<Keybuk> mjg59: \o/
<mjg59> Keybuk: ?
<seb128> ScottK: the guy is member of some teams already, I've used his account for the sync
<ScottK> seb128: Fine by me
<seb128> ScottK: bug closed ;)
<ScottK> seb128: Thanks
<YokoZar_> Do the package.install and package.dirs files respect architecture flags?  ie, can I have usr/lib32 [amd64]  in debian/package.dirs ?
<YokoZar_> oops sorry for repost
<ScottK> seb128: Do packages that were dep waiting on that one automatically get queued to build or do they need a manual shove?
<seb128> ScottK: dep wait works automatically
<ScottK> seb128: Cool.  Thanks.
<seb128> YokoZar_: I don't think so
<seb128> I'm not totally sure though
<seb128> I didn't have to use that myself yet
<Keybuk> mjg59: lcdfilter gets passed all the way from fontconfig up to gnome-terminal
<Keybuk> now I just have to figure out how to get fontconfig to match the monospace font
<Keybuk> for some reason, test name=family never works on monospace
<YokoZar_> seb128: I'm just worried about my package making an empty /usr/lib32 directory on a 32 bit machine
<seb128> YokoZar_: maybe that's the upstream makefile doing it?
<seb128> YokoZar_: empty dirs usually don't hurt though
<YokoZar_> no it's nothing upstream yet
<slangasek> seb128: well, it's not supported by upstream debhelper anyway
<slangasek> YokoZar_: I would suggest conditionally setting a variable in debian/rules based on the host architecture, containing the list of "extra" directories you're adding, and then pass that as an argument to dh_installdirs
<slangasek> (n.b., if this source package builds more than one binary package, you'll also want to use -p and -N options to make sure you don't add the dir to packages that don't need it)
<slangasek> oh... also, if this is a /non/-empty dir in the package, you normally don't need to list it in .dirs at all...
<YokoZar_> slangasek: it builds two binaries, one of which is dependent on the other (wine and wine-dev)
<YokoZar_> slangasek: I'm also thinking about the install file
<slangasek> yes, for the install file I have no good answers
<YokoZar_> slangasek: if the install file points to something not there (say, usr/lib32/*.so.* on i386), will bad things happen?
<slangasek> yes, you'll get a build failure
<slangasek> one option: create two separate .install files, symlink to the right one during the build
<YokoZar_> Something like wine.install.i386 and wine.install.amd64 ?
<slangasek> yes
<Keybuk> heh
<Keybuk> because I'm not using Vera, but DejaVu
<YokoZar_> slangasek: for some reason I think that which .install.arch file to use should be handled automagically, but it's probably just bad memory
<Keybuk> mjg59: 12px?
<mjg59> Keybuk: Sounds reasonable.
<slangasek> YokoZar_: oh, actually it does
<slangasek> right, I had a vague memory of that
<YokoZar_> slangasek: oh, cool.  So all I should have to do is just have those files then, and no wine.install file
<slangasek> YokoZar_: seems so, yes
<YokoZar_> slangasek: actually, I bet (hope) that the way it works is it calls the arch one first and then the general one.  So I'm supposed to put ones common to both in wine.install, and then amd64 specific ones (usr/lib32) into wine.install.amd64
<slangasek> YokoZar_: nope, if it finds an arch one it ignores the general one
<YokoZar_> slangasek: ahh ok
<YokoZar_> slangasek: thank you so much, hopefully I'll have a good Wine package by beta time :)
<rawler_> hey.. does anyone know anything about whether nvidia 100.14.19 will make it to Gutsy?
<ajmitch> good morning
<Keybuk> mjg59: 12px is perfect, my fonts are 13px high <g>
<seb128> hey ajmitch
<mjg59> Keybuk: Ha
<Keybuk> (and since I've been using the new filter for the last few days, I've gotten used to it and now prefer it)
<Keybuk> anyhoo
<Keybuk> http://people.ubuntu.com/~scott/lcdfilter
<Keybuk> source packages and debdiffs for your testing pleasure
<Keybuk> works for me (tm)
<bryce> rawler_: it's too late; we've been in Upstream Version Freeze for a while
<mjg59> Keybuk: What's the change to gnome-control-center?
<Keybuk> mjg59: changes the top "subpixel" option to use hinting=Slight
<Keybuk> which every single thing says is the right option
<Keybuk> (with turner's patches)
<rawler_> bryce: I kindof figured.. it's too bad.. it fixes a buttload of bugs..
<bryce> rawler_: I'll probably make backport debs of it available at some point though once the dust has settled on gutsy
<mjg59> Keybuk: Uh. No, I suspect not for the monospace case
<Keybuk> mjg59: indeed, which is why the conf.d for the monospace case sets the hinting level :p
<Keybuk> (as well as the lcd filter)
<mjg59> Keybuk: Ah, ok :)
<rawler_> bryce: sounds reasonable.. :) personally I'll resort to envy for now, but it just sucks having to do that for every nvidia-user i persuade into Ubuntu.. :)
<mjg59> Slight hinting absolutely kills monospace at low font sizes
<alex-weej> Keybuk: PPA? :)
<Keybuk> mjg59: hinting gets disabled completely for monospace at low font sizes
<mjg59> Now, or previously?
<bryce> rawler_: would you be interested in helping with this driver?  A large reason we're not up to date is just manpower
<Keybuk> previously and now
<mjg59> Hm.
<Keybuk> conf.d/20-unhint-small-vera.conf
<mjg59> That doesn't fit what I see - altering the hinting settings changes my terminal
<Keybuk> mjg59: you might be using DejaVu Mono instead?
<bryce> rawler_: pop over to #ubuntu-x if you're interested
<alex-weej> mjg59: /etc/fonts seems to change every distro upgrade
<mjg59> I'm using whatever a default install gives you
<Keybuk> (though they should include the instructions)
<Keybuk> not really relevant anyway
<mjg59> Ok, let me see how this turns out in a minute
<Keybuk> funny: I was sure I'd got the patch wrong, since the fonts looked ... weird
<Keybuk> but it turned out I was just so used to the new filter
<rawler_> bryce: thanks for the invite, and yes I'd love NOTHING more than help developing Ubuntu, but until that pays my rent, I'm afraid I have to go to sleep to bear another mindless day at work tomorrow.. :)
<ajmitch> bryce: what do you need with it? I tend to use nvidia on my gutsy desktop
<rawler_> bryce: so, I'll drop by, go to bed and if I get some time I'll see what I can do for the weekend.. :)
<bryce> ajmitch: aside from making new packaging (which I hope to automate away for Hardy), it involves just testing out new versions, riding herd on bugs, etc.
<bryce> rawler_: cool
<ajmitch> right
<bryce> we've been using this approach for -fglrx in the forums, and have had some really nice successes there for gutsy
<bryce> (not just -fglrx but also -ati and -radeonhd)
<mjg59> Keybuk: Ok, playing with hinting seems to suggest that stuff Just Works
<Keybuk> mjg59: your monospace appears with legacy lcd filtering?
<mjg59> Keybuk: Yup
<Keybuk> ok, seems that we're both happy now? :)
<Keybuk> slangasek: are you happy for me to upload?
<mjg59> Keybuk: Hm. No, I've got some very ugly rendering here with slight hinting
<mjg59> Hang on, let me try to figure this out
<mjg59> Ok. I'd say at the moment that this change plus full hinting seems to work fine
<mjg59> Slight hinting is generating severe colour blurring
<shaya> anyone suffer from a bug w/ clearlooks theme in gutsy?
<Keybuk> mjg59: yeah, I've alternated between Full and Slight for a while ...
<shaya> in pidgin, the tooltip info pop up doesn't always correspond to the right buddy
<shaya> but if I switch to human, it works fine
<Keybuk> I think the upload should not include the gnome-control-center change, and instead the mail should ask people to compare both and see which they like
<mjg59> Keybuk: Yeah, I'd go with that for now
<cjwatson> OK, tomorrow morning's CDs are going to be bust I'm afraid, despite my best efforts
<cjwatson> I need to fall asleep and I don't have time to finish the last debian-installer change that needs to land for beta
<Keybuk> cjwatson: :-(
<pkern> ):
<cjwatson> but I'll do it first thing tomorrow morning and rebuild CDs
<pkern> cjwatson: Well, have a good night anyway. (:
<Keybuk> cjwatson: g'night
<mjg59> Keybuk: I wonder if the hinting setting interacts badly with the bytecode interpreter
<Keybuk> mjg59: in theory, light hinting uses the autohinter
<Keybuk> (so I'm told)
<mjg59> Ok
<cjwatson> actually, I can upload, because there are no udebs for the last thing I wanted - argh
<Keybuk>         if ( mode == FT_RENDER_MODE_LIGHT             ||
<Keybuk>              face->internal->ignore_unpatented_hinter )
<Keybuk>           autohint = 1;
<Keybuk> (though I'm not convinced :p)
<Keybuk> ah, no, I see; the transition from FC_HINT_SLIGHT -> FT_RENDER_MODE_LIGHT is done by pango
<cjwatson> Keybuk: uploading debian-installer; could you take care of accepting it when it's done *AND* libdebian-installer and hw-detect are in the accepted queue
<cjwatson> ?
<Keybuk> cjwatson: sure
<cjwatson> Keybuk: the source needs to not be accepted before the latter happens or we all get to go round again :)
<cjwatson> thanks
<Keybuk> all three need to be accepted at once?
<Keybuk> (as source)
<cjwatson> ah, actually, they're in the accepted queue already, so that's not a problem
<cjwatson> Keybuk: no, I meant the binaries
<Keybuk> right
<Keybuk> it should auto-accept now, no?
<cjwatson> d-i needs the new binaries of its bits to be published <= its source
<cjwatson> the binaries will, but the source will land in unapproved
<cjwatson> sorry
<cjwatson> the libd-i and hw-detect binaries will auto-accept
<Keybuk> :)
<cjwatson> the d-i source will land in unapproved
<Keybuk> ok
<Keybuk> so d-i just needs to be accepted once the upload is done
<cjwatson> right, three minutes to process-upload
<cjwatson> but Kirsten is going to kill me if I don't get moving now :)
<cjwatson> (somewhat rightly so, I got four hours sleep last night)
<cjwatson> Keybuk: the kernel's going to need some more NEW love; I did it for some architectures
<cjwatson> i386 is still building
<Keybuk> there are *some* advantages to your partner living and working in another city :p
* Keybuk gets to hack late at night again now
<cjwatson> hah
<cjwatson> night
<bryce> cya cjwatson
<slangasek> Keybuk: if you and mjg59 are both happy, knock yourself out :)
#ubuntu-devel 2007-09-21
<bryce> heya slangasek, I've got a thrice-confirmed fix for beta bug 137604 that needs release manager approval
<ubotu> Launchpad bug 137604 in xorg-server "Black Bar Across Screen with gutsy i810" [High,Fix committed]  https://launchpad.net/bugs/137604
<bryce> slangasek: fix is pretty straightforward - just drops an errant patch.
<slangasek> bryce: is http://people.ubuntu.com/~bryce/Uploads/xorg-server_1.3.0.0.dfsg-12ubuntu6.debdiff the right debdiff?
<bryce> yep
<slangasek> bryce: no bugs referenced in the changelog for when the patch was originally added, you're comfortable that reverting won't cause a regression elsewhere?
<bryce> correct.  These were cherry-picked from xserver 1.3.99, but this particular patch did not have a LP bug associated with it.
<slangasek> ok, go for it
<bryce> great, thanks
<iwj> pitti: (Not here, but:) libc patch was very straightforward.  Yes, I'll close the bug - sorry.
<lamont> slangasek: did sysvinit get held up by the freeze?
<slangasek> lamont: er.  I don't think I even know how to find an answer to that question, at the moment
<lamont> slangasek: heh
<lamont> no worries.
<lamont> it'd be nice if it got accepted sometime soonish
<alex-weej> alex@flash:/etc/fonts/conf.d$ dpkg -S /etc/fonts/conf.d/53-monospace-lcd-filter.conf
<alex-weej> dpkg: /etc/fonts/conf.d/53-monospace-lcd-filter.conf not found.
<alex-weej> ?!
<mjg59> slangasek: Bah, forgot to mention a bug number in my gnome-control-center upload. It's #140485
<alex-weej> mjg59: you're still up
<alex-weej> what's this configuration option for enabling the default lcd filter?
<alex-weej> i am all up to date on the main archive but i don't seem to be getting the behaviour you and scott are describing in mailing lists etc.
<alex-weej> in fact i can't see any of these supposed changes in any of the relevant packages
<alex-weej> last changelog entry is basically you saying "reverting all this"
<lamont> Waiting for approval::
<lamont>  OK: sysvinit_2.86.ds1.orig.tar.gz
<lamont>  OK: sysvinit_2.86.ds1-14.1ubuntu28.diff.gz
<lamont>  OK: sysvinit_2.86.ds1-14.1ubuntu28.dsc
* lamont verifies that sysvinit is definitely in the "waiting" queue. :-(
<Vegar> is this the channel to ask questions about the debian/rules script from the kernel source package?
<Vegar> oh well, I'll give it a shot
<Vegar> I ran debian/rules custom-binary-vegar, which generated a linux-headers-2.6.22-12-vegar_2.6.22-12.36.deb
<Vegar> that .deb depends on linux-headers-2.6.22-12. how do I build one of those?
<lamont> Vegar: if you build the base package, you'll get that one.
<lamont> likewise, once the -12 source is accepted (beta freeze), then it'll get built.
<Vegar> lamont: how do I build the base package?
<lamont> debuild -b
<lamont> it'll, um, take a while
<Vegar> does it build images for all the architectures?
<lamont> all flavors for whatever arch you're running on, yes.
<Vegar> oh dear
<lamont> alterntatively, i'd expect that the linux-headers-2.6.22-12 package will be in the archive sometime tomorrow
<Vegar> and flavours are read from a file in a debian/*.d directory?
<Vegar> oh
<Vegar> tomorrow
<lamont> I think so
<Vegar> now that's interesting
<lamont> https://edge.launchpad.net/ubuntu/gutsy/+queue shows it blocked waiting approval
<Vegar> hah
<Vegar> debian/rules binary-headers is building it
<Vegar> wonderful
<pitti> Good morning
<IntuitiveNipple> morning
<pitti> eek, LP offline
<IntuitiveNipple> Anyone familiar with LRMI (Linux Real-Mode Interface) know where the latest (0.9?) source is? Sourceforge only seems to have 0.10 and yet I see references to 0.9 in some other packages (e.g. svgalib)
<desrt> pitti; crikey.
<desrt> what is happening to the world?  yesterday gnome bugzilla and today launchpad
<pitti> desrt: rollout apparently
<desrt> ahh
<StevenK> Morning pitti
<ajmitch> morning pitti
<pitti> hey ajmitch
<pitti> asac: did you see Q-FUNK's regression in bug 139403?
<ubotu> Launchpad bug 139403 in network-manager "network-manager should stop managing any interface configured in /etc/network/interfaces" [High,Fix released]  https://launchpad.net/bugs/139403
<ajmitch> LP back already?
<ajmitch> great
<evand> pitti: asac I had a similar experience, but it may just be a configuration issue.
<evand> I'm assuming that if I comment the device out of interfaces and restart, network-manager should use it, correct?  It currently does not.
<pitti> oh, that does look a little different now: https://edge.launchpad.net/ubuntu/+source/compiz
<pitti> evand: right
<evand> nm-applet does not die on me, though.
<tepsipakki> hmm, the latest sysklogd update makes klogd fail to start here..
<tepsipakki> but I guess it's not the same for everyone else
<pitti> tepsipakki: runs happily here; any details?
<tepsipakki> pitti: let me try a fresh install first. I put
<tepsipakki> uh
<tepsipakki> pitti: ... 'set -x' in the start script, and then it started fine, so I'm not sure what's going on :)
<ajmitch> hi LaserJock
<LaserJock> hi ajmitch
<LaserJock> I'm trying to debug a not-so-nice bug in feisty
<LaserJock> after a while when I go to logout/hibernate/shutdown the screen just freezes
<LaserJock> or rather it just doesn't do anything
<IntuitiveNipple> LaserJock: I solved a similar (if not the same) issue a while back on Feisty, on a local system. I *think* I bug-reported it but I'm not sure; let me have a dig
<LaserJock> that'd be helpful, I don't even know quite what to look for
<IntuitiveNipple> I remember having to apply it a couple of times after Feisty kernel updates but it was one of those manual things I kept at the back of my mind
<IntuitiveNipple> LaserJock: To help jog my memory, is the system using compiz?
<LaserJock> nope
<IntuitiveNipple> I'm not *positive* (and so far I can't find a bug-report I made on this), but I *think* the solution yo my issue involved disabling compiz sync to vblank
<IntuitiveNipple> s/yo/to/
<LaserJock> hmm, well I doubt that's my issue
<LaserJock> as I don't use compiz
<IntuitiveNipple> I've dealt with so many issues this past few months, I really can't remember which one it was - I do recall the fix was trivial once I recalled how to do it :)
<LaserJock> heh
<IntuitiveNipple> I *think* the solution may be in a forum-post I found, which would explain why I can't find a bug-report
<IntuitiveNipple> I'm scanning my bookmarks looking for a likely candidate
<LaserJock> it's so weird. If I logout soon after logging in it's fine
<LaserJock> if I wait a while it gets stuck
<dholbach> good morning
<Mithrandir> quadrophonic Daniel
<dholbach> :)
<tepsipakki> pitti: klogd still fails to start.. I need to boot in su-mode to debug that.. (now where were the passwords again)
<\sh> moins
<\sh> guys, is it allowed to change files inside debian/ directory during build time?
<\sh> especially <package>.dirs is important for me now
<pitti> \sh: preferably not
<pitti> \sh: but if it's just .dirs, you can certainly create the necessary dirs in debian/rules?
<pitti> \sh: ... and a lovely good morning!
<LaserJock> grr, this seems to be a gnome-specfic problem :/
<LaserJock> something maybe in feisty-updates I guess
<pitti> LaserJock: is this video driver or kernel specific?
<LaserJock> I have no idea
<pitti> LaserJock: you might try with vesa, and with booting the feisty/release kernel?
<LaserJock> hmm
<pitti> LaserJock: or with logging out of gnome and suspending with gdm? (to rule out gnome-power-manager, compiz, etc.)
<LaserJock> well, I can't log out of gnome, that's the problem ;-)
<pitti> LaserJock: hm?
<LaserJock> my problem is that at some point I can no longer log out of gnome
<LaserJock> it doesn't happen in KDE
<\sh> pitti: to you too...good morning :)
<LaserJock> and it takes a while of being logged in before it does it
<pitti> LaserJock: that sounds like a dbus or session initialization problem
<pitti> LaserJock: check system -> settings -> session -> current session
<\sh> pitti, problem is, that I'm trying to fix wine on amd64 to deploy it's libs into /usr/lib32 ...but the .dirs files needs /usr/lib so I'm trying to find a solution how to install /usr/lib or /usr/lib32 into the package depending on the arch
<pitti> LaserJock: anything there that tries to connect to the session, but fails? (a 'plug' icon)
<LaserJock> not yet
<LaserJock> I do know that it's happened since Feisty's release
<LaserJock> I'd guess a month ago or so
<pitti> \sh: sounds like you should do it dynamically in debian/rules; I. e. set a $LIBDIR depending on DEB_BUILD_ARCHITECTURE, and use install -D ... $LIBDIR/
<pitti> \sh: (or make install DESTDIR=... or whatever the upstream build system provides)
<\sh> pitti, this is not the problem :) the problem is that the package itself uses .dirs to move the files into the package...but when I only need /usr/lib32 on amd64 and /usr/lib on i386...how to avoid the usage of debian/<package>.install and debian/<package>.dirs...I woud use dh_install in debian/rules and avoid using the automatic stuff
<pitti> \sh: .dirs does not move any files, and in most cases, .dirs files are not necessary at all
<\sh> pitti, the upstream build version is autotools...so no problem with DESTDIR
<pitti> \sh: autotools -> ah, that has --libdir or so
<pitti> \sh: right, dh_install is too dumb for per-arch directories, so you cannot use that
<\sh> pitti, yepp..and depending on the build arch i'M setting CONFFLAGS += --libdir=/usr/lib32 on amd64...this is no problem.
<pitti> \sh: just use --libdir and DESTDIR=debian/ia32-libs/ ?
<pitti> that'll directly install the files into the binary package, isntead of into debian/tmp and using dh_install
<LaserJock> pitti: ok, it just did it again
<LaserJock> pitti: is there any good debugging I can do while it's frozen?
<pitti> LaserJock: hm, no idea
<pitti> LaserJock: unless you can ssh into the box and look at dmesg?
<LaserJock> I'm on the box
<pitti> LaserJock: is only X frozen, or the VTs, too?
<\sh> pitti, ok...or DESTDIR=debian/tmp and moving the files to the correct location e.g. debian/<package1>/ or debian/<package2>/
<LaserJock> it's actually just that the logout screen is frozen
<pitti> \sh: whichever is easier
<LaserJock> the mouse works
<pitti> LaserJock: oh
<\sh> pitti, thx...this helps me a lot :)
<pitti> LaserJock: that moves the bug into the higher gtk levels then
<LaserJock> if I click on *any* button in the logout dialog it does it
<LaserJock> even cancel
<LaserJock> pitti: do you know what package is responsible for the logout?
<pitti> LaserJock: I'm not entirely sure; dholbach?
<pitti> a combination of gdm/gnome-power-manager/gnome-session, I guess
<pitti> hey seb128
<seb128> hello pitti
<seb128> hi MacSlow
<gicmo> morning seb128
<MacSlow> hi seb128, pitti, gicmo
<pitti> hey MacSlow
<gicmo> jo MacSlow!
<seb128> gicmo: Alter!
<LaserJock> hi seb128
<seb128> Hi LaserJock
<dholbach> seb128, gicmo: ALTER
<gicmo> ALTER!
<seb128> hey dholbach
<MacSlow> dholbach, you should have taught seb128 the whole thing... "Alter Schwede!" not just "Alter!" :)
<LaserJock> ok, so when I go back to X the logout area is just white
<dholbach> MacSlow: ALTER is enough - I hear that more often than 'Alter Schwede' :)
<LaserJock> seb128, dholbach: any idea of what would make the logout dialog box freeze up?
<LaserJock> in Feisty that is
<seb128> freeze?
<seb128> like if you click on an action it doesn't do it and doesn't respond to the click?
<dholbach> LaserJock: no idea, I haven't used feisty in a while
<LaserJock> seb128: exactly
<seb128> LaserJock: never seen that, usually the dialog just doesn't open
<seb128> no idea
<dholbach> on my amd64-nvidia box, 'desktop effects can not be started' any more; the resolution does not seem to match the 3D map or something
<seb128> you are the first to report a such isssue
<LaserJock> seb128: after I've been logged in for a while, if I click on *any* button it freezes
<LaserJock> the mouse works
<LaserJock> but I gotta restart X to log out, which is kinda annoying
<LaserJock> it doesn't do it in KDE and I tried a fresh .gconf* .gnome*
<IntuitiveNipple> LaserJock: I just remembered - when this happened I couldn't restart GDM with Ctrl+Alt+Backspace but could with Ctrl+Alt+SysRq+K
<LaserJock> CtrlAltBackspace definately works here :-)
<IntuitiveNipple> LaserJock: strike 2 :p
<LaserJock> seb128: it's happened since release so I'm guessing it related to an update
<IntuitiveNipple> LaserJock: can you switch to a text console?
<LaserJock> yep
<seb128> LaserJock: it happened since release so it's not an update, is it?
<LaserJock> everything works except it won't log me out
<LaserJock> seb128: no, I'm saying it started since after the release
<LaserJock> my english wasn't very clear
<seb128> do you suspend or hibernate this box? is the lo interface working correctly?
<seb128> ok
<LaserJock> it started about maybe 1 month ago
<LaserJock> I do hibernate
<IntuitiveNipple> LaserJock: I wish I could remember how I solved it! It happened on a  dual-CPU Matrox G450 dualhead with no compiz, but unfortunately I recently wiped that one
<LaserJock> I think lo is working ok
<LaserJock> I've had lots of fits with swap/hibernation/networking but I thought I got them all worked out
<LaserJock> I just don't understand why hitting the "cancel" even would cause problems
<LaserJock> seb128: it doesn't always do it either, I have to be logged in for some time
<LaserJock> I can log in and then immediately log out no problem
<IntuitiveNipple> Yes, that was the symptoms I had as well
<IntuitiveNipple> LaserJock: what video chipset and driver is in use?
<LaserJock> it's an ATI 7000 IGP card
<LaserJock> looks like ati driver
<IntuitiveNipple> LaserJock: my memory is returning somewhat... I recall it being an issue with the Composite extension, and disabling it in xorg.conf prevented the freeze.
<LaserJock> that would do it for Gnome specifically?
<LaserJock> gah, I don't even know how to get a xorg.conf in these days of automatic configs
<LaserJock> seb128: I gotta run, is it worth a bug report?
<seb128> LaserJock: no, a support request
<seb128> LaserJock: a bug should describe a technical issue
<IntuitiveNipple> bug #138811 might be related
<ubotu> Launchpad bug 138811 in gnome-power-manager "Can't access shutdown menu when gnome-power-manager isn't enabled is sessions options" [Undecided,New]  https://launchpad.net/bugs/138811
<LaserJock> seb128: ok
<LaserJock> IntuitiveNipple: I check for gnome-power-manager already
* LaserJock is away
<IntuitiveNipple> LaserJock: this one looks closer: https://bugs.launchpad.net/ubuntu/+bug/38915/comments/54
<ubotu> Launchpad bug 38915 in ubuntu "Logout proces hangs" [High,Confirmed] 
<asac> pitti: that is not an ifupdown regression, but a network-manager crash
<asac> pitti: i have a patch for that.
<pitti> asac: you rock
<asac> siretart: wpasupplicant ... we need a decision. 0.6.0 is the development version for development of network-manager 0.7, while 0.5 is the supplicant for network-manager 0.6.
<pitti> seb128: hm, I guess removing f-spot from desktop is not an option?
<seb128> pitti: no it's not
<seb128> it's one of the cool applications nowadays
<pitti> it'd be 1.8 MB of the 4 I still need to shave off the CDs...
<asac> siretart: i think upgrading after beta is better than downgrading, so maybe we should really consider to downgrade now.
<seb128> can't we bzip some packages to win those 4meg?
<asac> siretart: let me know.
<pitti> seb128: we already did so with the most promising ones
<seb128> no need of promising ones to win 4meg
<pitti> seb128: gnome-user-docs recently grew by 2 MB, due to translations, I guess
<pitti> not sure whether we can optimize this a bit, it's a pretty big hog
<seb128> can't we remove some fonts?
<pitti> seb128: we did so yesterday, that saved us 6 MB
* pitti hugs ArneGoetje 
<siretart> asac: I've been using the 0.5.9 version for quite some time now. the "timeouts messages" haven't vanished completely, but they are much fewer compared to 0.6
<pitti> seb128: and I asked calc for some OO.o changes which will give us another 10 MB
<siretart> asac: I currently suspect that network-manager folks develop and test with that version rather than with 0.6
<pitti> hi Keybuk
<siretart> asac: therefore I agree to you that it seems to be better for our users to ship with 0.5.9
<seb128> pitti: do we have a list of what is installed on the CD and the size of each package somewhere?
<pitti> seb128: loop-mount the CD and ls -lR :)
<pitti> seb128: the list of pacakges is in http://cdimage.ubuntu.com/daily/current/gutsy-alternate-i386.list
<pitti> seb128: and in the .manifest files for -live
<seb128> where do you need to win 4meg? desktop CD? alternate?
* pitti kills nvidia-glx from the i386 alternate, it's already gone on amd64
<pitti> seb128: alternate is most pressing
<pitti> seb128: we don't have *any* langpacks on desktops any more either, so getting some space there would also be cool
<seb128> you can remove f-spot from alternate if required I guess
<seb128> I don't expect many desktop user using alternate anyway
<pitti> seb128: f-spot is in -desktop
<pitti> seb128: so we can only remove it from ubuntu-desktop, not just from alternate
<seb128> no then
<Keybuk> pitti: morning
<seb128> /pool/main/v/vim/vim_7.1-056+2ubuntu1_i386.deb
<seb128> is vim required on the CD?
<seb128> we already have nano
<pitti> seb128: right, let's kill that as well, at least for beta
<seb128> and why is thunderbird-locale-en-gb_2.0.0.0+1-0ubuntu1_all.deb listed? we don't install thunderbird by default
<pitti> or until we get OO.o smaller
<pitti> seb128: language-support-en dependency
<pitti> seb128: we already removed language-support-en from amd64, though
<seb128> shouldn't it be a recommend?
* Keybuk adds "ship on DVD by default" to the Hardy list :p
<pitti> Keybuk: that'll loose us many testers and downloaders, though
<Keybuk> pitti: surely it's better than being unable to add anything new to Ubuntu ever again?
<pitti> seb128: ok, vim (6 MB) and nvidia-glx (8 MB on i386) removed
<seb128> pitti: do we need wamerican and wbritish? only one of those wouldn't be enough?
<asac> siretart: how about the startup delay we see in bug 141233. how many tries do you usually see in 0.5.9 to connect to global control socket?
<ubotu> Launchpad bug 141233 in wpasupplicant "MASTER network-manager crashes when wpasupplicant ctrl socket is not available" [Medium,Confirmed]  https://launchpad.net/bugs/141233
<pitti> seb128: language-support-en, again
<seb128> pitti: well, we can modify language-support-en if required no? ;)
<pitti> seb128: we could drop language-support-en from the CDs and only install a subset of its dependencies, of course
<siretart> asac: err, I didn't notice that. While grepping through my logs, I do see that message, but the delay is less than a second
<pitti> Keybuk: it would encourage us to throw in a lot of stuff without ever cleaning up cruft, though
<pitti> ok, this should get down amd64 alternate to 702 MB and i386 alternate to 700 MB
<pitti> let's hope we get the new OO.o soon
<seb128> I don't think we will manage to keep everything on one CD much longer anyway
<pitti> that has always been a strong point of Ubuntu, though *sniff*
<Keybuk> true, but increasing numbers of people have DVD writers now
<Keybuk> and we don't need to fill the DVD, we could still artificially limit ourselves to <1GB or something
<Mithrandir> the main problem with DVDs will be the size of them and downloading taking a while rather than burning them
<Mithrandir> <2GB would at least be good, so we don't end up running into funny file system limitations.  *cough, fat*
<pitti> right, bandwidth is still an issue in many parts of the world (except Norway, of course :-P)
<Mithrandir> I only have 6.5Mbit at home.
<Mithrandir> at the office, I'm not sure.
<seb128> or we should stop using openoffice, but there is no good GNOME office at the moment :/
<Keybuk> seb128: gedit!
* seb128 slaps Keybuk
<Keybuk> epiphany+webkit instead of firefox/gecko?
<Keybuk> that seems quite a bit smaller
<Mithrandir> only 15Mbit here, it seems.
<Keybuk> if ubuntu-devel were Facebook, I would totally be in the "Get rid of OpenOffice.org now" group
<cjwatson> from the number of people who have been having problems with oversized CD images of late, I do not think it is yet true to say that most of the Ubuntu testing community have DVD writers
<cjwatson> entry-level laptops still frequently come with DVD readers at best - DVD writers are an option
<pitti> Keybuk: except that epiphany depends: firefox :)
<Mithrandir> pitti: which is why he suggested using the webkit patches, I believe
<asac> pitti: Keybuk suggests to switch to webkit ;)
<pitti> ah
<pkern> Some sites heavily relying on JS (most notably Google Apps like Docs & Spreadsheets) broke with Safari at least. Is this fixed with current Webkit? (I can't think of that as I guess Google blocks incompatible browsers on its own.)
<mvo> iwj: thanks for your fix for #137191!
<Mithrandir> pkern: try?  apt-get install libwebkitgdk0d ; /usr/lib/WebKit/GdkLauncher
<pkern> Mithrandir: I'm waiting for new cd builds to install Ubuntu I'm afraid. But well I guess I could fire up qemu-kvm, but then I will probably first need to download a trackload of new packages.
<pkern> Well, I can't even hit "Log in" on Google's Frontpage with it...
<pkern> mail.google.com doesn't work for me neither. (Page somehow doesn't load.)
<pkern> And clicking on a link on Heise Newsticker first worked fine, but near the end of the loading progress the program just crashed with "Fatal IO error 14 (Bad address) on X server"
<pkern> This just doesn't look useable to me \:
<pitti> ogra_: FYI, in ubuntu I removed nvidia-glx from ship; I merge this change to edubuntu seeds, since you have quite a size problem, too; please lart me and revert if that isn't desired by you
<Hobbsee> asac: oops, you broke it.  or do i blame the kernel upload?
<ogra_> pitti, nvidia-glx ?
<ogra_> but compiz by default ?????
<ogra_> what do our users do with compiz without a driver ?
<ogra_> (i'm fine to drop whatever ubuntu drops, just curious why we drop specifically this)
<pitti> ogra_: it's just in ship, and we need to free some space
<pitti> ogra_: and it's not enabled by default anyway
<pitti> ogra_: well, I don't like it either, but we have to drop *something* :/
<ogra_> true
<ogra_> indeed, dont ntell me
<ogra_> i still have a bit more to cut down
<pitti> ogra_: that, and the next OO.o will fix Ubuntu's space problem, but it's not even enough for edubuntu
* pitti hugs ogra_ 
<ogra_> ah, well, i'll find something ...
<ogra_> drop the kernel or so, i'll put it on the addon CD :P
<pkern> pitti: Will you trigger a rebuild of Ubuntu daily alternate later, with the size fixes applied?
<Kmos> latest update of gutsy was broken my boot
<Kmos> on local.scripts
<pitti> pkern: yes, once the new kernel has been settled
<Hobbsee> evening sabdfl
<sabdfl> howdy Hobbsee
<Hobbsee> bug #137441
<ubotu> Launchpad bug 137441 in linux-ubuntu-modules-2.6.22 "update iwlwifi drivers and firmware in gutsy >=0.1.14" [Medium,Fix released]  https://launchpad.net/bugs/137441
<pkern> What I wondered about: why is build-essential shipped on the CD?
<Hobbsee> pkern: for the poor people who have to use ndiswrapper and the like.
<ogra_> pitti, oh, the lastest changes i made aer not in yet, i delayed the meta rebiuld for more ubuntu changes ... i dropped samba from -server, that should gain another 5-7M
<ogra_> probably thats enough
<asac> Hobbsee: network-manager will get a fix for bug 141106 (old bug, but now needed) and bug 141233 (introduced in ubuntu11)
<ubotu> Launchpad bug 141106 in network-manager "network manager crashes when /etc/network/interfaces is touched [race] " [High,Fix committed]  https://launchpad.net/bugs/141106
<ubotu> Launchpad bug 141233 in wpasupplicant "MASTER network-manager crashes when wpasupplicant ctrl socket is not available" [Medium,Confirmed]  https://launchpad.net/bugs/141233
<cjwatson> pkern: pretty much every one of these things is accompanied by a huge argument that you can probably find if you look back in the archives
<Hobbsee> asac: i got the new kernel upload last night - my ipw3945 keeps trying to ask for the wpa p/w.
<pkern> Hobbsee: packages.ubuntu.com lists no ndiswrapper-source for gutsy, am I missing a rename?
<asac> Hobbsee: modinfo ipw3945 | grep ^version
<cjwatson> at this point there is almost nothing in the seeds that won't cause somebody problems if removed; which is why we often try to concentrate on shrinking things rather than removing things instead
<Hobbsee> asac: version:        1.2.2mp.ubuntu1
<asac> Hobbsee: has not been updated then
<asac> (unless they didn't bump version info)
<Hobbsee> asac: i was using the newer version from you, iirc?
<asac> Hobbsee: no that is my version
<ogra_> pkern, the general bits for a module build to get HW supported must be always there ... (but thats far from being what build-essential contains)
<asac> Hobbsee: no changes ... maybe ask on -kernel if they added another patch or something, but i don't think so
<Hobbsee> asac: as in, so they took your version, or their version never ovewrote yours
<Hobbsee> right
<asac> Hobbsee: he?
<asac> Hobbsee: it did ... its just the same module version :)
<Hobbsee> s/ovewrote/overwrote/
<Hobbsee> asac: ah right.
* Hobbsee wonders why it broke, then.
<carlos> pitti: hi, do you plan to do a new full language pack update for Gutsy before beta release?
<ogra_> pitti, meh, you dropped vim as well :'-/
<Hobbsee> !ping
<ubotu> pong
<pitti> ogra_: oh, did I? according to the conflict it wasn't there before
<ogra_> dunno, i only read the commit message in ubuntu
<pitti> ogra_: sorry, if you need it, put it back; (but we have vim-tiny in minimal)
<ogra_> no, dont need it
<pitti> ogra_: right, in ubuntu, but it wasn't even there before in edubuntu
<ogra_> ah, i didnt know ubuntu shipped that differently
<pitti> carlos: hm, I didn't plan it actually
<ogra_> i dropped the big vim package releases ago :)
<pitti> right :)
<Hobbsee> pkern: hmm.  seems so
<carlos> pitti: there is at least one application that misses translations because was moved from universe to main after latest language pack export
* ogra_ thought you also droopped vim-tiny
<carlos> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/kmplayer/+bug/123544
<ubotu> Launchpad bug 123544 in kmplayer "Langpack does not include kmplayer's translations" [Undecided,Confirmed] 
<carlos> pitti: a full export would fix it
<asac> Hobbsee: is it just that your pass is not remembered or that you can't connect anymore?
<pitti> ogra_: no, that would be blasphemy!
<laga> hi. is there any ETA for when the linux-ubuntu-modules FTBS will be fixed?
<ogra_> pitti, !
<pitti> carlos: well, sure, why not
<Hobbsee> asac: the latter.
<pitti> carlos: it would also downsize the langpacks a bit (which doesn't help much because we don't have any on the CDs, but we might be able to put some back later)
<carlos> pitti: ok, thanks
<asac> Hobbsee: i need your syslog then
<pitti> carlos: thanks to you; will you ping me once the tarball is available?
<carlos> sure, I will do it using the new infrastructure on production
<iwj> mvo: You're welcome.  Have you seen 137191 before ?
<cjwatson> laga: we're working on fixing the publisher at the moment. It's not really a true build failure, just waiting for other stuff to be published
<carlos> so we can test that
<cjwatson> laga: there was a Soyuz rollout this morning which caused some problems
<Hobbsee> asac: FWIW, http://wedontsleep.org/~sarah/syslog
<laga> cjwatson: thanks.
<mvo> iwj: I'm not sure, maybe in one other report
<mvo> iwj: but its not a frequent error
<Hobbsee> asac: (i switch to wired in there, adn try the wifi multiple times, hence the FWIW)
<amitk> bleh! my panels just resized to 75% of the screen after restarting with the latest updates..
<davmor2> Hobbsee:  Is this an intel issue?
<Hobbsee> davmor2: ipw3945, yes.
<asac> Hobbsee: it asks you for a password?
<Hobbsee> asac: yes
<davmor2> Mine is working fine....  I don't get asked for a password anymore now it just magically connects.
<Hobbsee> asac: i change it, and change it back, hit OK, then it goes back to configuring devices, and spits me another p/w box ~15 seconds later.
<Hobbsee> davmor2: mine has been, up till this point.
<iwj> mvo: Quite a scary one, when I found it.  It could have done almost anything ...
<davmor2> Hobbsee: Hang on I'll grab me lappy
<asac> Hobbsee: yes ... you don't get an association event  ... somehow
<soren> iwj: Did you get any further with kylem about the modem driver issue?
<asac> so it times out and thinks it might be a password issue
<Hobbsee> asac: davmor2 damn, sorry.  i'm being called to dinner, and getting yelled at
* Hobbsee will be back in an hour or so.
<Hobbsee> (thought i'd have longer)
<davmor2> go eat
<Hobbsee> hm, it's going to be longer than that, as we're movie watching
<davmor2> asac: I might not be around when Hobbsee gets back but everything is working fine here.
<asac> Hobbsee: maybe your password was changed? :)
<Hobbsee> asac: dad would normally tell me - and it hasnt changed in ages
<Hobbsee> but, possibly
<iwj> soren: Not yet.  I want to try the new sl-modem-daemon first.
<soren> iwj: Alright. Just give me a shout when you need me for testing.
<iwj> soren: Willdo.
<Hobbsee> asac: he didnt.  or if he did, he's not admitting to it :)
* Hobbsee --> really gone.
<asac> pitti: ubuntu13 of network-manager uploaded and probably waits for a kick :)
<pitti> asac: cool, thanks
<seb128> pitti: I'm discussing language-pack updates with carlos
<seb128> pitti: when do we need them for beta?
<pitti> seb128: hm, I'd say Monday at the latest
<seb128> pitti: we really should have the 2.20 upstream translations used for those or GNOME guys will be angry at us again
<pitti> right, agreed
<seb128> carlos: ^ monday looks a possible timeframe for the import?
<carlos> pitti: I was planning to schedule language pack exports for Gutsy on Saturday night and Tuesday night, as agreed with you
<pitti> carlos: I'm fine with triggering the full langpack build on Sunday
<carlos> I could move it to Sunday night though
<carlos> ok
<carlos> then I will leave it as we agreed
<asac> siretart: can you upload your 0.5.9 package with upstream verion 0.6.0+0.5.9 ?
<pitti> carlos: is Saturday night enough to get all the gnome 2.20 po files imported?
<carlos> that's a day and a half...
<carlos> I think it should be enough, at least for anything uploaded before OO.org
<pitti> carlos: if it takes until Sunday, that's still manageable
<asac> siretart: lets use bug 140763, bug 141233 and maybe bug 138873 to justify that upload :)
<ubotu> Launchpad bug 140763 in network-manager "NetworkManager is unreliable after resuming from suspend" [High,Confirmed]  https://launchpad.net/bugs/140763
<ubotu> Launchpad bug 141233 in wpasupplicant "MASTER network-manager crashes when wpasupplicant ctrl socket is not available" [Medium,Confirmed]  https://launchpad.net/bugs/141233
<ubotu> Launchpad bug 138873 in wpasupplicant ""*** stack smashing detected ***: /sbin/wpa_supplicant terminated" with iwl4965" [Medium,In progress]  https://launchpad.net/bugs/138873
<carlos> seb128: did you upload all your packages before oo.org update?
<seb128> carlos: has oo.org been uploaded? when?
<seb128> oh, on wednesday
<carlos>  Wed, 19 Sep 2007 10:28:41 -0500
<carlos> yep
<carlos> anyway, we can ignore that oo.org upload
<carlos> so don't worry
<seb128> carlos: 90% has been uploaded before
<seb128> almost all the applications
<seb128> so that should be alright
<carlos> it wasn't a new version, so we don't lose anything ignoring it
<pitti> asac: quite some changes :)
<asac> pitti: there are two bugs fixed ... and for the one fix i added more safety belts to prevent it. if you want some rational for some hunks let me know
<asac> pitti: debian/patches/41v_lp141233-fix-supplicant-cleanup-crashes.patch ... thats one is just one if(...ctrl) ... the rest is just indentation
<ogra_> WTF
<ogra_> is it wanted that NM commits suicide on upgrades andf blocks all networking if it cant start ?
<asac> pitti: debian/patches/20_do_not_take_over_dhcpv4iface_when_v6_is_configured.patch ... this is a old bug introduced ages ago that we now see when you change your network config through network-admin. Its a null-deref crash as you can see from the patch
<pitti> asac: right, I understand the race condition of half-written files
<pitti> asac: /e/n/i still has an inotify watch, I take it
<asac> pitti: yes ... actually i works that way
<asac> pitti: network manage will retry some times later ... or maybe its network-admin that touches the file again at the end
<asac> pitti: however it just fails now the first time it tries to parse ... then a few seconds later it succeeds
<asac> pitti: debian/patches/41t_nm_device_wireless_index_ctrl_sockets_by_run_count.patch this is mostly a belt-and-braces patch ... which fixes the bug that triggered the real crash fixed in 41v_lp141233-fix-supplicant-cleanup-crashes.patch
<pitti> asac: yes, I looked at the debdiff, and it's not too scary
<asac> ok
* pitti hugs asac
<asac> thanks
* asac hugs pitti 
<pitti> does anyone fancy taking a look at the pwlib FTBFS on i386?
<seb128> pitti: fernando on #ubuntu-desktop has a fixed package yesterday I think
<pitti> ah, cool
<seb128> pitti: might need sponsoring
<pitti> seb128: the FTBFS involved some 'no such file /home/fernando/...' stuff
<seb128> pitti: right, it's listed on the desktop team wiki, I'll sponsor it
<pitti> awesome, thanks
<seb128> no problem ;)
<YokoZar_> seb128: hey, you here?
<YokoZar_> seb128: I'm trying to figure out a new error with my package.
<seb128> YokoZar_: when I was writting on the chan just before I'm likely there
<\sh> hmm
<YokoZar_> Ooh, \sh is here too, nice
<\sh> apt-get source <package> doesn't work for me...anything known? deb-src is in
<seb128> YokoZar_: what package, what error?
<seb128> \sh: "doesn't work"
<YokoZar_> So, I'm trying the lib32 thing, and it compiles everything, but it's failing the package at this step: mkdir /usr/lib32/wine
<YokoZar_> mkdir: cannot create directory `/usr/lib32/wine': Permission denied
<seb128> do you get any error?
<YokoZar_> (my new Wine package)
<seb128> YokoZar_: you likely want to mkdir $(DESTDIR)/usr/lib32/wine
<YokoZar_> I'll upload it to REVU in a bit, but I'm trying to figure out if this is a totally obvious stupid error on my part
<\sh> seb128, E: E: Unable to find a source package for tomcat5.5
<\sh> seb128, nothing else...
<YokoZar_> seb128: I already put usr/lib32/wine into wine.dirs though
<YokoZar_> or, rather, wine.dirs.amd64
<\sh> YokoZar_, I talked about this issue with pitti
<seb128> \sh: apt-cache showsrc tomcat5.5?
<\sh> seb128, doesn't work either
<seb128> \sh: do you have an universe deb-src?
<\sh> YokoZar_, and then you  DESTDIR= to debian/tmp and move the files manually from debian/tmp to debian/<packagename>
<\sh> seb128, sure :) everything :)
<\sh> seb128, deb-src http://archive.ubuntu.com/ubuntu gutsy main restricted universe multiverse
<ogra_> have you apt-get updated ? :)
<\sh> ogra_, PENG ;)
<ogra_> ;)
* \sh is a noob, I know, but not so noobish ;)
<\sh> YokoZar_, so you don't use the .dirs and .install things
<seb128> \sh: ask mvo
<YokoZar_> \sh: why is .dirs broken here?
<YokoZar_> \sh: it seems a lot cleaner to use the .dirs and .install things
<\sh> YokoZar_, because it can't select between /usr/lib32 and /usr/lib and you don't want a /usr/lib32 in a package for i386
<\sh> mvo, peng
<\sh> mvo, aeh ping ;)
<YokoZar_> \sh: are you aware you can do wine.install.i386 and wine.install.amd64 ?
<mvo> \sh: hello
<\sh> mvo, apt-get source <package> doesn't work
<\sh> YokoZar_, so we don't need the .dirs, right?
<\sh> mvo, the same with apt-cache showsrc <srcpackage>
<\sh> mvo, while apt-cache show <package> works
<YokoZar_> \sh: errr, what do you mean, I can just eliminate .dirs entirely?
<YokoZar_> Actually I'm not exactly sure what .dirs does to begin with
<mvo> \sh: could you please pastebin your sources.list? and the content of ls -l /var/lib/apt/lists ?
<\sh> mvo, sure...moment
<cjwatson> YokoZar_: man dh_installdirs
<\sh> mvo, http://paste.ubuntu-nl.org/38103/
<cjwatson> YokoZar_: debhelper creates directories automatically - .dirs is only useful when you need to create directories for use by non-debhelper code in debian/rules
<YokoZar_> cjwatson: ahh ok
<YokoZar_> what bothers me is the error that is being thrown is a permissions error - it's trying to make /usr/lib32/wine rather than (local)/usr/lib32/wine
<YokoZar_> I'm gonna try junking the .dirs files and see what happens
<cjwatson> then it's not debhelper doing it
<cjwatson> removing .dirs will not help that
<\sh> YokoZar_, autocrap error
<cjwatson> it's more likely to be an upstream makefile
<YokoZar_> Yeah it looks like it
<cjwatson> perhaps you forgot to set DESTDIR, or perhaps it doesn't honour it
<cjwatson> if it's autotools, then more likely the former
<YokoZar_> This is my suspicion: 	CONFFLAGS += --libdir=/usr/lib32
<YokoZar_> That should be something else I think
<YokoZar_> that should be usr/lib32
<cjwatson> no
<mvo> \sh: and any apt-cache showsrc $pkg gives you a error?
<\sh> mvo, no...it doesn't show anyrthing
<cjwatson> YokoZar_: when you call 'make install', do you set prefix=?
<YokoZar_> $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr
<cjwatson> ok, so
<cjwatson> usually what you do is:
<cjwatson> build:
<\sh> YokoZar_, why debian/tmp/usr?
<cjwatson>         ./configure --prefix=/usr --libdir=\$${prefix}/lib
<cjwatson>         $(MAKE)
<cjwatson> install:
<cjwatson>         $(MAKE) install prefix=$(CURDIR)/debian/tmp/usr
<\sh> YokoZar_, this is wrong
<YokoZar_> \sh: I didn't change this, it was in the package before
<cjwatson> \sh: it's perfectly reasonable if you're then going to use dh_install
<mvo> \sh: aha, it looks like for some reason the authentication failed when apt-get update was run and it does not show untrusted sources. do you get a untrusted warning when trying to install a random package with synaptic or apt-get?
<\sh> mvo, nope not today or yesterday...
<\sh> YokoZar_, depends what makefile is doing now...I see $(DESTDIR)/$(libdir)
<cjwatson> YokoZar_: so then make install expands ${prefix} in libdir differently during install, and it all works fine
<cjwatson> but $(MAKE) install DESTDIR=$(CURDIR)/debian/tmp is sometimes more convenient
<cjwatson> either should work, just don't set both DESTDIR and prefix
<mvo> \sh: but your /v/l/apt/lists does not show a .gpg file, so I strongly suspect that this is the case. have you tested the unauthentication warning thing?
<\sh> mvo, strange...after the 10th apt-get update it now works...
<\sh> sudo apt-get update I have to say
<mvo> \sh: in the runs before, did you got authentication errors/warnings?
<\sh> mvo, nope
<mvo> *ick*
<\sh> mvo, is there any cli switch to show the IP which is used for archive.ubuntu.com?
<\sh> mvo, I wonder if it's our proxy or some mirror...
<Kopfgeldjaeger> hi
* \sh checks tomcat5.5 for CVE fixes
<\sh> yuck....
<YokoZar_> ok I have ./configure --prefix=/usr but --libdir=/usr/lib32
<YokoZar_> Should I switch that for --libdir=\$${prefix}/lib32  ?
<\sh> http://security-tracker.debian.net/tracker/source-package/tomcat5.5 much work
<mvo> \sh: please try -o Debug::Acquire::http it shows the IP on failure, but if no failure happens, there is no IP dispalyed AFAICS. I could add you a debug mode for this
<\sh> pitti, keescook  please have a look at http://security-tracker.debian.net/tracker/source-package/tomcat5.5 and http://tomcat.apache.org/security-5.html, for gutsy, do you think it's better to package the new version or trying to backport the security fixes by cherry picking them?
<mvo> \sh: please try -o Debug::Acquire::http it shows the IP on failure, but if no failure happens, there is no IP dispalyed AFAICS. I could add you a debug mode for this
<\sh> mvo, doing so
<\sh> mvo, I set it now as default in apt.conf
<cjwatson> YokoZar_: yes, that sounds correct
<cjwatson> YokoZar_: that's what I do everywhere
<YokoZar_> cjwatson: cool.  While I'm at it I'm adding a check to change 	dh_shlibdeps -L wine -l debian/wine/usr/lib  to 	dh_shlibdeps -L wine -l debian/wine/usr/lib32  if on amd64
* cjwatson nods
<YokoZar_> ok, I'm passing it to pbuilder now...hopefully this time it'll build :)
<siretart> asac: good idea! feel free to go ahead!
<\sh> YokoZar_, if you are on it, fix the symlinks of the last added two lines.. (you forgot in the revu package the / in the front) and please use a correct ubuntu-version notation, so that a MOTU can upload directly
<YokoZar_> \sh: eh, what's wrong with the version notation?
<\sh> YokoZar_, you have wine_0.9.45-0ubuntu1-1.orig.tar.gz ;)
<\sh> YokoZar_, but wine_0.9.45.orig.tar and debian/changelog should just say 0.9.45-0ubuntu1
<YokoZar_> wait I'm confused
<YokoZar_> what two lines are symlinks here?
<\sh> YokoZar_, usr/lib32/liblcms.so1 and usr/lib/libpng12.so.0
<\sh> YokoZar_, in the amd64 section....it needs a leading /
<\sh> YokoZar_, speaking of the 0.9.45 package from revu...
<YokoZar_> oh, thanks
<YokoZar_> good spot
<\sh> YokoZar_, and change the version and the orig.tar.gz to match the normal namning....means: wine_0.9.45.orig.tar.gz (think also of the tarball itself, it extracts to wine-0.9.45-0ubuntu1 not wine-0.9.45
* \sh has a cigarette
<YokoZar_> \sh: thanks
<ogra_> pitti, can you let my -meta through please ?
<\sh> and tries to cherrypick tomcat5.5 fixes
* ogra_ goes for coffee
<\sh> ogra_, greetings to suse...:)
<Mithrandir> ogra_: edubuntu-meta accepted
<\sh> YokoZar_, if you are fast we can push wine just before beta freeze...which would be great :)
<YokoZar_> \sh: so, it's 4am here...how fast is fast?
<\sh> YokoZar_, before 27th ;)
<YokoZar_> oh
<YokoZar_> so Wine 0.9.46 comes out the day after that ;p
<pochu> \sh: aren't we already in beta freeze?
<pochu> \sh: 27th is beta release, not beta freeze...
<\sh> oh sorry...yeah
<YokoZar_> but universe is different for beta freeze anyway
<asac> siretart: can you upload? as you already have the sources and all on your disc?
<\sh> YokoZar_, wine has a wildcard
<YokoZar_> ok, it's building.  I'm going to sleep now.  Although, I forgot to do pbuilder update first...hopefully it wont' die a horrible death.  I should have a new package up on REVU in like 12 hours if it works.
<\sh> YokoZar_, can you give me a .dsc,diff.gz and orig.tar.gz I can build it to and test
<\sh> s/to/too/
<YokoZar_> \sh: or I could just open a new tab and put what I have on REVU now
<\sh> YokoZar_, just put it on revu..I'll testbuild etc.
<YokoZar_> \sh: willdo
<siretart> asac: sorry, I need to leave now. a colluege is having his final exam now and I need to leave now quickly
<\sh> YokoZar_, thx :)
<siretart> asac: my sources are at http://siretart.tauware.de/upload-queue, I don't have other sources for that version anyway
<\sh> wah....cherrypicking patches for tomcat is evil
<YokoZar_> \sh: so this REVU upload is taking a long time
<\sh> YokoZar_, send me that debian/ dir separatly...the rest I can do here :)
<\sh> YokoZar_, sh@sourcecode.de
<YokoZar_> akk, now I'm getting this: Error '553 Could not create file.' during ftp transfer of wine_0.9.45-0ubuntu1.dsc
<YokoZar_> Note: This problem might be caused by files already existent on the server.
<YokoZar_>       For the official Debian upload queues, the dcut(1) utility can be used
<YokoZar_>       to remove stale files from unsuccessful uploads.
<asac> siretart: ok
<iwj> mvo: Did you manually forward my dpkg ubuntu15 changelog entry to bug 137191 ?  I intended to have it done automatically.  Is the syntax specified on the wiki page not right ?
<ubotu> Launchpad bug 137191 in dpkg "package update-manager 1:0.69 failed to install/upgrade: failed to fstat previous diversions file" [Undecided,Fix released]  https://launchpad.net/bugs/137191
<\sh> YokoZar_, send the debian/ dir as tar.gz and I'll prepare a build...
<YokoZar_> \sh: how about the .diff.gz
<Kmos> iwj: LP: #number is the syntax
<Kmos> it's mentioned in mail of LP 1.1.9
<\sh> YokoZar_, are there patches which you applied inline for orig sources?
<YokoZar_> yeah I fixed the naming problem too
<\sh> YokoZar_, send it too .)
<YokoZar_> \sh: oh there are no inline patches (pristine upstream wine 0.9.45)
<tepsipakki> pitti: apparently the klogd problem was due to broken ldap.conf :P
<\sh> YokoZar_, so diff.gz will be genrated automatically.. just the debian/ dir then
<iwj> Kmos: Yes, that's the syntax I used.
<iwj> Is it not supposed to be live yet ?
<YokoZar_> why should I tar that up when I can send you the entire finished package?
<\sh> YokoZar_, send it like you want :) debian/ would be enough :)
<YokoZar_> cuz, like, .diff.gz IS the debian dir
<\sh> YokoZar_, yepp
<Kmos> iwj: yeah.. when it's change status from pending to uploaded, it should set it fix released
<Kmos> iwj: better to ask on #launchpad what happened
<YokoZar_> I'm reuploading to REVU anyway
<YokoZar_> my error went away after 5 mins when it flushed out the failed upload
<cjwatson> iwj: it's been working well for me for some time
<Kmos> iwj: LP: #137191.) you used a "." in the end of number
<iwj> Yes, obviously.
<iwj> It's the end of a sentence so it should get a `.'.
<Kmos> that's the problem
<iwj> WTF
<Kmos> the "." should be after ")"
<iwj> I'll file a bug.
<Kmos> iwj: i think you should :-)
<Kmos> against soyuz
<cjwatson> heh, I've never had that problem because I do "Description of fix (LP: #nnnnnn)."
<cjwatson> iwj: you should not file a bug on Launchpad for this though
<cjwatson> iwj: the regex is in dpkg, just like for closes:
<cjwatson> iwj: and I don't see anything in that regex supporting Kmos' assertion
<cjwatson> while ($f{'Changes'} =~ /lp:\s+\#\d+(?:,\s*\#\d+)*/ig) {
<cjwatson>   push(@launchpad_closes, $& =~ /\#?\s?(\d+)/g);
<cjwatson> }
<iwj> Hmmmm.
<iwj> Must be at my end then.
<cjwatson> do you have the .changes around?
<iwj> Yes.  No Launchpad-Closes field.
<cjwatson> (it actually comes out as Launchpad-Bugs-Fixed, but still)
<cjwatson> source built with Debian dpkg maybe?
<cjwatson> we should get that patch in there
<iwj> Oh, I've got some wierd old bits in /usr/local ...
<iwj> I must have been doing some testing.
<iwj> And forgot to get rid of them.
<cjwatson> ah
<Kmos> <elmo> bazaar.launchpad.net and codebrowse.launchpad.net are going down for emergency maintenance, ETD is 10 minutes
<dholbach> MOTU Meeting in #ubuntu-meeting
<elmo> bazaar.launchpad.net and codebrowse.launchpad.net are back
<ogra_> seb128, ping
<seb128> ogra_: hi
<ogra_> http://www.gnome.org/start/2.20/notes/en/index.html#rnusers-login-and-screensaver
<ogra_> do you have any indicator how that message feature shold be implemented ?
<ogra_> the g-s-s changelog doesnt even remotely mention such a feture
<ogra_> "The GNOME Screensaver now allows people to leave you a note while your screen is locked, by clicking the "Leave Message" button. You'll see these messages when you login."
* ogra_ wonders where this "leave message" button should be 
<pedro_> in the lock dialog
<ogra_> which lick dialog ?
<ogra_> if i click lock screen it just locks, there is no dialog
<ogra_> *lock
<pedro_> system -> logout -> lock screen
<ogra_> yes, thats what i'm talking about
<pedro_> yep lock dialog, that's the name of the glade file (iirc)
<ogra_> beyond that its nothing thats implemented in gnome-screensaver it seems
<jdstrand> asac: what are your thoughts on bug 138217 getting fixed for gutsy?
<ubotu> Launchpad bug 138217 in network-manager "NetworkManager fills log on start up until dhcdbd has started" [Low,Confirmed]  https://launchpad.net/bugs/138217
<ogra_> pedro_, which glade file ?
<pedro_> ogra_: the glade file of that dialog
* ogra_ doesnt have a glade file in g-s-s that implements anything that talks to libnotify
<ogra_> pedro_, from which package ?
<pedro_> aham, no we are talking about different things
<ogra_> you are talking about the logout dialog (where i dont see such a feature at all), right ?
<pedro_> yes
<ogra_> i'm talking only about gnome-screensaver
<jdstrand> asac: logcheck has been churning away for the last 40 minutes (and counting) trying to process the logs
<pedro_> we are shipping g-s-s with a theme ?
<ogra_> it defaults to the system theme
<ogra_> seb128, any idea where exactly that is implemented ?
* ogra_ reboots for new kernel
<seb128> ogra_: no, somebody asked yesterday and I never saw that
<pedro_> saw a bug about that in b.g.o
<pedro_> http://bugzilla.gnome.org/show_bug.cgi?id=384509
<ubotu> Gnome bug 384509 in dialog "Allow disabling of leaving notes when screen is locked" [Enhancement,Reopened] 
<pedro_> it seems that it needs to be build with libnotify support
<seb128> pedro_: yes, it lacks a Build-Depends, I'm fixing it
<seb128> ogra: gnome-screensaver lacks a Build-Depends to get the feature
<pedro_> seb128: coool
<seb128> ogra: I'm fixing it
<cjwatson> there's a neat thing in Soyuz now that tells you what's happening with binary uploads
<ogra> seb128, ChangelogDoesnt mention it at all
<cjwatson> so https://edge.launchpad.net/ubuntu/+source/linux-ubuntu-modules-2.6.22/2.6.22-12.29 has:
<cjwatson> #   gutsy lpia   Successfully built  (DONE)
<cjwatson> # gutsy ia64 Successfully built (ACCEPTED)
<cjwatson> # gutsy i386 Successfully built (DONE)
<seb128> ogra: usually diffing the configure.ac between versions is useful
<cjwatson> just thought I'd mention it here since people might find it useful
<ogra> seb128, indeed, but usually such a massively new feature shows up in the ChangeLog as welll
<cjwatson> (works on non-edge too)
<ogra> all i find is a mention of the away message for the unlock dialog there ... but nothing for  a feture to leave messages to other users
<seb128> ogra: there is this one
<seb128> 	(gs_lock_plug_init):
<seb128> 	Make note feature and libnotify optional.  Apparently
<seb128> 	libnotify isn't an approved dependency.
<seb128> and
<ogra> gah
<seb128> 	(load_theme), (gs_lock_plug_init):
<seb128> 	Add ability to leave messages at the locked screen.
<seb128> 	Based on patch from Matthias Clasen <mclasen@redhat.com>
<seb128> 	Fixes #384509
<ogra> thats the one i talked about
<ogra> its a sting gconf key for the unlock dialog
<seb128> I've uploaded the fix
<ogra> thanks
<ogra> guess i have to apologize to the bug reporter :)
<seb128> pitti: could you approve the GNOME uploads pending (gdm, gnome-screensaver, rhythmbox)
<asac> jdstrand: i don't think its critical ... anyway, why do you think that its related to bug 137744?
<ubotu> Launchpad bug 137744 in network-manager "network-manager fills logs with nm_policy_device_change_check messages" [Wishlist,Fix released]  https://launchpad.net/bugs/137744
<Hobbsee> asac: go figure.  rm'd config files, took it all down, brought it all back up again, played black magic...seems to work.
<jdstrand> asac: sudo egrep 'Sep 21 .* NetworkManager' /var/log/daemon.log.0 | wc -l
<jdstrand> asac: 134590
<jdstrand> asac: and in syslog
<jdstrand> asac: that is a *lot* of output.  I just turned the computer on at 7:40am EDT
<hunger> jdstrand: Yeap, network-manager is extremely noisy:-(
<asac> Hobbsee: which config file did you rm?
<Hobbsee> asac: knetworkmanagerrc
<asac> ah ok ... no idea about that
<jdstrand> asac: it was doing a lot better, then there was the update around the 2007-09-13 and then got lots of output again
<Hobbsee> asac: neither.
<jdstrand> asac: I know this is marked as 'low', but this a lot of disk IO for my laptop, even without logcheck (which to me is really important)
<pitti> seb128: I'll have a look
<pitti> tepsipakki: *phew* :)
<pitti> ogra: -meta> will do
<ogra> pitti, Mithrandir did already, but thanks :)
<Keybuk> pitti: do you still have the edgy ddebs?
<pitti> Keybuk: no, we don't
<pitti> Keybuk: they were incomplete anyway, and there had been some problems with the archive creation tools as well as disk space, so we wiped them
<Keybuk> :-(
<jdstrand> asac: sorry, just looked at bug 137744 again
<ubotu> Launchpad bug 137744 in network-manager "network-manager fills logs with nm_policy_device_change_check messages" [Wishlist,Fix released]  https://launchpad.net/bugs/137744
<MacSlow> mvo, where are the default values for compiz-plugins stored again... I mean which package provides them?
<jdstrand> asac: I was seeing the output from 137744, then upgraded to 0.6.5-0ubuntu11 and things were fine.  Then had another upgrade (dbus I believe) that caused the output in 138217.
<jdstrand> asac: I think the issue is ' NetworkManager: <WARN>  nm_dhcp_manager_begin_transaction(): dhcdbd not running!'
<jdstrand> asac: grep 'dhcdbd not running' /var/log/daemon.log.0|wc -l
<pitti> asac: I'm confused; there is another n-m 0.6.5-0ubuntu13 in unapproved, but I already accepted that version earlier
<jdstrand> asac: 14150
<pitti> asac: ah, nevermind me, got it
<jdstrand> asac: I updated bug 138217 with these comments
<ubotu> Launchpad bug 138217 in network-manager "NetworkManager fills log on start up until dhcdbd has started" [Low,Confirmed]  https://launchpad.net/bugs/138217
<Kmos> iwj: you know if bug 28393 is fixed?
<ubotu> Launchpad bug 28393 in dpkg "Dutch translation of message for replacement of configuration file wrong" [Medium,Confirmed]  https://launchpad.net/bugs/28393
<iwj> Kmos: Not offhand ...
<pitti> seb128: rhythmbox> that new dependency python-louie is in universe...
<seb128> pitti: it's a Recommends
<iwj> Kmos: Looks like it has.
<asac> pitti: http://paste.ubuntu.com/346/
<pitti> seb128: OTOH it already recommends: gstreamer0.10-plugins-ugly and thus break closure of main
<seb128> "closure"?
<seb128> we don't install Recommends by default do we?
<pitti> seb128: "ogre model"
<pitti> seb128: we do
<pitti> seb128: all tools except apt-get do it
<seb128> since when?
<seb128> synaptic do?
<seb128> mvo: ^
<pitti> hm, edgy or so?
<asac> pitti: in addition it probably doesn't have bug 138873
<ubotu> Launchpad bug 138873 in wpasupplicant ""*** stack smashing detected ***: /sbin/wpa_supplicant terminated" with iwl4965" [Medium,In progress]  https://launchpad.net/bugs/138873
<seb128> I though only aptitude was doing that
<seb128> I use apt-get
<Hobbsee> seb128: not for non-metapackages, by apt.
<seb128> pitti: hum, how come that the rhythmbox Recommends on gstreamer0.10-plugins-ugly doesn't break then?
<pitti> asac: eww, 0.6 -> 0.5.8?
<seb128> Hobbsee: EPARSE, what apt?
<Hobbsee> seb128: aptitude does all the time, apt does for Section: metapackages.
<pitti> seb128: it doesn't break, since it's not a strict Depends:, but it's a bit unclean
<seb128> Hobbsee: right, which rhythmbox is not
<Kmos> iwj: you can handle it? it's assigned to you
<asac> pitti: yes
<Hobbsee> and synaptic/adept follows apt.
<Hobbsee> seb128: correct.
<pitti> asac: are you sure what you are doing? :)
<seb128> Hobbsee: so you are basically say the same thing as I do
<Hobbsee> seb128: debian is also moving to recommends by default - i'm assuming youv'e seen it.
<seb128> Hobbsee: we don't install Recommends
<asac> pitti: it was an error to have 0.6.0 in the first place ... 0.6.0 is a test-field for network-manager 0.7
<Hobbsee> seb128: excluding Section: metapackages.  correct.
<iwj> Kmos: As I say, it has been fixed.  I've adjusted the bug state.
<seb128> Hobbsee: yesn that's planned for several Ubuntu cycles, we already had the discussion with mvo
<Kmos> iwj: ah ok =) thx
<asac> pitti: i discussed that with siretart and he finally agreed on his own that we should downgrade
<iwj> Any particular reason why you're bring it up now ?  Eg, someone noticed it ...
<Hobbsee> seb128: ahh, ok.
<seb128> pitti: anyway I can file a MIR for louie if you prefer
<pitti> seb128: not a biggie, I let it through, just to raise a small discussion about it
<iwj> Kmos: Since if someone thinks it's wrong it may need more attention.
<Hobbsee> iwj: $mypetbug, most likely :)
<seb128> pitti: well, rhythmbox lists a plugin which doesn't work (upnp) at the moment
<pitti> seb128: not sure what it does; if it makes sense, why not
<seb128> pitti: python-louie needs to be installed to get that working
<seb128> pitti: I assumed that the Recommends would be the quicker way for now
<seb128> pitti: I'll do a MIR later, no hurry for that
<pitti> right
<asac> pitti: if you look at the bugs, there are plenty of failed connect attempts to wpa ctrl socket and TIMEOUT[CLI]  messages ... 0.5.9 doesn't have any of those.
<pitti> asac: 0.6cvs was uploaded at start of May, i. e. we have it for almost the entire live of gutsy
<pitti> asac: which means that we got essentially no testing *at all* of 0.5.8 in gutsy
<asac> pitti: yes, i couldn't prove that 0.6 is buggy until after nm ubuntu11
<iwj> Hobbsee: Yes, I thought that but it hardly seemed like a good candidate for a pet bug.  My pet bugs are all +3 dragons of laying waste.
<pitti> asac: I guess it by and large worked until now, what changed that?
<Hobbsee> iwj: :)
<asac> pitti: well before that network manager didn't visualize the timeout issues
<asac> pitti: i added that in ubuntu11, so now we see that wpasupplicant fails sooo many times to do anything for us
<pitti> asac: ah, a changed debugging output
<pitti> ?
<pitti> asac: can you please put that version in a ppa and ask bug reporters to test it and give feedback?
<pitti> and o u-devel@, can't hurt
<asac> pitti: yes ... before that nm just failed ... i finally figured out that its a timeout from wpa backend, so i added the debugging output on client side (TIMEOUT[CLI] 
<asac> pitti: well time is not on our side ... i would rather try this in cd testing and if there are new bugs, revert to 0.6.0
<pitti> asac: I see; ok, it would be unfortunate to leave it like that, but I want some confirmation that the new version doesn't change things for the worse
<pitti> asac: how much testing feedback did you get with 0.5.8 so far?
<asac> pitti: siretart uses it ... me uses it ... stgraber used it as well afaik.
<asac> pitti: but ok i will upload now
<asac> pitti: to ppa and lets see what feedback we get till monday
<pitti> asac: yep, we should get some community testing over the weekend
<asac> i will ask on forums as well
<pitti> asac: Monday is still fine, we still need langpacks and everything
<asac> pitti: yes, when does ISO testing start?
<pitti> asac: as soon as we get images, I hope I get some this evening
<asac> ok
<pitti> asac: they won't be 'good' yet, since we'll get another kernel, wpasupplicant, langpacks, etc.
<pitti> and OO.o
<pitti> but good enough for checking the installer and new kernel, etc.
<iwj> Hobbsee: Debian closed #1708 recently but it turns out it's not really fixed; they cloned it and the clone (#439769) is still open.
<StevenK> pitti: Who's the RM for the beta?
<asac> pitti: right ... thanks that you already put wpasupplicant in that list ;)
<pitti> StevenK: officially, slangasek; I'm backup, mentor, and release engineer
<asac> StevenK: i think pitti slangasek  dual head ;)
* StevenK nods
<pitti> asac: we'll need to bite that bullet, but I'm not crazy enough to let it through without some testing :/
* pitti hugs asac, sorry
<asac> pitti: i understand that
<asac> pitti: wouldn't do it as well ... and honestly i really feel bad about that
<asac> pitti: but as i said i had no strong point until recently to revert wpasupplicant :)
<mathiaz> pitti: who is responsible for accepting nominated bugs for a serie ?
<pitti> asac: did a lot of those bugs have "... but it worked in feisty"?
<asac> pitti: (bad feeling - about pushting this at this point of time)
<pitti> mathiaz: ~ubuntu-sru for stables, ~ubuntu-release for gutsy
<mathiaz> pitti: soren and I are trying to figure out how we can track which samba bugs we'd like to get fixed in dapper for example.
<asac> pitti: since the beginning of gutsy we had huge regressions
<asac> pitti: i always suspected that its the development version of wpa ... now i do lots of things to workaround, but its still too buggy
<pitti> mathiaz: ah, I see
<mathiaz> pitti: I don't think that ubuntu-sru should be involved at this stage of the process
<pitti> mathiaz: you can milestone them as 'dapper-updates'
<pitti> mathiaz: right, I misunderstood you
<asac> pitti: anyway, the improvements of NM are good even with old wpasupplicant, because now its pretty rock solid for things like wpasupplicant failures et al ;)
<pitti> mathiaz: create a dapper task and set it to 'dapper-updates' milestone
<pitti> asac: heh
<mathiaz> pitti: create a dapper task == nominate for release ?
<pitti> mathiaz: just adding the dapper task is enough probably, there are only 145 bugs with a dapper task
<pitti> mathiaz: right
<pitti> mathiaz: so something like /ubuntu/dapper/+source/samba/+bugs will give you the list
<mathiaz> pitti: but only if ubuntu-sru has accepted them ?
<pitti> mathiaz: no, ubuntu-qa should be able to create tasks
<pitti> mathiaz: that has been like that for a while, but I hope it has been fixed
<pitti> mathiaz: if not, use the workaround (change the url to ubuntu/dapper/... and click the 'needs fixing here' button)
<pitti> mathiaz: I'd rather reject one or two tasks that I think are not appropriate than blocking your workflow for every single bug
<pitti> in general I trust developers to judge which bugs are worth backporting
<mathiaz> soren: another issue I've noticed while going through samba bugs is that some of them are related to nautilius.
<mathiaz> soren: do you know if gnome-vfs uses smbclient to implement smb:// access ?
<soren> mathiaz: It does.
<seb128> mathiaz: it uses libsmbclient
<mathiaz> soren seb128: ok. Thanks.
<soren> Ah, yes, of course.
<\sh> pitti, ping tomcat5.5
<\sh> pitti, 5.5.20 has several CVEs attached...up to 5.5.25 which fixes them all...
<mathiaz> soren: so for samba bugs related dapper, have you read pitti suggestion ?
<pitti> \sh: will look in a minute
<soren> mathiaz: Short version: Add a dapper task for the ones we find severe enough?
<mathiaz> soren: yes.
<mathiaz> soren: I do that with other packages, but I'm not sure it actually works.
<soren> mathiaz: Makes perfects sense.
<\sh> pitti, FYI, debian has 5.5.23 so a sync is not ok...I'm trying to package 5.5.25 but I don't want to decide from the security PoV if it's better to wait for debian or just update...cherrypicking is difficult
<mathiaz> soren: I'm not sure they show up on the dapper list right away.
<soren> mathiaz: No, I've also found that marking bugs as targeted for a specific release doesn't magically fix them. That's really annoying :)
<mathiaz> soren: I'll make a test bug to check that.
<soren> mathiaz: Cool.
<mathiaz> soren: bug https://bugs.launchpad.net/ubuntu/+source/samba/+bug/141518
<ubotu> Launchpad bug 141518 in samba "Test for dapper task - ignore me :)" [Undecided,Fix released] 
<mathiaz> pitti: I've nominated bug 141518 for dapper, but it doesn't show up in dapper list: https://bugs.launchpad.net/ubuntu/dapper/+source/samba
<ubotu> Launchpad bug 141518 in samba "Test for dapper task - ignore me :)" [Undecided,Fix released]  https://launchpad.net/bugs/141518
<soren> I've got a few bugs I wouldn't mind marking as dupes of that one :)
<soren> mathiaz: It's only been nominated. I think it needs to be approved for DApper first.
<pitti> mathiaz: I approved the nomination
<pitti> mathiaz: seems that bug is still not fixed
<pitti> mathiaz: it should appear now
<pitti> mathiaz: so better use the workaround with the URL changing
<mathiaz> pitti: yes.
<mathiaz> pitti: it's the same thing.
<mathiaz> pitti: At least last time I've tried it.
<pitti> meh
<mathiaz> pitti: yes. I've used the url hack for edgy
<mathiaz> pitti: it doesn't create an edgy task.
<pitti> mathiaz: meh, they fixed it the wrong way around
<pitti> mathiaz: it's just nominated for edgy now
<pitti> mathiaz: can you set milestones?
<mathiaz> pitti: yes.
<pitti> \sh: (btw, my default answer is 'yes for the new upstream microrelease based on latest Debian', unless motu-uvf overrules me
<ogra> what was the name of the new CD build machine ?
<mathiaz> pitti: So we'll have to use milestone instead.
<pitti> \sh: s/overrule/explicitly decides this/
<pitti> mathiaz: that, or nominate them, and I'll approve them wholesale
<ogra> (and why dont i find *any* message about that change in my inbox)
<pitti> ogra: antimony
<ogra> pitti, ^^^ lithiium doesnt let me in and i forgot the name again
<ogra> ah
<mathiaz> soren: ok. So I'd suggest that first we milestone bugs for each release they're relevant.
<pitti> https://bugs.edge.launchpad.net/ubuntu/dapper/+nominations
<ogra> if we wouldnt have these godammned hashed ssh entries now i could just have looked up the last entry easily in known:hosts ...
<pitti> mathiaz: ^ ah, cool
<pitti> mathiaz: so, nomination is fine as well
<StevenK> ogra: ssh has a mode to edit the known_hosts file...
* ogra hates security standing in his way
<StevenK> There's a command for it, anyway. I can't remember anything else, sorry. :-(
<ogra> StevenK, indeed, but i cant just cat the file to remember a hostname now ...
<mathiaz> pitti: well. the reason I'd avoid nomination is that we need to clean up samba bugs first
<ogra> StevenK, that was what i remembered as well ... but not the name of the command :P
<bddebian> Heya
<mathiaz> pitti: ok. we'll use nomination then.
<StevenK> ogra: ssh-keygen does it
<ogra> StevenK, giving out the hostnames in cleartext ?
<ogra> (the manpage didnt mention that)
<StevenK> ogra: -F
* ogra meant ssh-showkey which we apparently dont have
<ogra> ah
<ogra> ah, crap i read the manpage of keyscan
<ogra> not keygen
* ogra blushes
<StevenK> ogra: Reading is a good skill.
<StevenK> ogra: :-P
<davmor2> asac: Hobbsee: did you manage to sort out the nm issue?
<Hobbsee> davmor2: surprisingly, yes.  we'll call it a heisenbug.
<ogra> StevenK, writing as well :P
<davmor2> Hobbsee: ?
<Hobbsee> davmor2: a few manually bringing evertying down, putting them back up, removing config files, etc.
<pitti> lamont: seems that util-linux fix wasn't sufficient; http://launchpadlibrarian.net/9439554/buildlog_ubuntu-gutsy-sparc.debian-installer_20070308ubuntu14_FAILEDTOBUILD.txt.gz
<Hobbsee> davmor2: seems to work fine.  but as for what was wrong...no idea
<pitti> lamont: it still fails with "sparc64: Unrecognized architecture"
<davmor2> oh well glad it's fixed :)
<StevenK> I thought all NM issues were heisenbugs?
* StevenK ducks
<ogra> hmm, that sabayon changelog isnt very informative
<\sh> pitti, as I said, debian has still 5.5.23 and this version has a lot of CVEs ... so 5.5.25 is the version for gutsy to go...if I can resolv the build problems
<keescook> \sh: the tomcat security issues have been, from what I can tell, mostly bugs in examples or base files, rather than core functionality.  So, to that end, I suspect just patching the fixes would pretty straight-forward work, assuming the patches are easy to find.  On the other hand, getting a newer version would be a good idea too, as tomcat is relatively old in Debian.
<\sh> keescook, well, debian has 5.5.23 and we have 5.5.20
<keescook> \sh: I think 5.5.23 is still vuln to a mess of stuff.  upstream is 5.5.25
<keescook> or, from another perspective, upstream is 6.0.14 :P
<pitti> \sh: right, as I said, I'm generally fine with updating to microreleases of universe at this point
<keescook> asac: should I just upload a fixed version of wpasupplicant, just to have the issue closed?
<pitti> cjwatson, lamont: FYI, I filed bug 141524 about the sparc d-i FTBFS
<ubotu> Launchpad bug 141524 in util-linux "sparc64: sparc64: Unrecognized architecture" [Critical,New]  https://launchpad.net/bugs/141524
<pkern> BenC: Was there any progress on slub&fglrx regarding Gutsy's release?
<BenC> pkern: point me to a bug report?
<lamont> pitti: sigh
<lamont> ok
<pitti> lamont: do you have an idea about that?
<lamont> pitti: please approve sysvinit if you haven't already
<pitti> lamont: done some hours ago
<BenC> pkern: as far as I know, if it's just a zero alloc warning, it's a non-failure
<lamont> pitti: yeah. my idea is that I need to look at it this morning. :-(
<cjwatson>   sysvinit | 2.86.ds1-14.1ubuntu28 |         gutsy | source, amd64, hppa, i386, ia64, lpia, powerpc, sparc
<pkern> BenC: https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/121653 as an example. I pointed you to it in one of the last kernel meetings.
<ubotu> Launchpad bug 121653 in linux-source-2.6.22 "[gutsy]  Suspend to Ram does not work on Z61m" [Wishlist,Confirmed] 
<mjg59> BenC: It seems to break suspend/resume, though given that it's fglrx it probably does that plenty enough already
<pkern> mjg59: Well, people confirm that reverting to SLAB fixes it.
<pkern> mjg59: And I have proper suspend/resume with fglrx and 2.6.22/SLAB, for what it's worth.
<BenC> pkern: I'd rather not revert to slab
<BenC> I'd rather ATI take bugs seriously and fix them
<pkern> BenC: You told me that you would contact ATI about that.
<asac> keescook: hmm, we hopefully can downgrade to 0.5.8 once i received enough feedback on that. Maybe you can take a look if the code does have the same issue?
<pkern> BenC: That's why I ask again.
<BenC> pkern: ATI has been contacted (not by me)
<asac> keescook: http://ppa.launchpad.net/asac/ubuntu/pool/main/w/wpasupplicant/
<pkern> Aye.
<soren> Grr.r..
* soren shakes his fist at ccsm
<pkern> So kernel rebuilds during Gutsy's lifetime to get working suspend, and let's hope for better free drivers. \:
<pkern> Hm, maybe I should try out fglrx 8.41.7...
<keescook> asac: 0.5.x does not have the issue.
<StevenK> BenC: Do you have some time to discuss modules for virtualbox-ose?
<BenC> StevenK: we wont include vbox modules again
<keescook> asac: does 0.6.0 really have that many problems?
<BenC> StevenK: I did that just before feisty release at the request of support center and we had to yank it after release, which is a really screwed up thing to do
<BenC> StevenK: it makes no sense for us to include modules in our packages that can and will change API with userspace
<asac> keescook: imo its too unstable ... its an early development snapshot of a new branch that is used to implement new features for network-manager 0.7
<StevenK> BenC: At this point, we are shipping virtualbox-ose in Gutsy
<asac> keescook: for instance just bringing up the wpa_ctrl sockets sometimes takes seconds ... or even fails completely
<asac> keescook: lots of commands i send from nm time out
<keescook> asac: wow.  :(
<asac> keescook: and it doesn't shutdown cleanly
<BenC> StevenK: but then I have to worry about our module conflicting with a newer virtualbox program
<asac> keescook: all these issues are not in 0.5.8
<BenC> StevenK: this has also caused a lot of headache for vmware
<keescook> asac: yeah, seems like a downgrade makes sense then.  I have no attachment to 0.6.  :)
<StevenK> BenC: Surely then we can say that the module we build is for the version of virtualbox-ose in Gutsy, and no other.
<asac> keescook: i couldn't see it until nm ubuntu11, because before that network-manager just silently failed on these problems ... and it just looked like broken randomness
* keescook nods
<BenC> StevenK: saying it doesn't help users that have the module installed and are having API conflicts with their userspace program
<BenC> StevenK: they don't know these things
<mjg59> BenC: We ship a distribution. If people deviate from that, it's their problem.
<StevenK> BenC: Agreed. But I'd still like to help the 95% of users that will use the version of virtualbox-ose in Gutsy and be happy that it works
<mjg59> Part of the point of providing a distribution is that we provide an integrated userspace and kernel
<BenC> I'd love to do that, but we've been bitten too many times in the past trying to provide kernel modules for vm's
<StevenK> BenC: The virtualbox-ose module source is in Gutsy too, so we need to make both are updated in lockstep, which is easy at the moment, since they are both in the same source package.
<StevenK> we need to make sure, even
<pkern> pitti: How is the CD part going? Did the kernel settle? (LP looks like it...)
<pitti> pkern: on it, lrm will be published soon, then we need -meta
<BenC> StevenK: either way, it can't get done for gutsy even ignoring the actual problems
<BenC> StevenK: too late to start dropping things in
<janimo> asac: I can upload my network-manager-gnome changes (after beta freeze) if you do not have time and it's ok with you
<StevenK> I'm happy to make a virtualbox-ose-modules package that builds the modules and have virtualbpx-ose Recommend/Depend on it
<BenC> StevenK: maybe at UDS we can have a forum to discuss these things, go over the past problems, and think of ways to make it not break
<asac> janimo: what kind of changes?
<janimo> asac: xfce
<StevenK> BenC: Speaking of, how long is your flight to Boston, like 3 hours? :-)
<asac> janimo: they should be in
<BenC> people will install applications like this from outside of our distribution, and we can't break those things
<BenC> StevenK: this will be the first time I've been able to take a direct flight to any UDS/Sprint...one hop, 2.5 hours :)
<janimo> asac: Lionel commented on the autostart desktop bug that it's still not there (the file shoul dbe in /etc/xdg not /usr/share/gnome/)
<StevenK> BenC: Hmph. :-)
<janimo> asac: also the libgnomectomy patch is not applied either
<asac> bug 95064
<ubotu> Launchpad bug 95064 in network-manager-applet "add XFCE to OnlyShowIn" [Medium,Confirmed]  https://launchpad.net/bugs/95064
<StevenK> BenC, pitti: What do you think of my virtualbox-ose-modules idea?
<BenC> StevenK: you should look at the DKMS package and its hooks
<asac> janimo: for me its properly installed in /etc/xdg
<StevenK> BenC: I'll keep that in mind, thanks
<asac> janimo: strange thing is that it has not been updated ... maybe its marked as a conffile?
<janimo> asac: yeah it's a conffile I think. When upgrading it may remain in /usr.share
<pitti> StevenK: sorry, I didn't read the entire scrollback; you want to make a working virtualbox-ose-modules for module-assistant?
<janimo> asac: IIRC there was a similar issue with gnome-power-manager when we moved the files
<StevenK> pitti: Nope, I want to make a virtualbox-ose-modules package that builds the module for i386 and amd64
<pitti> StevenK: ehm, -source already exists?
<StevenK> pitti: Indeed
<lamont> pwd; ./sparc64 uname -m; uname -m
<lamont> /home/lamont/gutsy/util-linux-2.13/debian/util-linux/usr/bin
<lamont> sparc64
<lamont> sparc64
<pitti> StevenK: I'm not terribly convinced, since that would mean that we would need to keep them up to date with ABI changes in -security, etc.
<lamont> pitti: hrm.
* lamont takes a stab at d-i
<pochu> Since when are we installing Recommended packages by default? Gutsy?
<lamont> pochu: ISTR feisty or so
<lamont> debian plans to do it for lenny, starting next month, fiww
<lamont> fwiw, even
<janimo> asac: I remove -P the install n-m-g and the file is in /usr/share hmm
<StevenK> pitti: I was plotting setting myself as the Maintainer and such like. I'm happy to update it, I just need someone to bug me
<ogra> pitti, hmm, any idea why we have myspell-en-za on *all* CDs regardless of the langpacks etc ?
<pochu> lamont: thanks
<pitti> ogra: language-support-en dependency
<ogra> ah
<ogra> thanks
<elmo> Package glibc-pic is a virtual package provided by: libc6-pic 2.6.1-1ubuntu4
<elmo> You should explicitly select one to install.
<pitti> hard to choose...
<elmo> orly.  can I pick option a or can I pick option a?  maybe option a ...
<Hobbsee> elmo: pick b. duh.
<pitti> you can install it or you can choose not to :)
<elmo> did apt always do this?  I thought it was smarter than that
<thom> no, it really is that dumb
<elmo> oh, that's a shame
<pitti> BenC: for the records, I'll move linux-ubuntu-modules-2.6.22-12-{rt,ume,xen} to universe, since the corresponding linux-image* are, and they are uninstallable ATM; in the long run we should fix this in the default Section:s, though
<pitti> BenC: -rt and -ume are quite clear, but I'm not so sure about -xen; isn't this supposed to be in main?
<BenC> pitti: it should be, but I don't get enough feedback on it to know it actually works
* lamont wonders when the next linux-source-2.6.22 upload will be, and if it will get the hppa fix in it.
<lamont> that was theoretically going to be in -11.35
<pitti> lamont: very soon, I was told
<BenC> lamont: kyle has your fixes in, and it will get uploaded soon
<lamont> danke
<pitti> lamont: sparc64> hm, so it does work in your installed system, but not in the buildd?
<lamont> pitti: faure's gutsy chroot.  testing d-i build now
<lamont> well, momentarily anyway
<LaserJock> mvo: ping regarding g-a-i
<mvo> LaserJock: pong
<ScottK> pitti: If you are archive admining today, Bug #139037 is available should be feel like stomping something out of the archive.
<ubotu> Launchpad bug 139037 in viewcvs "Please remove viewcvs source from Gutsy" [Wishlist,Confirmed]  https://launchpad.net/bugs/139037
<pitti> ScottK: oh, erk; normally I would, but I'm in release madness mode
<ScottK> Ah.  No rush.
<pitti> ScottK: but yeah, removals are always a pleasure :), looking
<ogra> WOAH !
<ogra> gnome-user-guide is 13M ???
<pitti> o_O?
<pitti> ogra: yes, that was on my mental list of 'packages to check', too
<lamont> ogra: still tiny compared to oo.o :-)
<cjwatson> grew by 5MB+ since feisty
<pitti> ogra: mainly due to translated screenshots and such
<pitti> and by 2 MB since tribe 5
<ogra> lamont, well, it would be ~50% of my 30M oversizedness of edubuntu
<cjwatson> it's already bzip2ed
<pitti> throwing out documentation would be really evil, though
<ogra> well, indeed
<ogra> does anyone know if it uses pngcrush already ?
<ogra> (assuming the schots are png)
<ogra> *shots
<lamont> I hear mp3 compresses better than bz2. :-)
<pitti> ogra: TBH, I'd really consider throwing out f-spot and tomboy, together with the mono stack; that's a relatively unevil slaughter IMHO (but just my 2c)
<ogra> lol
<jdong> lamont: AAC's where it's at :D
<ogra> pitti, ++
<ogra> even though i love my f-spot ...
* jdong likes tomboy though :)
<pitti> ogra: f-spot might not be the primary app for schools, and tomboy is something for fans, I guess
<StevenK> pitti: You can throw out tomboy? It is a default Gnome app
<ogra> but i'm fine using g-a-i :)
<pitti> StevenK: in edubuntu, I mean
<StevenK> Ah, right
<jdong> have you thrown out all the games yet? :D
<pitti> ogra: just a suggestion if you need to make space under the gun
<ogra> StevenK, we can do what we want :) its opensource .... we can even change the CODE ! :)
<StevenK> ogra: Oh, gasp. :-P
<cjwatson> I'm off for a while, since the publisher is churning on manual and CDs will build after that; Canonical people have my number if it's urgent
<ogra> pitti, yeah, mono would be the best i guess
<jdong> do you know that life is ....
<jdong> *sigh* my french sucks
<seb128> pitti: tomboy is not really "something for fans"
* lamont prefers thombot
<ogra> heh
<seb128> pitti: it's a note taker which is fairly common usage
<pitti> seb128: well, I would prefer killing tomboy over killing gnome documentation
<ogra> erm
<ogra> pitti, edubuntu doesnt have any mono apps ... we moved them in feisty to the addon
<ogra> :/
<ogra> i guess i have to move the remaining edu apps first and see whats left to downsize :/
<ogra> will be a pretty spare desktop on the server defautl install
<lamont> pitti: scratching my head now...
<jdong> out of curiousity, anyone checked how much space would be freed if the LiveCD were lzma'ed?
<lamont> debian-installer_20070308ubuntu14_sparc.changes
<lamont> debian-installer_20070308ubuntu14_sparc.deb
<lamont> in a fresh gutsy chroot on faure
<pitti> jdong: yes, IIRC fabbione did that a while ago; it was quite amazing
<ogra> ogra@laptop:~/packages/edubuntu-meta-1.44$ /home/ogra2/getpkgsize scribus
<pitti> lamont: boggle
<ogra> scribus:  8968k
<ogra> total: 8M
<ogra> aha !
* ogra moves scribus to addon
<jdong> printk: I would imagine so... but at a great cost to the time invovled to build a livecd
<jdong> err... pitti
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<pitti> jdong: that's mostly irrelevant, I think; the runtime penalty matters more
<jdong> pitti: it has a runtime penality on modern hardware?
<pitti> jdong: I don't have numbers, I just faintly remember some email conversation about that
<pitti> jdong: which doesn't mean that it won't happen, it was just mentioned
<jdong> I was under the impression lzma decompmressed loads faster than bzip2 and only marginally slower than gzip...
<jdong> just compression speed is horrid
<slytherin> Does anyone other than me thinks that libtheora 1.0beta (if released today) is worth freeze exception?
<highvoltage> there's also a wiki page comparing decompression speeds for ubuntu iso's
<jdong> *searches*
<pitti> slytherin: it most likely changes ABI/API, which would rule it out solidly
<jdong> I agree with pitti... it will have to mess with a whole ffmpeg/mplayer stack too
<slytherin> pitti: AFAIK, it doesn't do either, but then I am not very sure.
<highvoltage> jdong: it doesn't have lzma on there, but it might be useful: https://wiki.ubuntu.com/Dpkg7Zip
<lamont> pitti: I'm tempted to throw it back through the chompers one more time, but I'm 99% certain that'll fail too.
<pitti> slytherin: there are tons of rdepends, so only if it keeps soname and API we can even consider it
<lamont> OTOH, it only takes 5 min to die.
<pitti> lamont: can do, but it already failed similarly yesterday
<lamont> exactly
<highvoltage> jdong: in the results, bzip2 even uncompresses faster an gzip!
<slytherin> pitti: Ok. I will upload packages to my ppa once it is released, do some testing and then file a bug.
<pitti> slytherin: thanks
<lamont> hence the head scratching
<lamont> pitti: don't give it back
<slytherin> pitti: According to MikeS on #theora, alpha8 broke soname which they are fixing with beta.
<jdong> highvoltage: the results seem a bit oddly inconsistent....
<pitti> slytherin: wow, they seem to be really disciplined and distro friendy
<jdong> highvoltage: they do not agree with my current experience with LZMA (which I use for all my backups...)
<jdong> oh well, that's a gutsy+big_number topic, unimportant and OT now
* slytherin prays for theora 1.0 beta release today. :-)
<highvoltage> jdong: hmmm, perhaps you should summarize your findings and post them to ubuntu-devel-discuss
<highvoltage> jdong: indeed. I do agree that better compression would be nice for the Ubuntu packages
<jdong> highvoltage: look at jace2kv's test near bottom.
<jdong> highvoltage: it produces wildly different decomp results, more consistent with my experience
<StevenK> jdong: It isn't as predictable as gzip?
<jdong> highvoltage: it leads me to question the RAM/CPU limitations of the original tester, which is an important factor to consider though
<pitti> calc: just for planning, do you have a realistic ETA for a new OO.o?
<jdong> StevenK: it is much more CPU heavy to decompress, and RAM-heavy to compress, and gzip is low-cost both ways
<jdong> so yes, depending on system specs the comparative performance is lot less predictable
<jdong> but as we move into recommending larger amounts of RAM, LZMA becomes more and more viable
<highvoltage> jdong: yes, indeed. how does 7zip's compression compare to LZMA?
<jdong> highvoltage: same algorithm....
<highvoltage> jdong: aaaaah
<jdong> highvoltage: currently p7zip has multithreading over lzma, as lzma's release ver in Ubuntu is outdated
<pitti> lamont: would it help to try it on the other buildd?
<jdong> highvoltage: creating a tar.7z on an 8-core system is phenomenal!
<highvoltage> jdong: I can imagine!
<jdong> :)
<lamont> pitti: nope.  it's the buildd
<lamont> sparc32 sparc64 ls
<lamont> sparc64: sparc64: Unrecognized architecture
<jdong> highvoltage: 7z allows use of different compressors too; some are better for binaries and others are better for text. it affords more flexibility. 7z is like a container format :)
<jdong> highvoltage: its disadvantage is that the default commandset with p7zip is vastly not-gzip/bzip-like....
<jdong> which can be fixed easily with wrapper binaries
<jdong> that's on my todo list of experimenting
<highvoltage> jdong: that's very cool
<highvoltage> jdong: perhaps you should post your findings on the whiteboard of https://launchpad.net/distros/ubuntu/+spec/dpkg-7zip too, for when it comes under discussion again in a future UDS
<lamont> pitti: developing the fix now
<pitti> lamont: you rock
<pitti> ogra: I'm going to trigger new CD builds in some 20 minutes; do you still need seed changes?
<ogra> pitti, not today anymore. i'll fiddle over the weekend ... build one with the recent -meta so i have a base for tomorrow
<pitti> ogra: yep, I will
<pochu> pitti: providing it's your archive day, could you take a look at bug 140426? It was already synced, but it failed due to "Unable to find gnome-build_0.2.0.orig.tar.gz in upload or distribution."
<ubotu> Launchpad bug 140426 in gnome-build "[UVFe]  Please sync gnome-build (universe) 0.2.0-2 from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/140426
<pitti> pochu: I don't think that this bug changed since then, but I'll try
<pochu> pitti: thanks. seb128's log said it was downloading from librarian, but I got a message from archive@u.c rejecting it...
<pochu> pitti: if you can't do anything, I could do a fakesync :)
<pitti>   - <gnome-build_0.2.0.orig.tar.gz: already in distro - downloading from librarian>
<pitti> lying!
<pochu> That's what seb had, but it didn't seem to work...
<pochu> bug?
<pitti> pochu: it might be that it is in some ppa
<StevenK> pitti: sync-source.py needs a penatly card
<pochu> pitti: mine :)
<pochu> pitti: no, it isn't in mine.
<pitti> elmo: gnome-build is trying to override libgbf-1-dev_0.2.0-1ubuntu1~ppa2 without -f/--force.
<pitti> *nnnng*
<pitti> pochu: yeah, just do a sync with my script or so
<pitti> http://people.ubuntu.com/~pitti/scripts/syncpackage
<pochu> isn't it in ubuntu-dev-tools?
<pitti> pochu: nope, we shouldn't really use it widely
<StevenK> I hope not
<pochu> ah
<StevenK> It's special, you can only use it when pitti Says So.
<bddebian> heh
* pochu feels important *g*
<pochu> Would you like to use the current signature? [Yn] 
* bddebian feels useless
<Hobbsee> StevenK: that's such a jean-ism....
<lamont> sparc32 sparc64 -B ls
<lamont> audioctl-1.3  debian  elftoaout-2.3  prtconf-1.3  sparc32-1.1  src
<lamont> well.. that was only slightly painful
<StevenK> Only slightly?
<lamont> the "why does it work there and not here" issue
<pochu> pitti: current, or mine? note that I don't have upload rights...
<pitti> pochu: current is from the DD, so that won't help you either
<pitti> pochu: oh, then you need to find someone who can sync this for you
<pitti> lamont: \o/
<stgraber> pitti: Any idea when first Beta candidates will be out ?
<pitti> stgraber: I'll trigger new CDs in some 15 minutes
<pochu> pitti: that should be easy... any volunteer? :-)
<pitti> stgraber: these will definitively not be the beta images, but they should be good for some testing
<pitti> stgraber: we'll get a new kernel, lrm, ubiquity, and langpacks by Monday, so Monday evening we should have some good CDs
<stgraber> pitti: ok, before you add them on the tracker just ping me. I enabled e-mail notification last night and would like to check that everything is going fine
<pitti> bdmurray: do we have a CD testing assignment plan?
<pitti> stgraber: yessir
<pitti> stgraber: do you think we should add the ones from this evening?
<Hobbsee> pitti: you should always ask if it's a decent plan.
<Hobbsee> not just if a plan exists.
<lamont> +   } else if (!strcmp(p,"sparc64") {
<lamont> +       options |= ADDR_LIMIT_32BIT;
<pitti> Hobbsee: "planning is replacing coincidence with mistake"
<Hobbsee> pitti: haha
* lamont wonders if there are any more util-linux changes that need to be made for this upload
<Keybuk> pitti: I would like to have an SRU approved
<stgraber> pitti: if they are bootable + installable why not, it'd at least help debugging the eventual bugs I introduced in the tracker :)
<pitti> CD builds triggered \o/
<pitti> *phew*, that took long
<pitti> Keybuk: sure, #?
* Hobbsee watches them blow up
<evand> hooray
<Keybuk> pitti: Bug #141034
<ubotu> Launchpad bug 141034 in upstart "upstart turns machines into a scene from 'Dead Rising' " [Critical,Confirmed]  https://launchpad.net/bugs/141034
<jdong> good title
<kylem> a bit melodramatic
<stgraber> pitti: and as Xorg and Compiz should stay the same we can at least still test that
<jdong> Upstart Kills Children
<pitti> stgraber: right, as well as gnome 2.20, n-m etc.
<pitti> jdong: kittens
<pitti> Keybuk: I blame upstream!
<pitti> Keybuk: bug updated
<bryce> morning
<seb128> pochu, pitti: that's likely because somebody has the orig in its ppa archive which is soyuz bug #141019
<ubotu> Launchpad bug 141019 in soyuz "sync-source should not compare to ppa versions" [High,Confirmed]  https://launchpad.net/bugs/141019
<lamont> dear upgrade manager.  if there are nfs mounts extant on the machine, please install nfs-utils prior to upgrading mount, since mount will fail in preinst.  kthxbye
<seb128> pochu: you need to do a fake sync for now
<lamont> pitti/Mithrandir/slangasek: trying to figure out if we really don't care about that case....
<pochu> seb128: and will that bug need to wait for 1 month before being deployed? that sounds scary :)
<pochu> at least you won't do too much syncs at this point of the development cycle
<calc> pitti: i got the first test build done which primed my ccache, looking into trimming down the depends now
<seb128> pochu: fixes can be applied to production and there is not so many ppa conflicting with the archive new versions for syncs at the moment
<pitti> calc: thanks! I'll try to get online again tonight when I'm back
<pochu> seb128: true that
* pochu wonders who has uploaded gnome-build to his ppa
<pitti> stgraber: http://cdimage.ubuntu.com/daily/20070921.1/
<seb128> pochu: google is your friend ;)
<pitti> stgraber: they are slightly oversized, but if you have a burner and media that cope with that (or use DVDs or vmware) it should do
<pitti> stgraber: the lives should fit; for alternates we need to wait for the new OO.o
<cjwatson> lamont: dear lamont, I suggest filing a bug as mvo might not notice random complaints on IRC
<lamont> cjwatson: will do
<lamont> upgrade-manager is the name?
<cjwatson> lamont: that sort of thing is eminently handlable in update-manager, AFAIK
<cjwatson> update-manager
<lamont> update-manager.  check
<jdong> stupid question of the day: is amd64 gutsy tickless or not?
<stgraber> pitti: ok, I'll make sure testers have a look at the iso size and use DVD (I personally always do)
<Keybuk> pitti: uploaded to -proposed
<pitti> stgraber: so you'll add the first set of images yourself and test your email notification?
<stgraber> pitti: yes
<stgraber> pitti: what are the next ones to be built ?
<pitti> stgraber: kubuntu should be ready as well
<pitti> http://cdimage.ubuntu.com/kubuntu/daily/20070921.1/
<pitti> http://cdimage.ubuntu.com/edubuntu/daily/20070921.1/
<pitti> ogra: ^ FYI (heavily oversized i386, though)
<stgraber> ok, I'll wait till we have all of them (or at least a good part of them) so I can check that users receive only one mail and not one/ISO
<pitti> stgraber, ogra: sorry, ignore edubuntu .1; edubuntu will be 21.2
<stgraber> ok
<pitti> lamont: btw, when you upload this, can you use the magic "LP: #141524" syntax in the changelog?
<lamont> pitti: it's in the changelog.  OTOH, it's in the entry for -6, not for -6.1... should I add it there too?
<lamont> er, s/6.1/6ubuntu1/
<pitti> lamont: as long as you use -v properly (*hint* *hint* :) ), having it in -6 is fine
<lamont> does dpkg-buildpackage take -v?
<pitti> lamont: yep
<Vegar> why doesn't modprobe find the modules in my custom linux-ubuntu-modules package?
<lamont>  util-linux (2.13-6) unstable; urgency=low
<lamont>  .
<lamont>    * sparc-utils 'sparc64' binary sets ADDR_LIMIT_32BIT.  Closes: LP#141524
* lamont hopes that was the right format
<zul> lamont: (LP: #)
<pitti> lamont: not quite, but you can close it manually
<pitti> lamont: LP: #1234
<pitti> lamont: or you tack it to the ubuntu changelog
<lamont> ah, so s/Closes/LP/ in my fingers, and I'm good.
<lamont> pitti: that'd mean retagging and everything.. :-(
<pitti> lamont: nevermind then
<lamont> I'll close it manualy
<lamont> and remember the syntax next time
<lamont> uploaded, and debian upload in progress
<pitti> stgraber, ogra: http://cdimage.ubuntu.com/edubuntu/daily/20070921.2/
<mvo> lamont: hu?
<lamont> mvo: util-linux 2.13 dropped nfs support (now found in nfs-utils)
<lamont> rather than sucking in portmap and adding 5 listening ports to grandma's machine, we kinda ignored the dependency-for-a-release rule and made nfs-utils a Suggestion
<mvo> lamont: and the upgrade path is to automatically install nfs-utils if util-linux is installed?
<slangasek> iwj: hey now, the part of that bug in PAM is fixed, it's not my fault that shadow upstream /also/ blocks SIGINT :)
<slangasek> (and anyway, the log for Debian bug #1708 has gotten horribly mangled by spam over the years...)
<ubotu> Debian bug 1708 in libpam0g "`passwd' not interruptible when invoked by `adduser'" [Normal,Fixed]  http://bugs.debian.org/1708
<pitti> good morning slangasek
<slangasek> pitti: morning
<lamont> so, if /proc/mounts exists, and has nfs mounts listed in it, and nfs-utils is not currently installed, mount's preinst fails (intentionally)
<slangasek> jdong: no, amd64 gutsy isn't tickless AFAICS; I'd been hoping :)
<lamont> so the upgrade path is "if that preinst condition will be met, make sure that nfs-utils is installed prior to the dpkg run that installs mount"
<lamont> mvo: ^^
<lamont> mvo: and I'll toss all  that in a bug report after lunch.
<iwj> slangasek: Well, yes :-).  But I still count it as my oldest open bug ...
<lamont> our hand waving excuse was that if you are old enough to use NFS mounts, you're old enough to understand the error message. :-)
<mvo> lamont: that can be handled via update-manager
<lamont> mvo: hence the bug for me to file against update-manager after lunch. :-)
<cjwatson> slangasek: it's not often that I think the Launchpad bug tracking system is better than debbugs, of course ;-), but I have to admit that the ability to have multiple "tasks" on a single bug for different packages is rather useful here
<lamont> "mount Pre-Depends: nfs-utils [iff nfs mounts present in /proc/mounts] "
<mvo> lamont: heh, ok .) please send me the bugnumber, once you have it
<lamont> now we just need a parser that'll handle that. :-)
<iwj> IWBNI debbugs's clones at least made links to each other ...
<lamont> mvo: will do
<cjwatson> they do, but only in the entry summarising the control log
<mvo> lamont: but I think the postinst should not fail, but create a debconf notice or something instead, failing maintainer scripts are evil
<cjwatson> Bug 1708 cloned as bug 439769. Request was from Steve Langasek <vorlon@debian.org> to control@bugs.debian.org. (Mon, 27 Aug 2007 09:57:03 GMT) Full text and rfc822 format available.
<ubotu> Launchpad bug 1708 in malone "Malone should know how to create bug reports based on analysis of CVE reports" [Medium,Confirmed]  https://launchpad.net/bugs/1708
<cjwatson> like that
<cjwatson> sigh, shaddup ubotu
<lamont> mvo: removing the ability to mount /usr without letting the user fix it first is also evil
<iwj> cjwatson: Yes, but I meant at the top somewhere.
<cjwatson> iwj: *nod*
<iwj> In a way that made it possible to unlink and relink it I suppose.
<pitti> stgraber: http://cdimage.ubuntu.com/daily-live/20070921.1/
<lamont> mvo: it's even more special if the machine has nfsroot
<cjwatson> just needs entries in .summary for it I guess
<pitti> stgraber: barely within the size limit :)
<cjwatson> and due care to create and remove them at all the right points ... I think I've been away from debbugs hacking for too long
<iwj> TBH I don't think this is very important.  The current situation is liveable unless like me you want to maintain your submitter-of-old-open-bugs kudos :-).
<mvo> lamont: presumably /usr is mounted during the upgrade (and / too) - so its more about the next reboot. but its your package, so its your decision :)
<iwj> lamont: Are you the person to talk to about hppa ?
<lamont> iwj: yep
<iwj> glibc FTBFS ...
<lamont> yeah.
<iwj> Oh, so long as you know about it.
<lamont> patch extant, the machine it's on has the breaker off while our glibc hacker hacks electrical wiring.
<lamont> that'd be a 2.7 feature that snuck into 2.6.1
<lamont> (private futexes)
<iwj> I don't want to know.
<iwj> glibc is like something out of a Charlie Stross novel.
<lamont> we expect to get the patch in the next 36 hours or so.
<lamont> and, uh, then we'll be asking for a beta exception...
<stgraber> pitti: :)
<iwj> I wonder if I should email Charlie Stross and suggest he hint that Drepper is a demon, or something.
<pitti> stgraber: server is building, then all the alternates are complete
<cjwatson> iwj: you still have the oldest open bug though
<lamont> tuckerize drepper... hrm...
<cjwatson> (2297)
<iwj> Ooh, yes.  That one won't be fixed any time soon.
<mvo> pitti, slangasek: could you please review/accept my compiz upload? fixes a bug in the wrapper script that makes it unusable on a lot of nvidia cards
<pitti> mvo: already at it
<mvo> pitti: rock, thanks!
* mvo hugs pitti
<pitti> stgraber: the other lives are on the way, should all be 21.1 (I just have to leave soon)
<mvo> pitti: unfortunately it changes a bunch of indentions too, that is a upstream import, I could git cherry pick the actual fix if you are more comfortable with that
<stgraber> pitti: ok, I'll check and as soon as they are on cdimage will add them on the tracker
<pitti> stgraber: http://cdimage.ubuntu.com/ubuntu-server/daily/20070921.1/
<lamont> where do the uploads-pending-approval (due to freeze) show up?
<pitti> lamont: http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/
<pitti> lamont: slightly behind reality (only updated every 5 minutes or so)
<lamont> not to be confused with https://edge.launchpad.net/ubuntu/gutsy/+queue
<pitti> lamont: that works, too
<pitti> lamont: that's actually up-to-date, you just can't download the pacakges there
<jdong> slangasek: aww that's too bad. it really ticks me off. ;-)
<lamont> pitti: I don't see unapproved source there..
<pitti> https://edge.launchpad.net/ubuntu/gutsy/+queue?queue_state=1&queue_text=
<pitti> lamont: just change state to 'unapproved' and 'update'
<pitti> lamont: btw, do you have accept/reject buttons on that +queue page? I do, and they actually work now
<lamont> ah. ok. unapproved isn't one of the pulldown options
<pitti> lamont: for me it is
<pitti> lamont: might be my ~ubuntu-release badge
<lamont> https://edge.launchpad.net/ubuntu/gutsy/+queue?queue_state=unapproved&queue_text= gets me to the same page as without that
<lamont> state=1 gets me EPERM
<lamont> I bet it is your -release badge
<slangasek> cjwatson: well, you can assign a debbugs bug to two packages of course, you just only get one closure state ;)
<cjwatson> slangasek: yeah, it's the lack of independent state that's a problem
<cjwatson> it wouldn't necessarily be that hard to fix nowadays, just tedioius
<cjwatson> tedious
<cjwatson> lamont: it's his -archive badge
<cjwatson> jdong: it doesn't appear that the option even exists; it's not like it's CONFIG_NO_HZ=n, it's just not there
<pitti> mvo: the effective diff is just GL_MAX_3D_TEXTURE_SIZE  GL_MAX_TEXTURE_SIZE from what I can see; right?
<slangasek> cjwatson: indeed it's not; amd64 tickless isn't merged yet
<cjwatson> figures
<mvo> pitti: yes, that is the crucial bit
<lamont> mvo: #141559
<lamont> and I'm going to mark several util-linux bugs as dups of that one...
<lamont> mvo: and I'm not sure but what I should remove the "if Debian = $DISTRO" check
<lamont> can someone explain bug#131897 to me?
<evand> yay, no unionfs issues in the latest daily live cd here
<kylem> do you miss them? i can readd them if you'd like
<evand> haha, please do not
<Keybuk> is that like "please upload more, the CDs are undersized" ?
<evand> we need an excuse to go to blu-ray anyway
<pitti> Keybuk: alternates are still oversized, but the next OO.o will sort that out
<pitti> anyway, really gotta run now
<pitti> my part for today is mostly done, things are looking good now
<lamont> "fix released" ==> uploaded/in-the-archive, yes?
<cjwatson> http://launchpadlibrarian.net/9443097/buildlog_ubuntu-gutsy-ia64.debian-installer_20070308ubuntu14_FAILEDTOBUILD.txt.gz blink
<cjwatson> iwj: ^-- above looks like a dpkg segfault? could be transient ...
* lamont wonders if doko is around
<StevenK> Hmph. Damn it, postfix, the socket exists, stop saying it doesn't!
<lamont> heh
<lamont> StevenK: but does it exist in the chroot...;)(
<StevenK> DOH
<iwj> cjwatson: Looking ...
<cjwatson> iwj: I note that http://launchpadlibrarian.net/9420533/buildlog_ubuntu-gutsy-ia64.dpkg_1.14.5ubuntu15_FULLYBUILT.txt.gz mentions several warnings (implicit declaration of m_malloc etc.) which look like they could break ia64
<StevenK> I keep forgetting exactly how paranoid Weitse *is*.
<cjwatson> hard to say much more than that
<lamont> StevenK: actually, Wietse says that distros should not ship chroot-by-default
<lamont> I differ.
<StevenK> Surely changing chroot from - to n for lmtp should fix it
<lamont> see http://bugs.debian.org/151692 :)
<StevenK> Oops, wrong column
<iwj> cjwatson: Oh, ffs.
<iwj> cjwatson: I'd forgotten that dpkg has had -Werror removed.  That's almost certainly it.
<iwj> But err that would make dpkg 1.14.5ubuntu15 not work _at all_ on any 64bit arch.
<StevenK> Yay. Now I get a cyrus error
<iwj> cjwatson: Is there any way to get something resembling more information ?
<cjwatson> iwj: I don't believe that's true
<cjwatson> cjwatson@cittagazze:~ $ cat t.c
<cjwatson> #include <stdlib.h>
<cjwatson> #include <stdio.h>
<cjwatson> int main() { printf("%p\n", malloc(8)); return 0; }
<cjwatson> cjwatson@cittagazze:~ $ make t
<cjwatson> cc     t.c   -o t
<cjwatson> cjwatson@cittagazze:~ $ ./t
<cjwatson> 0x601010
<lamont> am I allowed to say dpkg --status inside a preinst?
<cjwatson> iwj: cittagazze is amd64
<iwj> lamont: Yes but most people who think they want that are making a mistake.
<lamont> heh.
<iwj> lamont: So why do you think you want to ? :-)
<cjwatson> iwj: elmo (or somebody else in IS) might be able to help but it depends whether it's reproducible
<lamont> I need to know if nfs-common is installed, or will be installed in this run
<iwj> lamont: You can't find out the latter at all.
<lamont> understood
<cjwatson> Mithrandir: would you mind giving back debian-installer on ia64 so that we can see if this is reproducible?
<lamont> hence just the former
<iwj> Eg,   dpkg -i your.deb nfs-common.deb    and nothing has worked out yet what nfs-common.deb is.
<lamont> cjwatson: ia64 is the arch where that will kill you.  amd64/alpha will "kill you sometime later"
<iwj> Why do you need to know ?
<cjwatson> iwj: did the dpkg code in question change recently?
<lamont> iwj: so i can reliably fail in preinst if it's not there
<lamont> based on other conditions
<iwj> lamont: Go on ...
<cjwatson> lamont: yeah, that was my recollection
<lamont> iwj: see LP #141559
<iwj> cjwatson: Oh, yes.
<ubotu> Launchpad bug 141559 in update-manager "update-manager needs to handle mount/nfs-common transition for gutsy" [Undecided,New]  https://launchpad.net/bugs/141559
<cjwatson> lamont: "is installed" -> can you not just look for a file it installs?
<lamont> and then mix that with debian #443466
<ubotu> Debian bug 443466 in mount "mount: upgrade fails if nfs-common is in removed but not purged" [Normal,Open]  http://bugs.debian.org/443466
<lamont> cjwatson: I do
<lamont> the debian bug is the one that's my current annoyance
<iwj> lamont: Do you need nfs-common to be unpacked or installed ?
* cjwatson -> dinner
<lamont> cjwatson: wrt int->ptr: ia64 always has non-zero bits in the top 32, alpha/amd64 generally happen to have zeros there for most apps for a long time into the boot.
<lamont> iwj: unpacked and installed some time before the end of this dpkg run
<iwj> lamont: Of course things you do in your preinst won't arrange for the package to be actually selected for installation so I take it you have something else to do with that ?
<lamont> I have no need for the bits, but don't want to leave the machine hosed if it reboots
<iwj> lamont: You can't find that out either.
<iwj> lamont: ia64> Right.  So if I fail to declare a function returning void* on ia64 it should crash every time ?
<lamont> iwj: that's why the preinst is basically saying "if you have nfs mounts in /proc/mounts, and no /sbin/mount.nfs, then die until you do".
<lamont> OTOH, no nfs-common in a chroot on a machine with nfs mounts is perfectly fine, and I need to distinguish that case.
<iwj> lamont: /sbin/mount.nfs is from nfs-common, right ?
<lamont> yes
<lamont> iwj: guaranteed.
<iwj> lamont: So looking for it will tell you whether it's currently unpacked but it won't tell you much about whether it will end up configured.
<iwj> lamont: guaranteed> You mean re my ia64 crash ?
<lamont> iwj: that's fine for this round, I think
<iwj> lamont: OK, then that's probably the right test.  I'll be a damn sight faster than dpkg --status too.
<cjwatson> iwj: lamont has a horrible sbuild hack in Debian that makes anything that does that fail to build on ia64 regardless of -Werror
<lamont> re pointers, see http://wiki.debian.org/ImplicitPointerConversions
<cjwatson> (by log grepping)
<lamont> see the ia64 build log for museek+_0.1.13+svn.20070906.r740-1 on buildd.debian.org, for an example of said hack
<lamont> the actual code parsing the log is found on that wiki page
<iwj> cjwatson: So presumably this bug can't be in dpkg ubuntu15 then.  And the coredump must be something else.
<cjwatson> iwj: it can because this grotty sbuild hack is only in Debian not Ubuntu
<lamont> iwj: so how do I tell if a package is removed vs isntalled?
<cjwatson> AFAIK it triggers on gcc warnings that dpkg ubuntu15 is emitting
<iwj> lamont: You're talking about mount.nfs still ?  If it's removed err it's not there.
<lamont> cjwatson: we should put the hack into ubuntu/ia64 as well, IMO
<cjwatson> iwj: we might have a job building the fixed dpkg if ubuntu15 segfaults all the time though; might need infinity's help there
<cjwatson> lamont: yeah
<cjwatson> (but I can't help)
<iwj> cjwatson: that failure log shows dpkg ubuntu15 not segfaulting, which is inconsistent with this theory as developed so far.
<cjwatson> iwj: OIC. Is there some possibility that it could only segfault in some uses? it only seems to happen when it starts unpacking udebs
<iwj> cjwatson: It seems unlikely to me.
<cjwatson> hmm. Well hopefully a give-back will tell us if it's reproducible or not and then maybe it can be reproduced on halley
<cjwatson> anyway, really dinnertime
<lamont> iwj: the three states I need to distinguish for nfs-using systems (for a chroot) are: 1) nfs-common not present, 2) nfs-common present (removed), and 3) /sbin/mount.nfs extant
<iwj> I think the right answer is to fix the bug, which is definitely a bug and trivial to fix (missing #include), and then see if d-i builds properly.
<lamont> #2 is currently a false positive
<lamont> ../../lib/tarfn.c:64: warning: implicit declaration of function 'm_malloc'
<lamont> ../../lib/tarfn.c:64: warning: assignment makes pointer from integer without a cast
<iwj> If it does we can say "oh, good" and if not we have a reproduceable thing we can investigate.
<lamont> fatal guaranteed. every time on ia64
<lamont> StoC and TarExtractor  will kill in ...15
<iwj> lamont: That log however shows ubuntu15 working.  Which is mysterious.
<lamont> which means it didn't call that functino
<lamont> or, you didn't use the pointer when it was passed somewhere
<ion_> Zomg, audio works in my laptop by default in gutsy. (opl3sa2)
<lamont> or you handle SIG{SEGV,BUS} :-)
<iwj> lamont: Yes, but those aren't plausible.  So we conclude that we don't understand fully.
<lamont> ok
<iwj> But we can make the situation more correct by fixing the bug and seeing if the symptoms go away.
<ion_> The last time i used this laptop, i was running breezy. For it, i had to pass a bunch of io/irq/dma parameters to the module.
<lamont> anyway, expect the sbuild hack to arrive in ia64/ubuntu sometime... for that matter, it really should go on all architectures...
* StevenK grumbles.
<StevenK> Now lmtp gets a BUS error
<jdong> why does nautilus-cd-burner stop trying to estimate burn time remaining when the speed changes?
<jdong> i.e. it's fine for the first step, but when my burner ramps 8x to 24x, nautilus stops outputting times
<iwj> I'm just cleaning a few other warnings while I'm here (ssize_t passed to printf %ld, amongst other things).
<jdong> it's pretty normal for high-speed burners to increment their speed piecewise
<lamont> iwj: implicit conversions/definitions are bad
<lamont> iwj: which log are we talking about?
<slangasek> StevenK: lucky for you, lamont has a lot of experience with bus errors
<lamont> iwj: re the debian-installer ia64 ftbfs log, where are you saying that dpkg is working in that log?
<lamont> slangasek: I make 'em all the time...
<StevenK> slangasek: Surely other people are running Cyrus 2.2 on sparc
<StevenK> I can't be the only one
<slangasek> oh, the bus error is in cyrus, not in postfix? :)
<StevenK> Sep 22 03:55:41 enervated cyrus/master[2013] : process 2022 exited, signaled to d
<StevenK> eath by 10
<lamont> iwj: the version of dpkg installing the build-deps in that log is 1.13.11ubuntu6 (dapper)
<lamont> and I don't see dpkg running anywhere else with success in the log...
<lamont> (build-deps are installed using the apt/dpkg in the real root, not the chroot)
<iwj> lamont: At line 37 it unpacks 1.14.5ubuntu15.  At line 41 you can see "Reading database" again, which means the new dpkg has started up.
<lamont> which means that fixing it won't be any big issue...
<lamont> yep.  all done by dapper's dpkg
<lamont> show me a dpkg instance after the line that reads "debian/rules build"
<lamont> or even debian/rules clean :-)
<iwj> Oh, you mean the outer bits are all i386 or something ?
<iwj> buildlog_ubuntu-gutsy-ia64.debian-installer_20070308ubuntu14_FAILEDTOBUILD.txt.gz
<iwj> lamont: Yes, yes, I know they're bad.
<lamont> no.  the outer bits are sbuild running the real-root apt-get with a _VERY_ long string of options pointing everything inside the chroot.
<iwj> lamont: I'm just trying to make sure we understand how it works at all since from what you're saying (which sounds quite plausible) it ought to break utterly every time.
<lamont> the dpkg at the top of the log is 1.13.11ubuntu6 running on a dapper ia64 machine.  The one inside the build is the gutsy version, in the chroot.
<iwj> So right at the top of that log it unpacks and installs dpkg_1.14.5ubuntu15_ia64.deb.
* jdong looks confusedly....
<lamont> right
<jdong> what does unionfs oopsing invalid opcode 0000 mean?
<lamont> installs it in the chroot.
<iwj> Oh, you mean that that dpkg isn't upgrading itself ?
<lamont> nope.
<iwj> Ahhhh.
<iwj> Right, I follow now.
<lamont> dapper's dpkg is upgrading the gutsy chroot, and then we do  a 'chroot .... dpkg-buildpackage ...'
<lamont> 99% certain that the dpkg-source -x is done outside the chroot as well
<iwj> I really need to beat Guillem Jover over the head a bit more and then I can start to sanitise dpkg's build system upstream a bit.  Then we can have -Werror back and this kind of thing won't happen any more.
<iwj> dpkg-source doesn't use dpkg.
<lamont> ok.
* lamont not that dpkg-literate
<StevenK> /usr/sbin/cyrreconstruct -r user.steven
<StevenK> Bus error
<StevenK> Can I kill something *now*
<lamont> cjwatson: and re: impl-decl snatching, you saying "make it so" helps quite a bit, thank you. :)
<iwj> lamont: How about getting Debian's gcc patched to call that warning an error ? :-)
<lamont> iwj: one could hope.  sadly, it's not always actually an error to do that.  At least not until you use it as a pointer.
<iwj> dpkg_1.14.5ubuntu16 on the way
<iwj> Oh dear, it's stuck in the approval queue of course.
<cjwatson> lamont: I do slightly question it after beta; not sure
<cjwatson> lamont: but absolutely make it so for hardy, and we can fight about gutsy
<cjwatson> iwj: not any more
<lamont> cjwatson: makes sense
<cjwatson> thanks for that
<lamont> cjwatson: do you know if it's possible to have LP send build logs to an email addr automatically>
<iwj> cjwatson: Thanks.
<lamont> ?
<iwj> lamont: Sorry to throw a bug at you and sorry for being confused.  I hope it'll be fixed now.
<lamont> iwj: no
<lamont> np
<lamont> damn keyboard
<iwj> we got no no no no no problem
<stgraber> Can someone please check what we don't have Xubuntu daily-live yet ?
<lamont> heh
<cjwatson> lamont: I think it already sends at least some subset of them to a mailing list, but you'd have to ask cprov/bigjools really
<cjwatson> stgraber: it's building
<stgraber> I'm waiting for it to add all the isos to the tracker
<lamont> iwj: so... back to my other question then... how can I tell if nfs-common is removed?
<lamont> rather than purged
<cjwatson> stgraber: waiting for the amd64 livefs to build
<cjwatson> livefs builds take a while
<stgraber> ok
<cjwatson> only started 17 minutes ago so I wouldn't hold your breath
* lamont lunches
* jdong cries :(
<jdong> all of neptune's forces are against me in installing Ubuntu on this Macbook
<bddebian> Gah, torbutton source makes torbutton-icedove and torbutton-iceweasal.. :-(
<jdong> yay, usb external keyboard worked
<jdong> silly bios emulator not emulating bios.
<kylem> jdong, it's actually a race.
<kylem> jdong, it thinks the IR port is a keyboard.
<jdong> kylem: ah, how interesting
<jdong> kylem: are there any known issues with macbook and the livecd unionfs panicking?
<kylem> how recent a livecd?
<jdong> today's.
<jdong> I get an invalid opcode 0000 oops....
<evand> jdong: .1?
<jdong> evand: there wasn't a .1 build of the livecd 10 minutes ago?
<evand> jdong: http://cdimage.ubuntu.com/daily-live/20070921.1/
<evand> it was there 10 minutes ago.  Perhaps you were pulling a cached version of the page.
<jdong> how confident are you that this build resolves my issue?
* jdong is already well into an alernate .1 install
<agoliveira> Tip: mc (Midnight Commander) can use a patch file as a filesystem so you can move, edit, and copy individual patchs easily as if they were files. Very useful if you have a patch that covers multiple different files.
<evand> jdong: quite confident, it resolved the same issue for me
<slangasek> it's the build that's explicitly supposed to fix the unionfs issue
<jdong> oh, ok :)
<jdong> too bad I didn't see it 5 minutes ago
<jdong> oh well, alternate's seeming to work fine
<iwj> lamont: (back at my keyboard now)
<iwj> lamont: Why do you need to distinguish removed vs purged ?
<jdong> aah the framebuffer corrupted on me....
<jdong> this cannot end well....
<iwj> Debian #443466 seems to be to do with something peering at /var/lib/dpkg/nfs-common.list, which is a bizarre thing to do.
<ubotu> Debian bug 443466 in mount "mount: upgrade fails if nfs-common is in removed but not purged" [Normal,Open]  http://bugs.debian.org/443466
<slangasek> this is lamont we're talking about
* lamont grumbles at slangasek 
<evand> Is Launchpad-Bugs-Fixed broken?
* slangasek waves at lamont :)
<lamont> iwj: peering at nfs-common.list was looking to see if nfs-common was installed (to handle the nfs-free chroot on a nfs-using system case)
<iwj> But if you look at /sbin/mount.nfs instead then this problem doesn't arise.
<iwj> Ie, that file won't be there whether it's removed or purged.
<lamont> iwj: older nfs-common doesn't deliver /sbin/mount.nfs
<iwj> But don't you need one that does ?
<lamont> so the cases are 1) no nfs-common, 2) old nfs-common, and 3) good nfs-common
<lamont> I need either 1 or 3
<lamont> 2 is bad
<iwj> No nfs-common is good even if you have nfs things in your fstab ?
<lamont> removed-but-not-purged nfs-common is case 1, the bug points out that I call it case 2
<lamont> for that check, yes it's good.
<iwj> bug points out> Yes.
<lamont> no nfs-common --> we are in a chroot or you've don amazing things to your machine and I don't want to get in your way
<iwj> lamont: OIC
<jdong> whoo! unionfs ain't blowing up!
<jander99> Does anyone currently work on the hardware database?
<jdong> I love you all!
<iwj> Isn't there some obvious file provided by the old nfs-common ?
<slangasek> lamont: wasn't there a consensus at one point that calling dpkg --status from maintainer scripts was permitted, and preferable over inspecting /var/lib/dpkg?
<lamont> iwj: hence the need to reliably determine case 2
<iwj> slangasek: Yes, that's definitely true.
<lamont> slangasek: yes
<lamont> I just hadn't gotten around to changing that.
<iwj> slangasek: But it's better still to inspect something on the filesystem.
<slangasek> iwj: agreed
<iwj> (Both faster and more accurate.)
<lamont> under the "if it works, why mess with it" theory
<iwj> lamont: So what bit of nfs-common does the old util-linux use ?
<lamont> nothing
<lamont> users of nfs used it
<iwj> I'm kind of missing something.
<iwj> mount is in util-linux, right ?
<iwj> And the reason you need new nfs-common for new util-linux is that the new mount calls mount.nfs from new nfs-common.
<lamont> OK.  I think I can go look at what file _does_ get delivered since antiquity by nfs-common, and key off of that file's existance instead of nfs-common.list
<lamont> mount is the mount binary from util-linux source, yes.
<slangasek> lamont: rpc.statd seems a good choice
<iwj> lamont: Just a moment, bear with me a bit more ...
<iwj> lamont: So why does having nfs things in your fstab without nfs-common installed mean you've done something amazine ?
<iwj> What amazing thing have you done ?
<lamont> iwj: properly speaking, one argument would be that mount should Depend: nfs-common for lenny, and then drop the depends at lenny+1.  security folks (myself included) would kill me for that
<lamont> iwj: it really just means that /proc/mounts and the rootfs are not from the same world -> chroot
<lamont> otherwise you've done something amazingly _special_ and deserve what you get.
<iwj> lamont: I don't understand how you can tell this from the lack of nfs-common.
<lamont> rpc.statd sounds like a very good choise
<iwj> What breaks if you don't have nfs-common, in the old world ?
<lamont> if you have nfs mounts on the system, you have nfs-common
<iwj> I mean, I have old setup and I put some nfs thing in my fstab and I say mount -av and what happens ?
<iwj> lamont: That's an inference, not a causal connection.  What feature of nfs-common is implied ?
<slangasek> iwj: the issue is that the old mount would mount nfs directly; the new mount requires nfs-common to mount it
<lamont> statd, for example
<iwj> slangasek: Yes.
<iwj> lamont: But I could mount with -o nolock or whatever ?
<lamont> iwj: the check in preinst is making an effort to create the dependency-via-error where it's appropriate, and not where it's not.
<iwj> lamont: Yes, I understand that.
<iwj> What I don't understand is how you can know that (in non-chroots) nfs in fstab implies nfs-common installed.
<lamont> that is a good point
<lamont> I suppose I could do the "am I in a chroot" test
<iwj> What you really want to know is whether the system you're about to unpack the new /sbin/mount into was/is responsible for doing the mounts.
<iwj> Which isn't really quite the same as "are we in a chroot" since sometimes people run mount inside a chroot.
<iwj> Mad people maybe, but it WFM when I can't be bothered not to :-).
<lamont> he
<lamont> heh
<lamont> OTOH, I don't care if we screw up your chroot as long as the real root will let you fix it...
<iwj> lamont: That's definitely true.
<lamont> and I'm not sure we can answer which root is responsible for the mounts
<iwj> And a check that fails to stop you screwing chroots in some obscure situation is probably liveable with.
<iwj> So you probably just want an "are we in a chroot".
<lamont> and it looks like someone fixed the old test
<lamont> you see, you're not _SUPPOSED_ to be able to tell that you're in a chroot
<iwj> *snort*
<iwj> If you've got /proc surely you can tell somehow.
<lamont> and I refuse to use the "inode of / != 2" check
<lamont> iwj: the old check was to look at /proc/1/exe or such
<iwj> /proc/1/fd perhaps.
<iwj> In this here chroot /proc/1/fd is EACCESS for root.
<lamont> ls -l /proc/1/fd
<lamont> total 0
<lamont> lrwx------ 1 root root 64 Sep 21 19:03 0 -> /dev/console (deleted)
<lamont> all hail gutsy
<iwj> (But I'm running a nonstandard kernel)
<iwj> root@anarres:~ # ls -ali /proc/1/root
<iwj> ls: cannot read symbolic link /proc/1/root: Permission denied
<lamont> so, like I said, it appears that they fixed it.
<iwj> -root@anarres:~> ls -ali /proc/1/root
<iwj> 65543 lrwxrwxrwx 1 root root 0 Sep 21 20:02 /proc/1/root -> //
<slangasek> Debian udev postinst has some currently-working magic
<iwj> Seems quite straightforward.
<lamont> readlink /proc/1/root
<iwj> Now someone will make a stunt system where init runs in a chroot :-).
<lamont>  /sbin/init is frequently installed in chroots.
<lamont> as for running it, that'd be silly
<jdong> evand: just got an identical oops from trying to start ubiquity on .1
<evand> argh
<jdong> EIP: unionfs_setattr
<iwj> lamont: No, I mean   init=/strange/script/which/does/chroot/-c/init
<iwj> Like an initramfs :-).
<evand> jdong: I imagine pkl_ would want to see that.  Bug 138915 is where I'm tracking the issue if you want to add your logs there.
<ubotu> Launchpad bug 138915 in linux-source-2.6.22 "unionfs NULL pointer dereference in 2.6.22-11.32" [High,Triaged]  https://launchpad.net/bugs/138915
<lamont> slangasek: ROCK
<slangasek> lamont: was that re: udev?
<lamont> yeah
<lamont> and stat is coreutils
<jdong> pkl_ / evand bug report updated...
<lamont> so... do I remove the Debian = "$DISTRO" check?
<ScottK> LaserJock: Edbuntu mentioned: http://www.groklaw.net/article.php?story=20070921112733615
<lamont> slangasek: do we care if ubuntu nfs users don't get the error?
<slangasek> uh.  I don't know? :)
<lamont> the general case is using update-manager, which will DTRT after 141559
<slangasek> then I suppose not
<mvo_> lamont: what do you change? the check ? and trust update-manager?
<lamont> mvo_: right now, the check is no-op on ubuntu
<lamont> I'm proposing checking on ubuntu, which means 'apt-get dist-upgrade' will produce errors if the user uses nfs
<lamont> however, that .01% of the population is generally of-clue.
<mvo_> lamont: it will be more complicated for me to ensure that its a pre-dep of util-linux, so not having the check means I can install nfs-common without caring too much for the odering and that makes my life easier. as for the general apt-get dist-upgrade case, we have release-notes and the release-upgrader (update-manager) that also runs in text-mode
<lamont> mvo_: sounds like a vote to not have the check.  works for me.
<mvo_> lamont: it is :) thanks!
<mvo_> lamont: without the ordering its very easy for me, I will add it right away
<mvo_> lamont: would you mind to add a note about it to https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes ?
<lamont> mvo_: will do
<mvo_> thanks!
<MacSlow> mvo_, http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-3.png
<MacSlow> mvo_, http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-3.1.png
<mvo_> MacSlow: what will "einstellungen" do if no ccsm is installed?
<MacSlow> mvo_, it's meant to offer to install it (similar to codecs)
<jdong> urgh it happened again
<jdong> can anyone think of an alternate install .deb that would cause the screen to be probed?
<jdong> because I can 100% reproduce a screen corruption bug with the alternate .1 today
<MacSlow> mvo_, and it should be ghosted until the user selects the "Custom Effects" option
<jdong> like 20% unto unpacking the main system, the screen goes blank as if probing X, and then when it comes back the installer is totally garbled
<mvo_> MacSlow: "This settings means that a modified set of effects is in use" <- what do you think about this text? do you plan to add this install feature for beta? I'm not really about it, I think that either we should install ccsm by default if we thing the user should see it or not show this option by default (or only if it is already installed). the amount of options is a bit overwheelming for the casual user
<mvo_> MacSlow: otherwise I like the dialog a lot!
<MacSlow> ccsm is heavy indeed, but the only reasonable way to offer a bearable gui (a lot better than gconf-editor :)
<MacSlow> mvo_, I would like to redo ccsm's UI but that will keep me too busy and distract me from more pressing bugs which need attention
<mvo_> MacSlow: its simply impossible for gutsy to get anything better done. and for hardy something is in the works already
<jdong> sorry, nvm, looks like bug 48164
<ubotu> Launchpad bug 48164 in xorg "Video corruption at installation of xserver-xorg" [Medium,Confirmed]  https://launchpad.net/bugs/48164
<mvo_> MacSlow: my point is that because we do not have a better editor, we should do the best we can with the defaults and not offer to use ccsm by default
<mvo_> MacSlow: the people who want it will find it
<MacSlow> mvo_, that would not be very "discoverable" and I don't like that.
<mvo_> MacSlow: I'm not religous about it and open for discussion. but I feel that our philosphy is to make it "just work" instead of offering a setup tool that let you tweak every possible option in existance. making that too easy discoverable will confuse user. I'm sure that 99% of the people will click on a advanced button if there is one (just because they are curious)
<cjwatson> jdong: well-known bug, that - happens on my laptop too
<cjwatson> many dups on xresprobe too, I'm not sure where it really belongs
<jdong> cjwatson: ah, ok, I guess I'll have to remember to disable fb at boot :)
<jdong> cjwatson: what do you think... can I do the rest of the install blindly? :D
<cjwatson> jdong: workaround is to boot the installer with a different resolution (select something other than VGA at the boot menu)
<MacSlow> mvo_, hm... I got to think about that a bit
<cjwatson> (that won't be passed on to the installed system, so suspend/resume will still work)
<cjwatson> jdong: yes, wait until disk activity stops and hit Enter
<cjwatson> that's another workaround ;)
<jdong> cjwatson: lol, I'll try that fist then :D
<jdong> err, first.
<jdong> fist second.
<mvo_> MacSlow: feel free to raise it on the mailinglist if you want a broader discussion about it
<mvo_> MacSlow: but I think we shouldn't let it slow down the control-center update, esepcially the "custom option" dection and the "click-on-normal-options-resets active_plugins defaults" changes are very important to have
<MacSlow> mvo_, hm... I posted an email to the ubuntu-devel ml and got a bounce informing me that it needs prior moderator-approval since I'm a non-developer (used my ubuntu.com email-address)
<Keybuk> MacSlow: approved and fixed so you're in the whitelist
<MacSlow> Keybuk, ah... so that was a pending thing anyway... ok thanks
<mvo_> MacSlow: thanks
<bryce> slangasek: another -beta bug fix that needs your a-ok - bug 141533
<ubotu> Launchpad bug 141533 in xserver-xorg-video-ati "Gutsy: Switching workspaces when playing XVideo overlay crashes X" [High,Fix committed]  https://launchpad.net/bugs/141533
<okaratas> hello
<MacSlow> good night folks
<davmor2> devs what is likely to stop ubiquity working on the iso test of xubuntu?  I get no feed back from it at all.  ps aux | grep ubiquity shows it is running but there is no installer at all
<Nafallo> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<gnomefreak> bryce: can you please take a look at bug 139726 this looks to have started with bulletproof X enabling and it wont go away no matter what i do except reformat and ive done that twice in last 2 weeks
<ubotu> Launchpad bug 139726 in gdm "[Gutsy} GDM is missing menu items" [Low,Incomplete]  https://launchpad.net/bugs/139726
<gnomefreak> and no it doesnt have to be right away it can wait til you have time
<bryce> gnomefreak: have you tried disabling the failsafeXServer line in your /etc/gdm/gdm.conf?
<bryce> that will determine whether it is a bulletproof-x issue or not
<bryce> gnomefreak: be sure to attach your gdm.conf, xsession-errors, Xorg.0.log, and xorg.conf to that bug report; currently there's not enough info to troubleshoot
<gnomefreak> bryce: no how would i do that (i thought it had # infront of it like the rest of the lines
<bryce> yes, putting a # in front of it is enough to disable bulletproof-x
<bryce> if it is commented out like that already, then the issue is not a bulletproof-x one
<gnomefreak> only thing helpful would be gdm.conf i checked .log1-4 and nothing im not getting errors but ill check that xsession-errors
<gnomefreak> change that i dont have an xsession-errors file at all
<gnomefreak> bryce: ok ty i added everything i could see and think of when ever you get a free minute its not too imporant more annoying than anything, we determined it wasnt gdm by installing older versions of gdm
<gnomefreak> i need to run for the night, night everyone
* mdomsch wishes he could 'apt-get dist-upgrade' over a network connection without NetworkManager dropping the connection
<gnomefreak> mdomsch: add sudo and you have it ;)
<mdomsch> oh I was sudo'd
<slangasek> bryce: acked; OOI, is there any reason for such fixes to not be uploaded to gutsy/unapproved, and accepted/rejected from there?
<davmor2> Riddell: ping
<bryce> slangasek: I guess not - if that's a better procedure, I can do that
<Amaranth> arg, wtf
<Amaranth> launchpad janitor spam
<ion_> Thats quick to remove. :-)
<ion_> Delete, that is.
* lamont looks around for more util-linux bugs to fix
<slangasek> bryce: they have to be touched again anyway once uploaded, so unless you have doubts yourself that the fix is correct that seems better streamlined :)
<lamont> what's the practice for dealing with a bug that is fixed in 6.10, resent in 6.06 (Bug #68967, for example)
<ubotu> Launchpad bug 68967 in util-linux "Wrong daylight saving data for CET/CEST" [Undecided,New]  https://launchpad.net/bugs/68967
<lamont> because it's fixed in feisty...
<lamont> and, of course, belongs to a totally different package than it claims
#ubuntu-devel 2007-09-22
<ScottK> lamont: Fix Released with an open task for Dapper if it's SRU worthy.
<lamont> ScottK: uh... "open task for dapper".. I assume there's a "create task" label somewhere on the page, eh?
<Fujitsu> lool: `Nominate for release', IIRC.
<Fujitsu> Bah, lamont ^^
<lamont> ok
<ScottK> WHat Fujitsu said.
<pochu> lamont: you can't do it without nominating: change the url from lp.net/ubuntu/+source... to lp.net/ubuntu/dapper/+source..., and then click on "This bug also needs fixing here" (or something like that)
<pochu> s/can't/can/
<pochu> That way you don't need a driver to approve it... (dunno if you're a driver though hehe)
<Fujitsu> pochu: It's not drivers - that piece of text is entirely wrong.
<Fujitsu> It's uploaders to the component.
<pochu> I thought it was drivers who had to approve them...
<pochu> Oh, it was some time ago, wasn't it?
<LaserJock> it used to be that core-devs where drivers
<pochu> But there was a spec... motu-bugs-permissions, or something like that
<LaserJock> but they've changed it to be uploaders to the component
<LaserJock> right
<Fujitsu> pochu: motu-bug-persmissions [sic] 
<pochu> Anyway, I can also 'approve' a nomination for a bug, with that workaround ;)
<Fujitsu> pochu: Yep, their permissions are very well enforced.
* lamont -> gone
<yipe> Thank you, thank you, thank you a thousand times thank you devs for gutsy!
<yipe> I love it already!
<cjwatson> davmor2: ctrl-alt-f1, 'dmesg | grep BUG' please
<cjwatson> slangasek: I agree with you, "upload and have archive admins approve when ready" is a better process
<gnomefreak> cjwatson: i had daily ISO i think tuesdays freeze at 15% during install if it happens again i should beable to save the files to usb stick right? so i can add to bug report?
* gnomefreak not sure how usb support is on desktop cd
<cjwatson> gnomefreak: we know Tuesday's was hopelessly busted
<cjwatson> unionfs was broken
<jdong> usb works for me today
<cjwatson> anything before this afternoon's build is not interesting
<gnomefreak> cjwatson: ah ok cool
<jdong> cjwatson: as I commented earlier today unionfs is still a bit busted on .1 today...
<cjwatson> jdong: yes but it's not clear how bad yet
<cjwatson> (it's working fine for me so it's not a universal problem)
<gnomefreak> i will grab mondays/tuesdays than and test
<jdong> it was bad enough that I couldn't get ubiquity to load :(
<jdong> I posted a dmesg on the bug report
<cjwatson> ok, I can't do anything right now and don't intend to, I have a zillion other things to fix before bed
<cjwatson> your concern is noted for Monday :-)
<jdong> no sweat, no hurry
<jdong> just wanted to make sure you guys were aware of it :)
<cjwatson> there is lots of hurry, beta is five days
<jdong> but sleep first :)
<cjwatson> no, fix wubi first
<cjwatson> then sleep
<jdong> you're a trooper
<mthaddon> LP going down for maintenance in 15 minutes for 1 hour
<calc> looks like i can't get rid of the java deps for ooo, but was able to disable the system lp-solve which saved some space
<cjwatson> mthaddon: bazaar.lp.net isn't down already, is it?
<cjwatson> I get ECONNREFUSED from it
<calc> so we only ended up saving ~ 4MB so far with tweaking ooo
<mthaddon> cjwatson, it is, yes - timing was for the web front end
<cjwatson> argh
<cjwatson> mthaddon: what's this downtime for? I thought this week was meant to be clear
<calc> cjwatson: wow you are up early
<cjwatson> calc: late
<cjwatson> I was hoping to get this code committed before the downtime
<mthaddon> cjwatson, bug fix post 1.1.9 release - I think next week is meant to be the clear week
<cjwatson> mthaddon: beta is Thursday
<cjwatson> we need a stable and available Launchpad
* calc looks for any other low hanging large deps for ooo to drop
<kiko> hi there
<kiko> I know
<cjwatson> this downtime will significantly reduce the chances of the Windows installer work making it into gutsy, since I was trying to land the last few fixes so that we could test them tomorrow morning
<cjwatson> (the last few fixes that we know about)
<cjwatson> can it at least be delayed an hour or two?
<kiko> cjwatson, I guess that's up to mthaddon. I have already been awake for some 18 hours, I can wait another two. :)
<kiko> let me chat with him.
<cjwatson> I'm up late too
<kiko> I know
<cjwatson> kiko: I realise bug fixes are often exceptions, which is fair enough, but could you clarify whether this week or next is the clear week?
<cjwatson> (aside from this particular case)
<kiko> cjwatson, it's next week.
<kiko> next week is week zero.
<cjwatson> so the week after beta?
<kiko> cjwatson, it is likely the rollout will not take a full hour
<cjwatson> oh, by "week" you mean Mon-Fri?
<kiko> the week that starts on the 24th
<kiko> yes
<cjwatson> sorry, I'm so used to thinking in Ubuntu weeks which start and end on Thursday :-)
<kiko> heh
<cjwatson> ok, that's cool
<cjwatson> kiko: I can't realistically stay awake until 4am
<kiko> cjwatson, how much more time do you need?
<calc> cjwatson: inject some caffeine ;)
<cjwatson> kiko: about 20-30 minutes I think
<cjwatson> it's just a matter of landing commits and uploading; we can turn off the publisher at this point if the uploader stays up
<cjwatson> (so that Tom isn't blocked on waiting for the publisher to stop)
<kiko> cjwatson, let's try and do the rollout quick so you're not blocked. it shouldn't take more than 15 minutes tbh, and if it does we can abort. deal?
<cjwatson> kiko: ok, I can cope with that
<kiko> thanks
<cjwatson> I'll go and get more coffee
<kiko> seems like I owe many beers tonight
<Riddell> davmor2: pong
<Riddell> davmor2: evand does ubiquity
<cjwatson> Riddell: I answered him
<kiko> cjwatson, it's going smoothly, should be soon now.
<kiko> the database updated fine.
<cjwatson> great
<mthaddon> cjwatson, should be back up
<cjwatson> great
<mthaddon> please check and let me know
<cjwatson> yep, works fine now
<mthaddon> cool
<cjwatson> thanks for your speed, I appreciate it
<kiko> cjwatson, thanks so much.
<cjwatson> sorry to make a fuss :-/
<mthaddon> np
* lamont wonders when linux-source-2.6.22_2.6.22-12.37 will get accepted.
<lamont> interesting that the unaccepted queue has -12.37.{diff.gz,dsc} and -12.38_source.changes....
<kiko-zzz> cjwatson, everything going okay?
<cjwatson> kiko-zzz: yep, all fine now
<cjwatson> about to fall over
<cjwatson> lamont: probably tomorrow after CD builds
<kiko-zzz> cjwatson, good job. congrats :)
<lamont> ah, right.
<lamont> I suppose I'll live.
<cjwatson> kiko-zzz: we'll see whether it all works ...
<lamont> cjwatson: how hard would it be for me to find a copy of the dsc, diff.gz and source.changes files before then?
<cjwatson> lamont: they should all be in the Launchpad librarian
<cjwatson> or do you mean of -12.37?
<cjwatson> lamont: http://people.ubuntu.com/~ubuntu-archive/queue/gutsy/unapproved/
<lamont> that has -12.37 diff/dsc, and .38 source.changes...
<cjwatson> the .changes is misnamed, that's all
<cjwatson> if you actually look at it it's for .36
<cjwatson> er, for .37
<cjwatson> dunno what kyle did to that
<lamont> there are tags for 12.37 and 12.38 in git...
<lamont> and the next upload looks like it wants to be -12.39 atm
<lamont> test build queued
* Hobbsee skewers mneptok
<manchicken> Anybody seen mvo lately?
* desrt blunts the end of Hobbsee's long pointy stick in the name of channel safety
<desrt> pretty sure the CoC has negative things to say about skewering
* desrt finds section 72 184a.57 -- "No skewering during feature freeze."
<LaserJock> manchicken: I saw him today
<LaserJock> today my time anyway
<manchicken> I totally need to pick his brain.
<LaserJock> I'm actually looking for him too
<LaserJock> gnome-app-install is acting funny on me :(
<manchicken> I'm trying to figure out how to get changelog URL generation working under adept.  mvo *is* the documentation for libapt.
<Hobbsee> desrt: heh :)
<Hobbsee> desrt: you wish.
* Hobbsee attacks desrt with the pointier end of the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<desrt> oh.  ow.
<`23meg> Hobbsee: http://ubuntuforums.org/showthread.php?t=553726
<jdong> would almost seem like the forusms are giving monkeys a bad name :D
<IntuitiveNipple> an alternative might be a 'vote' portlet that non-commenting users can do the +1 with to indicate their interest in the bug, without creating comment spam
<Hobbsee> jdong: *grin*
<Hobbsee> `23meg: ah yes, i think i saw that in my email
<jdong> :)
<jdong> IntuitiveNipple: perhaps at UDS we can hammer out some good way of flowing between LP and the forums
<Hobbsee> IntuitiveNipple: true - but popularity is not the only meter, nor a particularly good meter, of the priority of the bug.
<`23meg> IntuitiveNipple, subscribing is a way of showing one's interest
<IntuitiveNipple> Hobbsee: agreed, but getting some feedback as to the number of users actively affected is useful in deciding what to tackle and what priority to set
<IntuitiveNipple> `23meg: Yes, but how many of those users will then send "unsubscribe" messages trying to leave?  :)
<`23meg> unsubscribing from a bug doesn't send mail to everyone
<`23meg> neither does subscribing
<evand> Isn't this what the developer forum on ubuntuforums is for?  Soliciting feedback, that is.
<evand> I fear the day when this activity spreads to most other bugs.
<LaserJock> jdong: LP-forums stuff has been discuss for ever UDS I've been at, which is the last 3
<LaserJock> *discussed
<`23meg> jdong, there's also a blueprint I think
<IntuitiveNipple> I'm working on something similar, for Hardy, automated collection of hardware profiles and association with bug, and integration with Laptop-Testing, so we have a structured view of bug impact and effects, and a 'hardware popularity' contest
<LaserJock> I honestly think it's better for devs to go to the forums than the forums goin to devs
<evand> +1 ;)
<IntuitiveNipple> No reason not to have a link on a bug, to a forum thread URL, same as forums do to launchpad :)
<Hobbsee> IntuitiveNipple: true.
<Hobbsee> `23meg: if they do it stupidly, yes it does spam pepole.
<Hobbsee> LaserJock: so it seems.  which is why it wont get done :P
<`23meg> Hobbsee, people who post "+1" rarely use the mail interface
<IntuitiveNipple> wow, first major fog of the autumn out my window... I was expecting a nice sunrise
<LaserJock> `23meg: is there any way to anticipate when a bug report is gonna get spammed?
<Hobbsee> LaserJock: when it's something that lots of forum users would want
<Hobbsee> LaserJock: and set it to private, when that happens.
<LaserJock> if you can put a link to a forum thread for all the +1 stuff that allows people to still voice themselves
<`23meg> LaserJock, when a link is posted to a controversial forum thread, or one in which inexperienced users are involved
<LaserJock> but doesn't get in the way of the bug reports or send bug spam
<Hobbsee> LaserJock: i think they did - and they spammed teh report anyway
* Hobbsee --> work.
<IntuitiveNipple> Also, if you do that, they can add a vote to the forum thread, and +1 away :)
<IntuitiveNipple> reflect the vote results into the bug report, if there's a forum link :)
<IntuitiveNipple> makes +1 users happy, and saves tempers fraying for devs
<LaserJock> `23meg: I don't see a link to the forums from the bug report
<`23meg> LaserJock, it's the opposite
<LaserJock> or rather that was for Hobbsee
<LaserJock> I'm thinking that the reverse direction is more helpful
<`23meg> how exactly should that be done?
<LaserJock> put a link in the bug report
<`23meg> to a forum thread, and say "post the +1s here"?
<LaserJock> yes, basically
<IntuitiveNipple> I like the idea, because prompter text could say "to vote or discuss this bug visit this forum thread"
<LaserJock> we've been looking at linking from forums to launchpad
<LaserJock> but maybe going the other day around is more helpful
<`23meg> LaserJock, the forums have a "link to LP bug" function
<IntuitiveNipple> That's been there for a while - there's an option for a link to launchpad at least
<IntuitiveNipple> I know I've used it a few times
<`23meg> but I doubt it does anything beyond putting a bug URL on top of the forum post
<LaserJock> right, I know it's there
<`23meg> it's not possible to query for forum posts related to a certain bug, etc.
<LaserJock> I'm just saying sending hordes of people to LP doesn't really help us much does it?
<`23meg> sure
<`23meg> in this particular case, one user said something in the lines of "if you want this package included, please show your support in LP"
<LaserJock> right
<`23meg> which hints to lack of knowledge of bug tracker etiquette
<`23meg> which in turn brings us to the fact that the bug tracker has no etiquette page
<IntuitiveNipple> you know what? that K3B trumpet fanfare when it completes a burn made me spill my mug of tea!
<LaserJock> lol
<TheMuso> c
<LaserJock> `23meg: would people read it?
<TheMuso> wrong window
<TheMuso> IntuitiveNipple: IMO the ejecting of your drive should be enough. :p
<`23meg> LaserJock, whether people would read it is separate question
<IntuitiveNipple> TheMuso: lol... I was stood up looking out across the fields, absorbed in thought
<IntuitiveNipple> I think what we really want is to keep LP secret from the forum users, but have a link from LP to forums for devs to be able to look at discussions surrounding user experiences :)
<`23meg> when it's not there, there's nothing concrete to hold people accountable against
<StevenK> IntuitiveNipple: Ah, so Launchpad asks "Are j00 a forum user?" when signing up? :-P
<LaserJock> true
<IntuitiveNipple> lol
<`23meg> in other bug trackers, when users breach the etiquette, people typically post a link to the etiquette page (see GNOME bugzilla)
<IntuitiveNipple> You've got my drift... it's the silly time of the day
<IntuitiveNipple> 7am and I've been programming 5 hours
<StevenK> Or in the Gentoo bug tracker, refuse to fix the bug unless the submitter refiles it following etiquette rules
<minghua> Hmm, I think I registered for forum before becoming a LP user.
<IntuitiveNipple> Hmm, not sure I like that idea. I feel 'told off' if a bug report is marked 'Invalid' when it has resolved itself... I would like a "Resolved" status :)
<minghua> Because forum predates LP IIRC.
<IntuitiveNipple> I find forums better for documenting... code-formatting, quoting, and so forth
<`23meg> sure, the forums are much older than LP
<minghua> It's true that LP's web interface sucks for quoting, but email is always there.
<IntuitiveNipple> I don't think it does HTML <> LP does it?
<IntuitiveNipple> Grrr! I can't win. The Gutsy LiveCD fails through unionfs/i810 issues on the vaio notebooks, and now the alternate claims the CD isn't in the drive after it just booted from it!
<kagou> good morning
* Starting logfile irclogs/ubuntu-devel.log
* #ubuntu-devel  [freenode-info]  channel flooding and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<slytherin> pitti: When you say soname should remain same for a new version of library, what exactly does it mean?
<pitti> slytherin: i. e. the API and ABI must be backwards compatible
<slytherin> pitti: Does it have anything to do with actual name of .so file?
<pitti> slytherin: if you upgrade the library, all existing binary packages which linked and depend against the old version must continue to work with the newer library
<pitti> slytherin: the 'soname' is the common means of designating the backwards compatible "ABI version"
<slytherin> pitti: Ok
<stgraber> pitti: The tracker worked correctly yesterday and e-mail notifications were correctly sent, so next time you'll be able to add the new ISOs yourself.
<pitti> stgraber: cool
<pitti> stgraber: who does it notify now?
<cjwatson> stgraber: we might as well cancel testing of alternate images; they're screwed
<cjwatson> I just uploaded netcfg to fix them
* cjwatson goes out for a bit
<pitti> cjwatson, stgraber: alternates disabled in iso tracker
<pitti> stgraber: ^ erm, at least I wanted to; it doesn't actually seem to work; can you please have a look?
<stgraber> pitti: ok, I'll have a look. e-mail notifications are sent to people with e-mail notification enabled in their tracker profile (My profile)
<pitti> cjwatson: FYI, if someone complains about ubiquity crashing with a mmap SystemError, I filed bug 144001
<ubotu> Launchpad bug 144001 in python-apt "crashes with SystemError: E:Unable to write mmap - msync" [Critical,New]  https://launchpad.net/bugs/144001
* Hobbsee waves
<stgraber> cjwatson: alternate also means Edubuntu server and all the Netboot right ?
<stgraber> pitti: in fact the ISOs were correctly disabled (you can't post a result), it's just the ISOs list that doesn't show "rebuilding"
<pitti> stgraber: ah, I see
<slytherin> Do I need original maintainer field if the version I am packaging is not in debian?
<stgraber> Anyone having problems with ekiga ? (ekiga: symbol lookup error: /usr/lib/libopal.so.2.2: undefined symbol: _ZN11PSafeObjectC2Ev)
<Kmos> slytherin: for ubuntu you need.. XSBC-Original-Maintaner...
<Kmos> and Maintainer:
<stgraber> I'll try a package rebuild and see if that's just some kind of library change that's causing it
<slytherin> Kmos: ok
<Kmos> slytherin: better to ask on #ubuntu-motu
<Hobbsee> stgraber: i think there may have been a bug on that filed earlier, actually
<stgraber> Looks like bug 131569
<ubotu> Launchpad bug 131569 in ekiga "Ekiga does not start (Gutsy) - undefined symbol" [Medium,Triaged]  https://launchpad.net/bugs/131569
<Hobbsee> stgraber: is that amd64 weirdness, or?
<ion_> benc:
<ion_> Whoops
<ion_> benc: The nvidia_supported patch doesnt seem to be included in the newest l-r-m.
<ion_> benc: Additionally, the added echo "$start $stop $symname" line messes with its output.
<_MMA_> ion_: Do you mean you cant use the nVidia drivers anymore? Today, with the new upload was the 1st time I could use 'em with -rt.
<ion_> mma: No, only that the modalias pattern list is incorrect.
<ion_> benc: As a reminder, the diff to the previous version is at <http://heh.fi/tmp/nvidia_supported.diff> and heres the version with the diff applied, <http://heh.fi/tmp/nvidia_supported>.
<slytherin> if anyone is interested, I have created libtheora packages for 1.0beta1, should appear in my ppa in some time. http://ppa.launchpad.net/onkarshinde/ubuntu I will file bug on Monday.
<_MMA_> ion_: Ahh... Ok.
<yacoob> Hi there. Can anyone confirm that this http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402332 also applies to feisty?
<ubotu> Debian bug 402332 in coreutils "cp/mv do not respect default ACL set on the parent directory" [Normal,Open] 
<cjwatson> stgraber: anything using d-i where the installation profile includes the network-manager package
<asac> Hobbsee: was there a knetwormanager upgrade recently as well? or why can your .knetworkmanagerc become corrupted
<Hobbsee> asac: not to my knowledge.
<Hobbsee> asac: i have no idea.
<asac> Hobbsee: do you do backups of your HOME?
<asac> Hobbsee: maybe you can recover the broken file?
<yacoob> Sigh. Well, bug filed... :(
<Hobbsee> asac: er, i should do one of them.  i rm'd it, sorry.
<asac> ok
<asac> ;)
<yacoob> there's nothing more annoying when you look for something, you find the "perfect fix" and then it turns out it doesn't work as expected :/
<pkern> If I use boot.img.gz from d-i, does it only retrieve the installer components from the net and on install use the iso provided on the stick or is there some option I could turn on so that it automatically loads everything from the provided cd image?
<cjwatson> pkern: boot.img.gz is just a format, not an installation type; the thing you want to look at is whether it's cdrom, hd-media, or netboot
<cjwatson> pkern: ISTR that hd-media will grab everything from the ISO on the stick if it can
<soren> "update-manager -d" on feisty should offer to upgrade to gutsy, shouldn't it?
<soren> update-manager version is 0.59.23
<soren> Ah, I need to run it as root? That doesn't seem right.
<Kopfgeldjaeger> er... ubiquity does start anymore for me on the live-cd (well, that was the first time i tried it). can somebody confirm this?
<bigon> hi, could some buildd admin have a look at https://launchpad.net/~telepathy/+archive/+build/397159 ?
<Hobbsee> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<pkern> cjwatson: Oh, I guess I accidentally grabbed netboot then, thanks!
* Hobbsee seriously doubts that there are buildd admins around today
<Hobbsee> especially for non-beta critical stuff
<pkern> So almost time to trash the laptop with gutsy encrypted LVM install... ;)
<Hobbsee> bigon: oh, that's a ppa bug.
<bigon> Hobbsee: yep
<Hobbsee> bigon: in which the correct place to ask is probably #launchpad, but again, the stuff about weekends applies
<bddebian> Heya
<pkern> No fun, hd-media reports kernel mismatch... Hm.
<pkern> Published in gutsy-release 5 hours ago
<pkern> Gah... !@#@!#
<\sh> and on my desktop nautilus is getting mad and hitting  the harddrive...with something I can't identify...killing nauilus helps, but no gnome comes up..
<pkern> cjwatson: Is there a possibility to get a hd-media boot.img.gz built against the current kernel?
<\sh> strange thing, it just happens on this desktop machine...and not on my laptop
<jdong> \sh: does a logout help? When I applied the updates yesterday gnome went crazy infinitely regenerating thumbnails
<pkern> cjwatson: Hm, other way round, the cd image is the problem of course. \:
<\sh> jdong, nope...reboot doesn't help nothing...
<\sh> jdong, you say .thumbnails?
<\sh> hmm
<jdong> well that was my problem yesterday, yes
<\sh> jdong, I see after dm login, two or three times my panels coming up and destroying
<cjwatson> pkern: should already be one
<pkern> cjwatson: Yep it is, it's just incompatible to the current cd build.
<jdong> \sh: that's odd.... it could be the panel's crashing like crazy?
<cjwatson> current CD build is against -12 too
<pkern> There was a new revision 5h ago...
<\sh> jdong, no...when I kill nautilus form console...it stops hitting the harddrive
<cjwatson> you're just out of date with one or the other I expect
<jdong> hmm...
<pkern> cjwatson: Doesn't it also depend on the right kernel revision?
<stgraber> Hobbsee: yes it's amd64
<pkern> And how often does d-i get a rebuild pushed to the mirrors? (If it isn't that often my assumption is wrong anyway.) But I do get a mismatch between the hd-media image currently on archive and the current cd image (that's for sure, just jigdo'ed).
<cjwatson> pkern: they both have the right kernel version as far as I can see. d-i gets rebuilt manually when I feel like it
<Hobbsee> good morning pitti!
<pkern> cjwatson: Ok, thanks. I will investigate this one. ;)
<jdong> good morning, world :)
<jdong> it's a bright and shiny day....
<jdong> until someone brings up unionfs :D
<pitti> hey Hobbsee
<lamont> if apache was removed from gutsy, why were libapache-mod-* left?
<lamont> libapache-mod-{cgi-debug,filter,index-rss,ldap,mp3,random,relocate,text2html,trigger} all build-depend apache-dev
<\sh> lamont, check the depends...they are transitional packages
<\sh> sry...those ones
<bddebian> Oohh, pitti.  I was trying to use your syncpackage script for pochu to sync gnome-build but the dang thing keeps failing on signing the package.  I have DEBMAIL and DEBSIGN_KEYID set and I have no problems signing my packages or manually signing stuff.  Could you help?
<bddebian> pitti: Oh Hi, bye the way :-)
<lamont> \sh: ok.. I just know they're ftbfs on gutsy/hppa, and I expect that they'll be ftbfs on the rebuild testing for every other architecture...
<pitti> bddebian: no idea; just debsign the package manually after syncing it
<bddebian> lamont: That's a dang fine question.  Though libapache-mod-auth-radius became libapache2-mod-auth-radius.  Maybe we should do the same where possible for the oothers?
<pitti> bddebian: it's the last step anyway
<bddebian> And then just dput it?
<pitti> bddebian: well, check the source.changes for sanity first
<lamont> \sh Build-Depends: debhelper (>= 4.1.16), apache-dev (>= 1.3.34)
<bddebian> pitti: Hrm, this is the same reason signing is failing.  I get: Changed-By: Barry deFreese <> in the .changes file
<pitti> bddebian: ah, so it put in the wrong email address, it seems
<bddebian> Aye it put no email address :)
<pitti> bddebian: hm, but $DEBEMAIL is correct?
<\sh> guys
<bddebian> DEBMAIL=bddebian@comcast.net
<pitti> bddebian: DEB*E*MAIL
<bddebian> gah, wtf. I knew it was going to be something stupid I did
<\sh> I have in ~/nautilus-debug-log.txt messages like "0x8177888 2997/09/22 17:36:38.1745 (USER): debug log dumped due to signal 11
<\sh> and this is hitting my hd so hard..
<\sh> what is it? any clue?
<Vegar> how come the restricted drivers manager tells me I don't need any restricted drivers when I have an nvidia card?
<bddebian> pitti: Excellent thanks.  Now, it shouldn't add a build1 version or anything? I didn't think we were supposed to do that?
<pitti> Vegar: you have the nv driver ATM?
* bddebian feels like a freaking idiot
<Vegar> no
<Vegar> pitti: vesa
<pitti> bddebian: nope
<Vegar> pitti: it used to give me the choice to install the nvidia driver
<bddebian> pitti: OK, thanks again and sorry to bother you
<pitti> Vegar: it doesn't even appear in the list?
<Vegar> no
<pitti> Vegar: lspci | grep 0300
<pitti> ?
<Vegar> it tells me my hardware doesn't need any restricted drivers
<Vegar> sec
<Vegar> I'll log on on the laptop in question
<Vegar> no matches on that, pitti
<pitti> Vegar: erm... no graphics card at all??
* lamont usually uses lspci | grep VGA 
<Vegar> 01:00.0 VGA compatible controller: nVidia Corporation Quadro NVS 140M (rev a1)
<Vegar> oh, this is the -devel channel
<Vegar> I thought I was in ubuntu+1
<pitti> Vegar: what's the corresponding "lspci -n" line for that?
<pitti> lamont: that doesn't give me the vendor/product ID :/
<lamont> pitti: ah
<Vegar> pitti: 01:00.0 0300: 10de:0429 (rev a1)
<pitti> Vegar: ah, so 0300 *does* match
<Vegar> I might have forgotten the -n flag
<Vegar> meh
<pitti> Vegar: right, this model isn't in /usr/share/linux-restricted-modules/2.6.22-12-generic/modules.alias.override/nvidia
<Vegar> ah
<pitti> Vegar: please file a bug against linux-restricted-modules-2.6.22 and include above information (vendor/product ID and model name)
<Vegar> so that's a bug then?
<pitti> Vegar: you can manually edit that file to include your device ID, if you prefer
<Vegar> will do
<Vegar> yeah, I'll do that
<Vegar> I was looking forward to trying the new nvidia drivers
<pitti> Vegar: depends; if the card is actually supported by nvidia-glx, it's a bug of that restricted driver
<Vegar> it's nvidia-glx-new
<Vegar> isn't nvidia-glx the legacy driver?
<pitti> Vegar: you can also configure it manually, of course (install nvidia-glx and use displayconfig-gtk to switch the driver)
<pitti> Vegar: right, -new
<lamont> pitti: if you get bored feel free to look at the util-linux 2.13-{6,7} diff and tell me if you want that in pre-beta, post-beta, or in hardy.  (hwclockfirst.sh is debian only, btw)
<Vegar> what's the format of the nvidia alias override file?
<pitti> Vegar: just copy&paste a line and insert your product ID
<pitti> alias pci:v000010DEd00000429sv*sd*bc03sc*i* nvidia_new
<pitti> ^ Vegar
<sponix> anyone in here seen the /dev/null permission issue, every boot it goes to 600 instead of 666, _might_ be udev related (but udev rules are set for it at 666) ?
<Vegar> pitti: ah, wonderful
<Vegar> pitti: thanks a lot
<lamont> sponix: but 600 is far more secure than 666. :-D
<cjwatson> sponix: I'd bet more on some broken init script personally
<pitti> Vegar: please file a bug, though; in the end it's a bug in that stupid nvidia driver, but we can work around it with that list
<cjwatson> and we would love to know which it is ...
<cjwatson> for example something might remove /dev/null which would lead to it being recreated with bogus permissions
<Vegar> pitti: I'm working on that
<cjwatson> (doesn't happen here, though)
<lamont> sponix: is it still a character device file?
<sponix> lamont: perms are crw-r-r is what they keep getting reset to instead of crw-rw-rw
<Vegar> pitti: how come it suddenly stopped recognising my card? could it be because it was removed from that list in the latest restricted-modules upgrade?
<cjwatson> interesting
<cjwatson> so it's not just being removed
<pochu> pitti: gnome-build uploaded. since it's in universe, will it need to wait for beta release, or can you accept it?
<pitti> Vegar: yes, we updated the driver to a new version; the new nvidia driver might have decided to not support your card any more, or so
<pitti> pochu: I can accept it
<cjwatson> sponix: I think you need Keybuk to investigate, when he's around
<Vegar> ah, that's evil
<sponix> lamont: see xD card reader on these boxen doesn't wort without udev active in runlevel 2,3,4,5 so I turned that on... after that the problem seems to appear, but even after turning it off except S (startup), the issue still seems to persist
<lamont> interesting
<sponix> lamont: found a quick hack on a forum that makes it _work_ but its a bit dirty, and would like to know what causes the issue so I can fix it properly
<pochu> pitti: cool, thanks. that way I'll be able to request the anjuta UVFe.
<lamont> that is the challenge with quick hacks
<sponix> I don't mind a simple hack myself, but its on my wifes boxen also, and I have to leave for a year, would like to make sure she is setup correclty
<sponix> correctly
<lamont> understandable
<lamont> remote puppet-master support technology is still in its infancy
<sponix> lamont: quick h4x0rz was just to drop chmod 666 /dev/null at the end of /etc/init.d/rc.local to reset it to proper state at the _end_ of each boot
<sponix> but if anything updates bootscripts it could overwrite my change, leaving it so she cannot login
<cjwatson> sponix: err, you mean you added S links for udev in /etc/rc[2345] .d/ ?
<cjwatson> sponix: you really shouldn't do that, it's already started in rcS
<lamont> and stays running forever
<cjwatson> sponix: it would probably be easier to find out why you need to start it again there
* lamont agrees that if something is killing udevd, that's probably a bigger problem than just /dev/null perms
<cjwatson> sponix: forget about runlevel editors, look in /etc/rc2.d with a shell to see if there's anything matching *udev* in there
<cjwatson> I bet your runlevel editor threw in a K link when you disabled it ...
<sponix> cjwatson: see I uses sysv-rc-conf and it was default set to just S, I had to add 2,3,4,5 before the card reader would work
<sponix> cjwatson: had to start udev by hand with /etc/init.d/udev start the first go... prior, her card reader found the card, but didn't make the device for the partition
<cjwatson> sponix: 'sudo rm -f '/etc/rc[2345] .d/[SK] ??udev'
<cjwatson> sponix: seriously, that's bad news, I understand it fixed one problem (by luck) but it clearly introduced more
<cjwatson> lose it
<sponix> example, it showed /dev/sdg1 or /dev/sdd1 and would have /dev/sdg and /dev/sdd but no the /dev/sdd1 and /dev/sdg1 devices
<cjwatson> sorry, amend the above
<sponix> cjwatson: so you want me to try removing udev runlevels _completely_ and then give it a boot ?
<cjwatson> sudo rm -f /etc/rc[2345] .d/[SK] ??udev
<sponix> or you want just S and K ?
<cjwatson> sponix: udev should not be mentioned AT ALL in runlevels 2, 3, 4, 5
<cjwatson> sponix: it should only be in runlevel S
<lamont>  ls /etc/rc*/*udev*
<lamont> /etc/rcS.d/S10udev
<cjwatson> sponix: your runlevel editor is dumb and did evil things to your system when you did that
<sponix> not an problem.. I can mod that wht sysv-rc-conf
<cjwatson> no, do it at a shell
<sponix> ha
<cjwatson> I don't trust that program
<cjwatson> it broke your system
<cjwatson> (albeit at your request, but still)
<sponix> think it was it ?
<sponix> no, it was just acting on my dumb wishes ! ;)
<cjwatson> I bet you it left K links in runlevels 2, 3, 4, 5 when you asked it to reverse your previous action
<cjwatson> which shuts down udev which is really bad news
<cjwatson> run the command I gave above
<sponix> cjwatson: I'll double check on my broken laptop real fast
<cjwatson> then make sure that /etc/rcS.d/S10udev exists, as lamont showed above
<cjwatson> it's not worth trying to debug anything else until you've straightened that out
<sponix> yep, that command nuked K90udev from 2345
<sponix> going to temp remove my h4x0r and reboot, see if it still fsked
<cjwatson> now, the card reader may be broken again of course, but I bet there are better ways to fix that
<sponix> card reader is more for this desktop I'm on now.. but I implimented the "hose" on my laptop also just to make sure I was consistant at fscking things up :P
<stgraber> Hobbsee: Looks like rebuilding libopal (opal) helped, my ekiga no longer crash
<stgraber> Hobbsee: I'll use it for a while (trying to make it crash) and if it's stable ask a core-dev to do a zero-change upload for opal
<sponix> cjwatson: yep, that unhosed the boot, and udev is still running when I "ps ax|grep udev"
<cjwatson> great
<cjwatson> might be worth filing a bug on sysv-rc-conf - it shouldn't have let you do that
<sponix> cjwatson: I'll have the wife get me the digital camera card next time I catch her
<cjwatson> bug 77885 may be related
<ubotu> Launchpad bug 77885 in sysv-rc-conf "Minor: sysv-rc-conf inconsistency displaying rcS.d or not" [Undecided,New]  https://launchpad.net/bugs/77885
<cjwatson> certainly, one ought not to be able to set something up to have an entry (whether S or K) in both S and 2/3/4/5
<sponix> K=Kill correct ?
<sponix> I've been using sysv-rc-conf for a while, first time I've had it hose something up, I'll have to remember to double check its work, or quit being lazy and do it by hand
<sponix> Vista is So Sloooowwwwww, I thought it was locked up on boot... Been running ubuntu-7.04 on the same box for about a week, almost forgot how pathetic vista makes the same hardware look
<sponix> cjwatson: ever used Linux software raid5 ?
<Hobbsee> stgraber: i can throw it thru regardless, but it's easier after the main freeze, yes.
<Hobbsee> stgraber: of course, it's not exactly much I/O to rebuild it anyway, in the grand scheme of things, so then more people can test it.
<cjwatson> sponix: no
<cjwatson> sponix: yes, "S" means "run this script with 'start' on entry to this runlevel", "K" means "run this script with 'stop' on entry to this runlevel"
<lamont> sponix: root on my feisty machine is sw raid5
<sponix> lamont: what do you think of it? I've got 4-6 IDE 500G drives looking to backup my dvd collection, and then either nfs share them out to the other boxen, or make a web interface and vlc stream them
<lamont> cjwatson:  ls /etc/rc*/*hplip*
<lamont> /etc/rc0.d/K19hplip  /etc/rc3.d/S19hplip  /etc/rc6.d/K19hplip
<lamont> /etc/rc1.d/K19hplip  /etc/rc4.d/S19hplip
<lamont> /etc/rc2.d/S19hplip  /etc/rc5.d/S19hplip
<cjwatson> lamont: yes ...?
<lamont> sponix: I'd rather have hardware raid.  but then, I'm cheap
<lamont> that's a S in multiple run levels...
<cjwatson> surely software RAID is the cheap option
<stgraber> Hobbsee: at least I can now call without having ekiga to crash, and doing the same with another ekiga (without the rebuilt libopal) make it crash instantly
<Hobbsee> stgraber: OK.  got the bug #?
<lamont> cjwatson: and that's why I have sw raid instead of hwraid like I'd prefer...
<stgraber> bug 131569 IIRC
<ubotu> Launchpad bug 131569 in opal "Ekiga does not start (Gutsy) - undefined symbol (dup-of: 117732)" [Medium,Invalid]  https://launchpad.net/bugs/131569
<ubotu> Launchpad bug 117732 in opal "ABI changed without a corresponding soname change" [High,Triaged]  https://launchpad.net/bugs/117732
<sponix> doesn't have to be super fast, just be able to recover if a drive goes down, hate to lose 1.5+ TB of media over a single drive failing
<sponix> that is a _very_ long time of ripping my dvd's again :P
<cjwatson> lamont: I didn't say that was a bad thing
<cjwatson> lamont: I said putting an entry in S as well as in 2/3/4/5 is probably silly
<cjwatson> you have nothing in S (by which I meant rcS) there
<cjwatson> oh, right
<lamont> ah, ok
<sponix> cups-pdf is installed by default now, isn't it ... went to put that on the wifes box the other day, told me was already there
<Hobbsee> stgraber: do i need to mess with sonames and such?
<stgraber> Hobbsee: only thing I did was to rebuild it using pbuilder
<stgraber> Hobbsee: hmm, in fact it looks like I replaced an "undefined symbol" error by a segfault :)
<Hobbsee> stgraber: woot.
<Hobbsee> stgraber: looks like debian have packaged it slightly differently, anyway.
<Hobbsee> you know, for something that's apparently the same upstream version, but named differently...surely it should have the same upstream changelog?
<stgraber> receiving a call make it segfaults now :) I should try with : rebuild libopal + rebuild ekiga maybe that helps
<stgraber> but IIRC ekiga doesn't build with pbuilder (configure fails on a library version)
* Hobbsee checks if the debian VOIP team are on crack.
<Hobbsee> uh......wha?
<Hobbsee> since when does g++ need to be a build depend?
<jdong> Hobbsee: just to be absolutely sure we have it ;-)
<Hobbsee> stgraber: ask dholbach about that.
<Hobbsee> stgraber: (in particular, ask if we want to take their changes)
<Amaranth> arg
<Amaranth> session management is no fun
<broonie> Hobbsee: Things often have a versioned build dep if they don't build with old g++
<Hobbsee> greetings, Burgundavia
<Burgundavia> hey Hobbsee
<sponix> cjwatson: I'll be on the right box in a sec to see if I can make the card reader work without the mod to udev runlevels
<sponix> cjwatson:  ok... back...
<Vegar> is there a list of the patches applied to the ubuntu kernels?
<sponix> cjwatson:  still with me ?
<pkern> cjwatson: Sorry, I found the problem, I used the wrong CD image. But is it possible that cryptsetup is missing from the package pool on the CD?
<pkern> d-i insists on overwriting my sources.lists with the mirror source added, and is thus unable to find cryptsetup.
<pkern> The file list only lists the udeb, not the deb...
<pkern> And `chattr +i /etc/apt/sources.list' lists it break badly, but I expected that somehow.
<cjwatson> sponix: I'm no expert on udev rules, so at this point you need the udev maintainer (Keybuk) for further debugging
<pkern> It's a binary, not a script that forcefully overwrites the sources.list, right? \:
<pkern> Rough edges. *cough*
<cjwatson> pkern: good point - I've moved cryptsetup to ship for the next build
<sponix> cjwatson:  well, wanted to thank you for helping me unhose the base system anyway...
<cjwatson> pkern: it's a script, but there are plenty of *supported* ways to add sources.list entries ...
<pkern> cjwatson: Do you have a clue what I need to do at this point? (It installs the base system but breaks on cryptsetup.)
<cjwatson> pkern: wait for next build
<pkern> Hah.
<pkern> Possible but bad solution. \:
<cjwatson> or wget cryptsetup.deb and install it
<pkern> cjwatson: Is this sufficient?
<cjwatson> perfectly good solution from my point of view, you're working with a buggy daily build
<cjwatson> dunno
<pkern> cjwatson: That's my point. Or do I have to do some housekeeping?
<cjwatson> my priority is to fix the bug for the beta
<pkern> apt-get works fine in the chroot.
<cjwatson> you can always temporarily change sources.list again
<pkern> Of course, but the HDD is nuked now. It's just that I cannot successfully complete base-installer.
<pkern> If this is the last step in the list I'm fine.
<pkern> (i.e. I could ignore the failure and ask d-i to continue.)
<cjwatson> it's not, but you can probably install cryptsetup and then rerun base-installer
<cjwatson> it might be a bit confused
<cjwatson> it won't have run post-base-installer.d hooks or installed a kernel yet
<cjwatson> or processed the apt-install queue
<cjwatson> so you should definitely rerun base-installer and let it keep going
<pkern> cjwatson: From d-i that does not work, because it will try to start from the beginning again, and change the sources.lists just again before wanting to install cryptsetup.
<cjwatson> pkern: edit /var/lib/dpkg/info/base-installer.postinst and comment out the lines starting with 'waypoint' from install_base_system up to apt_update
<cjwatson> I think
<cjwatson> you'll get a message asking for confirmation of install over unclean target, but ignore it
<cjwatson> you do want to leave get_mirror_info I think because it sets several interesting variables
<pkern> cjwatson: That one worked, thank you.
<pkern> I hope there are no missing base packages or missing housekeeping *for cryptsetup* left now, but well...
<cjwatson> shouldn't think so
<LaserJock> cjwatson: you happen to know if mvo will be around this weekend?
<pkern> Ok, it's installing the system now, thanks. Next fun will be the reboot.
<cjwatson> LaserJock: don't know, sorry
<Amaranth> LaserJock: What's up?
<LaserJock> I think I've got a bug in g-a-i that is messing up the Edubuntu Addon CD
<Amaranth> Ah
<LaserJock> I've tried looking in the code a little bit but was hoping I could get ahold of mvo
<Amaranth> Dunno about that stuff, except for the pyxdg part
<LaserJock> well, thats kinda the stuff I'm trying to figure out
<LaserJock> for some reason it's not using my icons
<LaserJock> and I can get it to work doing very strange, at least to me, things
<Amaranth> LaserJock: what, exactly, is the problem?
<Amaranth> LaserJock: what is your Icon line?
<LaserJock> it's just got the name of the icon
<Amaranth> which is?
<LaserJock> various things
<LaserJock> Icon=xfce4 for instance
<Amaranth> are these icons installed in /usr/share/hicolor/<size>/<category>/<iconname>.png?
<LaserJock> no
<LaserJock> they are on a cd
<Amaranth> LaserJock: there is your problem
<LaserJock> I'm trying to supply custom icons
<Amaranth> pyxdg only reads from the icon theme unless you give it an absolute path
<LaserJock> right, which I would think it would be getting
<LaserJock> or hmm
<LaserJock> it should be given the app-install/ dir
<Amaranth> no no
<Amaranth> the Icon line needs to be an absolute path
<Amaranth> otherwise it uses the icon theme
<LaserJock> hmm
<LaserJock> then how come sometimes it works?
<LaserJock> although I guess that's when I set --desktopdir and --cachedir
<LaserJock> in g-a-i
<Amaranth> gnome-app-install might have a fallback to check the current dir or something
<Amaranth> or --desktopdir
<LaserJock> it's just weird
<Amaranth> not really
<LaserJock> becuase it only works when I cp my ro app-install/ from the CD to the hard drive
<LaserJock> and then I can point it to either directory, CD or Hard driver and it'll work
<LaserJock> I wondered if it was because the CD was ro
<Amaranth> gnome-app-install must have a fallback if pyxdg can't find the icon
<LaserJock> Amaranth: gotta run to do some shopping. I'll be back later if you're interested
<LaserJock> I'm gonna have to dig into the code and figure out how it does the icons
<Amaranth> err, alright
* LaserJock away
<ScottK> I'd appreciate it if someone from the archive/release team would accept wine 0.9.45-0ubuntu1.
<cjwatson> ScottK: done
<pkern> There is more broken. After reboot it doesn't get the root fs, but lvm seems missing, too. And I have a hard time getting rescue access to the disk.
<pkern> vgscan/vgchange did not list s.th. The partition type (using guided) was set to Linux, maybe that has caused it, but changing it did not fix it in the same session. *cough* Anyway, I'll close this for today, this is giving me headaches somehow (or they originate elsewhere, whatever).
* Inso is away: work
* cjwatson digs into that apt bug
<cjwatson> I think I might have a workaround
<IntuitiveNipple> Is the 20070921.1 desktop CD supposed to have a gnome menu-bar when running LiveCD !?
<cjwatson> IntuitiveNipple: yes
<cjwatson> (does here)
<IntuitiveNipple> ha, ok, so some kind of weird bug then. I'm testing it on an Acer Travelmate C104TCi - very strange, desktop's there, Examples and Install, right-click desktop brings up context menu, but no main-menu. It is all just desktop background. Ctrl+Alt+F1-F5 do't get a reaction, but Ctrl+Alt+Backspace restarts GDM correctly.
<IntuitiveNipple> (still waiting for the CD-ROM to restart the gnome session completely)
<cjwatson> some people have reported continuing unionfs breakage; may be what's happening to you
* jdong is one of them
<cjwatson> dmesg would be helpful if you can find a way to get at it
<jdong> cjwatson: has anything changed since yesterday's .1 that'd be worth me testing for the unionfs bug?
<cjwatson> doubt it, kernel team likes having weekends
<jdong> what are those?
<cjwatson> (though there were kernel uploads recently, admittedly)
<cjwatson> (but they aren't in today's image)
<IntuitiveNipple> cjwatson: possibly, that's been stopping me testing on the Sony Vaio notebooks
<jdong> ok, I'll sit tight and fool around with power consumption then.
<jdong> I'm a bit curious why OS X can pull off almost 1:30 extra runtime on macbooks compared to gutsy
<cjwatson> www.lesswatts.org
<IntuitiveNipple> argh, I can get a virtual terminal but it looks like the fbcon isn't loaded so no way to use it, blank video
* cjwatson uploads apt to hopefully fix its rather serious disagreement with the desktop CD
<cjwatson> IntuitiveNipple: you aren't selecting a resolution at the boot menu are you?
<jdong> yep, working on those tips currently
<jdong> though it should be *fewer*watts.org ;-)
<cjwatson> jdong: I did think that, but that's not correct - watts are continuous not discrete
<IntuitiveNipple> cjwatson: no, just standard CD startup testing... next test is to try Safe Graphics mode
<cjwatson> at least I think "less" is legitimate there though I think "fewer" would also be correct
<jdong> cjwatson: good point. Somehow less watts just doesn't sound correct to me
<cjwatson> yeah
<cjwatson> "less power" would be better :)
<jdong> indeed
<pkern> cjwatson: I in-place fixed d-i to generate the correct sources.list (thanks for the pointer) but after reboot it failed to mount the root device. luks actions on cryptsetup within initramfs segfaulted.
<pkern> (And on an unrelated sidenote with the cli install: my network interfaces were named eth1 and eth2 in persistent-rules but eth0 was set up in network/interfaces.)
<pkern> Or is `cryptsetup luksOpen crypt0 /dev/sda5' wrong syntax?
<slangasek> jdong: fewerwatts.org is an alias anyway ;)
<slangasek> pkern: wrong syntax - it's realdev decrypteddev, you have the last two args backwards
<pkern> cryptsetup segv in LUKS_dealloc_masterkey at keymanage.c:57
<pkern> slangasek: Hm, thanks.
<pkern> slangasek: The other way 'round it asks for a passphrase, yeah. (create has its arguments reversed.) So, thanks. *cough*
<slangasek> no worries :)
<IntuitiveNipple> pkern: Is there any provision to mount LUKS crypted volumes that *only* have a key-file (no password) at boot/startup ?
<pkern> slangasek: `[ -x /foo/bar ]  || exit 0' is a bashism, right? `/etc/cryptsetup/cryptdisks.functions' has two of them near the beginning. (Just another thing I encountered in initramfs... *cough*
<slangasek> no, what would be bashish about it?
<slangasek> it's a "not-set-e-ism"
<slangasek> but it's a "not-set-e-ism" in all dialects :)
<slangasek> (sorry, "non-set-minus-e-ism"
<slangasek> )
<slangasek> anyway, initramfs sure doesn't use bash in any configuration I've seen
<pkern> I thought that [ is only allowed after if... ok, fine. (It somehow failed in initramfs, though.)
<pkern> But... nevermind.
<Mithrandir> [ is just a normal binary in /usr/bin
<slangasek> nope.  "if [" is "if the [ command returns a zero exit code"
<davmor2> anyone here work on netboot?
<ion_> [ is a program (which may be implemented as a built-in), and you put any program after if.
<pkern> Right... \:
<pkern> Ok, off to another reinstall.
<Mithrandir> ion_: any program which is part of posix might be a built-in..
<ion_> Well, *any* program might be a built-in. :-P
<Mithrandir> no?  Having debconf as a built-in program would fuck up how dependencies work.
<slangasek> Mithrandir: nevertheless, POSIX doesn't /prohibit/ shells from adding random programs as built-ins :)
<IntuitiveNipple> Who'd be responsible for adding a patch to a hal script & gnome-mount to allow LUKS crypted volumes protected *only* by a keyfile (no password) ?
<Mithrandir> slangasek: true.
<Luke> asac: you on now?
<davmor2> cjwatson: ping
<asac> Luke: yes
<pkern> Fun. So I have a crypted root fs now, but I need to debug the initramfs because it does not find it at boot. (I suspect the missing `/etc/crypttab' might be the culprit, but I may be wrong of course, as day has shown. *cough*)
<cjwatson> pkern: after d-i, I have no idea how cryptsetup works, so I'm the wrong person to ask
<cjwatson> davmor2: pong, briefly
<davmor2> are you incharge of netboot?
<cjwatson> davmor2: d-i in general, yes
<cjwatson> (but trying to find the person "in charge" of something is usually the wrong plan, just ask the question)
<davmor2> netboot is installing the wrong desktops
<cjwatson> netboot is supposed to ask
<davmor2> edubuntu is listed twice both install kubuntu
<cjwatson> the task looks right ...
<cjwatson> but it's half-eleven on a Saturday night, I'm not going to debug it now. please file a bug
<davmor2> filed
<davmor2> bug 144145 + 144147
<ubotu> Launchpad bug 144145 in ubuntu "Netboot edubuntu desktop is listed twice both install kubuntu" [Undecided,New]  https://launchpad.net/bugs/144145
<davmor2> just pointing out while I get chance to as I'm still isotesting the other installs :)
<Luke> cjwatson: did you end up taking dell's disk remaster util under your wing?
<Luke> or will that stay with dell?
<Luke> asac: thanks for the replys. Sorry about the delay but I've been super busy with university this semester
<Luke> asac: are you looking for anything in specific in my syslog?
#ubuntu-devel 2007-09-23
<asac> Luke: no i have to look at all that is NetworkManager related
<Luke> i really think it's a Purdue problem not NM but we need an expert to help us fix the prblem
<asac> Luke: Usually its good to start with the line where network manager starts when providing a syslog
<Luke> kk
<Luke> you mean /var/log/syslog right?
<asac> yes
<Creteil> hi all
<Creteil> I'm currently running testing (gutsy) and playing with suspend (ram & disk) & resume ...
<Creteil> I hava acheived to suspend to ram properly, and also resuming from this step ...
<Creteil> This only thing blocking when the laptop resumed is the sound can't be used under gnome since the loopback interface was not up after resume.
<pkern> Hm. cryptopts=source=/dev/sda5 fixed the initramfs part, but I get another (useless) prompt later before fsck/
<Creteil> so, a simple sudo /etc/init.d/loopback stop & /etc/init.d/loopback start fix the problem
<Creteil> I just want to know if you know where i can put theses commands at resume step ?
<lamont> dear archive gods.  please accept linux-source-2.6.22 for hppa.  thanks muchly
<jdong> Creteil: /etc/acpi/resume.d should be executed on resume...
<Creteil> jdong : thanks, I'm gonna check that now ...
<ScottK> cjwatson: Thanks (for pushing wine).
<IntuitiveNipple> ScottK: Thanks for getting it working nicely on 64-bit :)
<ScottK> IntuitiveNipple: I just uploaded it.  Scott Ritchie and \sh did the work.
<IntuitiveNipple> ahhh... ok, well share the karma around :)
* IntuitiveNipple is cracking head on d-i solving non-recognition of CD drives
* lamont notices that pool/main/l/linux-meta has several -restricted-modules- debs for hppa and ia64.
<slangasek> cjwatson: the effect of bug #122281 isn't clear to me; it's true that eject-udeb still isn't in the initrd, but CD ejection seems to trigger just fine at the end of the install for me so I guess it gets pulled in post-initrd?
<ubotu> Launchpad bug 122281 in debian-installer "eject not available in the initrd" [Medium,Confirmed]  https://launchpad.net/bugs/122281
<Chris40> i am sorry i am posting here the msg , i tryed #ubuntu nobody answer there , : how can i Adding a startup script to be run at bootup ? (this is the command line i use in the terminal to load the script "nohup ./new_sockets.pl &") ?
<mpt> Chris40, if nobody in #ubuntu can help you might try asking at https://answers.launchpad.net/ubuntu
<Kmos> Chris40: use the gnome sessions
<Kmos> Chris40: menu System -> Preferences -> Sessions
<Kmos> Chris40: next time try mpt suggestion
<Chris40> does gnome sessions load the script in sudo access ?
<Lutin> no
<Chris40> so how can i load the script in sudo access on the startup (booting) ?
<Lutin> put it in /etc/rc.local
<Kopfgeldjaeger> hi
<cjwatson> slangasek: right, it should be
<cjwatson> slangasek: I've unmilestoned that bug, I'm not sure how it ended up milestoned
<cjwatson> I think it's just if you need to eject early on
<cjwatson> oh, might be different for netboot
<Mirv> Theora has beta1 release, if someone is interested. Performance has improved quite a lot, among else. Testable in debian unstable.
<stgraber> pitti: Hi, I've got a fix for the ekiga crash we currently have (when trying to make a call or receiving one), it's more or less rebuilding both libopal and ekiga (just a small patch on ekiga's configure to build against the new libpt we have). Don't know if you want that in before beta.
<pitti> stgraber: please get it both uploaded (with proper strict build-depends), I'll have a look
<pitti> stgraber: thanks for fixing it!
<stgraber> pitti: any core dev I can ping today (both opal and ekiga are main) or shall I wait tomorrow when everyone is back to work ?
<Kopfgeldjaeger> !packaging guide
<ubotu> The packaging guide is at http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html - See https://wiki.ubuntu.com/MOTU/Packages/New for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/DeveloperResources - See also !backports
<pochu> stgraber: there are some community core-devs, so you may be lucky and find one who is around and willing to sponsor you
<stgraber> LaserJock: feel like checking my debdiffs+upload ?
<pkern> ogra: ping
<MacSlow> if anybody wants to get the "genie"-effect back for the minimize-animation of compiz' animation-plugin, apply http://people.ubuntu.com/~mmueller/03_minimize_vacuum.patch to the source-package of compiz-fusion-plugins-main
<ion_> ...or just edit your personal compiz settings. ;-)
<MacSlow> ion_, no that does not work
<MacSlow> ion_, only with this patch one is able to change the minimize-animation to "Vacuum", which is the genie-effect actually
<ion_> Ok
<MacSlow> I really don't know why the compiz folks didn't leave it in
<MacSlow> it does not have to be the default and sw-patents... I have to look up that term in a dictionary :)
<cjwatson> MacSlow: that patch appears to make it the default, because the default is expressed as a number and you added it before Zoom, the previous default ...
<cjwatson> if the preferences are numeric, doesn't that mean that new items should always be added at the end?
<lambda> hi
<lambda> I am packaging a php/mysql server application
<MacSlow> cjwatson, no the order seems to be important... for some reason the animation-types of this compiz-fusion want to be ordered in alphabetical order
<cjwatson> ugh
<cjwatson> it should store defaults and such as strings then :)
<lambda> I put the sources there http://213.251.181.65//topic
<MacSlow> cjwatson, well yes... my patch makes vacuum/genie for the minimize animation the default... just a convenience for myself, since it's probably not going to be added to ubuntu or even move upstream
<mjg59> cjwatson: What would be the most sensible way of handling a situation where we want to build binary packages targetted at multiverse from a source that's in main?
<mjg59> (I fully expect the answer to be "don't")
<cjwatson> mjg59: that is indeed the answer - it's technically possible in our archive (unlike in Debian) but disallowed by policy
<mjg59> cjwatson: ffmpeg has various bits of functionality that would be helpful, but would need to be targetted at multiverse (and require additional build-depends, also not in main)
<mjg59> I guess the obvious answer is a separate multiverse source package?
<cjwatson> mjg59: yeah
<ion_> Hi BenC
<ion_> benc: Did you notice my message from yesterday?
<BenC> ion_: no
<ion_> benc: In the newest l-r-m package, nvidia_supported still doesnt contain my fix, and a line has been added to it that makes it output incorrect lines.
<ion_> benc: http://heh.fi/tmp/nvidia_supported should work.
<BenC> ion_: ok, thanks
<BenC> ion_: fix uploaded
<ion_> Thanks
<ion_> Now apt-mark-sync contains ams-run: ams-run aptitude install foobar is equivalent to aptitude install foobar && apt-mark-sync aptitude all, ams-run debfoster is equivalent to debfoster && apt-mark-sync debfoster all etc.
<lamont> BenC: did you happen to drop the gcc-3.4 build-dep and usage in debian/rules, or should I chase your lrm upload?
<BenC> lamont: doh, I forgot, sorry
<BenC> yeah, follow up on that I guess
<lamont> BenC: OK
<ion_> benc: Is there a VCS branch for l-r-m yet?
<ion_> A public one, that is. :-)
<BenC> ion_: we had one, and removed it because it was too much of a pain
<ion_> Oh. :-(
<lamont> ion_: the VCS for lrm is located at http://archive.ubuntu.com/ubuntu/pool/main/l/linux-restricted-modules-2.6.22 :-)
<lamont> BenC: uploaded
<BenC> lamont: thanks
<ion_> lamont: I cant have my own branch at archive.ubuntu.com. :-P
<lamont> thank you - I was stalling on uploading last night, thinking about beta freeze..
<lamont> ion_: ppa, dude.
<lamont> ion_: 99% of the uploads are just abi bumps.  -> pain
* lamont wonders why ports doesn't seem to be seeing any of the hppa builds that have finished in the last day or so
* lamont thanks the stealth-archive-manager
<Lamego> hello
<lamont> hello
<Lamego> is anyone familiar with apt dynamic mirrors selection (https://wiki.ubuntu.com/DynamicMirrorDecisions ) ?
<Lamego> :(
<ion_> Whats so sad about dynamic mirrors selection?
<Lamego> it is sad that I am unable to get proper information about it :P
<xtknight> this is a new bug, right?  or is this somehow by design that i'm missing.. this is a daily cd from a couple days ago, i dont see anything on launchpad about it  http://xtknight.atothosting.com/images/ubiq-122pc.png
<mlankhorst> hmm.. it's really a bad idea to enable Xgl with fglrx, the xgl server dies about once every 5 minutes here, plus all the slowing down things + redraw bugs if compiz isn't used :-/
<jdong> fglrx+xgl works fine here, but I havea pretty modern r500.
<mlankhorst> as do I..
<mlankhorst> it's really a better idea to delay it slightly and hope ati will release 8.42 soon
<jdong> I disagree
<Amaranth> arg
<Amaranth> i wish mvo was around
<jdong> we can worry about 8.42 when it comes out
<jdong> for all we know it could be equally unstable
<Amaranth> We don't enable Xgl automatically when you install fglrx
<Amaranth> Xgl is in universe and must be installed manually
<mlankhorst> it does in gutsy
<Amaranth> No, you installed it
<jdong> no, you must install xserver-xgl
<Amaranth> If you install it it will start automatically
<jdong> if you just install fgrlx, Xgl does not activate
<mlankhorst> ah ok, must be from my previous attempt at xgl, then
<Amaranth> Right, Xgl has been modified in gutsy to make itself start automatically in gutsy
<Martinp23> Is there something strange going on with the hppa buildds?  I see packages there waiting for >18hrs... :S
<Amaranth> So you just install and go
<Amaranth> Martinp23: is openoffice.org trying to build? :)
<jdong> lol
<Martinp23> lol - there doesn't seem to be anything currently building
<Martinp23> https://edge.launchpad.net/ubuntu/gutsy/hppa/+builds?build_text=&build_state=building
<Amaranth> Martinp23: that says gobby started a minute ago
<geser> Martinp23: hppa started building packages some days/weeks ago
<geser> again
<Martinp23> aha I see
<geser> so no need to worry about hppa builds at the moment
<Martinp23> thanks for the explanation :)
<Le-Chuck_IT1>  Hi there, somebody knows what packages are implementing the specification https://wiki.ubuntu.com/BootLoginWithFullFilesystem
<Le-Chuck_IT1> it happened and I need to debug it a little
<mlankhorst> hm, another crash, seems xgl doesn' t like konversation :-/
<cjwatson> xtknight: please file that one as a bug
<IntuitiveNipple> cjwatson: when you get a sec, could you cast your eye over https://bugs.edge.launchpad.net/ubuntu/+source/debian-installer/+bug/143958/comments/5
<ubotu> Launchpad bug 143958 in debian-installer "Gutsy Alternate fails: cannot detect and mount CD-ROM" [Undecided,New] 
<cjwatson> IntuitiveNipple: I saw it in #ubuntu-installer backlog, thanks; it's already on my list for first thing Monday
<xtknight> cjwatson, done, Bug 144278
<ubotu> Launchpad bug 144278 in ubiquity "ubiquity reports progress of over 100 percent" [Undecided,New]  https://launchpad.net/bugs/144278
<cjwatson> thanks
<xtknight> no problem
<IntuitiveNipple> cjwatson: ok... I was mostly interested in whether the patch is appropriate... I had to dive into the d-i code at short notice :)
<cjwatson> IntuitiveNipple: list-devices is the right place to start, but I don't like this business of checking the device name
<cjwatson> IntuitiveNipple: the odd thing is that it doesn't get ID_CDROM
<cjwatson> IntuitiveNipple: and contrary to your report, ID_CDROM doesn't contradict DEVTYPE=disk - my internal CD here has both
<IntuitiveNipple> cjwatson: ahhh ok, I was wondering about that. The key seems to be that for those external IEEE1394 devices they appear as disks
<cjwatson> IntuitiveNipple: apparently the CDROM_GET_CAPABILITY ioctl fails for them
<cjwatson> which in my book makes them kind of not CD drives ;-)
<cjwatson> but I'll look into it
<cjwatson> it may be that your hack is the right answer for now
<IntuitiveNipple> Maybe there is a deeper issue then - would explain why I had the same issue on a PowerEdge server with a SCSI CD-ROM
<IntuitiveNipple> I'm going to try the same solution on that server tomorrow - it's in the garage so I don't fancy standing out in the cold right now :)
<cjwatson> IntuitiveNipple: could you put the full udevinfo for that device in the bug? you included an incomplete snippet
<IntuitiveNipple> Hmmm... let me check; I've got it on remote ssh atm, since there's big issues with the video-driver too
<cjwatson> IntuitiveNipple: oh, and also the output of 'sudo /lib/udev/cdrom_id /dev/scd0'
<cjwatson> with any luck that will display an error
<cjwatson> <cjwatson@riva ~>$ dpkg -c /mirror/ubuntu/pool/main/u/udev/udev-udeb_113-0ubuntu9_i386.udeb | grep cdrom
<cjwatson> <cjwatson@riva ~>$
<cjwatson> I blame udev
<cjwatson> oho
<IntuitiveNipple> ok... does it help to have a CD in the drive? I'm seeing nothing atm
<cjwatson> again
<IntuitiveNipple> oh.. the sr0 device isn't listed now the system is booted :(
<cjwatson> IntuitiveNipple: I'd still be interested to see what the ID_TYPE is, if you can figure out a way to get udevinfo
<cjwatson> IntuitiveNipple: but I think I know where the bug is here anyway
<IntuitiveNipple> I'm chasing it :)
<cjwatson> IntuitiveNipple: will fix now though it won't help until d-i is rebuilt (which should happen tomorrow or so)
<IntuitiveNipple> You'll love this! I got the udevinfo after reconnecting and restarting the PC, and it reports ID_CDROM=1 now!
<IntuitiveNipple> So, is this something limited to the installer environment?
<cjwatson> IntuitiveNipple: yes
<cjwatson> IntuitiveNipple: does it have ID_TYPE=cd
<cjwatson> ?
<cjwatson> or what's the ID_TYPE, otherwise
<IntuitiveNipple> hold tight - just adding it to the bug report for you
<cjwatson> IntuitiveNipple: ok, waiting
<ivoks> shouldn't mdns4_minimal [NOTFOUND=return] , in case it can't resolve, delegate resolving to dns?
<IntuitiveNipple> sorry about that; my WAP/router decided to reboot itself with factory default settings!
<IntuitiveNipple> bug report updated
<cjwatson> right, no ID_TYPE indeed
<cjwatson> IntuitiveNipple: the problem was just that the CD identification tool wasn't in the installer environment
<cjwatson> IntuitiveNipple: fix uploaded
<IntuitiveNipple> aha!
<cjwatson> thanks for the help, that probably affected a lot of SCSI CDs
<IntuitiveNipple> Nice one Colin; thank-you! I've suffered hours of stress trying to sort that one :)
<IntuitiveNipple> now all we need is the unionfs bug fix and I *might* be able to get Gutsy to install from LiveCD :)
<cjwatson> IntuitiveNipple: pkl has more locking fixes for that I think, so I'll suggest that he upload the most conservative possible set on Monday
<cjwatson> fortunately that's just linux-ubuntu-modules which is a relatively quick build
<IntuitiveNipple> Yes; the latest he uploaded seemed to help but there's also a blank-video issue that doesn't help!
<cjwatson> I get that occasionally too, I'm not sure what's going on
<cjwatson> as in nothing on the vts?
<IntuitiveNipple> Could really do with ssh server installed and started *real* early for these alpha releases :)
<cjwatson> pkgsel/include=openssh-server
<IntuitiveNipple> nope, nothing... thats with the Vaio SRX51 & SRX41 (i810) and the Acer Travelmate C104TCi (silicon motion)
<cjwatson> openssh-server starts at rc2.d/S16 nowadays
<IntuitiveNipple> is it on the LiveCDs then?
<cjwatson> no
<cjwatson> that I can't easily help you wish
<cjwatson> with
<cjwatson> you might find that disabling usplash is enouygh
<cjwatson> enough
<cjwatson> F6 to edit the kernel command line, and delete "splash"
<IntuitiveNipple> unfortunately, so far, it hasn't helped.
<cjwatson> hmm
<cjwatson> I blame the kernel :)
<cjwatson> (un-usefully)
<IntuitiveNipple> I've been trying tribe and daily builds on the Vaio's since tribe-3 and so far not had much luck, but until unionfs is finally solved it might be the affects of that
<IntuitiveNipple> Feisty installed and runs perfectly on them
<IntuitiveNipple> It's kinds of weird, because this Vaio VGN-FE41Z wouldn't play nicely with Feisty but with Gutsy it's perfect. With the SRX's it's the other way around
<cjwatson> IntuitiveNipple: getting the alternate CD working will let you rule out unionfs
<IntuitiveNipple> cjwatson: Well, with my work-around I can at least get that installed now... I suppose I should start testing the SRX's but why spoil a successful Sunday night!?
<IntuitiveNipple> I'll leave the stress for tomorrow :p
<mjg59> Amaranth: 2000 or later ATI?
<mjg59> Amaranth: fglrx has the necessary support now?
<jdong> fglrx 8.41 supports the HD2000 series....
<jdong> but however it doesn't work well with pervious generations :)
<jdong> 8.42 is supposed to support all generations equally again.
<jdong> AMD also tags 8.41 as beta-quality too
<Nafallo> jdong: what was it before? :-)
<mjg59> jdong: With indirect acceleration?
<jdong> mjg59: no, no indirect until 8.42 :)
<mjg59> Right. Hence my question.
* Nafallo would guess alpha ;-)
<jdong> Nafallo: lol at least before it worked to some degree on all cards :)
<jdong> Nafallo: 8.41 can't play fullscreen video smoothly on my x1400
<jdong> however, performance on the HD2000's is spectacular
<Nafallo> jdong: I try to stick with Intel ;-)
<jdong> Nafallo: agreed :) until we see how these new-fangled radeonhd drivers work out
<Nafallo> naah, will still stick with intel ;-)
<Kopfgeldjaeger> somebody else and me translated the rhythmbox documentation into german. can we still get it into gutsy?
<geser> Kopfgeldjaeger: I guess so, try asking during the week when everybody is here
<Kopfgeldjaeger> geser: ok, thats nice
<ScottK> Isn't there an IRC channel just for translation stuff?
* ScottK thinks so, but isn't sure.
<geser> ScottK: #ubuntu-doc perhaps?
<Amaranth> mjg59: No but it's whitelisted
<Amaranth> mjg59: and i was talking later r200 and r300
<mjg59> Amaranth: Uhm. Why did you mention 2000, then?
<Amaranth> mjg59: nvidia
<Amaranth> mjg59: and the ati ones that work with the open source stuff
<mjg59> Oh, you mean the year 2000
<mjg59> Right
<jander99> is hwdb.ubuntu.com or hardware collection in general broken?
<mjg59> Not the 2000 serise
<Amaranth> right
<mjg59> That's somewhat confusing :)
<Amaranth> hehe
<mjg59> Though I think the r200 only appeared in 2002 or so
<Amaranth> oh?
<Amaranth> i know nvidia from around 2000 works
<Amaranth> well, except for the out-of-memory stuff
<rohan> i just checked that with the latest live cd, my screen resolution is NOT correctly detected anymore - 1280x800 on intel gma 950. is this bug already known and filed anywhere ? if not, what package do i file it against ?
<jdong> rohan: I can confirm
<jdong> my 1280x800 macbook panel is detected in 1024x768
<jdong> and the displayconfig-gtk util was capable of correcting the resolution
<mjg59> rohan: xresprobe
<roha1> jdong: i got disconnected
<roha1> what did you type ?
<rohan> jdong: i mean, relating to that resolution bug
<jdong> I said my 1280x800 macbook has the same autodetect problem
<mjg59> The bug should be filed against xresprobe
<cjwatson> poppy's down - I called elmo, he's on it
<cjwatson> er poppy == upload.ubuntu.com
<Nafallo> the fqdn made so much more sense :-)
<cjwatson> back up now
<cjwatson> elmo: thanks
<geser> siretart: ^^^
<siretart> geser: thanks!
<siretart> works :)
<Kopfgeldjaeger> gn8
#ubuntu-devel 2008-09-15
<lukehasnoname> are there any mirrors for the alpha 5 x64 alternate ISO? cdimage is still giving me trouble
<cjwatson> lukehasnoname: https://launchpad.net/ubuntu/+cdmirrors is mostly releases.u.c mirrors, but I'm sure there are some in there with cdimage mirrors too
<lukehasnoname> damn, they must all be synced to the same server which does NOT have any alphas, apparently
 * TheMuso remembers his ISP mirroring alphas, but can't remember if they still do, and thinks that an Australian mirror may not be the closest geographically.
<jerem> ubuntu-fr
<jerem> oops
<MattJ> Is cdimage.ubuntu.com down intentionally?
<james_w> MattJ: http://91.189.88.34/ should get you there
<MattJ> james_w: thank you so much :)
<james_w> only some of the servers behind cdimage are down, so going directly to one that isn't works
<TheMuso> RAOF: If you thought your issue with attempting to switch a stream from hda to your USB speakers was bad, try mine. Pulseaudio completely dies when I either start pulseaudio with my USB sound card connected, or connect my USB sound card while pulseaudio is running.
<RAOF> TheMuso: Ba baw!
<TheMuso> RAOF: Damn right.
<RAOF> I guess that answers the "will 0.9.12 be in Intrepid" question.
<TheMuso> Yay! Go assertions! This is a log I'll need to send upstream.
<TheMuso> But I think I need to try alsa 1.0.18rc3 first.
<RAOF> I'd send you my alsa-source package, but the lappy don't have internets.  And it'll be trivial for you to build one yourself :)
<TheMuso> RAOF: Yeah.
<TheMuso> gah! Alsa-project.org is down.
<RAOF> I _could_ throw it up on my webspace; it's not too hard to hunt down internet for my lappy.
<TheMuso> But the ftp is still up.
<TheMuso> RAOF: nvm, the ftp part of alsa-project still appears to fucntion.
<RAOF> Yay!
<TheMuso> RAOF: BTW if you are using alsa-driver 1.0.18rc3, and attempt to change the volume of your hda device, you will get an oops. If you want to be really sure about having this resolved, I've just pulled this patch from one of the alsa dev's git trees, and can make an updated package available if you want it.
<TheMuso> RAOF: patch to fix it that is.
<RAOF> TheMuso: Hm..  Let me try that.
<RAOF> It doesn't seem to oops here?
<TheMuso> hrm
<TheMuso> it may not be for all hda cards.
<TheMuso> but it did for mine, which sent me hunting for the patch I remember seeing on the alsa dev list. :p
<RAOF> :)
<RAOF> Yeah, I don't think mine does; I'm fairly sure I'm using 1.0.18rc3, and it doesn't oops for me.
<RAOF> Yay crazy hda!
<TheMuso> Totally agree.
<TheMuso> RAOF: Ah thats right, the oops only occurs when changing S/PDIF settings.
<RAOF> Heh.  I'm not so much with the digital out.
<TheMuso> RAOF: yeah well I was just playing with elements in the mixer when it happened for me. The patch fixes it for me though. and luckily this patch is only for 1.0.18rc3, as in it doesn't affect ubuntu as it stands./
<RAOF> :)
<TheMuso> ok even the latest alsa lib and driver doesn't stop pulse from dying.
<TheMuso> Upstream goes my log.
<RAOF> You've upstreamed my underrun logs, right?
<TheMuso> RAOF: Will be doing so as well.
<soren> I always seem to forget this: Is it necessary to specify a dependency on packages with priority: required?
<laptopnenolod> no
<laptopnenolod> lets go with iceweasel
<laptopnenolod> :D
<soren> laptopnenolod: [citation needed]
<cody-somerville> bryce, When you're around, could you give me a hand with an x.org issue in Intrepid? :]
<laptopnenolod> soren, priority: required packages are provided by the base system, and are not necessary
<soren> laptopnenolod: [citation needed] :)
<laptopnenolod> soren, the debian policy manual
 * cody-somerville notes that laptopnenolod is incorrect.
 * soren sighs
 * laptopnenolod notes that he is correct, and maintains several critical debian packages (have you enjoyed lilo recently?)
<cody-somerville> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5
<laptopnenolod> cody-somerville, priority: required is effectively equivilant to essential: yes
<laptopnenolod> infact, i do not know of any packages in priority: required that are not essential: yes
<soren> laptopnenolod: Look... I know that debian policy is the source for this source of information, so just referring to that is not very helpful.
<soren> laptopnenolod: er...
<soren> s/this source/this kind/
<soren> I'm looking for a specific reference to support your claim.
<laptopnenolod> <cody-somerville> http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5
<soren> laptopnenolod: ...which doesn't mention "priority: required" at all.
<laptopnenolod> assuming that your packages are essential: yes (which they should be if they are in priority: required)
<soren> Er... No.
<laptopnenolod> er, yes
 * soren rolls eyes
<cody-somerville> laptopnenolod, In which cases would priority be set to required and essential not be set to yes?
<soren> forget it.
<laptopnenolod> Package: bash
<laptopnenolod> Essential: yes
<laptopnenolod> Priority: required
<soren> laptopnenolod: procps
<laptopnenolod> cody-somerville, exactly! as i said, they are equivilant
<laptopnenolod> soren, that is odd.
<soren> No.
<soren> It's common.
<cody-somerville> laptopnenolod, It isn't a rhetorical question. I'm honestly interested since you seem to be knowledgeable about the essential field.
<laptopnenolod> cody-somerville, apparently procps, and some others. enough to make them "common"
<laptopnenolod> cody-somerville, but AFAIK debootstrap and cdebootstrap install all packages Essential: yes, and Priority: required .. so they are functionally equivilant.
<cody-somerville> I think the reason we don't depend on Essential is to prevent an unresolvable dependency loop.
<RAOF> Except you can probably remove a priority: required package without dpkg having a screaming hissy fit?
<laptopnenolod> RAOF, yes.
<laptopnenolod> so if for whatever reason, Essential: yes is not set, then you should depend on it.
<laptopnenolod> but if it's priority: required, then it is most likely also Essential: yes
<cody-somerville> Well, regardless, I think we've established a distinction.
 * StevenK can't think of a package this is Priority: required that isn't part of the essential set
<laptopnenolod> scanning main, i only see less than 10 packages that are not Essential: yes, but Priority: required
<soren> There are 67 packages that are required, but only 25 that are essential...
<soren> So no, they're not "most likely also essential: yes".
<cody-somerville> Regardless, there is a distinction and so although laptopnenolod your answer pragmatically might be correct, it isn't technically correct - and I think soren was looking for the more technical answer.
<laptopnenolod> i'm not scanning ubuntu. i should clarify that.
<soren> cody-somerville: Quite so. Thank you.
<cody-somerville> Btw, is there a pdf version of the Debian Policy Manual anywhere?
<laptopnenolod> not that i know of
<mdke> cody-somerville: the ubuntu-policy package appears to have a pdf in it
<cody-somerville> \o/
<cjwatson> laptopnenolod: you're definitely incorrect, sorry. adduser and procps are the usual exceptions
<laptopnenolod> i believe we settled this already.
<cjwatson> it wasn't clear, and I wanted to give soren a clear answer
<cjwatson> FWIW the main purpose of required these days is to be the first stage of debootstrap, i.e. stuff that's unpacked with ar and tar the first time round
<cjwatson> for example I wanted there to be an answer from somebody else who maintains key Debian packages - I trust you use your password file ;-)
<laptopnenolod> cjwatson, i mentioned [c]debootstrap already :P
<cjwatson> (oh and of course libraries must never be Essential: yes even if they're required - Essential is *not* closed under dependency - but they're sort of an edge case since you typically versioned-dep on them)
<soren> cjwatson: Thanks very much.
<laptopnenolod> in other news, can you guys replace abrowser with iceweasel. thanks
<cjwatson> I think that would be very confusing since our firefox package is not based on Debian's iceweasel package
<cjwatson> it would imply some kind of commonality that simply isn't there
<laptopnenolod> yes :P you should work with Debian wrt packaging and tell mozcorp to go away
<cjwatson> (right now, at least)
<laptopnenolod> i haven't even seen the EULA nagbox yet. my intrepid box is at home :(
<cjwatson> the unfortunate part about telling mozcorp to go away is that history demonstrates that that means our upstream bugs will suddenly get a lot less attention :-/
<cjwatson> which is one reason it isn't a slam-dunk
<laptopnenolod> i need to upgrade my laptop to either debian lenny proper or intrepid; right now it is running a derivitive which is more of a personal sandbox... but the concepts i am playing with are definitely a lenny+1 if not lenny+2 thing. decisions, decisions :P
<laptopnenolod> also working on a shadowed source package format that says "take package from X and apply these changes to it"... definitely lenny+2 imo there
<Adri2000> so, no one wants to comment on my email about vsftpd? or is it still too early monday morning? :p
<Adri2000> err, that was for -server sorry
* cjwatson changed the topic of #ubuntu-devel to: buildds down for maintenance for some hours | alpha-5 released | archive: open, feature freeze in place | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBu
* cjwatson changed the topic of #ubuntu-devel to: buildds down for maintenance for some hours | alpha-5 released | archive: open, feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> (actually not all buildds are down; we should still have one per architecture, but the rest are being moved around)
<dalew> I have the following command "apt-get -b source linux-image-2.6.27-3-generic" which fetches and build the kernel, the issue I'm having is that I need it to build a diffferent version of the source which is modified, any ideas on how to achieve this?
<cjwatson> apt-get source (no -b), cd directory-it-gives-you, hack hack hack, debuild -b
<dalew> apt-get source linux-2.6.26
<StevenK> Intrepid uses 2.6.27
<dalew> results in "E: Unable to find a source package for linux-2.6.26"
<cjwatson> the source package is just 'linux'
<dalew> I need to use the source I have.
<cjwatson> why not just build it in the usual upstream way, then?
<dalew> because if I have to answer one question then I'm foo-bared.
<cjwatson> you could copy in the debian directory from the current source, but configs will be out of sync and you will likely have to answer questions
<dalew> I can't be prompted for any information, it has to build without any user interaction.
<cjwatson> I think we need to understand exactly what you're actually trying to achieve here
<dalew> I want to build a modified source and creaet the .deb pacakges.
<cjwatson> but apparently noninteractively; why?
<dalew> because I want the build to work on all hardware and I don't have time to learn the ububtu way.
<cjwatson> dalew: you could use make-kpkg from the package 'kernel-package', if you just need to build debs
<cjwatson> you will still need to provide usable configs, though
<dalew> with the command used to build intrpid I was asked no questions, exactly how i need it to be.
<cjwatson> dalew: do you only need to build one specific piece of modified source, or arbitrary modified source?
<dalew> the who thing.
<dalew> whole
<cjwatson> what does that mean?
<dalew> build it all.
<cjwatson> I mean, do you want to be able to build anything from 2.6.ancient through to 2.6.future, or what?
<cjwatson> or do you only care about just one version?
<cjwatson> because you really do have to provide useful configs, which need a certain amount of human attention
<dalew> I have a modified linux-2.6.26 source based on the rc5
<cjwatson> it would be much easier if you only had to care about one version
<dalew> really,  the following command asked for nothing form me "apt-get -b source linux-image-2.6.27-3-generic"
<cjwatson> yes, you said.
<dalew> that fetched the source, I already have the source I want to use.
<cjwatson> that doesn't mean we have magic integration to build arbitrary source.
<cjwatson> dalew: how about you grab the source package from here: https://launchpad.net/ubuntu/+source/linux/2.6.26-5.17 - that's the last 2.6.26 we released
<cjwatson> dalew: unpack it with 'dpkg-source -x linux_2.6.26-5.17.dsc', and copy the debian directory into your modified source
<dalew> because it will not contain my changes.
<cjwatson> dalew: then debuild -b
<cjwatson> dalew: because you're not listening to me!
<dalew> ah but I see what your getting at.
<cjwatson> dalew: copy the *debian directory*. not the whole thing.
<dalew> sec.
<cjwatson> that will include configs
<dalew> darn, many sources to pick, the first generic is acceptable?
<cjwatson> no no, those are binaries
<cjwatson> the three links at the top of that page - .orig.tar.gz, .diff.gz, and .dsc
<dalew> downloading all 3
<cjwatson> (you can actually do this with just the .diff.gz, which is less of a download, but the process is more involved because you then have to filter out changes to the kernel source itself)
<dalew> ok got all 3 files.
<dalew> extracting.
<tkamppeter> pitti, hi
<dalew> ditto'd the debian dir.
<dalew> next step in this process?
<cjwatson> 09:59 <cjwatson> dalew: then debuild -b
<dalew> gotcha.
<cjwatson> in the directory just above debian/
<dalew> http://acm.pastebin.com/d48ce1516
<dalew> which is the root source directory.
<cjwatson> you're going to have to sync up debian/config/ with your source
<dalew> how do I do that?
<cjwatson> the reason our source package builds noninteractively is that that's already been done by the maintainer
<cjwatson> you could try 'debian/rules updateconfigs' to see if it can be done automatically. Make sure that you have a backup of the source though
<dalew> when I run it it keeps deleting the debian directory.
<cjwatson> *blink*
<cjwatson> I don't see anything that would do that and it's hard to believe. debian/ is important to source packages and our code doesn't typically run around deleting it ;-)
<dalew> after the update debuild -b ran debian/rules clean and it was gone.
<dalew> started fresh extract, copy and updateconfig seems to be building now.
<cjwatson> there's no way that 'debian/rules clean' should remove debian/
<cjwatson> but try just 'debian/rules build && fakeroot debian/rules binary', then
<dalew> well I don't know which command did it but I do know it vanished.
<dalew> debuild -b seems to be working ATM
<dalew> http://acm.pastebin.com/db013864
<dalew> here's the whole session, shwoing thta it starts out there but then fails with it missing.  http://acm.pastebin.com/d3c8d1485
<NCommander> cjwatson: what package setups up autologin on the liveCD?
<cjwatson> NCommander: casper
<NCommander> cjwatson: ok, since autologin broke on the xubuntu livecd
<NCommander> (not a good thing for the CD to prompt for a username and password)
<dalew> query, what are .udeb files?
<cjwatson> dalew: that session looks like you had previously used make-kpkg or 'make deb' or something on that source tree, and it thought it was cleaning up after that
<cjwatson> dalew: udebs are micro-debs used by the installer
<cjwatson> NCommander: what display manager do you use? has this ever worked for Xubuntu?
<NCommander> cjwatson: Xubuntu uses GDM. It worked in Hardy since I used an Xubuntu liveCD to install
<dalew> ok, it's from another attempt to follow instructions that didn't give a working install, your instructions seem to be going significantly further
<cjwatson> NCommander: check /var/log/casper.log to see if there's anything interesting in there
<NCommander> Yeah, I will
<dalew> cjwatsom: thanks
<NCommander> THere is a Critical bug against this on xubuntu-meta, and a New/Unclassified one on casper
<cjwatson> dalew: no problem
<NCommander> cjwatson: any good ideas what might be causing this to go boom
<cjwatson> NCommander: nothing comes to mind; if it's just gdm then it should be the same as Ubuntu, unless your configuration file location is different or something
<NCommander> cjwatson: well, I *think* I found the problem
<NCommander> cjwatson: it looks like someone removed casper from the live seed
<NCommander> cjwatson: it should be in that seed, right?
<cjwatson> yes
<cjwatson> oh, no, it doesn't need to be
<cjwatson> NCommander: livecd-rootfs already deals with adding it
<NCommander> cjwatson: that seems to be missing too
<cjwatson> yes, of course. livecd-rootfs isn't installed on the live CD, it's what builds the live filesystem
<cjwatson> http://cdimage.ubuntu.com/xubuntu/daily-live/current/intrepid-desktop-i386.manifest says casper is on your live filesystem
<NCommander> oh
<NCommander> Thanks
<NCommander> jelmer: ping
<dalew> cjwatson: just "dpkg -i" the image and header files is all that I need to do or should I do all of the .deb files??
<cjwatson> image and header should be fine
<dalew> it made a lot of .deb files, normal?
<dalew> ok, bootable, thank you for your time.
<cjwatson> yep, it's normal that it made lots
<dalew> I can imagine how longh it takes to build on fast machine, the dual 3ghz quad core Xeon does it in no time but the screen scrolls so quickly that it's hard to read anything.
<dalew> what is the average build time?
<dalew> or is under 5 minutes considered normal?
<Koon> doko: the libnss-mdns recommend in openjdk-6 was reintroduced in 6b12~pre1-0ubuntu2, I reopened bug 261847
<ubottu> Launchpad bug 261847 in openjdk-6 "Installing openjdk-6-jre-headless pulls in dbus/avahi" [Critical,New] https://launchpad.net/bugs/261847
<dalew> cjwatson, those would be generic installations meaning any CPU or are they going to be specific to my Xeon's?
<cjwatson> dalew: they ought to be generic back to i686 (supposed to be i586 but that was a bug in our 2.6.26 configs)
<dalew> oldest I got is Pentium-D so I should be safe then.
<dalew> mistake, Celeron-D on a D915G
<dalew> still pentium 4 class
<dalew> supposrting SSE3
<NCommander> lamont: are you around?
<tjaalton> hm, are the lpia buildd's really i386's?, or can I use DEB_HOST_ARCH to determine that a package is being built on lpia?
<kelemengabor> mvo__: could you fix please bug 270035? it' only one line, but prevents the generation of the pot file
<ubottu> Launchpad bug 270035 in app-install-data-ubuntu "desktopize.sh doesn't work" [Undecided,New] https://launchpad.net/bugs/270035
<mvo__> kelemengabor: sure
<kelemengabor> thanks :)
<cjwatson> tjaalton: they're i386 under the covers, but DEB_HOST_ARCH should work anyway
<tjaalton> cjwatson: thanks
<cjwatson> Mithrandir: could you change https://code.launchpad.net/casper/trunk to point to ~ubuntu-core-dev/casper/trunk, please? (I moved the old branch out of the way due to brokenness.)
<TheInfinity> hello ... i read about the plan integrating vmware-player into hardy partner sources ... does anybody know something about the plan when this will be done?
<dalew> cjwatson, you seem very knowledgeable about ubuntu and the builds, is it possible to have a binary with multiple arches, say i386 and ppc that would work in their associated environments?
<cjwatson> dalew: we don't have any real "fat binary" support that I know of, no
<dalew> shame, it would be nice to have a single installation that works on PPC or Intel based machines.
<dalew> oh oh, cleaned up everything, thought I'd make a fresh build in a build location and it generated the header and doc packages but then failed, use the same commands verbatim.
<NCommander> cjwatson: I thought ELF supported fat binaries
<NCommander> dalew: it would be in theory possible to create a universe installation disc for PowerPC and i386/amd64 since OpenFirmware doesn't use El Torro booting
<cjwatson> NCommander: in theory I think so, but there's no distro-level support for it
<cjwatson> you would almost certainly run into issues with per-architecture files that aren't ELF objects
<broonie> IIRC one of the Debian multi-arch install images is i386/amd64/powerpc (but that's essentially just 3 netinst images glued together I believe).
<NCommander> cjwatson: multilib would help resolve that if Debian ever got around to supporting it
<cjwatson> NCommander: I think that's very optimistic, even given the basic ground level of optimism involved in assuming that multiarch will happen any time soon
<NCommander> cjwatson: Solaris has multiarch (or something similar), so its at least possible
<cjwatson> Debian's multiarch proposals is not intended to resolve any more than providing multiple trees of libraries; it doesn't even contemplate addressing multiple-architecture binaries
<NCommander> Of course, that multiarch has made it rather difficult to make a nexenta solaris-amd64 port
<cjwatson> s/ is / are /
<cjwatson> and it doesn't even start to address things like providing the completely different sets of hardware support that would be required for i386+powerpc
 * NCommander nods
<cjwatson> broonie: right, that just exploits CD layout tricks to make them all boot and then has a giant composite apt archive
<NCommander> I was just saying that multiarch would be a step in the right direction
<NCommander> cjwatson: how much do you know about the acceptance of new ports, I wanted to ask about the possibility of an offical (community supported) Solaris Ubuntu Server port
<cjwatson> we haven't done it often enough for there to be a real process
<cjwatson> by default, it would be a decision for the technical board
<NCommander> cjwatson: I guess the next question is how is the easiest way I can ask (the port already semi-exists in the form of nexenta, although it needs some clean up before it would meet Ubuntu standards w.r.t to source cleaniness)
<cjwatson> the main problem with new ports is that there *has* to be a really solid more-than-one-person commitment to keeping it going. hppa has been a problem because it lags behind and developers occasionally end up so annoyed by e-mail about it that they invest time to clean it up
<cjwatson> I don't think we should be accepting one-man-band ports
<NCommander> It already has a community
<NCommander> nexenta is based off ubuntu dapper and hardy
<NCommander> six developers, and 50+ users
<cjwatson> and they must not involve source changes that would be unacceptable in Ubuntu; that seems obvious but is perhaps worth saying
<NCommander> cjwatson: of course
<cjwatson> sure, but that only helps if they would actually be interested in developing for Ubuntu itself and qualified to do so
<cjwatson> also, 50+ users is not worth the immense investment in terms of archive space
<NCommander> cjwatson: 50+ is the debian minimin for an offical port. Just saying.
<cjwatson> small user bases like that should be done separately, IMO
<cjwatson> NCommander: that doesn't change my opinion
<NCommander> I understand.
<cjwatson> every new port adds a significant fraction to the time that the hourly archive run takes, for instance
<NCommander> Right now, I'd just ask the technical board if such a port would be acceptable (since its non-Linux), and then proceed from there on moving towards matching up with Ubuntu and then slowly working towards becoming an offical port
<cjwatson> that time is already unacceptably long
<NCommander> cjwatson: its 40 minutes * arch last time I checked
<cjwatson> no it's not
<cjwatson> never has been
<NCommander> apt-ftparchive was in that ballpark for me on a clean run ont the archive with no database files
<cjwatson> currently it takes about an hour for all architectures. But when you consider that the cron job is hourly, that's not to be sneezed at
<cjwatson> we need it to take significantly less than an hour
<cjwatson> clean run is not the normal case
 * NCommander nods
<NCommander> What takes an hour in the script to run?
<cjwatson> so at the moment I would be inclined to say that the performance problems MUST be fixed before we can add new ports.
<cjwatson> err, all sorts of things. The Soyuz developers are aware of a number of problems and several of them are high-priority
 * NCommander had no intention of instantly creating this port out of nowhere, just if Nexenta should be making moves to match Ubuntu so if/when they can be offically accepted its a fairly streamlined process
<cjwatson> apt-ftparchive itself takes about 20 minutes
<ogra> anyone familiare with mtools ? "mcopy -i imagefile.img ::file ." would copy file out of imagefile.img into $(pwd) ... is there a way to defne a secont imagefile as target ?
<ogra> *second
<liw> ogra, I don't know if mtools can do it (it might), but would it not be simpler to loop mount the image?
<ogra> liw, that would require root/sudo :)
<ogra> i'm looking for a userspace way
<ogra> sadly defining a second -i option doesnt do what i expected
<wgrant> cjwatson: Do you know how much faster NMAFA is that apt-ftparchive?
<cjwatson> ogra: mmount two images on separate drive letters?
 * ogra reads about mmount
<cjwatson> wgrant: not in terms of hard numbers, no
<Mithrandir> cjwatson: done
<cjwatson> Mithrandir: thanks
<ogra> cjwatson, hmm, seems not to work without having a mtoolsrc
<cjwatson> ogra: you could just copy out and then copy in ...
<dalew> everyone, thanx for your time, time to head out to work so enjoy.
<ogra> cjwatson, yeah, thats an option
 * dalew shakes cjwatson's hand.
<cjwatson> ogra: you can set MTOOLSRC to a local mtoolsrc file
<ogra> yeah, thats what i thought about first
<ogra> but i want a single script ...
<ogra> sadly there are no global vars i could just set
<cjwatson> export MTOOLSRC="$(tempfile)"; trap 'rm -f $MTOOLSRC' EXIT HUP INT QUIT TERM; ...
<cjwatson> can still be in a single script :)
<ogra> lol
<ogra> wow
<ogra> indeed
<cjwatson> actually possibly "rm -f ..." rather than 'rm -f ...' there. but you get the idea.
<ogra> yeah
 * ogra hugs cjwatson ... genious
<ogra> liw, the idea is that most .img files we use are vfat anyway ... i want to have a script set for any user to create and modify images without needing root
<dalew> cjwatson: was just making notes on what I've done tonight, you gave me some alternate build commands which partial was "debian/rules build" but I only copied half the line, was going to try them later and see if it gave a better build., "Konversation" doesn't seem to keep logs.
<liw> ogra, ack, for that loop mounting isn't useful, unless you only run the script on systems where you are willing to set up /etc/fstab to have the loop mount with user option
<dalew> nevermind, I found the log file.
<jelmer> NCommander, pong
<NCommander> jelmer: I was going to ask what patch system you perfer for samba4, but I found that quilt was already enabled in the build-deps so I used that to fix the build on Ubuntu
<lamont> NCommander: back home now, generally not online at 4AM.
<lamont> 6AM, OTOH
<NCommander> lamont: I was going by your /away status ;-)
<lamont> heh.  away means I either remembered to set it, or I killed the client
<lamont> or I'm back and forgot to clear it.
<NCommander> lamont: :-P
<NCommander> lamont: my question was what's the easiest way to talk to the TB about the possibility of having a community-supported solaris-* port (essentially merging nexenta's efforts into our own), since an Ubuntu Solaris server would sport powerful features like ZFS
 * lamont generally finds email to be a good way to talk to the TB
<NCommander> point me to your leaders email address ;-)
<azeem> "The Ubuntu Technical Board can be reached by email at technical-board@lists.ubuntu.com"
<mvo> soren: do you happen to know what it means when I get "virtio-net header not in first element" ?
<soren> mvo: Not off the top of my head, no. I have sort of a guess, but it doesn't make much sense, I think. Where are you seeing it?
<mvo> soren: bug 270495
<ubottu> Launchpad bug 270495 in kvm "-net user -net nic,model=virtio stoped working" [Undecided,New] https://launchpad.net/bugs/270495
<davmor2> Is there a reason for the ula in FF3?
<soren> mvo: When did this happen? What changed?
<cjwatson> davmor2: there's an extensive bug log on the subject
<davmor2> cjwatson: ah okay ta just noticed it and thought I'd check if there was a reason
<mvo> soren: it happens shortly after I boot (can't give you details, it exists when the message appears)
<soren> mvo: I mean when did it stop working?
<wgrant> Extensive doesn't quite cover it any more.
<soren> mvo: 2.6.27-3, perhaps?
<mvo> soren: I think it was not working with 2.6.27-2 too, I'm currently trying to figure out if it depends on the guest or not
<mvo> soren: I will post more information into the bugreport, I was just curious if it is something known :)
<soren> mvo: I've not stumbled upon it before, no.
<mvo> thanks!
<NCommander> siretart: you around?
<siretart> NCommander: at work.
<NCommander> siretart: when you get home, there is a bug I'd like you to review (needs to be run by -release and ScottK wanted me to ask you) cause it required a dependency change
<siretart> NCommander: what's the number?
<NCommander> siretart: https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/270200
<ubottu> Launchpad bug 270200 in gnucash "Change libgoffice dependency from 0.4 to 0.6" [Low,In progress]
<siretart> NCommander: did you already talk to thomas about this? How about filing this as a bug in debian and add a remote bugwatch on it?
<NCommander> siretart: bug is in debian, no response
<NCommander> The original bug had the watch
<NCommander> Hold on, I'll readd it
<siretart> NCommander: but I don't see why it needs a confirmation from -release?
<NCommander> siretart: I was told that since it required a change in dependencies, it required approval
<NCommander> siretart: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498775 - debian bug
<ubottu> Debian bug 498775 in gnucash "Please change the dependencies from goffice0.4 to 0.6" [Wishlist,Open]
<munckfish> cjwatson: hi. Just to let you know I'm sort of back on the PS3 trail again. I have a stable kernel build (awaiting a git pull) so hopefully I can start to follow up some of the other issues on LP soon.
<cjwatson> munckfish: cool, that's good to know
<NCommander> Launchpad won't let me add a remote bug watch
<siretart> NCommander: I don't have any objections to that if you say you tested it and can confirm that it works okay for you
<NCommander> siretart: works for me
<NCommander> siretart: would you mind commenting that, and I'll subscribe u-u-s
<siretart> NCommander: sure, go ahead
<calc> companies that serve 2MB pdf's for disaster recovery information to potentially 2mil affected customers are pretty dumb
<calc> i guess they never heard of plain text
<calc> if all customers downloaded this data which is updated twice a day they would be doing ~ 7.25TB/day transfer
<calc> needless to say their site is constantly falling over
<calc> lovely now all i'm getting is IIS error messages :\
<kwwii> asac: what are the chances of getting this patch applied to firefox for intrepid? https://bugzilla.mozilla.org/attachment.cgi?id=332569
<tseliot> seb128: I have adapted my patches so as to make it easier for upstream to adopt them. If they are accepted we will only need a really small patch to make the xrandr capplet work automagically as planned. Here's the link to the bug which you filed: http://bugzilla.gnome.org/show_bug.cgi?id=545118
<ubottu> Gnome bug 545118 in Screen resolution "should give a clue about why the settings can't be applied sometimes" [Normal,New]
<seb128> tseliot: thanks
<asac> kwwii: what bug id is that?
<tseliot> seb128: of course, if they are not accepted, I will write other patches with the non-upstream functions marked with an "ubuntu" prefix. I guess it won't take long to have a reply from upstream since feature freeze is near, right?
<seb128> tseliot: they are already feature and api frozen, code freeze is today for GNOME
<seb128> tseliot: let's wait some days for commnents and then distro patch that for intrepid
<tseliot> seb128: ok, thanks
<kwwii> asac:  https://bugzilla.mozilla.org/show_bug.cgi?id=405421
<ubottu> Mozilla bug 405421 in Widget: Gtk "Ensure our widget painting is transparent for themes that support it" [Normal,Resolved: fixed]
<NCommander> seb128: so uh, first time I ever uploaded an FTBFS on i386 :-/
<seb128> NCommander: soyuz bug
<NCommander> \o/!
<NCommander> yay for bugs
<mathiaz> seb128: hi - I've ran into bug 121341 for the python-gobject package.
<ubottu> Launchpad bug 121341 in python-support "python modules need to work during dist-upgrades" [High,Confirmed] https://launchpad.net/bugs/121341
<seb128> hey mathiaz
<mathiaz> seb128: one solution could be to switch to python-central
<mathiaz> seb128: what do you think about it ?
<seb128> mathiaz: I would prefer avoid having to do this
<asac> kwwii: do we have a ubuntu bug for this too? if so, lets milestone that for beta
<mathiaz> seb128: the other option is to fix python-support then
<cjwatson> the word "non-trivial" comes to mind
<seb128> mathiaz: the situation just sucks, pygobject is almost on sync on debian but changing debian to python-central will not be possible
<seb128> one of the active pkg-gnome member is the python-support guy and he's against python-central
<mathiaz> seb128: hm..
<seb128> and I already discussed the issue with him and he says there is no clean way to have things still working during an upgrade and he doesn't want to do that in python-support
<mathiaz> seb128: ok - I'll have to come up with another solution then..
<kwwii> asac: https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/226139 seems like the right one
<ubottu> Launchpad bug 226139 in firefox-3.0 "Firefox 3 doesn't display all GTK form widgets correctly" [Undecided,New]
<asac> kwwii: ok thanks. I'll triage it and milestone
<kwwii> asac: great, thanks
<dholbach> mathiaz: https://wiki.ubuntu.com/GetRidOfPythonCentralAndSupport :)
<mathiaz> dholbach: awesome ! :)
<mathiaz> dholbach: but that won't make it in intrepid...
<dholbach> mathiaz: no, unfortunately not
<mathiaz> dholbach: yop - and I'm currently stuck in landscape-client because of this bug... So I'll have to find a workaround this ASAP
 * lamont wonders why in the hell libgnome-desktop-dev DEPENDS on dbus
<cody-somerville> lamont, its the new fad. headers communicate to one another via dbus.
<lamont> libgnome-desktop-dev -> libgnome-desktop-2-7 -> libgconf2-4 -> libdbus-1-3 -> dbus
<lamont> which really leads to the question of why libgnome-desktop-dev Depends on libgnome-desktop-2-7, I suppose
<lamont> everything past that at least kind of makes sense
 * lamont files a bug
<jcristau> lamont: having a libfoo.so symlink without the destination would be pretty dumb
<seb128> lamont: because the actual lib is there?
<lamont> seb128: let me rephrase that... why can't I have the -dev package installed without having DBUS RUNNING?
<jcristau> the libdbus -> dbus dependency, otoh
<lamont> ah, that does make more sense
<seb128> it's a recommends
<seb128> not a depends
<seb128> don't install recommends?
<seb128> I think it's a fair recommends use
<lamont>  libgnomevfs2-0 depends on dbus (>= 0.90).
<seb128> right, that's because the gnome-vfs-daemon needs dbus to run
<james_w> bug 270500
<ubottu> Launchpad bug 270500 in dbus "libdbus-1-3 shouldn't recommend dbus, makes up a heavy minimal seed" [Undecided,New] https://launchpad.net/bugs/270500
<cjwatson> Keybuk keeps saying that upstart is going to depend on dbus eventually anyway
<lamont> seb128: so... why can't I have libgnomevfs2-dev installed on a machine that lacks dbus?
<lamont> cjwatson: I don't need upstart in this chroot
<lamont> well, maybe, I suppose
<cjwatson> upstart is in the required seed ...
<lamont> OTOH, if dbus actually _started_ it would kind of help things, I suppose
 * lamont mounts /proc :-(*
<seb128> lamont: because gnome-vfs needs dbus
<lamont> meh.  it'd be nice to be able to complile things without dbus pain
<lamont> amusingly, dbus fails to remove if you do a /etc/init.d/dbus stop first
<lamont> for the total policy-violating fail
<lamont> in any case, it'd be nice if libgnome-vfs split the library out, IMO
<seb128> lamont: libgnomevfs is deprecated and I doubt it'll get lot of changes
<lamont> seb128: ah, well, that makes it self-correcting with time.
<seb128> right
<cjwatson> dendrobates: working on bug 269040, FYI; unfortunately my first solution is slothfully slow because it starts up debconf once per task, so, err ... I'll try not to do that
<ubottu> Launchpad bug 269040 in tasksel "The tasksel task for 'Basic Ubuntu Server'  shows up on server iso" [High,Triaged] https://launchpad.net/bugs/269040
<mterry> bryce: If I were trying to start xorg on a different VT without it immediately taking over the screen, do you have advice on how to do that?  (for the known-driver case; like, what code changes I might have to make, is it possible, etc.)
<bryce> mterry: hmm
<jcristau> mterry: x can't start without ownership of the vt afaik
<mterry> jcristau: :-/  X can do stuff on a non-foreground VT, so I thought it would be possible.
<bryce> mterry: there is a -keeptty switch but sounds like that makes it reuse the current vt
<bryce> mterry: if you're up for some X hacking, I imagine it might be possible to modify it to add a switch to permit that
<mterry> bryce: Yeah, the vt related command line arguments aren't useful.  My driver has a -noswitchvt that doesn't do what it sounds like.  Stops switching on shutdown or some such
<bryce> mterry: what exactly are you aiming to do?  maybe there's another way to do it?
<mterry> bryce: Fair question.  I'm trying to make the bootup a tad smoother.  Start gdm/X on a different VT, keep usplash up, and when GDM is fully up, switch VT
<bryce> ahh
<mterry> bryce: re: X hacking, I can comment out the obvious VT switching bits in the initialization code, but the driver still seems to draw to the screen (keyboard no longer works w/o the vt switching, so I assume the console didn't switch, but driver still p0wnd my display)
<cjwatson> I didn't think that was possible. Surely the driver needs to fiddle with registers before it can know whether it's going to be able to come up.
<bryce> mterry: have you looked into the kernel modesetting stuff?
<jcristau> mterry: gdm can't be 'fully up' before you've switched vt..
<mterry> bryce: I haven't.  I'm peripherally aware of the work, but it's not ready for the drivers/codebase I'm looking at (hardy)
<bryce> mterry: keep in mind that that stuff may hit in Jaunty, which may shake up that portion of the boot process
<bryce> ah, if you're basing on hardy, yeah that won't be of use to you
<bryce> mterry: well you might want to contact the driver developers directly
<bryce> mterry: sorry, did you mention which driver you were targeting?  We can suggest a person to contact.
<mterry> bryce: The intel/psb drivers
<bryce> mterry: -psb?
<mterry> bryce: -intel and -psb, yeah
<bryce> ok, for -intel the guy to contact is Jesse Barnes at Intel
<bryce> -psb is a bit of a special case
<bryce> it's developed by tungsten graphics for intel, but I don't think they provide community support, only contract-based support
<bryce> so I'd start with Jesse; he's very knowledgeable and hopefully can indicate if it's doable at all
<mterry> bryce: OK.  Thanks for the help!
<bryce> if it is, he may also be able to help get you in contact with some -psb folks; if not, let me know and I can give you a name
<cjwatson> mterry: the claim is simply that X has hardwired assumptions that screens have been initialised before actually starting to process any X events. We're just warning you that this is a rabbit-hole. :-)
<bryce> yep
<mterry> cjwatson: When you say 'screens', you're talking about internal data objects, eh?  Those could be created in the background without actually drawing on the screen, I had thought.  But I agree it's a rabbit hole.  :(
<cjwatson> I mean the internal objects, yes
<Chipzz> !release | chipzz
<ubottu> Chipzz, please see my private message
<dendrobates> cjwatson: is it possible for me to blacklist packages in server-ship and not affect the other seeds?  soren believes not.
<theclaw> how can I prevent a package from being upgraded?
<azeem> theclaw: sounds like a #ubuntu question
<azeem> theclaw: or do you mean in the archive, not on your system?
<theclaw> azeem: okay
<slangasek> has requestsync recently lost its support for an argument specifying whether to subscribe ubuntu-archive directly or to subscribe sponsors?
 * ScottK-laptop wonders if perhaps the subscribe sponsors option ought to be the default.
<slytherin> Can anyone please tell me if gstreamer base plugins have standing freeze exception?
<slangasek> hmm, and somewhere along the line people started appending 'ubuntuX' to the version numbers of ubuntu-dev-tools
<cody-somerville> lol
<slytherin> does anyone know where can I find slomo?
<james_w> slangasek: it tries to work it out for you now
<slangasek> james_w: which can't possibly work if you're submitting the bugs by email, which is still a supported option
<slangasek> I've filed a bug and subscribed jpds to it, since he seems to have driven these changes
<james_w> yeah, I think it does the lookup on http first
<james_w> though I haven't managed to get requestsync to actually request anything for quite a while now
<slangasek> hmm. eew?
<slytherin> james_w: me too. I simply copy it's report and create a bug manually
<seb128> slytherin: slomo is on holidays I think, why?
<seb128> slytherin: gst* don't have a standing exception but I do bug fix updates usually
<slytherin> seb128: There is a bug with DVD playing which is fixed in gst plugins base. I was thinking of I should try backporting the bug if new pre releases are not getting packaged before beta freeze
<slytherin> s/of/if
<seb128> slytherin: feel free to do the backporting
<seb128> dunno what schedule they have for the next tarballs
<slytherin> seb128: The pre release tarballs are available. And slomo usually package pre releases also. Next release is on 22.
<seb128> slytherin: ok, we will probably do the updates then
<seb128> slytherin: slomo sent some mail to say he was away, I'm not sure about the details now but he should be back in the next days if I remember correctly
<slytherin> seb128: My only concern is this bug as it blocks dvd playback completely.
<slytherin> bug #260765
<ubottu> Launchpad bug 260765 in gst-plugins-bad0.10 "DVD playback does not work anymore" [Undecided,Confirmed] https://launchpad.net/bugs/260765
<seb128> slytherin: it'll be fixed before intrepid if there a patch upstream no worry
<slytherin> :-)
<slytherin> I thought fixing it before beta freeze would be nice. :-D
<mathiaz> seb128: cjwatson: I'm trying to fix bug 268838 - hence my question about python-gobject and python-central.
<ubottu> Launchpad bug 268838 in landscape-client "registrating clients doesn't work when installing the package" [High,New] https://launchpad.net/bugs/268838
<mathiaz> Another option could be to use dpkg triggers to run landscape-config after python-support trigger.
<mathiaz> Would this be considered a good option ?
<cjwatson> dendrobates: soren's right in general, although it does depend on exactly what you're trying to do
<cjwatson> dendrobates: blacklisting is usually the wrong answer ...
<cjwatson> mathiaz: ew. um, I don't know whether triggers are ordered by dependency. In principle they shouldn't need to be.
<cjwatson> mathiaz: I don't think that will work reliably, sorry
<dendrobates> cjwatson: I am just looking for a solution to the jre-headless problem and the fact that minimal now pulls in dbus and X11 libs.
<cjwatson> dendrobates: if you try to use the blacklist for that, you'll remove dbus and X libraries from the Ubuntu desktop.
<mathiaz> cjwatson: right - another solution would be to use Pre-Depends - but as you've already mentionned on friday it's not the most suitable solution.
<dendrobates> cjwatson: works for me  :)
<cjwatson> if there's no other way round it, a Pre-Depends could work in your case
<cjwatson> but you should file a bug about it saying that the need for it should be fixed
<mathiaz> cjwatson: so if fixing python-support or switching python-gobject to python-central, I'm running out of options.
<mathiaz> cjwatson: python-central *is not possible*
<cjwatson> use a Pre-Depends and swallow the pain, I guess
<slytherin> does anyone have any idea why OOo build is failing again in powerpc?
<calc> hmm networkmanager apparently doesn't like wep too much
<calc> or else my intel wifi doesn't like it :\
<slytherin> calc: probably latter. I never had problem with nm and wep
<james_w> http://www.michaeldehaan.net/?p=718
<johanbr> WEP is just broken. There's no way of telling which password/authentication method combination the AP wants.
<slangasek> calc: no problems here, iwl3945; what are you seeing?
<calc> i'm using iwl3945 and its been hard to get connected with hex code wep
<calc> but it finally came back up i thought i was going to have to install intrepid to get it to work
<nxvl> james_w: looks cool
<calc> i'm running hardy with all updates
<slangasek> james_w: so he NIH'ed FAI, and now wants to replace it? :)
<james_w> looks like it :-)
<james_w> I remember someone looking at it, but can't remember who
<slangasek> calc: oh, hardy; that's like, old
<james_w> server team I think, so that may have been a better place
<nxvl> i remember to saw that name before, nothing else
<nxvl> :D
 * slangasek wonders if the guy understands Debian well enough to even evaluate whether it's a replacement for FAI
<calc> slangasek: well it supposed to be LTS ;-)
<calc> so hopefully will work
<nxvl> slangasek: i won't bet
<calc> lol
<nxvl> rpm and deb based distros are quite different (actually way different) but there is still people thinking it's not
<slangasek> calc: yes, but you're an Ubuntu developer, one would think you'd have tested whether the LTS worked on your system before it was released instead of 5 months after ;-P
<calc> slangasek: well i don't use WEP except when i'm evacuated to davidm's house ;-)
<slangasek> heh :)
<superm1> slangasek, could you queue another DVD livefs build log?  the CD ones are finally building again, and we haven't had a functional DVD since the 2nd or so
<calc> i don't think i even have enough diskspace to build OOo on my poor little laptop
<calc> i'll have to free up space to do it
<slangasek> superm1: I'm working on getting right-sized liveCDs first; I can queue a DVD livefs build after
<superm1> slangasek, okay great thanks
<calc> is there anything special i need to load to get usb->sata to see partitions
<calc> i hooked my desktop 1tb drive up and it sees it but doesn't show partitions, etc
<slangasek> you said "it sees it" - what sees it?
<calc> i'll pastebine
<calc> http://pastebin.ubuntu.com/47210/
<calc> it does that then never shows the partitions, etc
<torkel> nxvl: we are using a bissare mix of kickstart and FAI to install on of our clusters running CentOS. Not anything I would recommend though...
<slangasek> calc: hmm, strange; normally the kernel should spit out the partition list right after that, so I don't know what's wrong
<slytherin> is anyone already working on getting bluez 4.x in intrepid? Fedora 10 is going to have it.
<slangasek> somehow it thinks it's a scsi generic device?
<calc> maybe the device is too dumb to handle 1tb drive
<slytherin> superm1: I will see if I can create some test packages.
<calc> doh!
<calc> i know why it doesn't work
<calc> it sometimes helps to turn on the power
<calc> hmm this power bar doesn't appear to work at all
<mathiaz> kirkland: which component in the installer is responsible for asking the landscape question ?
<cjwatson> mathiaz: pkgsel
<mathiaz> cjwatson: great ! thanks.
<cjwatson> mathiaz: anything particular about it?
<mathiaz> cjwatson: I was trying to figure out if the landscape-client was installed
<cjwatson> elif [ "$RET" = landscape ]; then
<cjwatson>         echo 'landscape-client landscape-client/register_system boolean true' | \
<cjwatson>                 log-output -t pkgsel chroot /target debconf-set-selections || \
<mathiaz> cjwatson: IIUC only the question is asked and then the debconf entry is set correclty."
<cjwatson>                 true
<cjwatson>         apt-install landscape-client || true
<cjwatson> fi
<cjwatson> you remember incorrectly. :)
<mathiaz> cjwatson: ok.
<cjwatson> err, U => understand
<calc> thats the first time i've tried a broken power strip
<kirkland> mathiaz: sorry, cjwatson beat me to it
<nxvl> seb128: can you point me to a doc or something on how to add something to gnome-session from CLI?
<nxvl> seb128: or a man page on the topic
<seb128> nxvl: to gnome-session? what do you mean?
<nxvl> seb128: i mean, i want to launch a program at session start
<seb128> nxvl: that's for a package or an user setting?
<nxvl> seb128: and i want to add it from a script, not from menu->system->admin->session and such
<nxvl> seb128: user setting
<nxvl> can be a package aswell
<nxvl> i din't really mind to package it
<nxvl> :D
<seb128> nxvl: ls /etc/xdg/autostart
<nxvl> mmm
<nxvl> seb128: thank you!
 * nxvl HUGS seb128 
<seb128> you're welcome
<calc> now it works... after adding power
<seb128> you can have autostart in the user .config directory too
<lool> doko: Hmm I had python-ctypes installed on a system, presumably pulled by an old package and never forced away, it doesn't get autoremoved as many packages dep on python >= 2.5 | python-ctypes; it seems to break ctypes at the moment as there's a version check between python's ctypes and ctypes'
<lool> doko: Do you think we should patch the version or let python >= 2.5 break python-ctypes to force its removal?
<mathiaz> radix: you last patch for bug 268352 is the same as the previous AFAICT.
<ubottu> Launchpad bug 268352 in landscape-client "landscape-sysinfo should have more whitespace in login output" [Low,In progress] https://launchpad.net/bugs/268352
<doko> lool: well, we should have a python2.4-ctypes,
<lool> uh how come i saw it with 2.5??
<lool> Python-Version: 2.4
<lool> I just removed the package some minutes ago as the deps allowed it (only autoremove wouldn't catch it)
 * lool wonders whether autoremove should try to remove some group of packages to see whether the deps are still satisfied by other installed ones
<lool> And mvo disconnects muarf
 * sebner asks himself if lool gets a lot of highlighting ^^
<lool> sebner: I do
<sebner> lool: doesn't it disturb you?
<lunartear> anyone having issues with lwresd listening on 127.0.0.1:953 which breaks control communcation between rndc and bind?
<Treenaks> lunartear: why are you running lwresd AND bind?
<lunartear> thats what im wondering
 * pitti waves
<lunartear> does lwresd come with base or what
<sebner> huhu pitti :D
<lool> doko: So for some reason, my /usr/lib/python2.5/ctypes/__init__.py had version 1.0.2; now that I have removed and reinstalled python-ctypes, it's 1.0.3 and I don't get version mismatch anymore (it's python2.5's ctypes)
<geser> Hi pitti
<sebner> pitti: what person do I have to annoy to get information about upstart 0.5 -> intrepid?
<lool> I wonder how this could happen, perhaps an intermittent python-cetrnal bug; this system was installed under hardy so no 2.4 -> 2.5 upgrade
<pitti> sebner: upstart is Keybuk's baby, but he is sick ATM
<pitti> hi geser
<lool> sebner: upstart dev is mostly done by Keybuk I think, and last time I heard about it it wasn't finished for intrepid
<lool> So it's jaunty material
<sebner> pitti, lool : Thx for the info :D just saw that 0.5 is out since august
<radix> mathiaz: sorry, missed your message earlier
<radix> looking now
<radix> mathiaz: the last patch puts the wrapper script into debian/ instead of into scripts/
<radix> so that it doesn't affect non-debian/ directories
<lool> slangasek: Hey can I grab you for a sec?  pigment-python is depwait on all arches because libpigment0.3-dev was installed into universe instead of main; could you promote libpigment0.3-dev to main?  It was in main in hardy, I don't really know why it was demoted; I think it was a typo when libpigment changed SONAME
<alex-weej> question
<alex-weej> sabdfl's blog about packaging in bzr... does that mean we can branch, pull changes from Ubuntu, pull remaining changes from upstream AND maintain our own changes?
<Treenaks> alex-weej: if you know your bzr-fu :)
<alex-weej> awesome!
<alex-weej> i don't like jhbuild
<alex-weej> i'd like to have a bleeding edge environment with Ubuntu tools
<james_w> alex-weej: you will be able to eventually, but not in Jaunty.
<alex-weej> james_w: what's coming in Jaunty then?
<james_w> alex-weej: for jaunty there will only be Ubuntu history, we will then work on adding the rest later
<alex-weej> ok
<alex-weej> i was thinking it would be sane to just pull from upstream's RCS, forget about packaging history
<alex-weej> but if you have some kind of plan to merge the two, rather you than me!
<james_w> alex-weej: yeah, the details of merging them are still a bit hazy, for me at least, but we've got a while before we can implement it
<alex-weej> ok cool
 * hardwire does a little dance
<Laney> How does the bzr stuff work for packages we merge from Debian? Surely then we'll only get one monolithic "debian+upstream" change?
<Laney> Actually I guess you can separate out orig.tar.gz and diff.gz changes
<ScottK> Laney: There's a long spec on the proposed change.  I suggest search the wiki. (I don't recall the url).
<james_w> Laney: yeah, when Debian changes are integrated then you will be able to get diff upstream->debian and diff upstream+debian->ubuntu
 * Laney has seen it
<Laney> james_w: That's what I wanted to know, nice!
<james_w> Laney: and obviously any other combination of diff that you want, upstream->ubuntu etc.
<Laney> sexy
<_me_> j #kernel
<Adri2000> slangasek: if you've read my email about vsftpd on ubuntu-server@, what is your release manager opinion? I've got no answer from server people on the ml so far, so I'm asking you directly :)
<slangasek> Adri2000: I'm not subscribed to ubuntu-server
<slangasek> lool: libpigment0.3-dev, libpigment0.3-5 promoted
<Adri2000> slangasek: https://lists.ubuntu.com/archives/ubuntu-server/2008-September/002231.html
<lool> slangasek: thanks
<calc> http://photos-e.ak.facebook.com/photos-ak-snc1/v312/15/64/34406965/n34406965_33948748_6629.jpg <- lovely picture of a power pole
<calc> no wonder its going to take 4-6 weeks to get power back
<lool> slangasek: How long til I give back pigment-python?  next hour?
<slangasek> lool: is it not simply dep-wait?
<NCommander>  DktrKranz BAH
<lool> Oh right, it will figure itself
<NCommander> DktrKranz: there you are, I haven't seen you on in ages
<lool> slangasek: it is yes, nm
<lool> NCommander: I thought you were typing your password on IRC
<NCommander> lool: no, I'll never type iloveftbfs onto IRC :-)
 * NCommander runs
<NCommander> DktrKranz: https://bugs.edge.launchpad.net/ubuntu/+source/asis/+bug/268260
<ubottu> Launchpad bug 268260 in music123 "GNAT 4.2 Transition Tracking Bug" [Undecided,New]
<DktrKranz> NCommander, indeed! Mostly busy with new boss and working far away from home. I hope to have more time now
<NCommander> DktrKranz: I made your work easy in bug form
<NCommander> (although its not a fun bug)
<slangasek> Adri2000: it's my opinion that ftps is fairly niche, so a fix for that needs to be balanced against the risk of any other changes included; it doesn't look too bad from 1000 feet up, anyway
<DktrKranz> NCommander, it's a shame LP is so unfair with stable relase tasks on bugs with several packages affected
<NCommander> DktrKranz: well, please upload to proposed :-)
<DktrKranz> oh... so many packages, weren't only six or seven?
<NCommander> I removed the build-dep
<NCommander> There may be some that aren't needed
<NCommander> (these were all the ones I had and tested)
<DktrKranz> in https://wiki.ubuntu.org/HardyGnatTransition, I gave a little list of pacakges which could be affected
<DktrKranz> most of them don't need to be fixed at a first glance
<Adri2000> slangasek: ok, I'll try to get server people's opinions (maybe during the meeting tomorrow, though it will be difficult for me to attend), and if they agree, I'll file the FFe request
<Adri2000> DktrKranz: hi, may I ask you to re-check the ngircd sru please? I had to upload .2 to fix another bug discovered by norsetto
<DktrKranz> Adri2000, I'm leaving right now, could you please subscribe me to it?
<DktrKranz> so I can have a look tomorrow
<Adri2000> DktrKranz: sure, thanks
 * DktrKranz moves to bed
<Adri2000> night
<jelmer> ScottK: Thanks for looking into the FTBFS for Samba4 and OpenChange
<jelmer> ScottK, I didn't have a lot of time to dedicate to this in the last few weeks.
#ubuntu-devel 2008-09-16
<Persica> Sorry, new here.  What's the deal with automount on nfs partitions?  I was told it was patched to not work on an NFS partition, but it seems to try to start just fine on my NFS root.
<Persica> However, it won't mount anything after that...
<Persica> ah well, back to hacking at it.  I guess I have to dive deeper.
<Persica> oooh, is mkdir_path trying to do a stat on the directory and not getting a nice response from automount?
<slangasek> superm1|away: so it seems we have an issue with the amd64 livefs buildd hanging whenever I try to do anything with it, I guess DVD builds are going to have to wait until someone is available to unblock this
<slangasek> (and hopefully to diagnose it)
<jdong> lpget vlc/intrepid
<hardwire> whats lpget?
<pwnguin> probably a personal script to grab changes/packages/source/bugs from launchpad
<jdong> yeah, it's a python script to scrape LP for dsc links
<jdong>  3461 files changed, 1495678 insertions(+), 1152722 deletions(-)
<jdong> boy this'll be fun.
<pwnguin> surely most of that is moved files
<wgrant> jdong: Have you asked Debian if they've had a look?
<wgrant> We're basically in sync with them now.
 * RAOF blinks at 1.4x10^6 LOC changed
<jdong> wgrant: no, I haven't.... that would be a good idea though; right now I'm just trying to gain an understanding on the extent of the work required
<wgrant> jdong: Approximately infinite.
<wgrant> Or as close as a new minor version can get to infinite.
<jdong> wgrant: yeah it looks a bit painful indeed
<jdong> nonetheless, it's this or math homework.
<jdong> well, it seems to be getting through configure....
<jdong> of course I need to go back and s/drop/rewrite/ these patches.
<ender_> I have a data alignment question. I noticed that addresses returned from malloc() are always aligned (end in 0 hex) to the processors native data type?
<ender_> Is this something I can rely upon, i.e. it will always be the case?
<ender_> Nevermind... found the answer: "The address of a block returned by malloc or realloc in the GNU system is always a multiple of eight (or sixteen on 64-bit systems)." Very cool.
<j-b> hello
<j-b> what should I tag on launchpad when a bug is fixed upstream ?
<persia> j-b: You'd want to ask that sort of question in #ubuntu-bugs in the future.  TO indicate fixed-upstream, add a bug task for the upstream project, and link it to the upstream bug that is fixed.
<j-b> persia: ok, thanks...
<j-b> persia: not going ot be fixed before 10 month then :D
<persia> j-b: Hrm?  If it's fixed upstream, and it's marked as described, it appears in the list of bugs fixed upstream.  There are a few developers that regularly review these lists, and try to pull the fixes.
<yao_ziyuan1> i just hope intrepid can have a working netboot installer
<yao_ziyuan1> because my cd burner is not currently supported by linux kernel
<persia> yao_ziyuan1: Have you tried a netboot from one of the Alpha release candidates?
<yao_ziyuan1> no
<yao_ziyuan1> but i have nightmares with netboot in hardy
<yao_ziyuan1> as it said, netboot in hardy didn't work
<persia> yao_ziyuan1: Best path to make sure it works in intrepid is to test the netboot installer from the release candidates, and report bugs.
<yao_ziyuan1> persia: are you from iran...
<persia> yao_ziyuan1: Nope.
<yao_ziyuan1> ok. i'll make a snapshot of my windows virtual machine in vbox,
<yao_ziyuan1> and then try the netboot files of intrepid in this windows vm
<yao_ziyuan1> using grub4dos
<yao_ziyuan1> is that ok?
<persia> yao_ziyuan1: Not being someone who has ever tried a netboot install from Windows, I'm not sure, but there's usually no problems with testing in virtual machines.
<yao_ziyuan1> i'm installing intrepid alpha 5 in vbox as a new vm
<yao_ziyuan1> using the alternate installer iso
<yao_ziyuan1> maybe after installation i can take a snapshot and try netboot in it
<dholbach> good morning
<TheMuso> hey dholbach
<dholbach> hiya TheMuso :)
<ion_> Hi
<dholbach> hi ion_!
<ion_> Whatâs up?
<dholbach> I'm slowly waking up :)
<dholbach> how are you doing?
<ion_> I wrote a small program that tracks computer activity; by analyzing its log i can automate a sleep diary. :-)
<ion_> http://heh.fi/tmp/idlemeter
<Q-FUNK> howdy!  could someone please look into bug #194140 ?  it's been sitting there unattended for ages.
<ubottu> Launchpad bug 194140 in cyrus-sasl2 "Dependency cycle prevents upgrade of libsasl2-2" [Undecided,New] https://launchpad.net/bugs/194140
<persia> Anyone read Russian well enough to understand whether bug #270773 is valid?
<ubottu> Launchpad bug 270773 in postgresql-8.3 "How I'm build postgres deb packages whith this patches (step by step)" [Undecided,New] https://launchpad.net/bugs/270773
<persia> -ECHANNEL
<Treenaks> persia: google translate translates it pretty ok
 * NCommander is awake!
<NCommander> TheMuso: Good mroning
<TheMuso> Hey NCommander.
<NCommander> TheMuso: can I steal you for an ack on a package (its got a dependency change, I'm already got one ack from -release, but a second one would be nice so we could finally get this uploaded)
<TheMuso> NCommander: bug number?
<NCommander> TheMuso: https://bugs.edge.launchpad.net/ubuntu/+source/gnucash/+bug/270200
<ubottu> Launchpad bug 270200 in gnucash "Change libgoffice dependency from 0.4 to 0.6" [Low,In progress]
<TheMuso> looking.
<siretart> TheMuso: since when do we require freeze exception for patches that change dependencies like that bug?
<TheMuso> siretart: thats a good question.
<siretart> according to https://wiki.ubuntu.com/FreezeExceptionProcess#Exceptions%20for%20Universe/Multiverse, we don't
<persia> I don't think it needs a freeze exception, but that specific bug probably needs several pairs of eyes, as there are historical reasons why it still uses 0.4
<TheMuso> Interesting that ScottK didn't just mark it confirmed/upload it.
<NCommander> TheMuso: he wanted a second ack
<TheMuso> Oh ok.
<NCommander> We had three testers from the gnucash team test it in addition to myself. The upgrade also resolves quite a few bugs
<NCommander> (related to PDF and fonts)
<TheMuso> NCommander: SO it works?
<Q-FUNK> what are the changed between kernel packages for 2.6.24 and 2.6.27 that are needed to get the vcons back?  evidently, yet more changes to the way fbdev modules are packaged, but which ones?  is the strategy for this documented anywhere?
<NCommander> Yeah. It gained a new bug though because it uses the GTK print system now vs. its old one
<slangasek> while you're at it, can someone fix the annoying glitch that I can only select a reconciliation date in gnucash using the calendar widget, not by entering a date string?
<NCommander> TheMuso: That bug however affects all GTK applications
<NCommander> TheMuso: and has already been reported on LP and upstream
<TheMuso> NCommander: Ok.
<TheMuso> NCommander: Ok ACK.
<TheMuso> NCommander: in the bug also.
<NCommander> TheMuso: any chance I can convience you to upload as well ;-)?
<TheMuso> NCommander: Yep I'll do that as well.
<NCommander> \o/
 * NCommander starts attacking the libtool fixs
<StevenK> Hmph
<StevenK> You know, I was looking at libtdl3-dev NBS
<NCommander> I was working on ksimus
<NCommander> If you want I'll look at another one
<StevenK> I have a whole bunch that build
<StevenK> I can upload them
<NCommander> Which ones are left
<TheMuso> Don't remind me about libltdl/libtool. :S
<NCommander> At least powerpc doesn't usually break as often as other libtool architectures TheMuso
<TheMuso> NCommander: Possibly, I haven't dug that deeply.
<NCommander> StevenK: ?
<StevenK> NCommander: Hold on
<StevenK> I looked at the list like a week ago.
<StevenK> cacao freeradius gnash guile-gnome-platform ion2 ksimus myodbc openc++ openct pacemaker php-mcrypt snort
<StevenK> That's what I currently have as not building
 * NCommander grabs cacao
<persia> I thought now that we had ion3 we didn't need ion2 anymore.
<StevenK> I have 15 here that build successfully, but I have not uploaded them, or looked at which ones need uploading.
<StevenK> Yes, ion2 has been removed
<slangasek> ion2 isn't there anymore, yes
<NCommander> Ack
<ion_> People who didnât feel like using ion3 after it became non-free probably switched to some other tiling window manager than ion2.
<NCommander> cacao is just evil
<persia> cacao is essential.  Please fix it :)
<StevenK> freeradius looks odd, since it builds, and then exits 1 from debian/rules because openssl has been pulled in somehow
<NCommander> StevenK: its a faulty test
<NCommander> StevenK: I was helping to debug it. The test it detecting a non-existant openssl linkage
<StevenK> Hah
<NCommander> I thought a patch was already uploaded to disable said test
<NCommander> Guess now
<NCommander> *not
<NCommander> Well, cacao fixed in experimental, but its a new upstream version
<NCommander> *twich*
 * NCommander looks at backporting
 * StevenK looks at which packages built
<TheMuso> NCommander: uploaded.
<NCommander> \o/
<StevenK> Oh, grumble.
<NCommander> ?
<StevenK> I suspect someone has already uploaded them
 * StevenK sighs
<NCommander> Is openjdk available?
<NCommander> StevenK: the cacao build is really quite broken
<NCommander> StevenK: anyway, the problem with freeradius is one of its build-deps on Ubuntu is built with SSL while it isn't on Debian, and thus it gets linked against openssl even though its using none of ssl's symbols
<persia> NCommander: OpenJDK hasn't been ported to powerpc at last report.
<StevenK> NCommander: I figured that
<NCommander> O_o;
<NCommander> We have a port of openjdk to m68k, but not powerpc?
<persia> (upstream would welcome patches, but won't do it without someone else getting involved)
<NCommander> WTF?
<NCommander> persia: think you can answer a license question?
<NCommander> libsnmp depends on openssl
<NCommander> libsnmp is new-style BSD license so it can be safely linked
<NCommander> Can I then take that libsnmp w/ SSL and link it against freeradius?
<liw> what's the license of freeradius?
<geser> NCommander: net-snmp is also on Debian linked with libssl
<persia> NCommander: I'm willing to offer an opinion, but no warranty that said opinion is meaningful in any given jurisdiction, no assurance that said opinion represents informed counsel, nor does my granting of an opinion imply that it matches the opinions of the archive-administrators.
<geser> but in Debian "-lsnmp" doesn't get translated to "/usr/lib/libsnmp.so -lcrypto" during build but only to "/usr/lib/libsnmp.so"
<geser> during the build by libtool
<NCommander> On Ubuntu the pc file pulls into openssl
<slangasek> hit the .pc file with a hammer?
<persia> NCommander: My opinion is that you can't link it.
 * NCommander likes slangasek's suggest
<geser> liw: the main binary seems to be GPLv2 and the plugins LGPL
<NCommander> persia: which is mine too, but I wanted a second opinion
 * NCommander notes openssl is evil
<NCommander> evil like pie
<NCommander> or cake :-P
<liw> openssl is lethal to diabetics?
<NCommander> I was thinking more that you can never just take one slice of pie
<NCommander> It just sits there taunting you
<NCommander> Daring you to eat it
<NCommander> And when you do. BAMN, 20 pounds of fat you didn't have before
<yao_ziyuan1> seems the intrepid netboot installer can't respond well to network problems
<yao_ziyuan1> in the stage "Loading additonal components",
<yao_ziyuan1> i paused the vm and saved its state and closed virtualbox
<yao_ziyuan1> and then restarted the host machine (ubuntu 8.04 + kde 4.1.1)
<yao_ziyuan1> and then restored the vm
<yao_ziyuan1> now the netboot installer stalls at "Retriving crypto-modules-2.6.27-generic-di" (4%) forever
<yao_ziyuan1> i have to restart the netboot process
<yao_ziyuan1> i remember gutsy's netboot installer can give me a Retry button when it fails to download a package
 * NCommander sees if libsnmp will link against gnutls
<yao_ziyuan1> so i wonder why such good behaviors are not inherited by hardy's and intrepid's netboot
<yao_ziyuan1> hoho,
<yao_ziyuan1> it does provide a Retry dialog!
<yao_ziyuan1> good.
<yao_ziyuan1> i intentionally disabled the network interface of this virtual machine.
<NCommander> I think this is a serious bug, due to libsnmp linking against openssl
<NCommander> slangasek & StevenK: So it seems freeradius has been indirectly linking to openssl for years ....
<slangasek> not in Debian; I don't know about in Ubuntu
<NCommander> slangasek: libsnmp in debian is linked to libssl
<NCommander> And the changelog puts that change in '05 if not earlier
<slangasek> hmm.
<slangasek> I don't think the freeradius maintainers were aware of that, then
<NCommander> YEah
<NCommander> Since they have an explicate check for freeradius to see if it was linked against openssl
<NCommander> A change in the Ubuntu snmp caused freeradius to pull in the -lcrypto linking flag
<NCommander> (for some reason -lcrypto wasn't in the pc before for libsnmp)
 * slangasek mutters about Libraries.private
<slangasek> or Libs.private, or whatever
<NCommander> yeah
<AnAnt> Hello, is there anything I should add to this bug 269855
<ubottu> Launchpad bug 269855 in sl-modem "Please apply patch to fix issue with Si3054 modems" [Undecided,New] https://launchpad.net/bugs/269855
<NCommander> And since libssl didn't get pulled in since it wasn't directly linked
<NCommander> No lintian warning bells went off
<AnAnt> is Ian Jackson here ?
<wgrant> Doesn't look like it.
<persia> AnAnt: Frequently, unless there is a specific reason you need a specific person, you'll get a better response asking the question generally.
<AnAnt> persia: I did
<geser> NCommander: where did you find a .pc file for libsnmp?
<NCommander> geser: during my debugging
<NCommander> Although I don't seem to having it now in pkgconfig
 * NCommander grumbles
<NCommander> WOOOOO
<NCommander> I got a two-for-one license issue today
<NCommander> net-snmp is missing the openssl notifications in their copyright
<slangasek> huh? why should they have them?
<doggymenz> It is very important that Adobe Flash gets updated from -beta to -rc, and that VLC gets updated from 0.8.6 to 0.9.2 before the release of 8.10 Ibex
<NCommander> slangasek: clause six of the openssl license
<doggymenz> the -beta version of Flash is horrible slow in fullscreen mode, and has crappy performance, this is fixed in the -rc
<NCommander> http://paste.ubuntu.com/47375/ - how's that look? (I just want to make sure I'm not misexplaining the issue)
<slangasek> NCommander: net-snmp is not a redistribution of OpenSSL.
<NCommander> It includes bits of openssl via linking
<NCommander> To me thats redistribution "of any form whatsoever"
<slangasek> not copyrightable bits.
 * NCommander just caught a nice typo in his bug email
<NCommander> Hrm
<wgrant> doggymenz: What is so critical about breaching FeatureFreeze for vlc 0.9.2?
<NCommander> In that case, then freeradius can safely indirectly link to openssl, although net-snmp still needs the adversing notice as per section 3: http://openssl.org/source/license.html
<doggymenz> wgrant, the 0.9 branch is the long awaited update of VLC 0.8 branch, it brings much new stuff
<wgrant> doggymenz: It is well past feature freeze.
<slangasek> no, freeradius can't safely indirectly link to openssl; the GPL requires that when you ship a binary, the source to "all modules it contains" be made available under the terms of the GPL
<doggymenz> :(
<doggymenz> wgrant, ok, but flash can get new version?
<wgrant> "It has some new buggy features" doesn't sound like a very compelling reason to update to a new version.
<NCommander> slangasek: ok, let me fix my reasoning then
<wgrant> Flash I'm not sure about.
 * NCommander bows down to slangasek's expert knowledge of licenses
<slangasek> and this has long been intepreted in Debian as meaning that GPL apps can't dynamically link against GPL-incompatible libs within the archive
<slangasek> s/licenses/Debian traditions/...
<NCommander> I knew they couldn't do that directly, but I didn't know for sure via an indirect linkage
 * NCommander fixs his email up
<asac> anyone sees a reason why devscripts shouldnt have ca-certificates in Recommends?
<slangasek> why /should/ it have it?
<slangasek> what does devscripts have in it that cares about SSL?
<asac> slangasek: dget from launchpad
<NCommander> slangasek: http://paste.ubuntu.com/47378/ - would you mind looking this over to make sure I haven't missed anything important?
<asac> slangasek: bug 247157
<ubottu> Launchpad bug 247157 in ubuntu-dev-tools "dget/dgetlp should have ca-certificates in their Recommends field." [Wishlist,Fix released] https://launchpad.net/bugs/247157
<slangasek> NCommander: sorry, I don't really have time to right now
<NCommander> ah, it
<NCommander> s/it/ok/g
<slangasek> asac: that's filed against ubuntu-dev-tools though, not devscripts?
<asac> slangasek: no its against both
<asac> slangasek: ubuntu-dev-tools task is fixed. devscript has still a pending patch
<asac> which i planned to sponsor ;)
<slangasek> asac: ah.  well, I would argue that relying on LP SSL to verify .dsc files is the wrong trust model
<asac> slangasek: i think the idea is that you can easily dget from launchpad links
<slangasek> sure you can
<NCommander> dsc files already have a GPG signature, why can't you simply verify it?
<asac> (not to verify, but just to make it the https:// links work)
<slangasek> er, there are ways to make https:// work without pulling in the certificates, though?
<NCommander> dget uses curl or wget internally, wget has --ignore-certificates (or something like that)
<NCommander> Curl probably has an equivelent switch
<asac> slangasek: yes there are. but why not make it work out of the box ;)
<slangasek> I think we should make it work out of the box, without worrying about certificate validation...
<asac> but i am not really personal affected to it. just wanted to ask if someone has real concerns
<asac> slangasek: ok. I will ask him to make dget ignore certificate problems instead then (dumping a warning maybe?)
<asac> is that an accurate reflection of what your idea is?`
<slangasek> practically speaking, this isn't an issue for desktop users; and in my devel chroots I disable recommends; so I guess I don't have a strong argument why ca-certificates /shouldn't/ be depended on, it just seems to me that it's not the simplest solution
<slangasek> asac: I think that's accurate, yes
<asac> ok thanks for your input
<asac> slangasek: you submitted a patch to NM right? what was the bug id?
<slangasek> asac: 269010
<asac> ok
<asac> slangasek: good catch
<slangasek> asac: took me much longer than it should've to actually catch it ;P
 * slangasek wanders bed-wards
<asac> yeah. but you usually wouldnt expect such a glitch ;)
<asac> slangasek: isnt freeze for a-6 today?
<slangasek> asac: yes
<asac> when you wake up?
<slangasek> yes
<asac> or now?
<slangasek> :)
<asac> good ;)
<slangasek> I milestoned this bug anyway ;)
<mvo> +7h to upload crack^Wimportant fixes
<slangasek> mvo: didn't you hear?  The Feature Freeze now also includes a Crack Freeze
<mvo> hrm, that is a real blow :)
<asac> slangasek: ok committed and pushed upstreawm
<slangasek> cheers
<asac> ogra: meister :)
<ogra> asac, dude !
<ogra> whats up ?
<asac> gÃ¶ttingen ;)
<ogra> asac, kommste ?
<asac> ogra: thats the question :) -> priv msg
<ogra> yep
<davmor2> query on todays iso image.  Why is there a listing for other that contains a file call compiz that seems to do nothing?
<davmor2> in the main Applications menu sorry ^
<mvo> davmor2: that sounds like a bug, let me fix it
<davmor2> mvo: okay cool do you want me to report so you can cross it off once fixed?
<mvo> davmor2: its already in bzr, no need to file a bug (unless you want to file one :)
<mvo> (in bzr now)
<asac> cjwatson: working on sponsoring bugs i looked at bug 258036 ... the author already updated his patch. do you want to finish this or shall I?
<ubottu> Launchpad bug 258036 in cmake "cmake creates shortcut in Applications but fails to run" [Low,In progress] https://launchpad.net/bugs/258036
<davmor2> mvo: Okay I'll leave it and write one if it's still in place for alpha 6
<cjwatson> asac: go ahead
<NCommander> asac: were you working on fixing the EULA bug in abrowser?
<asac> NCommander: i dropped a comment in bug 269795
<ubottu> Launchpad bug 269795 in ubufox "abrowser shouldn't display the EULA" [High,Triaged] https://launchpad.net/bugs/269795
<NCommander> asac: I found a patch to fix it
 * NCommander opens a bug to request firefox moved to restricted as not free software as you can't modify it freely unless you disable branding
<NCommander> Regardless of the EULA, as long as that trademark policy is in place, its not free
<NCommander> asac: er, how is it belong to ubufox, an extension can't prevent a tab from opening
<cjwatson> NCommander: may be worth noting that even the DFSG permits licences that require derived works to change their name
<cjwatson> although that apparently wasn't carried over to the Ubuntu licensing policy, but I think that was an oversight
<NCommander> cjwatson: yes, if the version in Debian changes its name
<cjwatson> NCommander: the DFSG says no such thing
<cjwatson> http://www.debian.org/social_contract point 4
<NCommander> Debian packages are built with the orig and a diff, which by definition is a modification to the original package, and in my eyes, a derived
<cjwatson> I think that is at best unclear. For a long time Apache technically required a name change on modification ...
<NCommander> The reason I state this point is because under section 4, it says that the license must allow modification of the source at build time.
<cjwatson> which firefox does
<cjwatson> look, I don't particularly like the firefox situation, but you're making an overbroad claim
<cjwatson> the obvious counterexample to the claim that every part of the upstream source must be modifiable is that you are not typically permitted to modify copyright notices
<NCommander> The way I see it is that when you build a package, you apply a diff to the original source, and then get debs from it. That from me counts as a modification.
<NCommander> and if its a modification, then the rules applying to "may require a derived work to carry a different name or version number" appears to apply
<cjwatson> that depends on how extensive the requirement to carry a different name is
<cjwatson> if it's conditional, and if that condition is extended equally to Debian (or Ubuntu) and everyone else, then it doesn't violate DFSG#8
<NCommander> Last time I checked, firefox allows no modifications without prior consent
<NCommander> clause eight is why Firefox was eventually removed from Debian in place of Iceweasel
<NCommander> They were granted a license for the trademark with the modifications to build a deb, but it was rejected due to 8 since it was Debian specific
<cjwatson> of course, the Ubuntu licensing policy explicitly states that non-code elements will be considered case-by-case
<cjwatson> when founding Ubuntu we explicitly didn't want it to descend into interminable debian-legal arguments
<cjwatson> (and non-code elements were a big issue at the time)
<NCommander> Normally I'd agree, but the trademark prevents code modifications. You can't take a firefox source package, modify it, and redistribute it legally
<NCommander> You need to disable branding in the rules, and then rename the source package to remove the trademark
<cjwatson> that is an issue and it's something I and others are trying to sort out. That doesn't mean moving it to restricted RIGHT NOW is going to help
 * NCommander backs down from doing anything
<NCommander> I trust your judgement on such matters :-)
<asac> NCommander: the source package name shouldnt be an issue
<asac> NCommander: and afaik not even the package name and the binary name can be trademarked
<asac> NCommander: its really just about the marks presented in the UI
<NCommander> asac: unless I'm mistaken, the trademark extends to the name "Firefox"
<asac> NCommander: the package name is a functional element which shouldnt be covered by trademarks. but IANAL.
<NCommander> Neither am I
<NCommander> So I shall put that aside
 * NCommander hates to sound like a zealot, but this FF **** just pisses me off
<asac> the package description might be an issue if it wrongly claims that this _is_ firefox. we are certainly open for discussion how to improve this. and actually i am working with gnewsense folks to make the package more useful even for distros that cant ship the "firefox" source
<NCommander> asac: anything I can do to help?
<ogra> how are we communicating that to our derivatives ?
<asac> NCommander: you can join #ubuntu-mozillateam and contribute ;) i dont like the idea to do radical packaging changes for intrepid, but we could certainly experiment with the packaging of our 3.1 branch
<asac> ogra: is that a question in my direction?
<NCommander> Well, I'd like to at least make icecat available via a PPA
<asac> ogra: gnewsense "firefox" dev is in my channel and we are actively working on it
<ogra> asac, well, a general one ... if a derivative team comes and uses the ubuntu CD as a base ...
<NCommander> Just because it disables non-free plugin sensing, which while for me is not important, people who want to run all free systems would apperiate it
<asac> NCommander: that can be done in a different fashion
<ogra> asac, they should know what they can do and what they cant without violating laws ...
<NCommander> asac: ?
<asac> NCommander: we have the plugin finder wizard. derivitaves can just have their own database and dont show any non-free plugin there
<asac> NCommander: it is even trivial to provide that as a service from our database
<asac> because we have the "section" in the database
<asac> so ubufox derivitaves can just pass a special plugin finder url parameter and then dont get results for non-free plugins
<NCommander> Ah, I didn't know
<asac> i am working on that topic the gnewsense too ;)
 * NCommander has never looked deep within the depths of Gecko :-)
<asac> NCommander: the other feature is available in a icecat extension
<NCommander> I thought icecat worked by modifiying the firefox source
<asac> which someone should embrace in our firefox extension packaging community
<NCommander> If its an extension, I think I'll be shocked silly
<asac> NCommander: thats how icecat works. but that isnt the smartest solution
<asac> NCommander: not all is in an extension. i presented the idea of a "free" plugin finder database to icecat developers long time ago
<asac> and also suggested that they should try to put as much as possible in an extension instead of forking upstream code
<asac> they came back to me and said they had an extension that at least covers partso f the use cases
<NCommander> I've only written IE extensions, I know nothing of NSAPI :-)
<NCommander> (expect that its probably less braindamaging)
<asac> NCommander: NSAPI != extensions
<NCommander> oh right
<asac> NSPAI == content plugins (aka flash, totem)
<NCommander> Sorry, I'm still the old school plugins == extensions
<asac> NCommander: extensions is more like writing web-pages ... just using xul
 * NCommander has bad experiences with xul
<asac> of course tricky things that want to tweak stuff in the inner guts are not that simple
<NCommander> Then again, I ran xulrunner on m68k ....
<asac> NCommander: which is a stupid idea ... without questions asked ;)
<NCommander> I had to fix a portability bug ;-)
<NCommander> asac: I take it you perfer gecko over webkit then?
<asac> NCommander: anyway. packaging extensions is simple. join #ubuntu-mozillateam and help out ;) ... i can connect you to the icecat developer and tell him that you would be happy to help getting his icecat extension into the ubuntu archvie ;)
<NCommander> I .... err ... what?
<asac> NCommander: i have no preference preference for the rendering engine part. only thing i can say that webkit never made an official/supported release
 * NCommander finds webkit somewhat unstable
<NCommander> On Linux
<asac> NCommander: its not even that it might be unstable. it doesnt have any track record of how they do stable support (read: security)
<NCommander> ah
<asac> mozilla isnt good at that. but i have yet to see that webkit is better ;)
<asac> s/good/perfect/ ;)
<NCommander> I just perfer gecko over webkit at the moment on desktops
<NCommander> although if Presto was opened up ....
<asac> for the log: i think mozilla does a good providing security updates for their products - even if its not exactly the kind of support we would like to see for their rendering engine (e.g. long term support)
<NCommander> Well, Dapper using FF 2 still which is now dead upstream
<ScottK-laptop> NCommander: 1.5
<asac> anyway. i am happy that webkit exists. that gives us competition and puts some pressure on the gecko developers
<asac> 1.5 branch is maintained by distros yes.
<NCommander> ScottK-laptop: OW
<NCommander> MY BRAIN
<NCommander> OW
<asac> but we do quite a good job imo. we didnt see any considerable regressions and are still on top of all security patches - which is a lot.
 * ScottK-laptop has a Dapper desktop upon which he uses FF every day and agrees.
<NCommander> ScottK-laptop: please backport FF3 to dapper
<NCommander> ScottK-laptop: BTW, what were you asking me on SUbversion? (I posted a fix to correct the SSL certificate issues)
<ScottK> NCommander: Thanks.  I'll have a look.
<Company> mpt: ping
<asac> ScottK: whats the status of bug 231743 ?
<ubottu> Launchpad bug 231743 in dput "dput has wrong url for REVU uploads" [Low,In progress] https://launchpad.net/bugs/231743
<asac> ScottK: for me that patch makes sense, but i am not really up-to-date with REVU and such
<persia> asac: The fix was applied in dput 0.9.2.33 in Debian.  Do we not want any of the other adjustments as well?
<persia> asac: There's what looks like a useful adjustment to support PPAs as well
<asac> persia: not sure. if we want that change i would like to upload in any case. so the contributor gets his credits. we can then still sync
<persia> I guess.  That's the right address for REVU at least.
<persia> asac: Note that the other address also works, so it's really a no-op.
<persia> Personally, I think it's pointless to do this as an Ubuntu change.
<persia> (and it's the sort of thing I count negatively when considering package uploads when doing a technical review)
<asac> persia: right but he submitted that patch quite some time ago. and its a problem in the sponsoring process that this is now more or less outdated.
<asac> persia: but ok.
<persia> asac: So?  Does it make more sense to apply now?  Considering that it has *zero* impact on operations?  You can upload it if you like.
<cjwatson> we should thank him but then do whatever the right thing is in terms of getting the actual change into Ubuntu
<asac> ok
<cjwatson> sometimes multiple people submit a patch and we don't necessarily always credit them all
<persia> Also a useful question: did it make sense to apply previously?  The last two sponsors didn't think so.
<persia> cjwatson: True.  I try to go for earliest submission for credit when sponsoring, but that's not always simple (although it simplifies reviews)
<asac> cjwatson: right. but in this case we should have pointed him to debian in _may_ :)
<cjwatson> oh, I agree
<cjwatson> I just mean that we shouldn't do the wrong thing in terms of upload purely in order to be able to give credit
<cjwatson> there are other ways to thank contributors
<asac> i fully agree. its just that it wont show up in +packages ... which appears to be a prominent place to review contributions for MOTU membership and such :)
<persia> asac: Well, no.  +packages is completely broken (and has been for over six months).
<persia> Generally, one needs to review the -changes archives.
<asac> imo that way of looking at MOTU contributions should be fixed
<asac> but until that is happened it pops up as "i dont see many contributions of you".
<asac> persia: ack+
<asac> ok i will review the debian package and ask for sync if the changes are ok
<asac> but now lunch
<cjwatson> +packages doesn't work if changes from multiple contributors are included in one upload either. It's a completely unreliable method of gauging contributions whatever way you slice it.
<persia> asac: I'll keep saying "I don't see many contributions" if I don't, but it's not always the tools to blame.  More generally, we've outgrown the ogre model, and no longer effectively have two teams.
<cjwatson> and the contributor can and should defend themselves by pointing out their contributions
<cjwatson> I don't have much sympathy for people who don't reply to that sort of thing :)
 * ogra wonders why his SD card is sometimes mounted and sometimes ignored by gvfs
<persia> Absolutely.  The instructions for application are to list some people who can give strong endorsements, and provide examples of work of which they are particularly proud.  This is rarely actually provided.
<ogra> its the same card ... but seems it depends on the phase of the moon if it gets mounted or not ... dmesg shows the proper events
<persia> ogra: I had those symptoms with an SD card under linux 2.4.  It turned out to be related to how it was unmounted last.  Could be a different problem for you, of course.
<ogra> well, gnome-volume-manager did magae it right in former releases
<ogra> gvfs doesnt it seems
<ScottK> asac: Coming back in a little late, but I think sending the change to Debian and leaving it at that is the right answer.
<ScottK> OTOH, if someone feels it's worth uploading, I wouldn't object or anything.
 * ogra starts to suspect a polkit issue ... 
<ogra> the "places" link is shown fine but gnome-mount doesnt do anything with it
<seb128_> gnome-mount -b -v -d device
<jwendell> seb128, hi! login sound is not working on intrepid. Is that a know issue?
<seb128> hey jwendell
<seb128> jwendell: yes, libcanberra requires the freedesktop sound theme which is not available yet
<jwendell> ah ok
<jwendell> seb128, will it be available in time to intrepid?
<jwendell> do you know?
<seb128> jwendell: no I don't know
<seb128> debian has it packaged but it didn't get accepted there for licensing reasons
<jwendell> hmm
<seb128> and I've been too busy to push it to ubuntu, need to look into it again
<jwendell> need some help?
<seb128> jwendell: you are welcome to try to get it uploaded to ubuntu ;-)
<jwendell> ok, will try
<seb128> jwendell: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486559
<ubottu> Debian bug 486559 in wnpp "ITP: freedesktop-sound-theme -- default fallback theme for freedesktop.org sound themes" [Wishlist,Open]
<seb128> jwendell: I think one issue is that the upstream tarball has no license texts
<psyke83> asac: hi, I got your message on the forums. Most of the activity on the forums is using guinea pigs to test the PulseAudio "PerfectSetup" configuration (bug #192888, bug #198453) and test the new RC's of Flash. Luke's doing most of the heavy lifting now that he's maintaining preview packages of PulseAudio
<seb128> jwendell: sjoerd_ might know what were the issue for debian and if somebody is working on fixing those
<ubottu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents when using libflashsupport" [High,Confirmed] https://launchpad.net/bugs/192888
<ubottu> Launchpad bug 198453 in pulseaudio "Default ALSA device must use PulseAudio, otherwise ALSA applications may fail" [Medium,Confirmed] https://launchpad.net/bugs/198453
<asac> psyke83: ok. so you are already working with Luke?
<asac> psyke83: that makes me feel better.
<ogra> asac, i still dont get why we cant just SRU flash 10 for the libflashsupport issue
<psyke83> asac: I haven't been active on IRC for a while (I'm part of the ubuntustudio dev team, so I have contact with Luke there), but I've been reporting bugs on Launchpad against his builds
<asac> psyke83: whats the idea? did you find a config for the pulseaudio alsa plugin that auto fallbacks to default behaviour for kde?
<asac> psyke83: ok. thanks for clarifying. my main concern is flash  + pulse in intrepid. so if you need backup or help there let me know - though i think that Luke is probably on top.
<psyke83> asac: I believe Daniel had some patches pending to set this behaviour, see: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-August/005301.html
<asac> ogra: for the same reason that we still have no perfect solution in intrepid
<asac> ogra: and also from what i understood crimsun the pulse plugin for alsa in hardy wouldnt be good enough anyway and would need fixes
<ogra> asac, i dont get it ... according to lennart flash10 works flawless without libflashsupport, intrepid has flash 10
<psyke83> asac: however, we can handle the situation for non-PA configs in another way, without the need for patches. We can create a wrapper script so that the PulseAudio ALSA plugins are enabled (asoundconf set-pulseaudio) only on systems where PulseAudio is actually installed
<asac> ogra: upstream people sometimes are over optimistic and dont consider real life. we have to setup the pulse audio plugin for alsa by default to make it work perfectly
<ogra> psyke83, have a look at ltsp, it does exactly that with an Xsession.d script
<asac> ogra: but if we do that we break kde.
<asac> ogra: thats why we are looking for better configs.
<norsetto> seb128: hi seb, can I query you?
<asac> ogra: and on top the pulse plugin in hardy appears to be not good enough
<asac> (for the hardy backport)
<seb128> hey norsetto, yes
<ogra> weird that we never had a prob with pulse in ltsp in gutsy :)
<ogra> (*with* libflashsupport)
<psyke83> asac: have you seen the packages in my PPA? I backported the necessary parts to get PulseAudio working acceptably in Hardy (not the newest PulseAudio, but 0.9.10)
<cjwatson> seb128 (and maybe others): does bug 202038 make sense to you?
<ubottu> Launchpad bug 202038 in casper "Disable gnome-keyring-manager in Live mode" [Undecided,New] https://launchpad.net/bugs/202038
<asac> psyke83: lets first get all the required bits into intrepid
<asac> afaik, this still hasnt happened (or am i wrong)?
<asac> ogra: my story about this is that i that recent flash 9 updates probably changed the underlying infrastructure, which then made the unmaintained libflashsupport cause deadlocks/break
<seb128> cjwatson: I guess he would like an empty gnome-keyring password by default on the livecd so users don't get prompted for gnome-keyring password the first time it's used
<asac> and nobody can figure out how to update libflashsupport (because there is no info from adobe obviously)
<ogra> asac, yeah, i remember now ...
<ogra> gutsy was flash7
<leleobhz> compiling pymedia:
<leleobhz> In file included from audio/acodec/acodec.c:31:
<leleobhz> audio/libavcodec/dsputil.h:485: error: static declaration of âlrintfâ follows non-static declaration
<leleobhz> how can i solve this?
<cjwatson> seb128: or perhaps memory reduction
<asac> ogra: yeah ... flash 9 was a huge updated. from what i can tell they shipped flash 7 engine + a completely new engine (for flash 9 aka action script 3) in the same player
<psyke83> asac: I've been investigating libflashsupport, and it cannot be fixed. If you test Adobe's original implementation of libflashsupport (OSS/ESD support), it causes crashes as well. The API seems to be buggy
<asac> psyke83: the api isnt buggy. it just changed
<asac> and nobody knows how it was changed
<ogra> psyke83, well, the flash api changed
<asac> and if its actually really ment to work
<ogra> psyke83, libflashsupport was developed for flash 7
<ogra> whith which is worked flawless
<psyke83> ogra: http://labs.adobe.com/wiki/index.php/Flash_Player:Additional_Interface_Support_for_Linux
<seb128> cjwatson: right, that too
<psyke83> you're referring to Adobe's original implementation being flawless, right?
<ogra> psyke83, right and the one lennart pulled into the pulse source tree
<ogra> we used it in gutsy in ltsp when we started to use pulse on the clients and a virutal alsa device on the server side without any probs
<ogra> but that was flash7
<psyke83> I compiled Adobe's version of libflashsupport, and tested it *without* PulseAudio. I was still experiencing the segfaults as per bug #192888. My conclusion is that the API is buggy, and the problem isn't on the PulseAudio side
<ubottu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents when using libflashsupport" [High,Confirmed] https://launchpad.net/bugs/192888
<ogra> right
<ogra> between flash 7 and 9 something changed
<ogra> on the flash sie
<psyke83> I can't speak for flash 7, but I tested the "original" library on 9 and 10 and both crash
<ogra> libflashsupport was never changed
<ogra> the code is identical to what they released with flash 7
<NCommander> seb128: morning
<ogra> lennart made some minor changes during the flash 8 times
<psyke83> ok, when I said the API was buggy, I wasn't too clear, sorry. I meant to say that the API is exposing a bug within the Flash binary (i.e. the part we can't see)
<seb128> hello NCommander
<ogra> right
<asac> psyke83: ok. lets not look back, but to the future. when do you think could we have this startup script magic for intrepid?
<NCommander> seb128: mind retrying the gtkmm builds?
<NCommander> (buildd retry gtkmm should do the trick)
<asac> psyke83: saying that libflashsupport exposed a bug in flash is like saying that a binary build against gtk 1 exposes a bug in gtk 2 ;)
<ogra> asac, having a Xsession.d script is totally trivial http://paste.ubuntu.com/47442/
<seb128> NCommander: I did half an hour ago?
<psyke83> asac: I'll try to get in touch with Luke and discuss this, and see if PA 0.9.12 deserves a FFe. No matter, I'll work on this script and let you know when I have news
<NCommander> Oh
<seb128> NCommander: and I promoted pangomm to main too, will be effective after the next publisher run and unblock the depwait
<NCommander> GUess Launchpad being screwy, it still says "gtkmm No builds attempted"
<asac> psyke83: not exactly the same, but you get the point. maybe its a bug in the flash player. but it could as well just that libflashsupport wasnt adapted to the new flash contract ;)
<asac> psyke83: why do we need a new upstream release for that?
<psyke83> asac: IMHO, we need to completely eradicate this vermin that is libflashsupport ;). That also means removing it from ia32-libs for 64bit users
<NCommander> why is libflashsupport still needed?
<psyke83> asac: we don't need a new upstream release, it's just that Luke may know more details than I, perhaps the new release fixes other issues
<NCommander> I haven't needed it since upgrading to intrepid
<cjwatson> seb128: put another way, is there likely to be any actual downside from disabling gnome-keyring on the live CD?
<ogra> the prob is that lennart will refuse to update libflashsuport even if adobe would provide fixes since he thinks flash10 works fine out of the box
<asac> psyke83: thats understood. but want to see it fixed for real ;)
<cjwatson> seb128: I suppose it would be inconvenient if you were using the live CD as a glorified ssh client in a cybercafe or something
<psyke83> ogra: flash 10 does work fine, on a properly configured PulseAudio system
<asac> psyke83: i am sure that PA might fix other issues. but i am most concerned about flash still not having proper sound everywhere ;)
<norsetto> NCommander: did you see bug 270698 ?
<ubottu> Launchpad bug 270698 in samba4 "[Intrepid] ./configure arguments need "--localstatedir=var"" [Undecided,New] https://launchpad.net/bugs/270698
<seb128> cjwatson: how would you disable it? I don't think it allows that at the moment
<ogra> psyke83, right, but hardy has 9 :)
<cjwatson> remove the dbus service? :-)
<seb128> NCommander: no build attempted, it depwait on pangomm
<NCommander> norsetto: no, I didn't
<psyke83> asac: sure, I understand. We don't need to update PulseAudio to fix Flash. All that's needed is a) to remove all traces of libflashsupport, b) update ia32-libs, and c) work on a script to set the PA ALSA plugins only when it's appropriate
<cjwatson> disable_kwallet works in much the same kind of way - it removes a file in /usr/share/services/kded/
<NCommander> norsetto: I cleared the FTBFS, made sure it installed, but beyond making sure it installed and the binaries "worked", I didn't actually try setting up a test server
<norsetto> NCommander: sure but pls. check it out, we might need to patch it
<asac> psyke83: right. my only point is that the flash fix has been dragged for much too long. so whatever is required to fix that it should be treated asap. if that happens with a new upstream version or in a distinct fashion - i dont care ;)
<seb128> cjwatson: well, I'm not sure how network-manager will react when trying to store the passphrase in gnome-keyring if gnome-keyring is not running, I didn't try that
<NCommander> norsetto: you lost me
<psyke83> ogra: realistically speaking, we're probably going to be forced to flash 10 on hardy. The latest RC is versioned as 10.0.12.10 which indicates the final release will be soon. As soon as there's a security advisory, Flash 10 will be a mandatory upgrade
<seb128> cjwatson: same for evolution (or other applications using gnome-keyring)
<asac> psyke83: can you include my nick when you approach luke on this? when i am online iwould surely like to contribute to that discussion ;)
<norsetto> NCommander: why, busy saving the lehman guys from suicide?
<psyke83> asac: sure
<seb128> cjwatson: you can try, but I would not be surprised if those display errors if gnome-keyring is not working
<NCommander> norsetto: now you REALLY lost me
<ogra> psyke83, right, thats been my intro question :) "<ogra> asac, i still dont get why we cant just SRU flash 10 for the libflashsupport issue "
<cjwatson> seb128: hmm, ok, fair enough
<cjwatson> thanks for the feedback
 * norsetto looks around for NCommander
<NCommander> ogra: when we tried that via backports, it was bad, really really bad
<NCommander> norsetto: huh?
<ogra> NCommander, because you made ral bad mistakes
<norsetto> NCommander: ah ok, I found you. What is it that you don't get?
<NCommander> ogra: I didn't do that backport, I just know that it ended badly
<NCommander> norsetto: I don't get by patching, if all you need to do is add a configure flag
<ogra> NCommander, libflashsupport *doesnt* work with libflashsupport but whoever backported it left the dependency in
<ogra> err
<psyke83> ogra: it's not so simple. If you remove libflashsupport in Hardy, then it will rely on the PA ALSA plugins, and alsa-lib/alsa-plugin would need an update due to bugs in Hardy's versions
 * NCommander blinks
<ogra> *doesnt* work with flash10
 * NCommander decides /dev/coffee is needed and lights the stove
<ogra> psyke83, right
<psyke83> ogra, in my PPA I backported alsa-lib and alsa-plugins, and it all works fine for Hardy users
<ogra> psyke83, but leaving the dep to libflashsupport in the flash10 backport was a mistake nontheless
<psyke83> in fact they were 1.0.16, not the latest version in Intrepid
<ogra> and the base of all subsequent evil :)
<NCommander> norsetto: what do you need for me?
<asac> ogra: right. but that backport was removed?
<norsetto> NCommander: oh dear ... patching like "adding the configure flags" not as "add your own patch system and add a patch in debian/patches"
<ogra> asac, yep
<psyke83> ogra, I believe it's not a dep anymore, it's libflashsupport | libasound2-plugins
<asac> afair it was an accident that that was ever pushed out
<NCommander> norsetto: yeah, /dev/coffee is needed
<ogra> asac, right
<NCommander> norsetto: As I said before, I simply cleared the FTBFS, I didn't make sure the server worked beyond making sure it installed
<ogra> asac, though i could have told the backporter about it ... my name sits as packagedr in the libflashsupport package and it would have been one mail to ask :)
<norsetto> NCommander: I understand that, but you surely are in a better position to follow that bug report up, or not?
<NCommander> norsetto: OH!
<NCommander> norsetto: now I get it
 * NCommander is right now having a ENOCAFFIENE state of mind
<asac> ogra: i could have told him too
<ogra> yeah
<ScottK> asac: Accident is probably too nice a way to put it.  It was certainly not the best considered backports decision I've ever made.
<asac> ogra: it just happens that it was approved by accident
<ogra> yeah
<asac> ScottK: well. shit happens ... i dont think its a big problem ;)
<ScottK> Yeah.
<asac> but it might indicate that there is room for improvement on how we ack backports
<ogra> nah
<ogra> and its over anyway :)
<NCommander> norsetto: http://qdb.us/224378 - I'm reminded of this for some reason
<NCommander> what the heck is with Freenode this week, its been netsplitting like nuts it seems.
<norsetto> NCommander: hehe
<NCommander> I've done that actually
<NCommander> Not my smartest moment ever
<NCommander> Oh man
<NCommander> Instead of coffee I got sludge ;.;
 * Hobbsee covers NCommander in green sludge.
 * NCommander pours his coffee on Hobbsee and watches her desolve
<Hobbsee> ewww
<psyke83> asac: I mentioned that crimsun had a patch for the alsa-plugins to fallback to ALSA, but I see in the bazaar revisions that Luke is working on a better approach. I'll have a chat with him and see what the progress is
<radix> kirkland: would you have a moment to discuss bug #270131?
<ubottu> Launchpad bug 270131 in update-manager "kubuntu hardy-kde3 upgrade to intrepid hangs" [Undecided,Invalid] https://launchpad.net/bugs/270131
<radix> I'm not sure about the hanging part, but I'm trying to debug the bit about 'ln' failing
<asac> psyke83: good. please summon me in that discussion (by naming my nick) so i lurk or read the backlog
<psyke83> TheMuso: asac wants to know how you're going to deal with the ALSA fallback for the PA ALSA plugins ;)
<NCommander> Hobbsee: coffee is never ewww. Its the life blood of millions
<psyke83> asac: I think Luke's pretty busy, so I'll fire off an e-mail and forward anything I get to you
<asac> psyke83: well. that doesnt help me if the discussion doesnt just happen now ;)
<psyke83> hehe
<asac> psyke83: feel free to CC me in that email: asac@ubuntu.com so you dont need to forward. thanks!
<psyke83> sure thing
<NCommander> ScottK: got a chance to look at the SVN backport patch?
<ScottK> NCommander: Not yet.  $ELDEST_CHILD missed the bus today so I had to drive her.  I'm kind of behind.
<NCommander> ScottK: sounds like fun. At least you didn't get sludge for coffee
<ScottK> NCommander: I was in the Navy and drank "Still here from yesterday, but it's the midwatch and I'm REALLY tired" coffee for years.  All the coffed I have now is good.
<NCommander> ScottK: rofl. That's not too bad
<NCommander> ScottK: I believe my coffee would count as a chemical weapon in some countries
<ScottK-laptop> Unless you've experienced it, you don't know.
 * NCommander poours a cup of it on the ground and watches it eat right through the bottom of this channel
<NCommander> ScottK-laptop: I've had the coffee machine hasn't been cleaned since the turn of the century coffee a few nights ago
<StevenK> NCommander: Then how does it stay in the cup?
<NCommander> StevenK: lead cup
<NCommander> (638 was our command vechile, and its coffee maker is probably older than you are)
<StevenK> Bit hot to hold
<ScottK-laptop> NCommander: If you want to play that game, I have a coffee cup here that I started 'seasoning' in 1988 (I am not making this up).
<NCommander> Crap, that coffee is older than I am
<NCommander> ScottK-laptop: I had refridgated coffee I forgot about, and when I found it when we cleaned the fridge out when we sold the house ...
<NCommander> Well
<NCommander> I didn't know coffee could mutate like that
<NCommander> The worst though is crunchy coffee
<ogra> well, hot water can revive it
<NCommander> ogra: it was hot, crunchy, coffee
<ogra> oh
<NCommander> Our MTO forgot to put a filter in I think
<NCommander> (its the only way I can guess it could happen)
<johanbr> At my previous place of work, people would sometimes come in on Monday morning and drink the coffee that had been left on the pot over the weekend.
<NCommander> It was corsiacly ground, so it floated
 * NCommander is always amazed on how bad some coffee machines get
<NCommander> When we cleaned the one out at the training center, we used vinger, and we got a black tar :-/
<NCommander> I think we ended up using something the chemical equivelent to battery acid to clean that machine out
<ScottK-laptop> Cleaning is always a mistake.  Then it has to be properly seasoned again and that can take ages.
<NCommander> ScottK-laptop: when your coffee comes out as tar vs a fluid, I think its worth cleaning
<persia> NCommander: No, that's when it's worth drinking
<ogra> now you guys made me thursty ...
 * ScottK-laptop high fives persia.
<NCommander> you like tarry coffee?
 * ogra makes some fresh coffee
 * StevenK doesn't drink coffee
 * NCommander used the emergency instant since the machine is broken it seems
<ogra> StevenK, how do you manage these 18h days without coffee o_O
<StevenK> ogra: Tea
 * broonie always has a backup cafetiere for these purposes.
<NCommander> "In case of no coffee, break glass"
<ogra> ah
<StevenK> ogra: And powdered tooth enenemal
<ogra> french press FTW
<persia> NCommander: I no longer drink coffee.  When I was a coffee drinker, my favorite preparation was to make 4 cups of espresso, boil for about 10 minutes to get rid of the excess water, and mix 2 parts with one of condensed milk.
<NCommander> persia: o_o;. You have no taste
<NCommander> ANd I mean that as taste buds
<ogra> french press with freshly grinded espresso though :)
<StevenK> persia: And how did you get a stronger hit? With a needle?
<persia> NCommander: coffee doesn't affect the taste buds: it's a smell thing.
<ogra> so it still stays liquid
<NCommander> persia: after drinking that, I would be suprised if you have any taste buds left
<ogra> having to use a spoon and to chew coffee simply isnt the right thing
<jdstrand> mvo: hi!
<NCommander> persia: maybe we should snort coffee vs drink it ...
<persia> StevenK: boil strong tea.  Mix with NaHCO3.  bake.  Boild again.  Cool.  Add dichroromethane.  mix.  Dry thouroughly.  Filter with Na2SO4.  aspirate.  finely powder.  smell gingerly.
<persia> ogra: It's very popular that way in some parts of the world.
 * _MMA_ laughs as #ubuntu-devel descends into coffee madness. :)
<NCommander> It's on topic. ubuntu development is driven by coffee
<persia> No.  It's not really ontopic :p
<jdstrand> mvo: so I have a situation where I would like to do basic authentication with https via apt. I installed apt-transport-https, but I get a 401. I check through the docs, but don't see how to set the username/password in apt.conf (this isn't a proxy). is this possible?
<StevenK> MOTUs and core-devs turn coffee/tea into packages and bug fixes.
<NCommander> StevenK: now if we could only some how turn packages and bugfixes into coffee, we'd have a self-sustaining ecosystem of coffee
<StevenK> Haha
<NCommander> I figure if we could make Ubuntu coffee, we could simply close bug #1 by converting the masses to our uber and free coffee
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/1/+text)
<mvo> jdstrand: yes, but you need to add the password into the sources.list (like deb http://user:pass@foo.com/)
 * jdstrand slaps head
<mvo> jdstrand: it may also complain (in intrepid) about the certificatio (just like firefox) if you only have a self signed one
<jdstrand> mvo: cool-- thanks!
 * jdstrand nods
<mvo> jdstrand: I would like to overcome this limitation (the password in sources.list one) but hadn't had time yet
<jdstrand> mvo: but it seems there are various knobs for that
<mvo> indeed
<jdstrand> mvo: I can chmod 600 it for now
 * mvo nods
<ion_> summon Keybuk
<ion_> Not seb128, i said Keybuk.
<seb128> ion_: ?
<ogra> ion_, focus better then
<ion_> < ion_> summon Keybuk  -!- seb128 [n=seb128@ubuntu/member/seb128] has joined #ubuntu-devel ;-)
<seb128> ah
<seb128> yeah, try again
<NCommander> Nope
<NCommander> THat just made people leave
<NCommander> Try again
* NCommander changed the topic of #ubuntu-devel to: alpha-5 released | archive: open, feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<persia> Umm.  Shouldn't that mention the soft-freeze for Alpha-6?
<NCommander> hrm
* NCommander changed the topic of #ubuntu-devel to: Development of Ubuntu (not support, not application development on Ubuntu) | alpha-5 released | archive: open, feature freeze, in soft-freeze for alpha-6 | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<persia> Maybe s/alpha-5 released/Soft freeze for Alpha-6/ ?
<persia> THat works.
<NCommander> I just wanted to remove the buildds were down message
<NCommander> since it was old
<ogra> is the freeze in effec already ?
<jdstrand> mvo: is the plan something along the lines of Acquire::http::<server> "https://<user>:<pass>@<server>"; or some such?
<jdstrand> (in apt.conf or apt.conf.d)
<persia> NCommander: https://launchpad.net/+builds shows several buildds down
<persia> (well, at least two)
<ScottK-laptop> persia: Bet the message was from when they were all dead due to bad upload.
<ScottK-laptop> Bet/But
<jdstrand> mvo: btw, user@pass in sources.list worked just great
<persia> Ah.  Yeah.  That was sorted.  There seems to have been a marked reduction in PPA buildds as well, but packages are being built.
<cjwatson> ScottK-laptop: no, lots of buildds were taken down in order to move them between datacentres
<mvo> jdstrand: I was thinking of something like /etc/apt/netrc - however I'm not sure if its flexible enough
<cjwatson> that was yesterday morning though, so yes it's fine to remove that message
<ScottK-laptop> Ah.  OK.  I thought it was from the gcc 4.3 problem last weekend.
<mathiaz> slangasek: have you started to the Alpha6 Release notes wiki page ?
<mathiaz> kirkland: ^^
<kirkland> mathiaz: thx ;-)
<mathiaz> kirkland: has update-motd been accepted into main ?
<kirkland> mathiaz: waiting on response from pitti
<kirkland> mathiaz: i believe that i have addressed his concerns in a sequence of uploads yesterday
<kirkland> mathiaz: i vetted my changes by kees, and he seemed to it looked okay
<kirkland> mathiaz: you're welcome to review them too
<kirkland> mathiaz: see the MIR bug for update-motd for detailed explanation of changes
<mathiaz> kirkland: ok - landscape-client doesn't currently installs from the -server iso because update-motd is missing.
<kirkland> mathiaz: i understand this....  and i'd push update-motd if i were an archive admin
<kirkland> mathiaz: :-)  but que sera sera
<kirkland> mathiaz: i don't see pitti or doko online at the moment
<persia> kirkland: mathiaz: https://wiki.ubuntu.com/ArchiveAdministration lists the duty schedules for the archive admins.  Today is Tuesday.
<kirkland> persia: thanks...
 * kirkland wonders if Riddell is around :-)
<persia> Now you're looking for the right person :)
<mathiaz> persia: The MIR hasn't been accepted yet.
<mathiaz> persia: IIUC we first need to get that step done and then we can bring in the archive admin team :D
<persia> mathiaz: Oh, so it's not NEW, but promotion?  Yeah, that's a smaller set of people.
<mathiaz> persia: yes - a set composed of 2 people that are both not around today.
<kirkland> persia: right, pitti raised some concerns, i think i've addressed them, would like him to review my changes and perhaps approve the MIR this time
<persia> Sorry.  I misunderstood.  I hope the link will be useful later, although pitti usually does the promotion when approving the MIR.
<cjwatson> NCommander: I can't reproduce gdm prompting at login on Xubuntu CDs. which boot option are you using?
<cjwatson> NCommander: and is this reproducible with current dailies?
<NCommander> cjwatson: default options on amd64, haven't had time to check the dailies
<tseliot> superm1: are you planning to change the names of symlinks such as /var/lib/dkms/nvidia/kernel-2.6.27-2-generic-i686 in DKMS?
<superm1> changing the name of symlinks?
<superm1> tseliot, do you want to elaborate?
<tseliot> superm1: when you build and install a module for a certain kernel a symlink such as kernel-$(uname -r)-i686 is created, right?
<tseliot> in the nvidia or fglrx directory
<superm1> right
<tseliot> superm1: you're not planning to change the name scheme of these symlinks, are you?
<tseliot> just to be sure
<superm1> not anytime soon, no
<tseliot> ok
<tseliot> superm1: there are still users who have several directories in /var/lib/dkms/nvidia from older drivers because of that bug (which I fixed) in the postinst
<tseliot> and I want to make sure that such directories are removed when a new driver is installed
<superm1> tseliot, well make sure that you check for upgrades only from broken versions when you are upgrading
<superm1> tseliot, so that this problem will conditionally eventually go away then
<tseliot> superm1: yes, sure but I would like to avoid deleting those symlinks. This is why I asked you
<tseliot> about the name schemes
<tseliot> superm1: oh, and did you send my patch to NVIDIA?
<tseliot> (nvidia-settings)
<superm1> tseliot, i brought it up to them, they haven't responded to me about it yet though
<tseliot> superm1: ok, thanks
<didrocks> ScottK: around?
<NCommander> hey lamont, are you around?
<NCommander> or anyone with a hppa box?
<ScottK-laptop> didrocks: What's up?
<didrocks> ScottK-laptop: I am trying to backport ufw to hardy (from a request on -server ML). For that, I had to backport iptables
<didrocks> I want just to be sure I have followed the process described at https://help.ubuntu.com/community/UbuntuBackports
<didrocks> current state is:
<didrocks> - I had to make a trick so that iptables compiles (and run) on hardy
<didrocks> - no change has to be done for ufw
<didrocks> the associated bug report is at https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/268931
<ubottu> Launchpad bug 268931 in iptables "Please backport ufw 0.22 from intrepid" [Undecided,Confirmed]
<NCommander> didrocks: I'm not sure iptables is elliable for backports, thats a massive change.
<mkrufky> superm1: hello
<didrocks> NCommander: yes, the backport was not straight, that's why I want to know if it's possible or not :)
<ScottK-laptop> didrocks: I'm not at all comfortable with backporting iptables.  At the very least it's have to be tested with it's rdepends and the list is long.
<superm1> hi mkrufky
<mkrufky> superm1: bug 199398 ....  i think enough time went by now... can we upload our w_scan package?  ;-)
<ubottu> Launchpad bug 199398 in debian "[needs-packaging] w_scan" [Unknown,Fix released] https://launchpad.net/bugs/199398
<mkrufky> superm1: especially considering the recent activity there... since you already did the packaging, may as well use it somewhere...
<didrocks> ScottK-laptop: for sure, is it possible to have some king of automation to test with them?
<NCommander> does anyone have hppa hardware?
<ScottK-laptop> didrocks: If you have such a thing, but AFAIK nothing currently exists.
<mkrufky> superm1: and FYI, i uploaded the latest version (with ATSC support) to bug 258479
<ubottu> Bug 258479 on http://launchpad.net/bugs/258479 is private
<mkrufky> :-/ ... thats annoying
<didrocks> ScottK-laptop: ok, so, atm, I can build it in my ppa and try to ask for volonteers ?
<soren> Do we have a preferred python templating engine? I don't see any in main at this point.
<NCommander> didrocks: we usually use the backport testing PPA
<ScottK-laptop> didrocks: Sure, but be sure to document what's tested and how so when I ask you a lot of questions, you'll have answers.
<ScottK-laptop> soren: I don't think we do.  In #debian-python I find a lot of pylons fans.
<soren> Cheetah seems to be the canonical (no pun intended) python templating engine.
<didrocks> ScottK-laptop: ok, I will take some notes
<soren> That's more of web framework, isn't it?
<ScottK-laptop> I guess.
 * soren digs Django for that sort of thing.
<ScottK-laptop> Honestly this Web 2.0 stuff hurts my brain.
 * soren chuckles
 * ScottK-laptop just updated his web site to actually use CSS, so is somewhat behind.
<soren> I'm not actually using it for any web related stuff
<ScottK-laptop> No idea then.
<soren> Err... I mean..
<soren>  I use Django for web related stuff.
<soren> ...but I don't intend to use the templating engine for web stuff. It's for VMBuilder.
<slangasek> mathiaz: it's a revolving document, https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview
* slangasek changed the topic of #ubuntu-devel to: archive: main frozen for alpha-6, feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<ScottK-laptop> NCommander: On your svn backport fix, the bug says pending test results.  Do you have any test results?
<NCommander> ScottK-laptop: hrm. I forgot I said that
<NCommander> none of the people from the backports bug have posted anything about the tests
<ScottK-laptop> OK.  Absent some test results I'm a bit reluctant to proceed.
<Riddell> kirkland: hi
<mihai81> hi, how can someone get involved in ubuntu development
<kirkland> Riddell: hiya, i was pinging you earlier, but I think I'm still waiting on pitti to approve the MIR ;-)
<persia> mihai81: There are lots of ways.  I think the simplest is to find a bug on LP that you can fix, fix it, and ask lots of questions on #ubuntu-motu until it gets released.  Repeat a few times, and you'll be an expert.
<slangasek> Riddell, ScottK-laptop: are either of you looking into the kdepim/kdesdk uninstallables by chance?
<ScottK> No, but I suppose I could look at kdepim since I TIL.  What was uninstallable?
<slangasek> http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html
 * ScottK looks
<slangasek> akonadi-kde
<ScottK-laptop> OK.
<ScottK> slangasek: I'll look at mail-spf-perl too.
<slangasek> great, thanks
<ScottK> slangasek: spf-tools-perl should be demoted to Universe.  It's not needed in Main.
<Chipzz> I was just wondering
<Chipzz> I was setting up an SSL cert
<Chipzz> and different packages manage SSL in diferent ways
<Chipzz> dovecot apparently autogenerates a key
<Chipzz> other packages do different things
<ScottK> slangasek: For libmail-spf-perl, it looks like I MIR'ed the wrong Perl module.  I wanted libnetaddr-ip-perl and I did libnet-ip-perl.  Urgh.
<slangasek> heh
<slangasek> ok, I'll demote spf-tools-perl back out, at least
<Chipzz> maybe a package ca-something could be made, which has some debconf questions; ie do you want to set up a self-signed CA, or do you want to generate a CSR
<Chipzz> which sets things up accordingly
<Chipzz> and other packages (like dovecot) could depend on that package, to generate the needed SSL certs automatically
<\sh> pitti: why do I always get "can't find source blabla" when doing BUILD=0 ./fetch-and-build for ia32-libs...and always on different packages
<slangasek> Chipzz: I believe you're describing the ssl-cert package
<Chipzz> heh
 * Chipzz slaps self
<ScottK> slangasek: For kdepim, akonadi-server needs to get into Main.  The source package, akonadi is already in Main.
<slangasek> ScottK: hey, sounds like an easy fix; promoting, thanks
<Chipzz> slangasek: anyway, there would be some bugs in those packages for not using it?
<slangasek> Chipzz: yes
<Chipzz> slangasek: ah yes, I see where the confusion comes from; even when it's generated through debconf, the name still is ssl-cert-snakeoil.pem
<ScottK> For kdepim that looks like the only issue.
<slangasek> Chipzz: well, it's still a self-signed cert with no PKI, so it is sill snake oil unless you do something more with it ;)
<Chipzz> slangasek: ah I see what the issue is:
<Chipzz> slangasek:
<Chipzz> # grep make-ssl-cert /var/lib/dpkg/info/ssl-cert.postinst
<Chipzz> make-ssl-cert generate-default-snakeoil
<Chipzz> so installing the ssl-cert package will always generate the snakeoil cert
<Chipzz> it never even asks if you want to supply the information yourself
<Chipzz> which is why I didn't know about it
<slangasek> yes, it needs to be able to work non-interactively by default
<Chipzz> why not use a debconf question with lower priority then?
<Chipzz> low enough so by default it will generate the snakeoil cert, but for admins who set the debconf threshold lower, they get asked if they want to generate a cert themselves?
<Chipzz> s/threshold/priority/
<slangasek> Chipzz: isn't that what it does?
<\sh> pitti: forget it..*grmpf* libltdl3 is now libltdl7
<mathiaz> slangasek: I'm going to upload the landscape-client package split.
<slangasek> mathiaz: o
<slangasek> k
<Chipzz> slangasek: no, the postinst unconditionally generates the snakeoil cert
<Chipzz> 19:23 < Chipzz> # grep make-ssl-cert /var/lib/dpkg/info/ssl-cert.postinst
<Chipzz> 19:23 < Chipzz> make-ssl-cert generate-default-snakeoil
<slangasek> Chipzz: if you look inside make-ssl-cert, it uses debconf to populate the contents of the certificate
<slangasek> so I don't see that we need to support asking the user if they want to generate a cert themselves; if we can ask them what to put in the cert instead, that should be just as good
<Chipzz> maybe print a message along the lines of: "a default certificate was generated for you; if you want to generate one yourself, run make-ssl-cert manually"?
<persia> No.  Non-mediated output is bad, and for many frontends, the user won't even see it.
<fbond> What are the odds we could sync python-django 1.0-1 from sid for intrepid?
<ScottK-laptop> fbond: There's already an approved Freeze Exception, but there is an existing Ubuntu diff that needs to be merged.  Just waiting on that to get done.
<fbond> ScottK-laptop: thanks.  Who's doing the merging?
<ScottK-laptop> There's an open bug on it.  I don't recall, but it's in the bug.
<fbond> Man will I be happy to have a stable Django API in the repos... :)
<luisbg> hello all
<luisbg> I have a problem with how packages get installed in a group
<luisbg> I have a package that needs to be installed after an other one (some dpkg-divert involved with a file)
<luisbg> but if both packages are installed at the same time (apt-get install A B) which happens at install time of ubuntu studio
<luisbg> it won't work properly
<luisbg> :(
<luisbg> [18:56:18] <luisbg> it is about the menu, first the package gnome-menus needs to  be installed
<luisbg> [18:56:41] <luisbg> and then the package ubuntustudio-menu that moves the original menu to .orig and replaces it with the derivative done menu
<luisbg> if both packages are installed at the same time only the studio menu is installed (and no .orig)
<luisbg> this means that if a user removes the studio-menu file, the system has no menu
<luisbg> which is not good :(
<ogra> Keybuk is alive \o/
<azeem> luisbg: didn't you just say the same in #ubuntu-motu?
<Chipzz> persia: OTOH, ssh shows the output of generating keys (so you get an indication a key is being generated), while arguably it is less usefull there (there won't be many cases where you will want to generate the ssh keys with different options); so maybe having showing the openssl output so you know a key is getting generated would be a compromise?
<Chipzz> s/having //
<luisbg> azeem: I was then recommened to ask in here
<persia> Chipzz: Maybe.  Having it display through mediated output would be better.
<Keybuk> ogra: at last! :)
<Keybuk> ogra: it has *not* been a good week
<ogra> luisbg, have a look at edubuntu-menus how you can do that without diverting
<ogra> Keybuk, at least you are alive :)
<Keybuk> ogra: I am alive *and* in Portland
<ogra> oh
<luisbg> ogra: let me check
<Nicke>  
<ogra> luisbg, though persia might tell you that setting XDG_CONFIG_DIRS is evil, it is surely classes better than using dpkg-divert
<ogra> since as you see in your current setup it breaks
<ogra> :)
<luisbg> ogra: so you change where XDG_CONFIG_DIRS looks for the menu?
<Chipzz> persia: let me put it this way. I have been using debian for over 10 years, and though I don't want to sound arrogant, I consider myself highly proficient in debian (I know a lot of stuff the average user doesn't know about). If even I missed it, how will other people find out?
<persia> Yeah, well, I wasn't advocating dpkg-diverts instead of using XDG_CONFIG_DIRS, only using DefaultMergeDirs when it was possible.
<persia> Chipzz: Right, which is why I suggest *mediated* output.  That way it actually displays in a front-end.
<persia> (or rather, can be displayed in a front-end).
<persia> If you just echo something, almost nobody will see it.
<Chipzz> slangasek just said he didn't want that
<ogra> luisbg, yeah, install a file in /etc/X11/Xsession.d that sets XDG_CONFIG_DIRS="/usr/share/ubuntustudio" and put your .menu file in tht dir
<luisbg> ogra: we use to do that and we switched for dpkg-diverts
<luisbg> but now it isnt working
<luisbg> so I do know that is a possible solution
<luisbg> ogra: thanks :)
<Chipzz> 19:40 < slangasek> Chipzz: if you look inside make-ssl-cert, it uses debconf to populate the contents of the certificate
<Chipzz> 19:41 < slangasek> so I don't see that we need to support asking the user if they want to generate a cert themselves; if we can ask them what to put in the cert instead,  that should be just as good
<slangasek> persia: you don't want debconf for this because it shouldn't be interactive; the frontends should already capture the stdout/stderr output from package installation, then it's up to the frontend to decide what to display by default...
<ogra> luisbg, well, if that doesnt work xgd is broken (or your .menu file is incorrect) :)
<ogra> *xdg
<persia> Chipzz: I read that as not wanting a question to be asked, rather than not wanting information to be available.
<luisbg> ogra: :)
<persia> slangasek: Well, OK.  Most of the front-ends don't display anything by default :)
<Chipzz> anyay, I don't want to make a big fuss about it; I know about it now; if you guys decide it should stay the way it is now, that's fine with me too. I just think it should be more discoverable.
<slangasek> even a debconf 'error' would interrupt the install process
<ogra> a note wouldnt ...
<persia> But isn't there a NEWS mechanism that lets one inform the user of stuff, which could be used to report that a certificate was generated?
<persia> Or a note?
<ogra> and you ususally have a frontend ... only if you force passthrough or noninteractive you dont
<Chipzz> (in my case it wouldn't have helped me much anyway, since I needed a CSR, and the debconf way doesn't generate one, it just generates a cert)
<slangasek> ogra: you mean the deprecated debconf note, that is approximately equivalent to an error except sometimes it will send you email instead?
<slangasek> which the user then won't receive...
<ogra> slangasek, bah another of the policy police ... :)
<Keybuk> slangasek: don't suppose you know how to change the timezone? :p
<Chipzz> but this actually brings me to another question: how do the generated certs get used anyway?
<slangasek> Keybuk: petition Congress?
<Keybuk> slangasek: just in Ubuntu ;)
<slangasek> Keybuk: dpkg-reconfigure tzdata, isn't it?
<Keybuk> let me try that
<Keybuk> ah, yes, that works
<Keybuk> thanks
<slangasek> sure
 * Keybuk remembered there being a tzconfig or something, but that seems to have gone
<slangasek> yep
<Keybuk> why did that go?
<Chipzz> since if I manually generate one, it can end up anywhere, for example outside of /etc/ssl, and I don't see how packages using ssl-cert to generate certs would find the arbitrary name I give it anyway?
<ogra> slangasek, i havent understood why 'note' was deprecated yet ... if it was buggy sending mails that should have been fixed ... but note is a valid thing imho
<slangasek> Keybuk: because tzconfig wasn't adequately debconf-y; now we have something that's too debconf-y instead
<slangasek> ogra: note was deprecated because package maintainers were abusing it to chat with users
<ogra> teach them :)
<ogra> dont remove the tool
<Keybuk> slangasek: I thought debconf *wasn't* a configuration database?
<slangasek> there is no legitimate use of the tool that isn't handled by errors
<Keybuk> ie. it wasn't a tool for modifying /etc :p
<Keybuk> is debconf now becoming a yast-a-like?
<ogra> slangasek, right, but an error will stop my install process
<slangasek> Keybuk: no one ever said it's not a tool for modifying /etc
 * Keybuk is sure joey once did, very loudly
<slangasek> Keybuk: debconf is not a *registry*, i.e., you're not allowed to treat the contents of /var/cache/debconf as authoritative
<slangasek> was that in between Manoj's exclamations that policy is not a stick to beat people with? :)
<Keybuk> I've frequently wanted a stick to beat Manoj with
<persia> policy :)
<slangasek> tsk, elder abuse
<ogra> persia, yeah, so policy makes ipossible to do what you wanted with the cert
<ogra> *impossible
<Keybuk> slangasek: it doesn't have to be elder, any kind of wood would work
<persia> ogra: I know, which makes translations hard, which makes me want to deny Chipzz's valid desire.
<ogra> because policy writers want to parent devs
<persia> ogra: no, that's not why.
<ogra> sure
<ogra> <slangasek> ogra: note was deprecated because package maintainers were abusing it to chat with users
<ogra> thast totally not a valid reason imho
<azeem> "Hi User, if you meet ogra, please tell him he still owes 5 bucks, thx"
<slangasek> if "what you wanted" was "interrupt the install and leave the user with a message sitting on their desktop asking them to click through acknowledging that an ssl cert was created", then yes, policy doesn't allow that
<slangasek> ogra: you seem to be missing the point that 'error' replaces 'note' for all the legitimate use cases :P
<ogra> azeem, yeah, good idea ... we should add that as default to cdbs :)
<persia> slangasek: No.  I just wanted a mediated exchange so it wasn't restricted to English and wasn't lost in stdout.
<ogra> slangasek, error stops my install process
<slangasek> ogra: so did a note!
<ogra> it shouldnt
<persia> I specifically didn't want to bother the user unless they were interested.
<slangasek> except in cases where it was emailed to you instead, which is equivalent to /dev/null for default Ubuntu
<ogra> it is a note about something the user should actually be made aware of
<ogra> and it should work like that
<ogra> error DTRT for an error
<jcristau> get debian/NEWS translated
<slangasek> then what you're asking for is not what the debconf note interface /ever/ did, so I don't see why you care that it was deprecated
<ogra> well, it should be fixed instead of being dropped :)
<Chipzz> couldn't notes just get queue'd, and shown in one batch at the end of the installation?
<Chipzz> (I know technically that would be hard I suppose, but just as an idea)
<ogra> well, ideally you shouldnt have notes ...
<ogra> but there are cases where they make sense
<Chipzz> lets say you install dovecot which requires ssl-cert
<Chipzz> all installation would just go ahead
<slangasek> NEWS.Debian, + apt-listchanges --which=news, + the i18n interface for NEWS.Debian that I never got around to writing would be a better solution for displaying messages unconditionally to the user
<Chipzz> and you would end up with a screen which says: "Hi, I installed dovecot successfully; ALSO, this is a note from ssl-cert..."
<Chipzz> slangasek: NEWS.Debian can't be translated though
<slangasek> Chipzz: ... "+ the i18n interface for NEWS.Debian that I never got around to writing"
<Chipzz> ah
<ogra> :)
<persia> Chipzz: It just requires the i18n interface :)
<Chipzz> slangasek: but how many developers would use that anyway?
<slangasek> all the ones that I beat with the elder stick
<ogra> only the few that actually need to make use of notes :)
<Chipzz> and on top, how many translators would bother translating that?
<slangasek> all the ones that bubulle beats with the Translation Czar stick
<Chipzz> my guess is translatable NEWS.Debian would end up in the back of the translators queue
<ogra> or just launchpad if you put it on there :)
<Chipzz> s/back of the ... queue/bottom of the pile/
<Chipzz> you get the picture :P
<slangasek> s/pile/stack/ ;P
<Chipzz> anyway, as it stands a lot of HOWTO's on the internet suggest using CA.sh
<Chipzz> and don't even mention ssl-cert
<Chipzz> but I think I've seen a similar discussion here already (about debconf notes), and I'm not getting my hopes up on it getting fixed :P
 * ogra goes to prepare dinner
<persia> Chipzz: File a bug anyway, comment on why it's hard, mark it wishlist, and maybe someone will have a good idea.
<slangasek> Chipzz: your hopes of getting which part fixed? :)
<Chipzz> the ssl-cert visibility thing :)
<Chipzz> there was some other issue too, but no-one commented on that yet :P
<Chipzz> 20:14 < Chipzz> but this actually brings me to another question: how do the generated certs get used anyway?
<Chipzz> 20:15 < Chipzz> since if I manually generate one, it can end up anywhere, for example outside of /etc/ssl, and I don't see how packages using ssl-cert to generate certs  would find the arbitrary name I give it anyway?
<slangasek> Chipzz: indeed, if you generate your own cert, you'd either have to put it in place over the snakeoil one, or modify the config of each package to use it
<Chipzz> it would need to have the snakeoil name?
<slangasek> to be seen without modifying package configs, yes
<Chipzz> I'm thinking a symlink to the snakeoil certs, and having packages use the symlinks would be more appropriate?
<\sh> slangasek: https://edge.launchpad.net/ubuntu/+source/gail just tell me what went wrong here...looks like I don't get any libgail-common installation candidate on intrepid...regarding lp it's correct ...but thinking about the buildd outputs, it's wrong
<\sh> slangasek: looks like the last autosync of gail never build or never been pushed to the archive
<\sh> slangasek: forget it ...I hate launchpad
 * \sh doesn't get it anymore..
 * slangasek eyes the new uninstallables on http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html
<persia> slangasek: Why are matchbox-window-manager and libmatchbox in there?  Those should have been demoted to universe.
<slangasek> I don't know, but they weren't there an hour ago
<slangasek> hmm, the source was moved to universe, but not the binaries...
<persia> Yeah.  libmatchbox was FTBFS for all of intrepid until now, and matchbox-window-manager hadn't been uploaded since gutsy, but FTBFS because of ogre-model.  I requested demotion of both today to get them built.
<slangasek> or the binaries were moved to main but not the source, dunno
<slangasek> anyway, binaries demoted now, thanks
<persia> Probably source demotions without binary demotions.  The archive-admin doing it was new at the job.
<slangasek> ah
<persia> That ought make them able to be installed again :)
<persia> Were those the new ones you were eyeing, or is there something else?
<slangasek> StevenK: use -S to grab the binaries too when demoting :)
<slangasek> persia: those were the new ones I noticed, yes
<persia> Oh good.  I was afraid I broke something else :)
<sebner> slangasek: mighty mighty ubuntu and debian release manager. can you tell me an estimated lenny release date? just the month is enough ;)
<slangasek> sebner: I'm not a Debian release manager anymore, the Debian RMs have published everything on debian-devel-announce
<slangasek> sebner: or you can try to extrapolate based on the graph at http://bugs.debian.org/release-critical/
<sebner> slangasek: thx mighty slangasek. I suppose still some months left ^^
<Keybuk> sebner: you could fix some and make it faster :p
<sebner> Keybuk: and you could include/fix upstart 0.5 to make intrepid faster :P
<slangasek> burrn
<persia> sebner: That would probably break more than it would fix right now.
 * persia would at least have to rewrite a couple things
<sebner> persia: we still have alpha status :P :P :P
<persia> sebner: Just barely.
<Keybuk> sebner: err, why would that make intrepid faster?
<slangasek> if we ever want to get /out/ of alpha status, we have to stabilize
<Keybuk> Upstart 0.5 missed UVF
<Keybuk> and I'm in the same city as slangasek, so I'm not about to break freezes ;)
<sebner> You Spoilsport :P
<slangasek> hah
<Keybuk> at least, not without _asking_ :)
<slangasek> oh, is there anything interesting happening downtown tonight, then?
<sebner> slangasek: on a tuesday??
<Keybuk> there's some event tonight to end the kernel summit and open plumbers
<sebner> Keybuk: how does mark want to make jaunty boot faster?
<slangasek> on a tuesday the week of the LPC, yes
<Keybuk> sebner: push it down a very steep hill ;)
<sebner> Keybuk: with a BIGGG kick
<Keybuk> I've never understood why people think Upstart makes things faster
<Keybuk> it's not supposed to, we've never said it does, and we've denied it every time someone has claimed it would :p
<ScottK-laptop> Keybuk: So by the first law of conspiracy thinking it must be true.
<sebner> Keybuk: I thought it should replace the old init system (what was old) and makes it faster (what I felt it did)
<Keybuk> sebner: ah, you mean the first release of Ubuntu that had Upstart booted much faster than the previous one? :p
<Keybuk> I'm afraid that was because we switched from bash to dash as /bin/sh in that release :p
<sebner> Keybuk: rofl
<sebner> Keybuk: but everybody said that upstart makes things faster xD
<Keybuk> (seriously - that was the primary reason we did that, and it worked)
<sebner> Keybuk: don't lie. you implemented a secret *boost*-function :P
<Keybuk> "Need you now,  buddy!" [TURBO BOOST]
<sebner> Keybuk: but it seems to me that every new ubuntu version boots faster. reason? or is it because of the newer kernels?
<Keybuk> sebner: it's something we care about
<Keybuk> though it's not always true
<sebner> Keybuk: yes?
<tedg> Keybuk: Do you know why sometimes isn't picking up HAL?  Is it a boot dependency issue?  (mighty annoying one)
<tedg> (sorry, for got the "X isn't picking up")
<Keybuk> tedg: on Intrepid/
<Keybuk> shouldn't be boot order there, dbus is S12, hal is S24 and gdm is S30
<soren> ScottK-laptop: Blimey. Building django takes half an hour on my laptop.
<sebner> Keybuk: so tell me what your speedup tricks are :P
<ScottK-laptop> soren: I'm currently building kdebase on my laptop and considering additional insulation between it and my legs.
<tedg> Keybuk: Yeah, on Intrepid :(  It must be a parse time thing then... don't know, definitely happens.  Was worse with the 177 nVidia drivers -- they must be faster :)
<Keybuk> sebner: don't waste time doing stuff
<tedg> Everyone tells me XML is fast -- I don't see what could slow HAL down.
<sebner> Keybuk: no, I mean why does every ubuntu release gets faster (or is this not true)
<Keybuk> sebner: as I said, it's not always true
<sebner> Keybuk: nice :), and now .. what are the plans to make intrepid faster .. and how?
<Keybuk> no plans for intrepid
<ScottK-laptop> sebner: Buy an new laptop.
<sebner> Keybuk: argh, sry. jaunty
<sebner> ScottK-laptop: my laptop is pretty new. but also a quadcore and 4gb ram doesn't make ubuntu boot in 10 seconds :P
<Keybuk> sebner: no plans have been drawn up for jaunty yet, that will happen at the UDS in December
<sebner> Keybuk: I see .. it's just that I can't say: "Make ubuntu boot in 10 seconds" without knowing how this could be reached
<kirkland> seb128: i'm having some intrepid/evolution issues that i'm having trouble describing to Launchpad... after i've read a few messages, and I try to view one in the preview window, the entire message will be greyed out...  double-clicking it to open in a new window helps for a few messages, then those are greyed out too.  restarting evolution allows me to view those messages, but after reading a few more, the same thing happens.
<seb128> kirkland: screenshot?
<kirkland> seb128: sure, one sec...
<Keybuk> sebner: why would you say that?
<slangasek> heh, the dbus postinst is comical
<slangasek>     # Do not restart dbus on upgrades, only on fresh installations.
<slangasek> [...]
<slangasek> # Automatically added by dh_installinit
<kirkland> seb128: only happens on new, incoming messages... let me way for some more spam to arrive ;-)
<sebner> Keybuk: dunno, it's just when *I* have a goal I usually know *if* it's possible and *how* it could be reached
<cody-somerville> who said that we'll have Ubuntu booting in 10 seconds? :S
<Keybuk> sebner: do you have a goal?
<sebner> cody-somerville: that was just an example
<sebner> Keybuk: for what?
<Keybuk> sebner: sorry, I'm trying to find the context ;)
<Keybuk> sebner: whose goal is 10s boot time?
<sebner> Keybuk: this was just an example ^^
<sebner> Keybuk: Mark wants a faster booting ubuntu and I thought you are the guy to realize it. ^^
<Keybuk> sebner: it was a complete surprise to me that Mark talked about boot speed
<sebner> Keybuk: so I'm sorry
<calc> 10s ubuntu on a regular hd... nice :)
<calc> iirc my system is somewhere around 20s already
<calc> 10s on a 250MB r/w ssd (doesn't exist yet?) probably is already possible
<calc> er 250MB/s
<calc> intel's new SSD's are about that for read but not write yet
<sebner> calc: with a new intrepid I had 25 secs but now it's dirty and b0rken so I have 35-40 secs xD
<calc> sebner: you can retune it, i forgot the command
<sebner> calc: nvm. I reinstall it in 1 month
<Keybuk> ~25-35s is the lower bound limit of a cold boot right now
<Keybuk> faster drives won't speed that up
<sebner> Keybuk: windows 7 can boot in 15 secs I heard ^^
<Keybuk> sebner: Windows nearly always boots faster
<Keybuk> has done for ages
 * cody-somerville decides to not make a joke.
<sebner> cody-somerville: ^^
<sebner> Keybuk: /me never understood *why*
<Keybuk> sebner: it's detailed, and technical
<cody-somerville> Yea, we had several hours of discussion about it at the last UDS.
<Keybuk> but basically, they do most of their stuff after you login ;)
<sebner> Keybuk: yes that's an argument
<sebner> it's never bad to have a fast boot OS
<sebner> fast boot = <20 secs :P
<Keybuk> or, put more properly
<Keybuk> they do stuff in the right order
<Keybuk> and don't waste time doing things because somebody who wears sandals might want to do things wrong
<sebner> ^^
<sebner> Keybuk: so technically speaking there is a physical barrier with lets say 25secs for a normal kernel/boot? I know a haXX0r can tweak it somehow with selfcompiling and customizing ..
<Keybuk> there's a barrier, yes
<cody-somerville> and sadly Keybuk is more interested in upstart than boot time :P
<Keybuk> that barrier goes away if you compile your own kernel, and build in the drivers you need
<Keybuk> cody-somerville: no, keybuk is very interested in boot time also
<sebner> Keybuk: so I'm interested if mighty ubuntu folks can accomplish Marks goal O_o
<calc> i'm not sure if the 20-25s of my boot is from cold start or not, its what bootchart showed
<calc> iirc it supposed to include full boot time
<Keybuk> calc: bootchart measures from end-of-grub
<ScottK-laptop> slangasek: If you're still around, would you please accept the kdebase in hardy-backports.
<calc> Keybuk: oh ok
<calc> Keybuk: i thought it grabbed the counter off the cpu to get full time
<Keybuk> which is why there's the little white space at the start, which is the kernel starting
<Keybuk> calc: we use kernel clock time
<calc> ok
<Keybuk> (we can't speed up bios :p)
<Keybuk> and the grub time is configurable, so uninteresting
<calc> true :)
<calc> the bios will get taken care of by microsoft
<cody-somerville> I remember when the bios was the longest part of the boot process.
<azeem> I remember my C64
<Keybuk> azeem: your C64 didn't boot
<azeem> it said "Booting GEOS"
<Adri2000> slangasek: bug #271058
<ubottu> Launchpad bug 271058 in vsftpd "FFe request for vsftpd 2.0.7" [Undecided,New] https://launchpad.net/bugs/271058
 * hardwire pokes soren, respectfully
<sebner> bad bios
<Keybuk> azeem: it had a ROM in it with all of the operating system code
<Keybuk> it just started executing from a prearranged point
<Keybuk> and all the hardware was exactly as it was last time
<sebner> Keybuk: btw, a quick question. A friend of mine has also ubuntu and before it boots up it takes some seconds. on the screen stands: No raid found, and trying to resume the kernel image. after some seconds it boots normal. any idea? I know here is not a support chan ^^ Btw it's a laptop so I'm wondering about the raid thing
<Keybuk> sebner: slow hardware
<sebner> Keybuk: it's a brand new Asus G2 ;)
<Keybuk> so?
<Keybuk> it can still be slow ;)
<Keybuk> without further details, it simply sounds like it takes some seconds for his root disk device to be probed, power up, etc.
<sebner> Keybuk: if you need futher details just ask. A Asus G2 is a gaming laptop which high end cpu and that stuff. how to fix that?
<Keybuk> sebner: means nothing
<sebner> Keybuk: in what sense?
<Keybuk> in fact, a rule of thumb is the more fancy, singing and dancing a disk controller - the longer it takes to power up
<sebner> Keybuk: well, ubuntu but not vista for example :P
<Keybuk> you didn't say vista didn't take long
<sebner> Keybuk: sry :)
<Keybuk> and I suspect, neither did he :p
<sebner> Keybuk: actually vista is really booting normal/fast ;)
<Keybuk> interesting
<sebner> Keybuk: I'm confused by the "No raid found". there isn't a raid thing I suppose and also vista is booting normal
<Keybuk> I can't think of any reason either way
<Keybuk> it's probably just a message
<LaserJock> sebner: I get that message on all of my machines I think
<Keybuk> a bit like the resume one
<Keybuk> you get a message whether or not you're trying to resume
<Keybuk> so I expect you just get that message because there's no raid
<LaserJock> exactly
<sebner> Keybuk: well, maybe but it take 5-6 seconds until the real boot begins and that's not normal. Also because I'm not seeing it
<Keybuk> probably the system reacting to the slow boot, and checking to see whether it's due to failed raid
<Keybuk> and because it isn't, saying no raid was found ;)
<sebner> Keybuk: isn't the question why it's slowly booting what leads to checking for raid?
<Keybuk> sure
<Keybuk> it'll be the hard drive taking a while to turn up
<Keybuk> it might not be, of course
<Keybuk> but that'd be where I'd put my money
<sebner> Keybuk: interesting because as I said a gaming pc which should have a pretty good/fast high end hard drice
<sebner> *drive
<Keybuk> so?
<Keybuk> drives are rated on their speed when they're *running*
<Keybuk> not speed to spin up
<slangasek> ScottK-laptop: accepted
<Keybuk> in fact, the faster the drive, the longer it's going to take to spin up!
<sebner> Keybuk: but the vista boot question remains
<ScottK-laptop> slangasek: Thanks.
<Keybuk> sebner: could be driver issue
<sebner> Keybuk: so a new kernel *might* fix it?
<Keybuk> maybe
<Keybuk> worth trying
<Keybuk> /var/log/dmesg might be revealing
<sebner> Keybuk: I'll tell him. thx :)
<Keybuk> scott@ubuntu.com
<sebner> Keybuk: hmm?
<Keybuk> get him to e-mail it to me there
<sebner> Keybuk: well, if you can wait 2 minutes I'll give you a link to a pasteservice ;) (he isn't that good in english so I'm doing this stuff)
<Keybuk> sure
<sebner> Keybuk: http://paste.ubuntuusers.de/391993/
<sebner> Keybuk: could it be that the problem is that he is using 32bit hardy with 4gb ram?
<Keybuk> [    0.000000] Detected 2593.872 MHz processor.
<Keybuk> [   20.441090] Console: colour VGA+ 80x25
<Keybuk> 20s?
<Keybuk> sebner: nope, I tend to recommend 32bit
<sebner> Keybuk: why?
<Keybuk> [   26.870365] usb-storage: probe of 4-1:1.0 failed with error -5
<Keybuk> [   26.873351] usb-storage: probe of 4-1:1.1 failed with error -5
<sebner> Keybuk: and it's a dualcore
<Keybuk> could be a slow USB device?
<Keybuk> in fact ...
<sebner> Keybuk: hmm I remember that I saw it once. the usb error message
<sebner> Keybuk: so what usb error could it be?
<Keybuk> in fact
<Keybuk> yes, I'd say it's likely that USB device
<sebner> Keybuk: hmm, he tells me that the usb error is *after* that thing
<Keybuk> if udev is still trying hard to get that probed, it won't mount the disk
<Keybuk> sebner: CD-ROM drive maybe
<Keybuk> nothing else stands out
<sebner> Keybuk: CD-ROM != usb!?!?!
<mathiaz> slangasek: landscape-client is currently in NEW. Could you let it there ? It seems that there is an upgrade issue from intrepid.
<Keybuk> can you get a "lsusb" output from him and pastebin that?
<slangasek> mathiaz: I won't touch it, but I'm not on archive duty today
<mathiaz> Riddell: ^^
<Keybuk> [   25.876249] usb 5-1: not running at top speed; connect to a high speed hub
<sebner> Keybuk: sure
<Keybuk> sebner: something storage-related is definitely on USB
<sebner> Keybuk: so this might be the boot issue or a seperate issue?
<Keybuk> and is definitely slow
<Keybuk> I reckon this is your boot issue
<Keybuk> it's taking about 4s to probe that device
<Keybuk> so that'll show up as a 4s dead period
<sebner> Keybuk: also if the error appears later?
<Keybuk> error is irrelevant
<sebner> kk
<sebner> Keybuk: so a controller thing? because nothing external is attached to an USb port
<Keybuk> no, there's definitely a device there :p
<Keybuk> provide lsusb
<Riddell> mathiaz: accepted.  and on my day off too :)
<Keybuk> it could be something surprising like a modem
<sebner> leyhttp://paste.ubuntuusers.de/391994/
<sebner> Keybuk: huwai
<Keybuk> that'd be it
<sebner> Keybuk: that's the internal modem?
<Keybuk> there's a lot of 0000:0000 crap on the bus
<Keybuk> sebner: bet it has a usb storage device with the windows driver on it
<Keybuk> and I bet the modem isn't even detected by Linux
<sebner> Keybuk: so 2 usb issues?
<Keybuk> there's some usb issues, yes
<Keybuk> the modem will be hardware related, it's probably simply dog slow
<sebner> Keybuk: how can a windows driver be on that storage device?
<Keybuk> the lack of ids could be hardware, or driver
<Keybuk> sebner: all the cool kids are doing it
<Keybuk> and by cool kids I mean drug-crazed korean dudes
<Keybuk> the USB device appears as a USB storage device with a driver and firmware files on it
<Keybuk> once you load the driver, it knows how to kick the device, at which point the USB storage device goes away, and it magically turns into a modem or something
<Keybuk> I've seen it for 3G modems
<Keybuk> and I've heard of it for TV capture too
<ion_> Heh
<sebner> Keybuk: so again. a new kernel *might* help? ^^
<sebner> Keybuk: so also hardly a new kernel can fix that?
<Keybuk> sebner: only may help
<Keybuk> the fact it waits for that usb device is a more recent fix to a race condition
<Keybuk> which I want to fix a different way
<Keybuk> but probably not for jaunty
<sebner> Keybuk: hmm he tells me that the internal modem is working without problems ^^
<Keybuk> interesting
<Keybuk> the HSDPA one?
<Keybuk> I didn't think we even vaguely supported those yet
<NCommander> Keybuk: HSDPA modems from the computers perspective are the same as EDGE or GSM
<Keybuk> NCommander: I know
<NCommander> Keybuk: same AT command set
<Keybuk> NCommander: the problem isn't their command set
<Keybuk> it's their presentation
<NCommander> presentation?
<sebner> Keybuk: so the problem is a usb thing. maybe not the internal modem but a usb thing?
<NCommander> Oh, I see
<NCommander> right, some modems show up as a USB device, not a serial port device
<Keybuk> sebner: I reckon so
<Keybuk> NCommander: it's the fact they don't even show up as modems
<NCommander> Keybuk: An anonying problem to say the least. Some don't even support the AT commands :-/
<NCommander> And finding specs is (near) impossible
<sebner> Keybuk: I see. and you spoke about a fix. dirty fix/good fix?
<Keybuk> sebner: the current fix is a good fix, but that introduces a slow down for others
<Keybuk> like your friend
<Keybuk> there is a better possible fix
<sebner> Keybuk: I don't understand. it is not fixed and slow. how can it be fixed and slow?
<Keybuk> it is fixed
<sebner> Keybuk: in intrepid?
<Keybuk> you misunderstand me
<Keybuk> there was a bug
<Keybuk> which was fixed
<Keybuk> but the *fix* means your friend's laptop boots slower
<Keybuk> which is arguably better than not booting at all :p
<sebner> Keybuk: and tells a error message ... what was the bug? ^^
<Keybuk> what error message?
<sebner> Keybuk: about that usb thing xD
<sebner> Keybuk: so the bugfix fixes the booting but breaks the usb thing? ^^
<Keybuk> it doesn't break it
<Keybuk> that's broken already
<Keybuk> the bugfix just means the boot waits for it to finish
<Keybuk> whereas before, it would have carried on even though that usb device wasn't finished
<sebner> Keybuk: which is bad?
<Keybuk> no, it's not bad
<Keybuk> it's simply non-optimal
<sebner> Keybuk: faster booting is always nice. nvm on that usb thing
<Keybuk> sure
<Keybuk> but booting at all is better
<sebner> Keybuk: you said: carried on
<sebner> Keybuk: or wouldn't it boot without the fix?
<Keybuk> someone else's machine doesn't boot without the fix
<sebner> Keybuk: I see. so back to the usb issue. it might be fixed with a new kernel that "can" with this usb thing?
<Keybuk> I doubt it
<Keybuk> but maybe
<sebner> Keybuk: sounds bad. so bad asus because of putting windows driver and firmware on it?
<Keybuk> nothing to do with asus
<sebner> Keybuk: but?
<Adri2000> slangasek: ping?
<sebner> Keybuk: nvm. He is an idiot xD He isn't believing you. I'm sorry. However. A big thanks from me for taking time :)
<cody-somerville> sebner, meh, Keybuk is 50% charm, 50% lies :P
<Keybuk> lies?
<Keybuk> I don't like
<Keybuk> err, like
<Keybuk> err, LIE
<Keybuk> see, I can't even *spell* lie
<Keybuk> I'm frequently mistaken, incorrect or just plain wrong; but that's different
<cjwatson> luisbg: your description of your dpkg-divert problem from way back definitely indicates you're using dpkg-divert wrongly, I think (either calling it in the wrong place or with wrong options). dpkg-divert is supposed to work no matter whether you call it before or after the diverted file is installed.
<cjwatson> (and indeed if it didn't do so upgrades involving diversions would break really obviously)
<NCommander> hey cjwatson
<cjwatson> evening
<Keybuk> definitely afternoon
<NCommander> how goes it?
<NCommander> Keybuk: evening here
<cjwatson> I have been a bug-fixing machine today. Feeling good about the graphs
<cjwatson> </modest
<cjwatson> >
<NCommander> cjwatson: awesome. I'm a sleep-deprieved machine today :-), although I've been filing bugs on licensing issues I've found and working on improving Nexenta
<cody-somerville> It feels like I've gotten very little done today : (
<NCommander> cody-somerville: don't worry, that feeling will soon pass
 * NCommander hugs an Xubuntu bug :-)
<kirkland> cjwatson: thanks for applying the grub-installer fix this AM, that was a dirty little bug ;-)
<cjwatson> no problem
<cjwatson> the ubiquity graph on http://people.ubuntu.com/~bryce/Plots/ is making me happy at the moment
<bryce> cjwatson: almost looks like the US stock market
<cjwatson> ha
<james_w> cjwatson: hi, I looked at luisbg's source package, and it was calling dpkg-divert the way that is suggested in debian policy, modulo argument ordering, which the code suggested would make no difference.
<cjwatson> then I'm pretty confused - not sure I have time to look at it right now though
<james_w> however, if dpkg-divert is supposed to work in that case then I agree there must be something wrong
<cjwatson> if memory serves you do dpkg-divert --blahdeblah --rename --divert foo.orig foo
<cjwatson> in the preinst
<james_w> yeah, that's what was in policy
<NCommander> Oh that's lovely
 * NCommander hates his college
<TheMuso> asac: Its on my radar. Theres a couple of different solutions I'm looking into.
<TheMuso> NCommander: You don't care about gnucash FTBFSing on hppa do you?
<NCommander> TheMuso: thats a transiant failure, its a misidentified depw-ait
<NCommander> TheMuso: its not like I can do much on hppa failures; I don't have access to the hardware
<TheMuso> NCommander: oh ok you know about it then. I'll leve it up to you to sort out.
<NCommander> TheMuso: It needs to be retried once the build-dep is in place
<TheMuso> NCommander: ok.
<cody-somerville> NCommander, have you become the FTBFS-go-to-guy? :)
<NCommander> cody-somerville: it seems so
<NCommander> cody-somerville: where is the FTBFS?
<TheMuso> cody-somerville: In this case, I uploaded gnucash for NCommander, so was just checking he knew of the FTBFs.
<NCommander> There isn't much I can do with it since hppa has fallen behind again :-/
<cjwatson> glib2.0 FTBFS on hppa; fixing that would help
<asac> TheMuso: ok. you think we can get an initial solution for broader testing before beta?
<NCommander> cjwatson: know where I can find a public HPPA box running Ubuntu? (or debian with a pbuilder ubuntu chroot_
<cjwatson> not I, lamont might
<NCommander> lamont said he can't give shell access to his machines ATM
<TheMuso> asac: I hope so. Thats what I'm planning on.
<cjwatson> I don't know of an hppa porter box for Canonical developers, even
<cjwatson> though the list I'm looking at has been known to be behind
<TheMuso> Frankly, i'm not bothered, but since it was NCommander's upload, I thought he migh care. :)
<cody-somerville> To be honest, I'm really broken up over it. : (
<TheMuso> heh
<NCommander> cjwatson: I'm suprised hppa is a port due to the distinct lack of hardware. We've been trying to fix an FTBFS in KDE for HPPA, and we've currently had three uploads, and three misses
<NCommander> cjwatson: Well, I have a pending developer account request with HP for remote access to one of their hppa boxs
<cody-somerville> I think I already have one myselgf
<NCommander> cody-somerville: what, hppa?
<cody-somerville> I think
<NCommander> "think"?
<NCommander> cody-somerville: can I possibly buy it off you? (I'll drive to come and get it ;-))
<cody-somerville> No, I think I have a shell account from HP
<NCommander> Oh :-P
<cody-somerville> but I may know someone with an actually hppa box.
<cody-somerville> erm
<cody-somerville> *actual
<NCommander> Well, it hopefully if this request is approved, I'll get both IA64 and HPPA accounts
<NCommander> So I might be able to help fix fun FTBFS on all architectures
#ubuntu-devel 2008-09-17
<cjwatson> slangasek: I'd like to upload http://paste.ubuntu.com/47604/ to ubiquity (plus changelog etc.) in response to the GtkAdjustment item in the GTK release notes; I haven't yet done a bug trawl but I think this should be RC because it probably results in partitions always being resized a little bit smaller when you edit them in the manual partitioner
<cjwatson> at least bug 264599 appears to be due to this
<ubottu> Launchpad bug 264599 in ubiquity "Intrepid: manual partitioner fails to use remaining space fully" [Undecided,Confirmed] https://launchpad.net/bugs/264599
<TheMuso> /c/c
<ScottK-laptop> slangasek: Emergency MIR for libnetaddr-ip-perl to make libmail-spf-perl installable: Bug 271124
<ubottu> Launchpad bug 271124 in libnetaddr-ip-perl "MIR for libnetaddr-ip-perl" [Undecided,New] https://launchpad.net/bugs/271124
<bryce> cjwatson: have you seen https://bugs.edge.launchpad.net/ubuntu/+source/acpi/+bug/267682/comments/37 ?
<ubottu> Launchpad bug 267682 in linux "Hotkeys no longer working in Intrepid on Thinkpads" [Critical,Triaged]
<bryce> cjwatson: the commenter says the root cause of this problem is that the kernel rejects keys from acpi-fakekey now, and that we should no longer be using acpi-fakekey for forwarding hotkey presses
<bryce> cjwatson: looking in the acpi package it seems there's tons of similarly titled bugs.  "Sony FN keys don't work", "Hot keys not detected", etc.
<bryce> some of those bugs are fairly old -- see lp #64290 as an example that's 2 years old but seems to describe the same symptoms as mdz, et al
<ubottu> Launchpad bug 64290 in acpi "Hot keys not detected" [Undecided,Confirmed] https://launchpad.net/bugs/64290
<bryce> well, _similar_ symptoms anyway
<ScottK-laptop> slangasek: For the kdesdk problem cvsservice needs to get promoted to Main.  Source package is already in Main.
<ScottK-laptop> slangasek: That's it off of http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html that I'm working on.
<bryce> bdmurray: btw, I notice there are a lot of bugs (>100) filed against 'acpi' which probably really belong to 'acpi-support' or other packages
<bryce> bdmurray: 'acpi' is a simple command line tool that just displays the battery usage.  Most of the bugs filed against acpi are about deeper issues.
<bryce> bdmurray: it might be worth a script to move them?
<bryce> bdmurray: I suspect they were mis-triaged.  The bugs definitely sound like ACPI issues, but I'm figuring the triager mistakenly assumed package 'acpi' was for general acpi issues.  But actually I only see a tiny handful that actually are about the acpi cmdline tool.
<bryce> bdmurray: also probably it would be worth a bug day to clean this up, and also maybe do some work on acpi-support
<cjwatson> bryce: I keep being told that acpi-support is supposed to go away for this cycle, and that everything should end up using pm-utils
<slangasek> until pm-utils handles the wireless hotkey on my thinkpad, the people who say this are lying
<thom> i love that acpi-support is still used :)
<slangasek> cjwatson: ubiquity> yes, go ahead
<slangasek> ScottK-laptop: hmm, I don't believe I have emergency MIR powers, and both the MIR team are off today
<cjwatson> bryce: cf. bug 217504 if you haven't seen it already
<ubottu> Launchpad bug 217504 in linux "acpi_fakekey stopped working for certain keycodes" [High,In progress] https://launchpad.net/bugs/217504
<slangasek> ScottK-laptop: will look at cvsservice later this eve
<cjwatson> has a lot more detail and a patch that reverts to the old behaviour (although also a contention that acpi-fakekey shouldn't be relying on this ...)
<cjwatson> slangasek: ta
<stgraber> hey bryce, any idea when we'll get a new driver from ati (fglrx) ? (if possible one that's compiled for the new Xorg)
<ScottK-laptop> slangasek: OK.  I guess I'll ping pitti tomorrow then.
<ScottK-laptop> (for the MIR).
<cjwatson> ScottK-laptop: libnetaddr-ip-perl promoted; I don't think pitti and doko will mind if I borrow the MIR hat
<ScottK-laptop> cjwatson: Thanks.
<ScottK-laptop> slangasek: Then that just leaves cvsservice for you and I'm done ...
<StevenK> slangasek: I did.
 * kirkland superm1 ping
<ScottK-laptop> LaserJock: You around?
<LaserJock> yeah
<ScottK-laptop> LaserJock: edbuntu-kde is on on the uninstallable list: http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html
<ScottK-laptop> LaserJock: I have the solution for it.
<ScottK-laptop> Are you still the right person to run it past?
<LaserJock> yeah
<ScottK-laptop> OK, it just needs khelpcenter/khelpcenter4 throughout.
<ScottK-laptop> LaserJock: I can upload it if you're OK with that.
<ScottK-laptop> LaserJock: ??
<ScottK-laptop> LaserJock: I've tested this a couple of times in a clean chroot (including one with no Universe), so I think I'm ready to upload.  What do you think?
<TheMuso> 5~/c
 * ScottK-laptop waits for an ugh.
<ScottK-laptop> Heya TheMuso.
<TheMuso> ScottK-laptop: hehe. Not quite, I've slightly adjusted the way I have my IRC and other terminal windows/tabs set up, and its still taking a little bit of incorrect key presses to adjust.
<ScottK-laptop> Actually it's been a long time since I've seen an ugh, so I guess it's all working better than it used to.
<TheMuso> Yeah it is.
<TheMuso> And I keep the ugh to myself now. :p
<TheMuso> should there be one
<anilg> A question related to the graphviz package that i'm porting.. is it fine to add d-shlib overrides to successfully run the d-devlibdeps in debian/rules?
<anilg> details at http://lists.sonic.net/pipermail/gnusol-devel/2008-September/001151.html
<slangasek> StevenK: really?  then perhaps -S is broken, hmm :/
<slangasek> ScottK-laptop: cvsservice promoted
<slangasek> \o/
<StevenK> slangasek: The command said "There are no binaries published, oh well"
<StevenK> slangasek: I'm more inclined to blame Soyuz
<slangasek> hmmm
<persia> I suspect it was that there was a placeholder for the binaries, but no actual binaries (FTBFS due to ogre-model, and never built in main)
<ScottK-laptop> slangasek: Great.  The only remaining kde related thing was edubuntu-kde and laserjock said he'd fix their seeds tomorrow.
<slangasek> spiff
<slangasek> superm1: latest DVD livefs build fails because of nvidia-related deps: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu-dvd/20080916/livecd-20080916-amd64.out
<Adri2000> slangasek: could you take a look at the vsftpd FFe request please?
<slangasek> Adri2000: not currently; fixing up alpha-6 takes precedence.  I'll revisit the list of FFes as soon as I can.
<Adri2000> slangasek: ie. after alpha 6 is released?
<slangasek> well, no, hopefully I'll get a chance to look at them tomorrow
<Adri2000> ok
<slangasek> lool: is there an MIR pending for python-dateutil, which python-elisa now depends on?
<slangasek> asac: what are the odds of an upload for bug #269010 today?
<ubottu> Launchpad bug 269010 in network-manager "nm-system-settings crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,Fix committed] https://launchpad.net/bugs/269010
 * wgrant clears throat.
<wgrant> slangasek: "BY USING THE MOZILLA FIREFOX BROWSER, YOU ARE CONSENTING TO BE BOUND BY THE AGREEMENT. IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, DO NOT USE THE MOZILLA FIREFOX BROWSER."
<asac> slangasek: great that you are here
<asac> slangasek: i wanted to ask you for permission to upload the latest NM branch - which includes this fix
<asac> slangasek: let me give the info for you
<slangasek> asac: ok
<asac> slangasek: http://bazaar.launchpad.net/~network-manager/network-manager/ubuntu.0.7/annotate/2895?file_id=changelog-20070529224034-rodq6xuj4xbig4cr-3
<slangasek> wgrant: perhaps that's what it says.  I don't know, I haven't read it!
<wgrant> slangasek: Unwise to agree to something that you haven't read.
<wgrant> Though I fail to see how that statement can be even slightly legal.
<asac> slangasek: bug 269010 is your bug; the other is #269755 which is a RC regression from a RC bug 259503
<ubottu> Launchpad bug 269010 in network-manager "nm-system-settings crashed with SIGSEGV in g_type_check_instance_cast()" [Medium,Fix committed] https://launchpad.net/bugs/269010
<ubottu> Launchpad bug 259503 in network-manager "MASTER NetworkManager 0.7 crashed with SIGSEGV in nm_device_get_act_request()" [High,Fix released] https://launchpad.net/bugs/259503
<asac> slangasek: the other bug is also more or less RC: #268095
<asac> RC for final -> 100% ... alpha-6 == more or less ;)
<asac> but we have those bits in the branch and i have received good feedback on them
<asac> and getting those on a CD is helpful for my final round of gathering hal fdi tweaking before beta
<slangasek> wgrant: I haven't agreed to it, have I?
<asac> slangasek: so. not really a choice. unless you have questions I'd like to upload that now
<wgrant> slangasek: Oh, but it asserts that you have by using the browser. I'm not sure how it can possibly say that.
<slangasek> wgrant: even if I were to have read that in my browser, (which I haven't, I've only had it second-hand from you), I don't recognize that this has any power to bind me
<wgrant> slangasek: Neither. It's a very strange EULA.
<slangasek> asac: yes, please upload
<asac> thanks
<asac> slangasek: done.
<slangasek> ya
<slangasek> yay
 * TheMuso catches up on conversation. Was actually about to check whether nm asking for a wireless passphrase all the time was a known bug. :)
<StevenK> I saw that back in ... Feisty?
<TheMuso> Yeah but network manager wasn't as mature I would think.
<slangasek> TheMuso: I don't think that's fixed yet, given my experience testing so far
<slangasek> I've just fixed the bug that caused the system backend to crash; it still flakes out on me when it comes to actually giving up the passphrases :P
<TheMuso> Right.
<wgrant> Does it cache networks overzealously for others? Whenever I resume it attempts to connect to the last network, asks for a passphrase when it can't get DHCP, and thus crashes.
<slangasek> (I mean, clearly this iteration of the system backend wasn't tested at all, it segfaulted every time; so I'm not surprised that it still doesn't work after fixing the crasher bug :/)
<slangasek> wgrant: "thus" -> it crashes because it asks for a passphrase?
<wgrant> slangasek: When I click "Connect" on the auth dialog it crashes, yes. I've been meaning to get apport to file it, but on the network I'm on when it occurs I don't have appropriate access.
<slangasek> heh
<asac> wgrant: is that WPA-EAP?
<asac> wgrant: the resume fix is now fixed
<asac> err: resume crash
<wgrant> It's WPA Enteprise of some variety.
<wgrant> I'll check once the connection editor unhangs.
<wgrant> WPA-EAP with CHAPv2.
<asac> yeah
<asac> thats strange. we have fixed a bug caused by in appropriate use of NSS ... which should have been responsible for that
<asac> let me check if we actually have that or if we landed that upstream only
<wgrant> I last upgraded about 36 hours ago.
<asac> wgrant: yeah. the resume crash is fixed by the upload i did 5 minutes ago
<wgrant> asac: Great! Thanks.
<asac> wgrant: the NSS fix should be fixed. but most likely upstream only
<asac> if so its my fault because i submitted it there directly assuming that i would merge from upstream soon.
<asac> wgrant: hmm. so we have that patch
<asac> wgrant: have you filed the NSS crash report?
<wgrant> asac: No, they always happen on the network where I'm horribly proxied.
<wgrant> And by the time I get to a good network I've inevitably got some out of date packages which apport objects to.
<asac> wgrant: there are two options: 1. you install -dbgsym packages up front and run NM in gdb until it crashes
<asac> 2. you could also do a -O0 -g build locally and run that in gdb
<wgrant> asac: I'll try those tomorrow when I can see the network. Thanks.
<slangasek> asac: n-m build regression on !x86?
<asac> slangasek: yes. investigating
<asac> from what we currently see its a glib problem in gbacktrace.h
<slangasek> ok
<asac> i am checking whether we can remove the code part triggering this
<asac> slangasek: http://paste.ubuntu.com/47719/
<asac> seb128: ^^
<slangasek> yes, sounds correct
<asac> seb128: nm fails like http://paste.ubuntu.com/47720/ on all not amd64 or i386 when using G_BREAKPOINT
<seb128> asac: http://svn.gnome.org/viewvc/glib?view=revision&revision=7495 ?
<asac> seb128: slangasek: we probably can comment this out in nm to unblock alpha 6 and then fix that in glib right after that. or do we want to try to fix glib directly for alpha 6?
<seb128> asac: would that fix it?
<slangasek> I don't think it's critical to fix this for the ports before alpha-6, is it?
<\sh> asac: what does that say? do we need another lib in ia32?/usr/lib/nspluginwrapper/i386/linux/npviewer.bin: error while loading shared libraries: libxcb-render-util.so.0: cannot open shared object file: No such file or directory
<asac> seb128: hmm
<asac> seb128: _MSC_VER?
<\sh> asac: this is the cli output when running ff3 + flash + some random app ;)
<seb128> asac: ok, probably not the same issue ;-)
<asac> isnt that windows code? or am i just confused?
<asac> seb128: from our current evaluation its a missing signal.h in gbreakpoint.h :/
<asac> slangasek: you are RM ... i can live without those archs ;)
<seb128> asac: gbreakpoint.h didn't change for ages, that's weird
<asac> hmm ... then probably libc?
<asac> like an implicit include?
<slangasek> asac: rather, I think these archs can live without the latest bugfixes for alpha-6
<asac> that doesnt exist anymore?
<asac> slangasek: thanks.
<slangasek> asac: since there, um, aren't a whole lot of hppa users who need WPA support
<slangasek> anywho, off to bed for a few hours
<asac> seb128: but maybe they dont want crashes on resume ;)
<asac> err
<asac> slangasek: ^^ ;)
<seb128> asac: anyway including signal.h in gbreakpoint.h looks like a correct thing to do yes
 * ogra grumbles about evil firefox
<ogra> it used to tell me the amount of open tabs when i hit the close button
<ogra> now it only asks if it should close them :(
<asac> seb128: you want a bug or can you directly file upstream? or maybe ask your glib contact frirst?
<seb128> asac: I'll file it upstream now
<asac> seb128: thanks. http://launchpadlibrarian.net/17689412/buildlog_ubuntu-intrepid-sparc.network-manager_0.7~~svn20080908t183521%2Beni0-0ubuntu3_FAILEDTOBUILD.txt.gz thats the full log of a failed build if the pastes above arent enough
<asac> those were: http://paste.ubuntu.com/47719/ and http://paste.ubuntu.com/47720/
<asac> ogra: maybe too many tabs?
<asac> or too few?
<ogra> asac, surely over 50
<ogra> i just wanted to know the number ... i used to hit the window close button and got an accurate number by that before
<ogra> though its a while ago that i did that last time ... might have been hardys ff2
<bigon> infinity, are you around?
<asac> \sh: looks like
<asac> \sh: wierd that i dont see it. let me retry
<asac> \sh: hmm. i am not seeing this on the console. how do you trigger it?
<cody-somerville> Someone told me that recommends were no longer being pulled into the cd builds. Is that correct?
<cody-somerville> Because I'm seeing some strange behaviour : (
<cjwatson> cody-somerville: you were misinformed
 * cody-somerville peers at NCommander.
<cjwatson> cody-somerville: what's the strange behaviour?
<cody-somerville> cjwatson, Well, it isn't strange if recommends are being pulled in
<cjwatson> OK
<cjwatson> I don't know where NCommander got that from
<cody-somerville> Actually, there is some strange behaviour
<cody-somerville> cjwatson, http://people.ubuntu.com/~ubuntu-archive/germinate-output/xubuntu.intrepid/desktop
<cody-somerville> IF you search for "xscreensaver", you'll see for example:
<cody-somerville> xscreensaver-data            | xscreensaver                | Xubuntu.Intrepid desktop seed          ...
<cody-somerville> However, xscreensaver *isn't* in the Xubuntu.Intrepid desktop seeds.
<cody-somerville> xscreensaver-data and xscreensaver-gl are on the other hand.
<ogra> xscreensaver-gl : Recommends: xscreensaver | gnome-screensaver
<ogra> i guess that needs to be reordered
<ogra> xscreensaver-data doesnt have recommends
<davmor2> guys Firefox is nolonger displaying the startpage.html even after a restart is this known?
<jordi> TheMuso: hey
<cody-somerville> ogra: Yes, and the Recommends for usplash need to be reordered as well.
<jordi> TheMuso: I think it's time to revisit our "try to merge Debian and Ubuntu's ALSA teams" plan. :)
<TheMuso> jordi: SOunds good to me.
<cjwatson> ogra: that shouldn't make the reason show up as "Xubuntu.Intrepid desktop seed"; that should make the reason show up as "xscreensaver-gl"
<ogra> yeah, thats a bit weird
<cody-somerville> ogra, If I switch changes Recommends: usplash-theme-ubuntu | usplash-theme to Recommends: usplash-theme | usplash-theme-ubuntu, will that have the desired effect of usplash-ubuntu-theme not being installed because I have xubuntu-artwork-usplash seeded?
<cjwatson> ah, that germinate output is using the wrong seeds
<cody-somerville> doh : (
<ogra> cody-somerville, if xubuntu-artwork-usplash provides usplash-theme, yes
<cjwatson> cody-somerville: no, please don't do that, the real alternative should come first
<cjwatson> cody-somerville: seeding xubuntu-artwork-usplash before usplash should be sufficient
<cjwatson> actually the order shouldn't even really matter
<cjwatson> leave the Recommends order alone
<ogra> cody-somerville, do you ship gnome-screensaver ?
<cody-somerville> Yes.
<ogra> hmm
<cody-somerville> but if xscreensaver is installed, we use that instead
<cody-somerville> so I don't want xscreensaver installed by default
<ogra> well, lets see what the germinate change does then :)
<TheMuso> jordi: Is there an alsa channel for debian? if so, I'll join there and discuss further.
<jordi> TheMuso: sorry, was afk
<cody-somerville> xscreensaver and usplash-ubuntu-theme are two packages that are getting pulled into Xubuntu builds currently that I don't want. I'm pretty sure both are via recommends.
<jordi> TheMuso: no, there was back in the day, #debian-alsa, but we mostly work via the mailing list
<cjwatson> cody-somerville: oh, for the output above, I misread and it looks like you did too
<ogra> cody-somerville, no, because germinate uses the wrong seeds
<jordi> TheMuso: you should be added to the alioth project and get svn rights
<cjwatson> cody-somerville: the columns are binary | source | reason, so xscreensaver-data is the binary and xscreensaver is the source package. That output isn't saying that xscreensaver is pulled in
<jordi> TheMuso: do you have an alioth login?
<ogra> but the order in the seeds could be wrong "<cjwatson> cody-somerville: seeding xubuntu-artwork-usplash before usplash should be sufficient"
<TheMuso> jordi: I have an alioth account, however when trying to recover my password, I get told the username doesn't exist, however when I attempt to create an account with the same username, I'm told it already exists...
<cjwatson> ogra: I corrected myself immediately afterwards
<ogra> ah, k
<cjwatson> germinate sets all directly seeded entries before resolving dependencies
<ogra> weird then
<cody-somerville> cjwatson, ah, right.
<cjwatson> I'm regenerating that germinate output
<cody-somerville> Okay, that should give us some answers :)
<cjwatson> oh, meh, cdimage needs to be pointed at the new seeds too
<cjwatson> this is ridiculous
<TheMuso> jordi: I guess I need to contact the alioth admins about that one...
<cody-somerville> Okay, I just looked at the manifest for today anyhow
<cody-somerville> xscreensaver isn't getting pulled in anymore
<cody-somerville> So usplash-theme-ubuntu is the big issue atm
<cjwatson> this might be a germinate bug. Give me a while to look at it
<jordi> TheMuso: #alioth tends to be very responsive
<TheMuso> jordi: Ok I'll try again, and if I still have the issu, I
<TheMuso> jordi: Ok I'll try again, and if I still have the issu, I'll contact the admins.
<cody-somerville> cjwatson, thanks :)
<cjwatson> eep, I never pulled the fix for bug 254042 onto antimony
<ubottu> Launchpad bug 254042 in germinate "debootstrap does not install apt with --variant=buildd for intrepid chroot" [High,Fix released] https://launchpad.net/bugs/254042
 * cjwatson fixes
 * ogra wonders how we could even build working CDs with that 
<cjwatson> ogra: it just means some priorities come out wrong
<cjwatson> the CDs have all those packages on anyway
<cjwatson> cody-somerville: yes, I think this is a germinate bug. It fails to consider Provides when looking for packages to promote from lesser seeds to satisfy dependencies
<ogra> ah, ubuntu-desktop had the mentioned special casing ?
<cjwatson> ogra: no?
<cjwatson> this has nothing to do with desktop - it's purely about the allocation of packages between required and build-essential
<ogra>  ? "* Add support for setting per-seed features, so that following Recommend can be disabled for some seeds but not others "
<ogra> ah
<cjwatson> ogra: which we did only for the required seed, and all the packages pulled in that way are on the CD for some other reason anyway
<cjwatson> the only difference is their Priority field
<ogra> yeah, understood now
<cjwatson> cody-somerville: this isn't Xubuntu-specific either, as you can see from 'apt-cache show usplash-theme-ubuntu | grep ^Task:'
<cjwatson> cody-somerville: bug 271309
<ubottu> Launchpad bug 271309 in germinate "fails to consider Provides when promoting packages from lesser seeds" [High,Triaged] https://launchpad.net/bugs/271309
<superm1> slangasek, is that because nvidia-settings is in universe then?
<superm1> slangasek, and if that's the only problem, then tseliot can you do a MIR for it?
<cjwatson> cody-somerville: damn you, this is viciously complicated. :)
 * davmor2 is sorry he located the xubuntu usplash issue
<cjwatson> I think it wants to look something like http://paste.ubuntu.com/47748/, but argh melty brain
<jordi> TheMuso: after that, we can discuss changes in ubuntu that we obviously want to have in Debian
<davmor2> Who deals with Jockey?
<cjwatson> davmor2: pitti
<davmor2> cjwatson: ta
<TheMuso> jordi: Yes.
<luisbg> cjwatson: james_w: the package worked with no problem in hardy, but I have been testing in intrepid and it does
<luisbg> I did follow the policy and it should work ok, but it doesnt
<luisbg> so I feel forced to change the approach to what Edubuntu does, eventhough I don't like having to change XDG configurations
<cjwatson> Riddell: sorry about the Kubuntu CD build noise, fixed now
<tseliot> superm1: what should I do for slangasek? What's the problem?
<fta> bryce, i'm experiencing some image corruptions in firefox. looking at https://launchpadlibrarian.net/7592385/breezy_cof-mugshot.png (from https://edge.launchpad.net/~ubuntumembers), i get weird stuff like http://www.sofaraway.org/ubuntu/tmp/corrupted2.png or http://www.sofaraway.org/ubuntu/tmp/corrupted3.png. This is with nvidia-glx-177
<tjaalton> fta: not much we can do about nvidia
<tseliot> fta: what does this command say? sudo aptitude show nvidia-glx-177 | grep Version
<jcristau> tseliot: you know, you don't need root for dpkg -s
<fta> tseliot, 177.70-0ubuntu2
<tseliot> jcristau: I like to do things my way ;)
<tseliot> fta: can you report the problem here? http://www.nvnews.net/vbulletin/forumdisplay.php?f=14
<tseliot> only NVIDIA can fix it
<asac> fta: could you try if that problem goes away when using nv ?
<fta> nv is unusable
<asac> so you cant even start X and see if that same pic is corrupted too?
<fta> i'm not sure it's nvidia's fault here
<asac> fta: thats why i asked you to test the free driver ;)
<jcristau> so try with another driver. if it works, it was nvidia's fault
<fta> i can't reproduce with ff3.0, just ff3.1
<jcristau> if it doesn't, it may still be nvidia's fault, but at least you have somewhere to start
<asac> fta: thats only for pngs or jpegs or for all images?
<fta> just this png so far, but 100% reproducible in ff3.1
<fta> could be cairo too
<asac> fta: is it system-cairo we are using?
<fta> yes
<asac> fta: i think if its in upstream builds too, we would need to ask vlad
<fta> asac, latest upstream build impacted too, using a copy of my ff3.1 profile (so reusing my session)
<cjwatson> -* Chose usplash-theme-ubuntu to satisfy usplash
<cjwatson> +! Promoted xubuntu-artwork-usplash from desktop to desktop-common to satisfy usplash
<cjwatson> +* Chose usplash-theme to satisfy usplash
<cjwatson> this is looking more sensible now
<cjwatson> cody-somerville: if you don't mind, I'm going to defer this patch until after alpha-6 - it's big and scary
<ogra> would put some extra excitement into alpha6 though
<ogra> :)
<cody-somerville> so should I just modify the priority of the xubuntu's splash alternative?
<cjwatson> can you just live with the bug for now?
<cjwatson> I don't think we should be mucking around with packages for a germinate bug
<ogra> might be problematic for people to get rid of the ubuntu usplash later though
<ogra> unless you tel the to manullay remove
<ogra> *tell them to manually
<cjwatson> you'll have to do that from alpha-5 anyway
<cjwatson> this isn't a new bug, AFAICS
<cody-somerville> I don't think Xubuntu shipping with Ubuntu's artwork would go over well.
<cjwatson> cody-somerville: alpha 5 did; why is alpha 6 much worse?
<cody-somerville> oh, for alpha 6
<cody-somerville> sorry, I misread you.
<cjwatson> we won't ship the beta this way - I have the bug fixed, I just don't think it's safe for alpha 6
 * cody-somerville nods.
<cjwatson> because it's a honking big complicated patch
<cjwatson> and involves heuristics
<cody-somerville> I agree.
<cody-somerville> No problem :)
<cjwatson> ok, great, that's a relief :)
 * cjwatson didn't want to explain to slangasek why he broke germinate
<cjwatson> I've marked the bug as beta-critical so we don't forget
<cjwatson> slangasek: if you find you need to pull that ^-- germinate fix in, then just run 'bzr pull' in antimony:cdimage/germinate/
<superm1> tseliot, well so i believe the issue is that the dvds won't build because nvidia-settings is in universe and a Recommends for nvidia-glx-*
<ScottK-laptop> lool: elisa and python-elisa are currently uninstallable in Main because python-dateutil is in Universe.  Since you show up in debian/changelog, I figured you'd be the most likely interested party.
<ogra> ScottK-laptop, he's at a summit in berlin, dont expect immediate reply
<davmor2> Jockey doesn't offer the option to reboot your machine once you have installed a driver :(
<ogra> ScottK-laptop, i dont think they are used anywhere on CDs so i guess it can wait until monday
<tseliot> davmor2: don't worry, we'll fix it
<ScottK-laptop> OK.  I guess up to slangasek how much he cares for the Alpha 6 milestone.
<tseliot> superm1: ah, so the Recommends breaks the DVD, very interesting...
<superm1> tseliot, well that's what i gather from looking at the DVD build log
<superm1> tseliot, http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu-dvd/20080916/livecd-20080916-amd64.out
<superm1> tseliot, but i'm not sure if perhaps the conflicts is what's throwing it too
 * tseliot has a look at the log
<ogra> ScottK-laptop, well, nobody apart from loic really knows these packages i think ... better to wait for him to return
<ScottK-laptop> OK.  I was interested enough to find the problem, but not interested enough to write another MIR.
<tseliot> superm1: ok, maybe nvidia-settings should be in main
<tseliot> superm1: it would be interesting to know why it says that "nvidia-177-kernel-source: Conflicts: nvidia-kernel-source"
<tseliot> when it shouldn't be a problem
<superm1> tseliot, perhaps is that happening because they're all providing nvidia-kernel-source?
<superm1> and then causing a handful of conflicts and not wanting to be on the DVD for that reason?
<tseliot> superm1: ok but conflict, replace, provide should be ok. Those packages replace each other
<tseliot> NOTE: I have no idea of how Ubuntu CD/DVDs are created
<superm1> cjwatson, perhaps can you look at this error a bit? I wouldn't think that conflicts/replaces would prevent packages from ending up in the archive on the CD, is it just nvidia-settings thowing it off, or the conflicts/replaces too?
<cjwatson> superm1: if packages in the relevant tasks (ubuntu-dvd-live in this case) conflict, then they can't all be installed at the same time, which is what we're asking for by having them all in the dvd-live task
<cjwatson> dvd-live means that they're actually on the live filesystem not simply available as .debs on the CD
<cjwatson> you are correct that if they were in the dvd seed then conflicts wouldn't be a problem - but they aren't
<superm1> cjwatson, ah well that's a mistake then in that commit.  they should be available as debs on the DVD
<superm1> cjwatson, would you be able to correct the seed?
<cjwatson> sure
<superm1> cjwatson, thanks.  will it still be troublesome that nvidia-settings is in universe then too, or will that be silently ignored?
<cjwatson> I think that should be silently ignored
<superm1> okay that's good then
<tseliot> ok, great
<cjwatson> should be sorted now
<cjwatson> except you'll have to wait for the next publisher run where a package is actually published (the condition there is due to a Soyuz bug) before you can rebuild livefses
<cjwatson> slangasek: ^- note caveat
<lool> slangasek, ScottK-laptop: ack, python-dateutil and  python-cssutil will need MIRs
<lool> slangasek, ScottK-laptop: I'm at a conference this week, may it wait til next week?
 * ScottK looks at slangasek
<lool> slangasek: Also, there's a new pigment with new SONAME and corresponding new elisa which came out yesterday or today lalala
<lool> slangasek: There isn't much risk in going to these, pigment-python is the only rdep of the new libpigment
<lool> slangasek: But I'd understand if you consider it's too late for such things
<lool> slangasek: In fact, it's probably a better choice to defer the new elisa and pigment to next cycle as they play with new UI concepts, and these specific parts might not be ready
<fta> bryce, tjaalton, tseliot: nm my image corruption issue, it is caused by the new color management feature in firefox 3.1, see http://mozillalinks.org/wp/2008/09/color-profiles-turned-on-for-firefox-31/ (i'm using 1=full, not 2=partial)
<psyke83> asac: no news re: the pa alsa plugins, but ia32-libs has been updated, so flashplugin-nonfree can be updated as well. The debdiff is in bug #257403
<ubottu> Launchpad bug 257403 in flashplugin-nonfree "Update Flash plugin 10 to the new RC" [Wishlist,Confirmed] https://launchpad.net/bugs/257403
<asac> psyke83: i have the latest, but still have /usr/lib32/libflashsupport.so
<asac> e.g. i have ia32-libs 2.2ubuntu12
<asac> \sh: ^^
<asac> $ dpkg -L ia32-libs | grep libflashsupport
<asac> /usr/lib32/libflashsupport.so
<asac> \sh: you missed the most important part for flash ;) ^^
<asac> \sh: can you do ubuntu13?
<tseliot> fta: ah, ok
<asac> yeah. but its a driver bug
<asac> i dont see it anyway with any color management option
<asac> (using ati)
<psyke83> asac: yes, it ideally needs to be removed. On the other hand, 64bit users won't note so many crashes due to nspluginwrapper. The worst that happens is that flash content will "turn grey" on web pages (i.e. npviewer.bin segfaults, but firefox doesn't)
<asac> fta: we really need nv tested. otherwise that  will surely be the first question asked
<asac> psyke83: it _has_ to be removed
<asac> no matter what
<psyke83> yep :). I just don't care as much, I'm stuck with 32 bit... hehe
<asac> psyke83: it got worse and sometimes crashes flash while playing
<psyke83> I see
<asac> previously it only crashed flash when leaving the site
<asac> or switching to a new film
<asac> now it crashes it right up-front
<asac> for a bunch of cases at least
<asac> psyke83: all the other changes didnt block flash 10
<asac> at least not the packaged flash 10
<psyke83> asac: if it crashes like that, it's highly likely to be a windowless mode bug. That's bug #239182, and also see http://blogs.adobe.com/penguin.swf/2008/07/addessing_wmode_crashes.html
<ubottu> Launchpad bug 239182 in firefox-3.0 "Segfault in cairo_draw_with_xlib" [Undecided,Confirmed] https://launchpad.net/bugs/239182
<asac> psyke83: well. lots of these crashes go away with removing libflashsupport
<psyke83> though my understanding of the upstream report is that 3.0.2 has it fixed
<asac> i know that there are other issues with windowless mode
<psyke83> asac: yep, and I'm not disagreeing re: libflashsupport - it definitely needs to be removed
<TheMuso> c
<TheMuso> psyke83, asac re alsa apps going via pulse only for when pulse is running, I know what to do to make it happen, I just have to do it, and test it. I will be doing that tomorrow.
<asac> TheMuso: ok. any insight about what we plan to do?
<psyke83> TheMuso: thanks, I'll be happy to help test whatever ends up in your PPA. Just note that asac is eager to push that fix in Intrepid, but not necessarily PA 0.9.12 (though it would be nice)
<TheMuso>  asac We firstly adjust alsa-lib to look for an extra asoundconf file, one which will be shipped with pulseaudio. If this file is not present, it won't break anything. This file will have definitions to check if pulseaudio is running, and if so, it will send all alsa apps via pulseaudio. Otherwise, the audio will be sent to alsa. Pulseaudio depends on alsa-plugins to make this happen.
<TheMuso> So for desktops not using pulse, i.e KDE, nothing will be any different, except for alsa-lib searching for a non-existant configuration file.
<TheMuso> psyke83: I think we wil stick with 0.9.10, but I am going to make a few tweaks, such as the resampler used, etc.
<TheMuso> Mandriva have some nice patches that I will be using to fix up a few bits as well.
<asac> TheMuso: ok thanks for clarifying
<asac> TheMuso: once you have fixed that in intrepid we should talk about hardy
<asac> ;)
<TheMuso> asac: Yeah. Unfortunately that may be difficult to push out in an SRU, but we will see how we go.
<psyke83> TheMuso: thanks, but please don't use the speex-float-0 method. It introduces a lot of distortion in high-range sounds (e.g. explosions). I've tested, and speex-float-1 doesn't have any issues
<asac> TheMuso: yes. we should look into ... but not as long as the theory isnt tested. thanks for your work.
<TheMuso> asac: The changes to alsa-lib are trivial, so that shouldn't be a problem.
<psyke83> and the trivial resample method is terrible
<TheMuso> psyke83: ?
<psyke83> TheMuso: talking about the resample methods. By default it uses speex-float-3
<asac> TheMuso: yeah. i assume the pulse plugin for alsa is more what troubles us. but lets see when we get to that
<TheMuso> psyke83: Oh right. Let me check to see what Mandriva uses.
<TheMuso> psyke83: mandriva uses speex fixed 0
<psyke83> TheMuso: yes, I linked to that report in our bug. I've tested all the methods - all the fixed methods have distortion, and so does speex-float-0. The best compromise was speex-float-1. You may want to test it thoroughly before making changes (and find a good quality audio sample to test)
<TheMuso> psyke83: Ok, the prblem is, all my hardware appears to perform without issue on the pulseaudio default.
<TheMuso> psyke83: So I fear that whatever I test should e ok.
<psyke83> IMHO, the resampler isn't the source of stutter. On all my systems, changing the fragment sizes/amounts is always what eliminated stutter
<TheMuso> will be ok even
<TheMuso> c
<psyke83> TheMuso: ok, have you been testing with VLC and SDL applications? They tend to stutter a lot
<psyke83> GStreamer apps don't stutter at all with the default settings, on my systems - but SDL apps, Skype, VLC, do
<TheMuso> psyke83: No, because they are not accessible.
<TheMuso> However I will make an effort to test with those apps tomorrow when I am doing more work on all this stuff.
<psyke83> cool
<slangasek> superm1: it looks like nvidia-settings not being in main (... restricted?) is part of it, but also that we're trying to install all of the packages at the same time in the livefs, and they conflict?
<slangasek> cjwatson: hrm, so that germinate fix isn't related to the kubuntu liveCD build failure? :/
<tseliot> slangasek: nvidia-settings is GPL v.2, therefore it could be moved to main. Those packages cannot be installed at the same time but this shouldn't be a problem, right?
<slangasek> tseliot: it's a problem for trying to put them in the livefs!
<cjwatson> slangasek: I fixed the Kubuntu live CD build failure, I believe
<cjwatson> sorry about the noise; it was due to a regression in germinate that I incautiously pulled ...
<tseliot> slangasek: yes, I know
<NCommander> wooo, I got access to a HPPA box. Time to fix some FTBFS :-)
<Riddell> cjwatson: kubuntu livefs hasn't built today as far as I can see
<Riddell> the CDs themselves work fine
<cjwatson> Riddell: so do you actually want landscape-client in your desktop seed? we took it out of Ubuntu
<Riddell> not if ubuntu doesn't
<Riddell> I'll remove it
<slangasek> lool: yes, python-dateutil MIR appears to be able to wait until next week
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/seeds/kubuntu.intrepid>$ grep landscape *
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/seeds/kubuntu.intrepid>$
<cjwatson> hmm
<cjwatson> am I missing something?
<slangasek> lool: pigment-python> if that's an FFe request, please file it via LP :)
<Riddell> cjwatson: oh, it was in platform
<Riddell> cjwatson: so it just needs a meta package rebuild I expect
<cjwatson> ah, ok; sounds like an obvious soft-freeze exception :)
<cjwatson> "make it work"
<slangasek> tseliot: ok, I see this was discussed in bits of the scrollback that didn't highlight me, and is now resolved :)
<Riddell> infact slangasek has already done kubuntu-meta
<slangasek> cjwatson, Riddell: I already did a kubuntu-meta rebuild to drop landscape-client for the nonce ?
<slangasek> yes
<superm1> slangasek, none of those should have been installed in the livefs that was an oversight when it was committed to the wrong seed earlier, cjwatson committed a fix so that they're shipped as debs on the DVD instead
<Riddell> slangasek: so do you know why the livefs still wants it installed?  was it just run too soon?
<slangasek> Riddell: apparently so; I set up the build to trigger on the appearance of kubuntu-meta 1.90 on antimony, that seems to have not been enough for the livefs buildds
<slangasek> so I'm respinning now
<Riddell> slangasek: thanks
<Riddell> slangasek: I see the kubuntu alternate CDs also have landscape and old kubuntu-desktop on them, could you rebuild them?
<slangasek> Riddell: hrm, I did... wonder what's going on then :/
<slangasek> oh, perhaps the .deb synced over before the Packages file or something
<slangasek> which doesn't sound right, but bleh, rebuilding anyway
<slangasek> superm1: btw, I never heard back about pushing a mythbuntu alpha-5 image set; I've respun now for alpha-6, can someone vet these in the next day or so?
<superm1> slangasek, yeah we had issues with alpha5 disks so we never acked them
<superm1> hopefully these are better now
<slangasek> superm1: ah; an explicit nack would've gotten you daily images going again sooner :)
<superm1> slangasek, sorry, we were focusing on "bigger" issues in the live images so the extra spins probably wouldn't have been tested for a few days.  i'll make sure you get an ack/nack on these images
<Riddell> slangasek: kubuntu alternate looks good this time
<ldp> no
<ldp> wrong tab, sorry
<slangasek> Riddell: yep - livefs build is also fixed, will post as soon as it's available
<davmor2> Should log out still be on the task bar or should it be shutdown now?
<persia> cjwatson: When creating the mobile.intrepid seeds, the entire contents of the ubuntu.intrepid seeds were copied in order to better preserve earlier history.  Is there any benefit to preserving seeds there that are not specific to any of the mobile flavours?
<cjwatson> persia: no
<persia> Great.  That will reduce merging efforts then :)
<cjwatson> persia: are you actually using the mobile.intrepid seeds yet?
<cjwatson> I mean, ubuntu-mobile is still built out of ubuntu.intrepid, I thought
<cjwatson> generally people should not need to do seed merging any more
<cjwatson> there are some exceptions but half the point of the split was to avoid the merge-o-rama
<persia> cjwatson: Certainly.  They are the basis of the mobile-meta package.  It's still based on lp:~ubuntu-core-dev/ubuntu-seeds/mobile.intrepid, rather than somewhere under ~ubuntu-mobile-dev
<cjwatson> oh, we did hoik ubuntu-mobile out of ubuntu-meta, OK
<cjwatson> in that case we should stop ubuntu-meta building from universe ...
<persia> Yes, probably :)
<cjwatson> are you intending to switch to ~ubuntu-mobile-dev, and are you blocked on anything for that? last time I asked your team about that I think you were uncertain
<persia> It's really pending some further activity or guidance on ArchiveReorganisation.  Until there is a firm plan for reorganisation, ubuntu-mobile-dev is only a placeholder group.
<\sh> asac: yes...
<persia> I'd personally be happy to move the seeds, but it's not blocking anything to keep them where they are.
<\sh> asac: btw...libxcb-render-util0 is also used by nspluginwrapper somehow
<asac> \sh: yeah. i also get that when running the adobe air installer:
<asac> ./adobeair_linux_b1_091508.bin
<asac> Error loading the runtime (libxcb-render-util.so.0
<\sh> asac: I'll add the lib too...
<persia> cjwatson: Another, only slightly related, question: from which seed is the list of packages for the alternate CD generated?  Is that the same as for the live CD, but just a different process of collecting the packages?
<asac> \sh: can you try to run that installer before uploading? maybe we miss something else :/
<cjwatson> persia: from the graph starting from ship
<\sh> asac: I'll try :) it's a bit difficult, because source package is in company...and build machine is at home with less bandwidth ,->
<cjwatson> persia: in the case of the server CD, from the graph starting from server-ship
<\sh> asac: flashsupport is in
<cjwatson> persia: the live CD works differently because we need to install lots of packages with apt, and then stick a little archive on the top that's composed of the stuff in ship-live
<cjwatson> so we have to punt everything back through the archive via metapackages and tasks
<\sh> asac: or did I miss something..libflashsupport.so is in /usr/lib32/ (at least in my build of the package)
<persia> So live is more closely controlled by livecd-rootfs than from the seeds directly, and then extra stuffing comes from ship-live?
<cjwatson> with the alternate/server CD, it's really simple 'cos you just run germinate, assemble a big list, and copy all those packages onto the CD. In theory anyway ...
<cjwatson> persia: right, although most of the stuff that livecd-rootfs installs still ultimately comes from seeds
<cjwatson> it's just that sometimes it's mediated either by developers uploading metapackages or by the archive synthesising Task fields
<persia> But through meta packages, so it needs refreshed uploads to take effect?
<persia> Ah.  Right.  Thank you.
<cjwatson> not everything requires an upload, although it takes some experience to remember which is which
<cjwatson> unfortunately, the archive currently won't regenerate Task fields unless the relevant pocket (e.g. intrepid RELEASE) is "dirty", which can only be done by uploading something to it
<persia> What sort of seed changes would affect a liveCD without an upload of -meta (aside from the ship-live seed)?
<cjwatson> this is usually not relevant since churn is so high, but is an occasional gotcha during freezes; it's a bug
<cjwatson> adding anything (and waiting for the publisher to fill in Task fields, prodding it if necessary) would affect a live CD without an upload of -meta
<asac> \sh: yes. but _thats_ the problem :)
<asac> \sh: it has to go away -> remove it from there please
<cjwatson> although if you're adding a package to a seed that has a corresponding metapackage, then you *should* upload -meta
<\sh> asac: oh you mean, you want that go away ;)
<asac> \sh: yes ... desperately ;)
<asac> make it disappear forever :/
<cjwatson> if you're removing a package from a seed with a corresponding metapackage, then -meta *has* to be uploaded for that to take effect, because otherwise germinate will see the dependency from the metapackage itself and fill that in when expanding dependencies :)
<cjwatson> removals from seeds without metapackages (e.g. live) are just like adds
<persia> OK.  That makes sense.  I'll have to learn more about Tasks before I've grasped it completely, but thank you for the explanation.
<asac> \sh: its #192888 if you want to close it in changelog
<\sh> asac: thx
<asac> \sh: the summary is quite good if you dont mind a read ;)
<psyke83> asac & \sh: it seems flash 10 may depend on additional libraries, so perhaps let's stall the ia32-libs update (so we can remove libflashsupport and add the new libs at once)
<\sh> psyke83: you mean  #246911)
<asac> psyke83: i want it to be removed independent of all the other issues
<\sh> bug  #246911
<ubottu> Launchpad bug 246911 in ia32-libs "[Wishlist] please add libnspr4-0d to ia32-libs" [Wishlist,Fix released] https://launchpad.net/bugs/246911
<\sh> libcurl3 nspr4 nss3 and ssh2 are already in for flash10
<psyke83> \sh, yep, it seems that libxcb-render-util0 is also needed, and possibly others. I'll try to find out exactly what's missing for flash 10
<asac> psyke83: ... without that we dont get real exposure for the pulse plugin in alsa on 64bit
<\sh> psyke83: xcb isnow in too, but that's an issue with the new X it seems...finally flash10 doesn't work as expected...I can run our flash application but not our flex app with flash10..but with flash9 it works perfectly...
<psyke83> asac: sure, I thought that \sh would want to address these concerns together, as ia32-libs is a >450mb source package :)
<bryce> cjwatson: btw, timo says there's 8 revisions to acpi-support on top of what we have, including one change that mentions thinkpad X60 hotkey support
<\sh> psyke83: that's not the problem right now :) 100MBit/s upload bandwidth is enough..if this is not enough I'll go to our GBit links
<asac> i can certainly wait a day or two. but i just want to see this fixed. its been open for far too long. ill leave it to \sh to decide when to do it ;)
 * \sh declares, that \sh is not Pitti - NG ;)
 * \sh needs to fetch some intrepid archive mirrors for i386 and amd64 now...ia32-libs needs a while until upload
<psyke83> \sh: I've already built an updated flash 10 deb, and nspluginwrapper now works on i386. Will I post the output of "/var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so" in bug #246911, so you can determine missing libraries?
<ubottu> Launchpad bug 246911 in ia32-libs "[Wishlist] please add libnspr4-0d to ia32-libs" [Wishlist,Fix released] https://launchpad.net/bugs/246911
<psyke83> \sh er, "ldd /var/lib/flashplugin-nonfree/npwrapper.libflashplayer.so"
<asac> \sh: i certainly owe you a beer for removing that from that package ;) ... thanks
<asac> psyke83: does nspluginwrapper (i386) work more or less well with latest flash?
<psyke83> asac: no, unfortunately. For some reason, npviewer.bin seems to randomly segfault, e.g. when switching firefox tabs. I'll check it more thoroughly today (and flash is 100% stable without nspluginwrapper)
<asac> psyke83: ok.
<asac> psyke83: what we could try is to disable windowless mode in nspluginwrapper to see if its that code part (which is quite new) that causes the issues
<psyke83> asac: I'm checking the source and don't see an obvious compile-time option. Do you mean to disable wmode in flash itself? (/etc/adobe/mms.cfg)?
<psyke83> I'll try that anyway
<asac> psyke83: err. no. i mean wmode in nspluginwrapper. you need to hack that out of it ;)
<psyke83> ok
<asac> there is no flag
<asac> let me see
<\sh> psyke83: yes sure :)
<psyke83> ALLOW_WINDOWLESS_PLUGINS macro in npw-viewer.c
<\sh> btw...if anyone has a good string to adobe, please tell them they should fix the proxy rtmpt bug
<\sh> asac: http://bugs.adobe.com/jira/browse/FP-519 <- ;) that's why flashplugin is not usable in most of the corporate environments when using livecasting ,-)
<tedg> slangasek: Where were those ical files you posted of the release schedule?  I can't seem to find the e-mail now.
<cjwatson> tedg: http://people.ubuntu.com/~vorlon/IntrepidReleaseSchedule.ics http://people.ubuntu.com/~vorlon/UbuntuReleaseSchedule.ics
<tedg> cjwatson: Thanks.
<psyke83> \sh: more fun with ia32-libs, yay! See bug #246911 ;)
<ubottu> Launchpad bug 246911 in ia32-libs "[Wishlist] please add libnspr4-0d to ia32-libs" [Wishlist,Fix released] https://launchpad.net/bugs/246911
<psyke83> \sh, I'm downloading ia32-libs source to see what needs to be added for flash 10. At the moment, we need libxcb-render-util0 and libxcb-render0. I'll add another comment when I've checked everything
<\sh> psyke83: libxcb-render0 just added..
<psyke83> the -util0 is necessary too, a user seems to have confirmed it in a duplicate
<\sh> psyke83: already added ;) because I saw that this morning :)
<psyke83> I'm afraid my bandwidth doesn't quite compare to yours... *sniff* :(
<psyke83> cool
<\sh> psyke83: please open a new bug for that...I can't change the status anymore (bug somehow in lp) and assign me pls
<psyke83> \sh, sure. There was a duplicate, I'll unmark it
<\sh> grmpf...never work with two browsers at the same time...untilboth have cookies
<\sh> psyke83: in one of the last flashplugin installations I saw a libcurl3.so (I thought it was the last beta or the one release before) (on amd64) looks like that's gone now completly?
<psyke83> \sh: yes, I noticed that too...
<psyke83> would it be bad to keep libcurl in ia32-libs, in case the dependency re-emerges later on?
<\sh> psyke83: no...I'll leave that in just to be safe
<psyke83> \sh: bug #271392 is the new task, I have to wait for ia32-libs to download before I can double-check we have all the new required libs, but the ldd output is in the report if you want to check first
<ubottu> Launchpad bug 271392 in ia32-libs "Unable to install flashplugin-nonfree -- libxcb-render-util.so.0 not found" [Undecided,Confirmed] https://launchpad.net/bugs/271392
<\sh> psyke83: I think tomorrow morning I'm able to upload again...Ihave to wait for my local intrepid archive mirror :)
<lool> slangasek: After discussion with people here, I'm convinced we don't want to go with the new pigment/elisa; the current ones are the ones we want
<psyke83> \sh: cool. It's asac that care, I don't even have 64bit hardware to test on ;)
<psyke83> *cares
<\sh> psyke83: /me cares too...that' s why I'm dealing with it now...I need a working flashplayer for work on amd64 ;)
<asac> \sh: thank you!
<psyke83> yeah, thanks!
<psyke83> \sh, and to keep your blood pressure low, maybe you could consider getting rid of ia32-libs entirely for intrepid+1, and hook getlibs into packages instead: http://ubuntuforums.org/showthread.php?t=474790
<psyke83> ;)
<psyke83> \sh & asac: damn, I just remembered. If we switch to the PA ALSA plugins, that means that ia32-libs will need libasound2-plugins available too. Is that already part of ia32-libs?
<\sh> psyke83: the real fun would be to have multi-arch-lib packages like lib32asound or something like this...that would help
<persia> psyke83: Is that the best way to do it?  Previous discussion on the topic seemed to indicate that it might make sense to create special 32-bit libraries in the individual library packages where needed.
<psyke83> persia, that means that maintainers for all packages would have to get involved in fixing 64bit bugs... not that I'm using that as an argument, but it could cause problems
<\sh> CCFLAGS="-m32" is not a problem on amd64 ;)
<persia> psyke83: That's true today: there are two supported 64-bit architectures for every library.
<\sh> persia: that we need to do anyways.
<psyke83> persia: sure, but the maintainers of the libraries can handle the problems, but maintainers of applications may not
<psyke83> well maybe not, but it just crossed my mind
<persia> \sh: Right, so adding -m32 for a special additional build for some libraries to kill ia32-libs wouldn't be that bad.
<persia> The problem is it's never something anyone decides to do at the *beginning* of a release cycle.
<\sh> persia: the problem is just time to fix the debian/control and the debian/rules file...
<persia> \sh: Yep.
<persia> \sh: And then we don't need ia32-libs anymore.
<\sh> I did that some time ago for sles9
<\sh> psyke83: you want libasound2-plugins as well in the ia32-libs ?
<jdong> how does Redhat's multiarch yum system work?
<\sh> jdong: yum can multiarch?
<jdong> it just allows installing 32-bit distro's .rpm's on the 64-bit distro, right?
<jdong> \sh: yeah, like yum install firefox.i386 is valid on AMD64
<psyke83> \sh: yes... do you want me to open a new bug? It should be part of the task for bug #192888, though.
<jdong> at least that's how I understand it
<ubottu> Launchpad bug 192888 in ia32-libs "firefox crashes on flash contents when using libflashsupport" [High,In progress] https://launchpad.net/bugs/192888
<\sh> psyke83: just add it to #192888
<psyke83> \sh, unfortunately I'm not sure what else may be necessary to ensure PulseAudio works for 32 bit application. I do know that libasound2-plugins *must* be included, though
<jdong> I just feel a double-build for amd64 packages sounds a bit redundant when we already have 32-bit debs available for the i386 distribution :-/
<jdong> it would be nice if there were some way of utilizing them
<psyke83> jdong, yes, which is what makes getlibs useful - it grabs the actual 32bit debs and extracts the necessary libs, as far as I know
<jdong> psyke83: yeah, but that sounds a bit hackish to me
<jdong> I'd rather have dpkg -i some_32_bit_lib.deb do the "right thing"
<\sh> jdong: when I read all the crap about the ia32-libs correctly, there were more problems then just i386 libs...the search for 32bit libs in apps is one of them
<\sh> I mean libs are one thing, 32bit apps another
<jdong> long-term is there some kernel-level magic we can do to make the system look 32-bit to 32-bit apps and 64-bit to 64-bit apps?
<jdong> (this is really far fetched now :D)
<persia> psyke83: getlibs uses --force-all which is almost always not what you actually want to do.
<\sh> jdong: ms doesn't make it different...(only the weired namespace...32bit libs are now under system64 or so, and the 64bit libs under system32 to be backward compatible, afaik)
<jdong> \sh: right
<jdong> \sh: it doesn't sound like a very unreasonable idea.
<jdong> \sh: MS does kernel magic when 32-bit apps run, right? They look around and see everything as 32-bit with the WOW64 system, right?
<jdong> I was thinking it'd help if when a 32-bit app looks at /usr/lib it sees 32-bit binaries, but a 64-bit app looking there would see 64-bit binaries.
<jdong> would require some evil magic lower-level though
<\sh> jdong: I don't know actually...I just overheard some windows devs here...they are doomed sometimes because of that
 * \sh is one of two people here in the office, who are using only ubuntu :) 
<jdong> cool :)
<jdong> often times I find myself having a 32-bit chroot that I have dchroot wrappers to go into
<jdong> would be nice if that's automatically transparent
<\sh> that makes me think: I'm the only one who got new hardware for the DC...and all the hardware (ok, not on the ciscos) is running on ubuntu hardy server
<cathya> whats the topic about ms 32 bit
<\sh> cathya: multi arch ;)
<jdong> cathya: I walked in late, seems liek just how to handle multiarch
<jdong> basically a manly whose-hack-is-less-hideous competition :)
<cathya> ohh
<cathya> ok
<cathya> heh
<hoonteke> What kind of testing framework do y'all have for the Ubuntu Desktop?
<pwnguin> hoonteke: there was an IRC session during DeveloperWeek about that subject
<hoonteke> pwnguin: okay, since I'm not a regular Ubuntu dev, is that irc session recorded somewhere?
<pwnguin> yea
<hoonteke> you have a link handy to which to pointer me?
<pwnguin> https://wiki.ubuntu.com/MeetingLogs/devweek0809/AutoTests
<hoonteke> brilliant, thanks.
<persia> hoonteke: You may also be interested in discussions in #ubuntu-testing.
<hoonteke> ooh, even more rooms to learn about.  hehe thanks
<psyke83> \sh: I added a comment to #192888. I would recommend that you test it on your system - when you have a functioning Flash 10 (without libflashsupport), set PulseAudio as the default ALSA device (asoundconf set-pulseaudio). Then you'll see what libraries are necessary
<\sh> psyke83: will do
<psyke83> \sh, thanks for all this, I'm sure many people will appreciate your effort (if it works.. fingers crossed, heh)
<pitti> hi
<pitti> kirkland: got a minute to talk about update-motd?
 * pitti hugs superm1; thanks for DKMSifying virtualbox!
<ara> hey pitti
<kirkland> pitti: please!
<kirkland> pitti: what can I do for you?
<pitti> kirkland: ah, was just typing a comment
<kirkland> pitti: i've uploaded a couple of changes, hopefully addressing your concerns
<kirkland> pitti: i see your point
<kirkland> pitti: but i realy want to be able to start/stop/restart update-motd itself
<kirkland> pitti: and running as a cronjob, not a daemon presents a unique challenge
<alex-weej> during the Hardy dev cycle there was news about KVM becoming the "official" virtualisation tool of Ubuntu
<alex-weej> i'm not exactly sure what tools I'm missing, but I install virt-manager, and it's quite buggy.
<liw> alex-weej, buggy in what way?
<alex-weej> well networking doesn't work properly unless you run it as root
<alex-weej> and you can't add an SDL output, which means you're stuck with very bad graphical performance via VNC
<alex-weej> VirtualBox OSE has SDL and it's very fast
<alex-weej> (if you try and add an SDL display it throws exceptions)
<alex-weej> these have both been problems since Hardy and through current Intrepid
<alex-weej> i was wondering if i was actually missing something and was supposed to be using other tools
<mathiaz> slangasek: https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview <- is the page tracking the release notes for alpha6 ?
<liw> alex-weej, the #ubuntu-virt channel should be able to give you good answers, but let me point out that the virt-manager and virsh tools are just management layers, and the underlying kvm can do things the management tools don't want to do (at least currently); for example, you don't need VNC and can use SDL if you run kvm directly
<alex-weej> liw: thanks, and good point. though for some reason I had assumed that the announcement of official support would come hand-in-hand with first-class configuration tools.
<liw> alex-weej, they're... not so bad, when you run servers in your virtual machines :)  but yeah, I am not terribly happy with virt-manager myself, all the time
<alex-weej> ok then i guess we should fix up virt-manager
<alex-weej> i was just wondering if there was some secret program i didn't know about
<liw> alex-weej, there may be, I am a novice with this stuff :)
<slangasek> mathiaz: yes (now doing a slightly better job of it)
<Riddell> cjwatson: does this look like something a recent upload might have caused? https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/271467
<ubottu> Launchpad bug 271467 in ubiquity "freeze on kubuntu install" [Undecided,New]
<mathiaz> slangasek: ok - I'll a section about samba2.
<slangasek> mathiaz: ok, thanks :)
<mathiaz> slangasek: *samba3.2*
<tkamppeter> pitti, hi
<superm1> pitti, it's been on the TODO for a while, now i really hope that debian picks up dkms, the delta was huge to add in dkms support.
<superm1> pitti, are there any other pending packages that should be DKMSified while i'm at it that you can think of off hand?
<pitti> superm1: at least that's the only one which regularly causes trouble in kernel SRus
<pitti> and I don't know any other important out of tree driver
<pitti> (which we have packaged in the archive0
<superm1> pitti, okay well if you think of any others, let me know.  ideally would like to have no necessity for additional SRU's beyond kernel itself and LRM for intrepid when there are kernel uploads :)
<pitti> right, me too
<ScottK> superm1: You might want to put out a request for inputs on ubuntu-devel.
<cjwatson> Riddell: blink, nothing I did
<kirkland> Ampelbein: ping
<Ampelbein> kirkland: pong
<Ampelbein> ?
<kirkland> Ampelbein: hi, i see you registered an ecryptfs project on launchpad
<kirkland> Ampelbein: and that you're listed as the maintainer?
<davmor2> Riddell: no it's evands fault ;)
<kirkland> Ampelbein: i'm co-maintaining ecryptfs-utils upstream, and we're looking at moving some of the functionality that was being provided by SourceForge to Launchpad (mailing lists, bugs, etc)
<Ampelbein> kirkland: i just registered the project to have easier access when reporting bugs upstream
<evand> Riddell: I just uploaded a fix.  I'm waiting on a Kubuntu CD download to fully test it.  Sorry about that.
<kirkland> Ampelbein: would you be opposed to transferring ownership to me?  :-)
<Ampelbein> not at all ;-)
<Ampelbein> i did not want to make a hostile takeover
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 22:00 UTC until 23:59 UTC for a code update | archive: main frozen for alpha-6, feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http:/
<Riddell> evand: ah, sorted
<Ampelbein> kirkland: done
<kirkland> Ampelbein: you da man!  thanks a bunch...
<slangasek> hmm, is ichthux actively maintained?
<slangasek> (ichthux-desktop has deps on NBS kde packages, and the seeds are maintained outside of lp)
<ScottK-laptop> slangasek: When I pointed out stuff that needs to be updated, they fixed it.
<slangasek> ScottK-laptop: what's the most effective way to point this out?  The maintainer field on the package points to a single individual; email him?
<cjwatson> slangasek: I seem to remember the maintainer is raphink, who's here
<slangasek> oh
<slangasek> yes, I was looking for a "txwikinger", ok :)
<ScottK-laptop> Yes
<slangasek> raphink: ping; can ichthux-meta be updated to migrate the deps on kghostview and khelpcenter to something suitably kde4-ish, please?
<slangasek> cjwatson: thanks
<ScottK-laptop> He's usually on kubuntu-devel
<ScottK-laptop> slangasek: nixternal has also been involved in that one (at least sponsored there stuff).
<ScottK-laptop> there/their
<slangasek> calc: have you seen that the ooo-l10n build appears to be trying to create the libuno-cli-basetypes1.0-cil binary package in debian/rules? http://launchpadlibrarian.net/17420202/buildlog_ubuntu-intrepid-i386.openoffice.org-l10n_1%3A2.4.1-8ubuntu1_FAILEDTOBUILD.txt.gz
<calc> slangasek: yes, i will be uploading a 9ubuntu1 soon and will fix that along with some other issues
<slangasek> ok
<calc> slangasek: didn't want to do it during freeze ;-)
 * slangasek makes vague hand gestures
<wgrant> jcastro: I can use ALLCAPS to complain against an ALLCAPS EULA if I feel like it, TYVM.
<jcastro> whatever floats your boat
<wgrant> They deserved a taste of their own medicine.
<slangasek> "they"?
<wgrant> Good point.
<slangasek> awesome, I'm making points without knowing it
<wgrant> That's the best way to do it.
#ubuntu-devel 2008-09-18
* mthaddon changed the topic of #ubuntu-devel to: archive: main frozen for alpha-6, feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<NCommander> wgrant: I don't remember, did you ever sponsor any of my uploads?
<wgrant> NCommander: I did not.
<NCommander> ok
<NCommander> StevenK: ping?
<ion_> wgrant: Where is this ALLCAPS complaint about an ALLCAPS EULA?
<wgrant> ion_: Only the description of my bug that has been circulating everywhere... Have you not seen it?
<sbeattie> ion_: bug 269656
<wgrant> That one.
<ubottu> Launchpad bug 269656 in firefox-3.0 "AN IRRELEVANT LICENSE IS PRESENTED TO YOU FREE-OF-CHARGE ON STARTUP" [High,Confirmed] https://launchpad.net/bugs/269656
<ion_> Thanks
<ion_> The bug report is missing âHEREAFTER REFERRED TO AS âTHE BROWSERââ etc. ;-)
<wgrant> Sorry.
<slangasek> cody-somerville: xubuntu images are up for alpha-6 and awaiting testing
<nxvl> \o/
<_Zeus_> this isn't gmail :P
<nxvl> _Zeus_: ?
<_Zeus_> that's a gmail smiley
<slangasek> it's not a smiley
<_Zeus_> oh?
<slangasek> it's an army
<nxvl> nop, that's a clasic celebration ascii emoticon
<_Zeus_> slangasek: whoa, you're the guy who answers like all the launchpad bugs
<_Zeus_> hmm..
<slangasek> I am? :)
<_Zeus_> OH wait.  i was thinking of \m/
<_Zeus_> slangasek: yeah.  Steve Langasek.
<nxvl> it's a guy with the arms up
<_Zeus_> ah
<_Zeus_> now i see him
<nxvl> _Zeus_: yeah, slangasek can be a little grumpy sometimes, but really funny when not :D
<slangasek> _Zeus_: oh, yes, I suppose I am him
 * nxvl HUGS slangasek 
 * slangasek hehs
<nxvl> \m/ is a hand with 2 fingers up, the clasic ROCK ascii emoticon
<nxvl> :D
<_Zeus_> ya
<_Zeus_> anyone know how to remedy this? https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/271459
<ubottu> Launchpad bug 271459 in qt4-x11 "Skype fails loading object file" [Undecided,New]
<pochu> If a package is moved in Debian from contrib to main, what's the procedure to get it reviewed/moved from multiverse to universe? bug 269074
<ubottu> Launchpad bug 269074 in cglib2.1 "Please sync cglib2.1 2.1.3.dfsg.2-1 (multiverse) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/269074
<_Zeus_> no one has any idea i take it...
<cjwatson> pochu: file bug, subscribe ubuntu-archive
<mathiaz> cjwatson: is partman-auto-raid working ? I'd like to get it included on the server cd
<cjwatson> mathiaz: I don't know that it isn't, but then again since we haven't been using it it's untested in an Ubuntu context
<_Zeus_> is mark shuttleworth ever on irc?
<ion_> Yes
<cjwatson> mathiaz: given its structure, it's harmless if not explicitly activated, so I have no objection to somebody adding it to the platform.intrepid/installer seed after alpha 6
<_Zeus_> ion_: what's his username?
<mathiaz> cjwatson: ok - I'll also have to write a MIR for it
<ion_> zeus: sabdfl. You could have found out it by grepping this channelâs WHO list. :-)
<cjwatson> Mark's IRC username is easily found; but he's a busy man, please don't bug him :)
<ScottK> persia: It turns out that reading debian/copyright doesn't help at all when it comes to discovering the conditions under which one is allowed to freely modify Firefox.
<slangasek> debian/copyright doesn't cover the copyright license of the firefox logo?
<ScottK> Well it's actually a Trademark issue, not a copyright issue.
<ScottK> But no.
<ScottK> I think it's perhaps a policy hole that was opened when we diverged from Debian on allowing such restrictions, but didn't describe how they are to be documented.
<slangasek> ScottK: the whole reason Debian forked was over the inclusion of a restrictive copyright license on the logo to enforce their trademark
<ScottK> OK.  Maybe I'm tangled up in terminology then.
<slangasek> so either something's changed in the licensing that I'm unaware of, or there's a bug in debian/copyright for it not being documented
<ScottK> No, it's in the upstream file called "LEGAL"
<ScottK> Also the argument that we have 'abrowser' so one's right to modify/distribute is unhampere started to seem a bit specious to me when I noticed it's a binary built out of the firefox-3.0 source package.
<ScottK> So I'd suggest it's more correct to characterize it as an unbranded version of Firefox, not as an unbranded alternative that is actually DFSG Free.
<slangasek> I don't see the distinction there
<ScottK> If I grab the Iceweasel source package, I can patch it and upload it and distribute it in any MPL/GPL/whatever the third license is manner I want.
<slangasek> ok, so you're asserting the restrictions on naming mean it's not DFSG Free.
<ScottK> Yes.  I don't think that's in question.
<slangasek> I don't either; I think it's just false ;)
<ScottK> It's just that I think "Don't worry about Firefox not being quite free, it's OK we have abrowser" is meaningless.
<cjwatson> "The license may require derived works to carry a different name or version number from the original software." DFSG#4
<ScottK> OK.  I'm a muppet then.
<ScottK> So why do we have Iceweasel?
<slangasek> ScottK: because the Debian maintainer chose to rename it to free himself from the requirement to get everything approved by MozCorp
<slangasek> it was entirely the maintainer's choice, not something that was considered a requirement (by Debian at large) under the DFSG
<ScottK> I see.
<slangasek> I think it was a reasonable choice to make, because Mozilla's intertwining of copyright and trademark in the license went beyond the pale for free software projects
<slangasek> but I don't think Ubuntu taking the other path means a choice for non-freeness, either
<ScottK> I agree, but I think there's a limit to how far down that path it's reasonable for us to tread.
<slangasek> fwiw, if you want precedent in Debian for software with renaming requirements on modification, try apache and metafont :)
<ScottK> Obviously people will disagree, but it's my opinion (based on the incomplete information I have) that we went a bridge to far.
<slangasek> (but neither of those includes an EULA, of course)
<ScottK> Right.  I'd have preferred we renamed, but understand the choice and accept it.
<ScottK> I don't understand how we could have accepted this (and I hope that at some point it'll be explained why this was OK).
<cjwatson> those of us who were involved weren't exactly comfortable with it either, although we saw different trade-offs; but, reading Mitchell Baker's blog, it looks like it should turn out OK in the ned
<cjwatson> end
<ScottK> I'm deeply curious about Mark's comment in the bug that staying with an older version without the EULA requirement like Fedora did was not an option for us.
<ScottK> To me that would have seemed like the easy right thing to do.
<cjwatson> we can't do that with Firefox; they have a history of bundling security updates with other updates in such a way that they're infeasible to disentangle
<cjwatson> same reason as Firefox has a standing exception for new upstream versions in stable releases
<kirkland> cjwatson: i have an update-motd, removing the initscript, all of the debconf configuration, etc.
<ScottK> I understand we couldn't have released that way, but release is a ways off yet.
<cjwatson> kirkland: what did you put in place of the init script?
<kirkland> cjwatson: nothing
<cjwatson> ScottK: that would have just landed us with the same problem after release, which would have been worse. This has been brewing for a while
<kirkland> cjwatson: pitti was pretty anti-init script for this utility
<cjwatson> ScottK: it was better to get it out of the way
<kirkland> cjwatson: http://people.ubuntu.com/~kirkland/update-motd/
<kirkland> cjwatson: i have not uploaded to universe
<kirkland> cjwatson: i understand it's middle of the night for you, probably
<kirkland> cjwatson: so no request to review
<ScottK> cjwatson: Thanks for taking the time to give me your perspective on it.
<cjwatson> any reason not to upload it?
<kirkland> cjwatson: if you'd like to, though, i'm all ears
<kirkland> cjwatson: well, i do have one question
<kirkland> cjwatson: etc/cron.d/update-motd is being installed into place, rather than being generated via debconf/config/postinst
<cjwatson> I'd just like to say that the objection to the init script was pitti's; I wasn't concerned by it
<kirkland> cjwatson: so users upgrading from 1.5 to 1.6 will get a question about what to do about a conflicting conf file
<kirkland> cjwatson: I understand ;-)  we're all looking out for our best interest...  no complaints from me.
<cjwatson> there are sneaky ways around that, though they may not be worthwhile
<kirkland> cjwatson: i did put a lot of effort into the debconf code, and you recognized that, which I appreciated, but I think you're right in the end... just more room for bugs
<kirkland> cjwatson: so what i did in place of an init script was to add --disable and --enable options to /usr/sbin/update-motd itself
<cjwatson> yeah, I think it was doing the right thing, but ... well, I'm debconf co-maintainer and even I can't just look at that kind of code and say whether it's correct or not
<kirkland> cjwatson: where --disable touches /var/run/update-motd.disabled, and --enable removes it
<cjwatson> ah, ok
<cjwatson> that sounds sane
<kirkland> cjwatson: that gives the flexibility i wanted ...  to be able to turn it off without uninstalling the package or farting around with the cronjob
<kirkland> pitti and i came up with that in a private IRC conversation
<ScottK> kirkland: That doesn't mean it comes back on after every reboot does it?
<cjwatson> much more intuitive than an init script, I expect
<kirkland> ScottK: nope.  it's sticky
<ScottK> OK.  Even though /var/run is tempfs?
<kirkland> it does throw an error message, if you try and run it when disabled
<cjwatson> tmpfs> I was about to say the same thing :)
<kirkland> update-motd is currently disabled.
<kirkland> You might try:
<kirkland>   * update-motd --enable
<kirkland>   * update-motd --force
<cjwatson> so where is the state stored between reboots?
<kirkland> i stand corrected, i didn't realize that /var/run was tmpfs
<kirkland> so it's not sticky
<kirkland> if you want to disable it over boots, remove the cronjob
<kirkland> the enable/disable is merely meant as a simple convenience for short term disabling
<cjwatson> can I suggest /var/lib/ somewhere instead then? it seems like it ought to be sticky
<kirkland> cjwatson: sure, would /var/lib be the best place for it?
<cjwatson> that would be my instinct, though the convention there seems to be to create a subdirectory
<cjwatson> sorry for YA minor change
<kirkland> sure, that's easy
<cjwatson> kirkland: I think you need to exit 0 after parsing --enable as well as after parsing --disable?
<slangasek> kirkland: /var/run is declared in the FHS to be not sticky, so it's a tmpfs ;)
<cjwatson> kirkland: what's the point of echo 2>&1?
<kirkland> cjwatson: well, i mentioned in the manpage that it will enable AND run it immediately
<cjwatson> if you want it to go to stderr, use 1>&2 (or >&2)
<kirkland> cjwatson: but i'm indifferent
<cjwatson> ah, I didn't see that, OK
<cjwatson> that seems reasonable enough
<kirkland> slangasek: thanks ;-)    more knowledge > kirkland
<cjwatson> >>, we hope ... ;-)
<StevenK> Haha
 * slangasek laughs
<kirkland> :-D
<StevenK> "Want device .... used for digging food ..." "A spoon?" "Yes"
<cjwatson> the diff looks good to me otherwise and should mean there's no contention about main inclusion
<kirkland> cjwatson: thanks for catching my broken stderr redirects
<kirkland> cjwatson: i'll exit 0 after --enable, and note in the manpage that it exits immediately (not updating the motd)
<cjwatson> I don't care about that, if you prefer the other behaviour then it sounds completely sensible
<cjwatson> I just noticed the asymmetry, that's all, but life is not necessarily symmetric
<kirkland> cjwatson: do one thing and do it well :-)
<kirkland> cjwatson: enable and exit
<cjwatson> mkay
<kirkland> cjwatson: changes pushed to http://people.ubuntu.com/~kirkland/update-motd/update-motd-1.6/
<kirkland> cjwatson: i'll do some testing of the /var/lib changes, for sanity
<kirkland> cjwatson: what about purging the old /etc/init.d/update-motd script?
<kirkland> cjwatson: on upgrades, i mean
<cjwatson> yes, might be reasonable with a version guard
<kirkland> cjwatson: can you point me to a package with a sample?
<cjwatson> hmm
<cjwatson> alsa-base.postinst
<cjwatson> consolekit.preinst has a more paranoid version that removes it only if unmodified
<cjwatson> dhcdbd.p* has an even more careful and (I think) correct version that removes it only if modified and deals with rollback in the event of failed unpack or configure
<NCommander> StevenK: you floating around?
<StevenK> NCommander: I might be
<Hobbsee> NCommander: only if you test some cds :P
<NCommander> Hobbsee: for what, and why?
<Hobbsee> NCommander: alpha 6!
 * NCommander burns
<NCommander> Ew
<NCommander> *er
<Hobbsee> NCommander: https://lists.ubuntu.com/archives/ubuntu-bugsquad/2008-September/001134.html - get to it!
<NCommander> I can
<Hobbsee> good man :)
<NCommander> I didn't say I would ;-)
 * NCommander runs
<Hobbsee> NCommander: you inferred it, and my Long Pointy Stick of DOOM!!!!!!!!!!!!!!!â¢ is nice and sharp, for if you don't...
<bddebian> Wow, haven't seen the pointy stick in quite a while
<NCommander> Hobbsee: your stick is in metric, and I'm in imperial. Its incompatable with me
 * Hobbsee attacks bddebian with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!!â¢
<Hobbsee> NCommander: actually, i'ts both.
<bddebian> NCommander: Heh, nice one
<Hobbsee> NCommander: so, fail.
<Hobbsee> bddebian: which image are you going to test?  :P
<kirkland> cjwatson: http://people.ubuntu.com/~kirkland/update-motd/update-motd-1.6/debian/postinst
<kirkland> cjwatson: while I'm at it, should I go ahead and 'fix' the conf file overwrite prompt?
<kirkland> cjwatson: would that go in postinst, or elsewhere?
<cjwatson> kirkland: TBH I'd just leave it, it's a one-time thing and only affects alpha users
<kirkland> cjwatson: fair enough!
<cjwatson> postinst is fine
<kirkland> testing looked good, i'm going to upload, and email pitti
<bddebian> Hobbsee: None of the above? :)
<kirkland> he said he'd check email and review
<Hobbsee> bddebian: so you will face the Stick.  Poor Man.
<cjwatson> kirkland: ok, cool
<kirkland> cjwatson: as always, big thanks \o/
<TheMuso> cd
<persia> Is there a tool that can track when packages are no longer built for a given architecture?  I've hit this before, but have again run into some outdated arch-specific binaries for packages that will no longer supply them, and was interested in hunting for some tool to track everything out-of-date towards requesting they be removed as old, buggy, and unlikely to be fixed.
<slangasek> you're looking to track packages that have been dropped on /an/ architecture, but not on /all/ architectures?
<slangasek> if so, I'm afraid the only tool I know of for doing this is dak; unless pitti's NBS script happens to cover that case
<persia> Nope, the NBS script doesn't happen to cover that case.
<persia> And I'll admit to a little trepidation in trying to import Ubuntu into dak just to hunt for these.
 * wgrant wonders where bug #271502 should go.
<ubottu> Launchpad bug 271502 in ubuntu "No ddebs for -backports" [Undecided,New] https://launchpad.net/bugs/271502
<slangasek> persia: yes, I don't think importing the database into dak is the right way to go about it :)
<persia> No, probably not.  And e.g. http://people.ubuntu.com/~ubuntu-archive/testing-ports/intrepid_outdate.html only covers main, which is only part of the list.
<persia> What's the best way to request removal of these?  A bug listing all the individual binaries to be removed on a per-arch basis, or a pointer to the changed source?
<persia> (today's annoyance being the linux-meta binaries for *all* ports)
<slangasek> list of binaries
<persia> OK.  I'll file a bug.  Thanks.
<persia> Also, do you know of any way of generating the _outdated.* output for universe as well?
<slangasek> britney
<slangasek> it just needs to be fed the full Packages lists; this isn't done because the version of britney being used is resource-intensive
<slangasek> switching to a newer one is on my TODO
<persia> So if full packages lists are available somewhere, running britney ought do the right thing?
<slangasek> yes, if britney is invoked correctly
<persia> wgrant: Is that something that would be trivial to set up, or does it need someone to construct the code?
 * wgrant can look into that.
<persia> wgrant: Thank you.
<bryce> slangasek, cjwatson: I've been picking through the changes between our acpi-support and debian's.
<bryce> slangasek, cjwatson:  I found there's a huge amount of changes Debian made, that didn't get rolled into ours.  The package has basically forked in a major way.
<bryce> slangasek, cjwatson:  to try and bring things back closer together, I've cherrypicked a bunch of the changes that look understandable and safe to me.  Here's what I've got so far:  http://bryceharrington.org/ubuntu/ACPI/
<bryce> slangasek, cjwatson:  Anyway, I'd like to hear your comments/encouragement before continuing with the next set of changes.  The next set of changes get into some structural issues that significantly change how this package works, so would like to get your thoughts first.
<bryce> hi cjwatson
<slangasek> bryce: I'm afraid I'm not going to be able to provide much guidance there as far as the correctness of such changes; I've been aware for some time of the Debian forking of acpi-support, but haven't had the bandwidth to chase it up
<bryce> slangasek: hmm, do you think I should continue with pulling in selected debian changes?
<slangasek> for intrepid?  probably only ones you confirm fix bugs :)
<bryce> are Debian bug fixes ok?
<bryce> so far I've just been pulling in ones that look logically correct to me just by eyesight
<bryce> well, and a few that seem appropriate for thinkpads...
<tjaalton> I think acpi-support upstream should be debian and not us..
<tjaalton> since we don't have anyone maintaining it ;)
<slangasek> bryce: if they're valid bugfixes that are relevant to us, sure; there's no requirement that you file bugs in LP before fixing them
<bryce> tjaalton: I've been wondering about that
<bryce> slangasek: okie doke.  I plan to look through LP and see if we have bugs that these changes fix.
<sbeattie> asac: ping
<slangasek> persia, TheMuso: any expectations of testing UbuntuStudio alpha-6 soon?
<persia> There was some testing going on 12-3 hours back.  I'll see if I can get the results somewhere.  Where do you need them?
<asac> sbeattie: ?
<sbeattie> asac: was just wondering if bug 271654 was known already
<ubottu> Launchpad bug 271654 in ubufox "intrepid: on first run, firefox opens homepage in 2 tabs" [Undecided,Confirmed] https://launchpad.net/bugs/271654
<slangasek> persia: on http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all
<sbeattie> and whether ubufox was the right place to file it.
<asac> StevenK: no its not
<asac> sbeattie: can you reproduce this outside of liveCD?
<sbeattie> asac: this was post install
<sbeattie> asac: should have made it clearer in the bug report, but i'm a bit tired.
<StevenK> asac: Hm?
<asac> sbeattie: oh ok
<persia> slangasek: Aha!  It's the amd64 variant that didn't get *any* testing.  I'll see if I can do anything about that.
<asac> StevenK: sorry .. not you ;)
<slangasek> persia: ok, cheers :)
<asac> sbeattie: does this also happen when you move .mozilla away and start firefox?
<sbeattie> asac: i can reproduce each time I start firefox after doing rm -rf ~/.mozilla/
<kagou> Hi
<asac> sbeattie: ok thanks. please add that info to the summary.  (e.g. reproduce by removign .mozilla)
<sbeattie> asac: sure thing.
<stefan__> hey, kann jemand Ã¼ber die konsole eine tv-karte initialiesieren?
<\sh> asac: with ia32-libs 2.2ubuntu13 flashplugin10 works now as expected...(well, I need to test the rtmp connections still)
<stefan__> hallo?
<\sh> stefan__: this is an english speaking channel
<wgrant> !de
<stefan__> to do that?
<ubottu> Deutschsprachige Hilfe fuer Probleme mit Ubuntu, Kubuntu und Edubuntu finden Sie in den Kanaelen #ubuntu-de, #kubuntu-de, #xubuntu-de und #edubuntu-de
<stefan__> why is nobody there?
<wgrant> I am not here.
<stefan__> lucky Answer
<\sh> stefan__: your question is better suited in #ubuntu (this is a development channel only)
<stefan__> oh, take sure, sorry
<stefan__> uhhhh
<persia> stefan__: The answer to your question is "Ja", but the procedure you need is best collected in one of the channels ubottu mentioned.
<asac> \sh: rock
<\sh> asac: uploaded
<\sh> asac: and air works too...(at least the installation ;))
<pythonic> can i build a package for ubuntu on debian? using debootstrap?
<azeem> sure
<pythonic> which release should i use? intrepid?
<azeem> that depends which release you want to build it for
<pythonic> i'd like to submit the package for inclusion in ubuntu
<azeem> that has nothing todo with building, Ubuntu does source-only uploads
<azeem> pythonic: you should contact #ubuntu-motu for that
<pythonic> yes, but i should check that it builds on some given release
<pythonic> k, thanks
<\sh> asac: http://paste.ubuntu.com/47990/ <- I just installed the "Color Browser" app from the air showcase...and I ran it from its installation dir...this is the only cruft I have left.
<asac> \sh: sigh
<\sh> but it works :)
<asac> maybe ia32-libs should be ia32-all-libs-in-main ;)
<asac> \sh: yeah ... most likely just broken theme engine for KDE users
<\sh> asac: the libqt4engine.so for sure...
<\sh> what bugs me is gio modules ;)
<asac> oh .. i only looked at the bottom
<\sh> asac: air app installer... Failed to load module: /usr/lib/gio/modules/libgiogconf.so
<\sh> and so on
<asac> shouldnt gio be in ia32-libs too?
<\sh> that's libgio0 right?
<\sh> dpkg _l
<\sh> grmpf
<\sh> gvfs
<\sh> ah...I think that's not important
<\sh> air installer uses gtk file dialogs...and I think it tries to use now the gvfs stuff..the modules are in the gvfs server package...and I wonder if that is sane to include into ia32-libs
<therealjosh> hey
<therealjosh> i am wondering, i have made a program with is a budget program written in gtk. How would I go about getting it into ubuntu? I know intrepid is already frozen, but is j??? a likely target? where do I go to find out about the process?
<liw> therealjosh, https://wiki.ubuntu.com/UbuntuDevelopment is a good place to start
<therealjosh> so do i need to get involved in the MOTU team just for one package?
<liw> no
<liw> the easiest way to get your package into Ubuntu would be to find someone to do the actual packaging for you, or with you; a MOTU could help you with that
<liw> on the other hand, it would also be possible to go via Debian -- find a Debian developer to help with the packaging, and then the package will get into Ubuntu as well
<therealjosh> So I should ask on #ubuntu-motu if anyone would like to package my application?
<therealjosh> that would be better because it gets more coverage, correct?
<therealjosh> thanks
<therealjosh> i have to go
<Robot101> https://bugs.launchpad.net/ubuntu/+source/ffmpeg-debian/+bug/254201
<ubottu> Ubuntu bug 254201 in ffmpeg-debian "feature regression: ffmpeg lacks some video encoders (like h263+, MPEG4, maybe more...)" [Undecided,Triaged]
<Robot101> does anyone know the rationale behind requesting the removal of these?
<Robot101> it's totally cripped several video-capable sip/jingle clients including empathy and ekiga :(
<Robot101> *crippled
<siretart> Robot101: well, the archive admins don't accept mpeg based encoders in the 'main' archive
<siretart> Robot101: the package has a script that disables some mpeg 1 decoders from ffmpeg, see debian/strip.sh in the source package
<seb128> Robot101: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433287
<ubottu> Debian bug 433287 in ffmpeg "ffmpeg" [Unknown,Open]
<Robot101> so it was just an accident that they were there for 4 or 5 years before being removed?
<siretart> more or less
<Robot101> there was me thinking ubuntu were being cool and more functional than debian
<Robot101> so can they go in multiverse?
<seb128> Robot101: I'm not sure it has been discussed for ubuntu
<seb128> siretart: is the discussion you had a debian or an ubuntu one?
<Robot101> seb128: they were in everything up until intrepid
<siretart> seb128: both
<Robot101> now intrepid's ffmpeg is crippled similarly
<Robot101> debian's not had the encoders for a long time
<siretart> seb128: the end of the discussion with ubuntu was "well, if debian doesn't accept them, we won't as well" (shortened)
<seb128> siretart: who did you discuss this with?
<Zdra> I don't know if medibuntu is kind of "official" but at least non-free codecs should be added there
<siretart> seb128: that was in sevilla with at least pitti and elmo in the room
<seb128> Zdra: no it's not
<seb128> siretart: sevilla, that was ages ago
<Robot101> I've not found a very good justification for them being removed in Debian either, tbh
<seb128> siretart: we had no issue with those until now, I'm not sure why that's an issue now
<cjwatson> bryce: pretty much what Steve said - I'm not going to be able to provide specific review unfortunately, so his general guidance sounds about right
<siretart> seb128: so we do accept mpeg encoders in the 'main' component?
<Robot101> I can understand MPEG4 having people enforcing it, but H263 is very, very old...
<seb128> siretart: I don't know and I'm not the one to decide, I think that deserve some thinking and discussion
<broonie> Robot101: There's rather a lot of money to be made enforcing it.
<siretart> seb128: sure. each time I started that discussion it was.. difficult
<Robot101> broonie: patents on H263?
<siretart> because nobody wants to decide on that subject
<seb128> siretart: is h263 that problematic?
<broonie> IIRC, yes.
<cjwatson> bryce: looks like you're doing the right kind of thing at least from looking at the changelog, though
<siretart> seb128: I have no idea, TBH. there are patents on that, but I have no idea if its being enforced
<Robot101> does anyone have any /actual/ source of knowledge on this, rather than heresay? :)
<Robot101> s/ere/ear/
<Hobbsee`> oh, so this is what server everyone's on.  I wish freenode wouldn't curl up and die like that.
<seb128> siretart: I think that should be taken to the technical board
 * broonie is seeing if he can dig up some notes from when he worked on this.
<siretart> Robot101: use google patent search for h263
<Robot101> like does Canonical have lawyers they can ask and get an answer
<siretart> seb128: again? - well, I welcome you to mail the TB, CC'ing me.
<Robot101> siretart: patents merely existing isn't a problem, it's if they're actively enforced
<cjwatson> yes, we do; technical-board would be the place to start for that
<siretart> seb128: I'd love to see an unrestricted ffmpeg in ubuntu
<persia> Robot101: Even a laywer can't necessarily answer the question "Is it safe to distribute foo".  There are many jurisdictions, and each is different.
<cjwatson> (if it hasn't been through the TB already of course)
<siretart> cjwatson: the problem is determining if a codec 'is actively enforced' or not
<cjwatson> persia: given what patents are like, our question is usually a bit more like "can we afford to distribute foo, I think"
<Robot101> persia: right, but presumably Canonical's lawyers are used to opining on such vague questions :)
<cjwatson> siretart: yes, I'm familiar with the problem
<persia> cjwatson: Well, perhaps, but I think it's a matter for the TB, rather than a lawyer hired by a sponsor.
<siretart> cjwatson: from what I've heared from the ffmpeg people is that they are not enforced against non-commercial projects but for companies that make a profit from them
<siretart> some ffmpeg developers are hired by companies that pay patent fee to develop and sell their products
<cjwatson> persia: the body who would be sued, in practice, is Canonical; therefore Canonical deserves the opportunity to decide
<Robot101> siretart: on what exactly? MPEG4 I can very much understand, the MPEG people are very active in enforcing. H263 I'm not so certain.
<siretart> it is very unclear if ubuntu would be considered as 'non-profit' in that context
<siretart> I'm off for lunch, brb in 45min - cu later
<cjwatson> persia: for example, there is a history (and I'm afraid I forget the specifics) of Mark saying that he was OK with distributing certain enforced-patent audio codecs but not others
<persia> cjwatson: Er.  Well.  Perhaps.  I don't think it *should* be that way, but I can see that point
<cjwatson> as in "I think this is worth it"
<cjwatson> (actually I think it may have been more like "bring it on" but as I say I forget the specifics :-) )
<Robot101> :P
<persia> cjwatson: I understand.  The distinction is Mark as "representative of Canonical" and Mark as "leader of Ubuntu".  Anyway, as I said, given the current environment, it may not matter, especially for the ffmpeg question.
<cjwatson> there are certainly things that might be considered too much of a risk, though; Canonical in principle has quite deep pockets and it could get ugly
<persia> Sure.  Canonical being sued is significantly less than ideal.  That Canonical is the default body getting sued is likely also so.  That said, this isn't the forum to address that.
<sykopomp> http://www.kroah.com/log/linux/lpc_2008_keynote.html I'll just leave this here.
<sykopomp> ;)
<stdin> sykopomp: ok, now leave then
<persia> sykopomp: I'm not sure how that's relevant.
<sykopomp> persia: Blame stdin, he told me this is where it belonged :)
<elky> sykopomp, did he?
<stdin> no, I didn't
<sykopomp> persia: and I'm not sure how something directly related to ubuntu development is irrelevant.
<elky> sykopomp, i'm not sure how berating the developers is a help in any way, shape or form.
<persia> sykopomp: It's claims by someone that some company doesn't contribute to some selected subset of projects based on unavailable data.
<sykopomp> elky: berating?
<seb128> cjwatson: hi
<sykopomp> persia: mmhmm
<mvo> sykopomp: there is a replay at http://mdzlog.wordpress.com/2008/09/17/greg-kh-linux-ecosystem/ that is worth reading imo
<sykopomp> persia: because the kernel is a meaningless subset that canonical accepts as perfect, and thus unworthy of man-hours of patching.
<persia> sykopomp: Considering that the majority of developers do not have a formal relationship with that company, it's at least confused, and not likely contributory to further development of Ubuntu.
<seb128> cjwatson: thanks for the comments about the new GTK, it made me uneasy too since that's somewhat a compatibility change, I mailed the GNOME list about reverting it for this cycle
<stdin> sykopomp: please stop talking about things which you have no clue about, ie: everything
<cjwatson> seb128: great, thanks
<sykopomp> stdin: clever retort. Did you learn that in Internet School?
<seb128> cjwatson: I think we should revert the change for ubuntu in any case, will do that in the next upload, is that something which is required to get a working installed in alpha6?
<stdin> sykopomp: nope, came up with it all by myself
<sykopomp> stdin: your mum must be proud.
<sykopomp> mvo: and thank you, that looks interesting :)
<sykopomp> mvo: was sort of hoping for an actual reply that didn't involve made-up logic (re: stdin)
<elky> sykopomp, carry along now, and come back when you have something constructive to contribute.
<sykopomp> elky: 'bawww'
<Hobbsee> sykopomp: do you have something useful to add?
<Hobbsee> sykopomp: and personal attacks are unwelcome in this channel.
<elky> (and yes, attacking an entire company and an entire project is a personal attack)
<sykopomp> Hobbsee: it's good to know personal attacks are unwelcome. That's the kind of rule that builds strong, mature communities. :)
<elky> sykopomp, feel free to read the code of conduct some time too.
<sykopomp> elky: link?
<Hobbsee> !coc
<ubottu> The Ubuntu Code of Conduct to which we ask all Ubuntu users to adhere can be found at http://www.ubuntu.com/community/conduct/
<sykopomp> thanks
<sykopomp> You're all a lovely bunch, but I need my beauty sleep. Don't get your panties in a bunch, I'm not taking a dump on your work. Don't take inquiry as trolling, this wasn't ;)
<cjwatson> stdin: code of conduct applies to you too. You're out of order
<sykopomp> nite, all, and happy hacking.
<stdin> cjwatson: yes, I was getting annoyed. so I stopped responding
<broonie> Robot101: My grovelling appears to indicate a possibility of crossover between MPEG and H.263 IP; I've got a feeling that may be a mistake for H.264, though.
<Robot101> broonie: right, H.264 ~= MPEG4
<Robot101> I thought H.263 and MPEG4 were developed quite separately, and MPEG4 was later adopted as H.264
<broonie> Yeah, that's why I've got a feeling it may be a mistake.
<broonie> but it's possible that some of the lower level stuff got shared while the overall structures are very different.
<siretart> Robot101: well, I think I kind of agree with you that we can/should reenable h263 again.
<siretart> Robot101: what I want to avoid at any price is that after reenabling I get approached by the archive admins rejecting the package
<siretart> Robot101: this has happend to be already in debian, where we enabled _all_ encoders and had to implement this debian/strip.sh solution
<siretart> Robot101: so what I actually ask for is for some guidelines what encoders are okay to leave in and what are to be disabled
<seb128> siretart: really you should take that to the technical board so we have a clear decision taken on the topic
<siretart> seb128: yes, perhaps you're right.
<siretart> seb128: on my todo list is also to investigate the mplayer package, which also seems to contain all encoders in source and approach debian's ftpmasters with that. I didn't get to that yet, however
<Robot101> that's likely to just have the functionality asked to be removed from mplayer too
<siretart> but perhaps you're right and I should contact the tb in paralell.
<seb128> siretart: speaking about todo, do you think you will update the ffmpeg snapshot before intrepid? ;-)
<siretart> seb128: definitly not.
<seb128> siretart: why not?
<siretart> seb128: ffmpeg has changed both API and ABI last week, I do not have the ressources to fix all reverse dependencies
<siretart> seb128: the API changes aren't that bad, but we still need to touch every package because the headers get installed into an other location, so we have to adjust all CFLAGS
<seb128> siretart: can't you take a snapshot slightly less recent which doesn't break the compatibility?
<siretart> the header change commit was done somewhen in april or may, we could perhaps update to something around that date, though
<siretart> however since we are in feature freeze anyway, I think working on the package in experimental and clearing the patent issue has is more important, no?
<siretart> seb128: why do you want to have ffmpeg updated? do you have a specific bug in mind?
<seb128> siretart: no, I didn't follow the details but some bugsquader said there is several good reasons we should update, he mailed one of the ubuntu lists too about that
<siretart> seb128: yes, I remember that guy. ignore him
<siretart> seb128: he wants AMR support, which he confused with the AAC decoder, that got merged in early september this year
<seb128> siretart: he's doing quite some good work on lot of bugs for some weeks and have good points often, not sure why you want to ignore him
<siretart> on this point, the suggestion is totally unreasonable.
<siretart> he was pretty demanding on that bug. and started a bug status change war. I decided to ignore him from then on
<\sh> siretart: this amr stuff was this "external zip file with the not-known-royalty-free-source inside" right?
<siretart> \sh: kind of. you need to build it against an libamr, which has unclear licensing AFAIUI
<seb128> siretart: I didn't read the bug, but I'm not convinced that using 6 month old snapshots is good either
<siretart> unclear or incompatible
<\sh> siretart: yeah...got that during combots crap
<\sh> unclear...there was some patent Ã¼pending or so
<seb128> siretart: I'm pondering making gst-ffmpeg uses its ffmpeg copy again and not ffmpeg-debian
<siretart> seb128: gst-ffmpeg's copy is even older, no?
<seb128> siretart: they rolled a new tarball on 2008-09-03, let me look at what version they used there
<seb128> siretart:
<seb128> "	* ffmpegrev:
<seb128> 	Update our 'prefered' ffmpeg snapshot to rev 15004. This has the fix for a nasty
<seb128> 	wma2 decoding regression."
<seb128> siretart: do you know if this revision is a recent one?
<siretart> r15004 | michael | 2008-08-28 02:46:09 +0200 (Do, 28. Aug 2008) | 2 lines
<seb128> siretart: ok, so no it's not older
<siretart> ah, so they updated the copy
<seb128> yes
<siretart> well, that date has the header already installed to a different location
<seb128> that's one reason why this guy started to request the ffmpeg-debian version
<seb128> the new gst-ffmpeg fixes lot of issues
<siretart> updating the package to that version would instantly break all other packages using ffmpeg
<seb128> but we don't benefit of those because we use ffmpeg-debian which is clearly outdated
<seb128> siretart: how many packages are we speaking about?
<siretart> if you can convince the security team to use the embedded copy, it might be an option to use the internal ffmpeg
<wgrant> Why would we want to do that?
<siretart> everything build-depending on libavcodec-dev, libavformat-dev, libavutil-dev and libpostproc-dev
<seb128> wgrant: because siretart refuses to update ffmpeg-debian and updating it would fix lot of issues
<siretart> not sure about about libswscale-dev, I think not but might be wrong
<seb128> wgrant: an easy way to get those fixes for gstreamer users would be to use the upstream gst-ffmpeg
<wgrant> I don't blame siretart for not wanting to.
<siretart> seb128: I don't refuse to update the version. I rather say that I don't have the ressources to fix the resulting breakage
<wgrant> A better way is to hit ffmpeg upstream harder until they become less retarded.
<seb128> wgrant: that will not make intrepid suck less for our users
<siretart> wgrant: a better way would be to help me with ffmpeg maintenance
<wgrant> seb128: Perhaps not, but it would make everybody's lives easier in the long run.
<seb128> siretart: that's probably not the first ffmpeg breakage no? you have no idea about many packages are concerned? I'll have a look to that number
<seb128> wgrant: not discussion that but that's orthogonal to the intrepid issue
<wgrant> siretart: My time is unfortunately limited these days.
<seb128> discussing
<siretart> seb128: last time I counted it was about ~40 packages
<siretart> including universe
<siretart> for main its not so bad, but it includes packages like xine, kino and the like
<siretart> seb128: updating to a newer ffmpeg upstream version requires to forward port the bounch of patches we carry in the package. OTOH, all of them were merged or no longer necessary versions > early september
<seb128> siretart: I'll discuss with the security team about using the gst-ffmpeg copy for intrepid and we should upgrade the snapshot when intrepid+1 opens
<siretart> seb128: yes, updating the snapshot for intrepid+1 is on my todo list. actually, I'm working on having a more updated package in debian/experimental, which I'll sync to some PPA
<siretart> so we have the package ready when jaunty opens
<seb128> siretart: looks good, thanks
<psyke83> \sh: thanks for the work on ia32-libs. As per bug #192888, you removed libflashsupport - but we still need libasound2-plugins added. Would you like me to open a new bug or will I change the status back to assigned?
<ubottu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents when using libflashsupport" [High,Confirmed] https://launchpad.net/bugs/192888
<\sh> psyke83: libasound2-plugins is in...
<psyke83> \sh: awesome, thanks. I didn't see it in the changelog
<\sh> psyke83: it was already in :)
<\sh> libasound2-plugins
<psyke83> ah... I thought that it wasn't
<\sh> psyke83: but I wonder if that helps, when some apps are looking under /usr/lib/... instead of /usr/lib32/....
 * \sh declares, that he has no clue about nspluginwrapper and his function ;) so could be that it rewrites all the cruft
<psyke83> \sh: did you test PulseAudio & Flash 10 RC? Install "padevmon" to get access to the PulseAudio GUI utilities, run "asoundconf set-pulseaudio", restart firefox and play some flash content - see if it uses pulseaudio
<psyke83> asac: ping re: testing the pulseaudio output with flash 10
<psyke83> \sh: no clue either ;)
<asac> psyke83: so whats the problem?
<\sh> psyke83: work
<psyke83> asac: there's no problem, I hope. Remember yesterday I suggested that you test Flash 10 output
<\sh> psyke83: and flex is working again ;)
<asac> psyke83: does pulse plugin 32bit lib work with flash through nspluginwrapper?
<psyke83> asac: i.e. make sure it lists itself as a pulseaudio client
<\sh> asac: it works via alsa-plugin of pa
<lool> slangasek: Hey, my nice upstream filed a MIR for python-dateutil; BTW allow me to clarify: it's needed for an embedded lib (storm); in the mean time, a new storm came out with twisted integration
<cjwatson> 10:41 <seb128> cjwatson: I think we should revert the change for ubuntu in any case, will do that in the next upload, is that something which is required to get a working installed in alpha6?
<cjwatson> seb128: sorry, I just noticed I missed that question
<psyke83> asac: on a 32bit system, nspluginwrapper works fine... the only problem I noticed was some intermittant times when flash would "disappear", I still need to test that more
<lool> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/python-dateutil/+bug/271680 and https://wiki.ubuntu.com/MainInclusionReportPythonDateutil
<ubottu> Ubuntu bug 271680 in python-dateutil "MIR for python-dateutil" [Undecided,New]
<cjwatson> seb128: no, we've fixed the installer for alpha-6 to use page_size=0
<asac> psyke83: ok. i think i have to wait a bit more before the new ia32 libs is published
<\sh> http://www.youtube.com/watch?v=R13Gu3fr6Ug <- works quite nicely
<seb128> cjwatson: ok good, I've the new GTK version ready on my disk with that changed, I'll upload after alpha6
<psyke83> ah yes, I forgot
<lool> slangasek: If you like, I can look into updating storm to the latest upstream which came out; I don't think the version currently in the archive is widely in use, but I'm not sure
<lool> slangasek: It would be nice to drop an embedded copy of it for sure
 * lool hugs seb128 
<\sh> asac: http://launchpadlibrarian.net/17716833/ia32-libs_2.2ubuntu13_amd64.deb :)
<seb128> hey lool
 * seb128 hugs lool
<seb128> lool: did you read my question about the glib update? ;-)
<lool> seb128: I sent you an email on that glib stuff, you were disconnected when I saw your ping
<seb128> ah ok
 * seb128 looks
<seb128> lool: ok thanks
<psyke83> asac: I'll ping you again when the package is published and in the repos, though I reckon it works, as \sh confirms. As for the PulseAudio issue, we just need Luke's passthrough patch to alsa-plugins and we can fix bug #198453
<ubottu> Launchpad bug 198453 in pulseaudio "Default ALSA device must use PulseAudio, otherwise ALSA applications may fail" [Medium,Confirmed] https://launchpad.net/bugs/198453
<asac> psyke83: thats nice
<asac> psyke83: is flash 10 already updated in archive too?
<psyke83> asac: no, but the debdiff is available. I can build the package for you if you want to test it soon
<\sh> we need an UVF Exception right?
<psyke83> asac: I have it in my PPA, as well (though it differs slightly from the proper version, as it deletes a configuration file that the previous version set to disable windowless mode)
<\sh> or does flash has a standing exception, universe wise?
<asac> \sh: for flash?
<\sh> asac: yepp
<psyke83> \sh: yes, though I think flash gets an exception due to vulnerability issues. And the tarball is not archived on the labs.adobe.com server, so the package will break
<\sh> flash10 i mean
<NCommander> ACK, SPAM
<psyke83> \sh: there was beta 1, beta 2, rc and rc2, all on the labs.adobe.com server. The older tarballs are deleted when they are obsoleted by a newer release
<\sh> psyke83: do you have any clue on the final release date for flash10? eventually we need to push the final through updates
<psyke83> \sh: I would imagine very soon, as the version string is using the rXX pattern - so it's a "genuine" release candidate already
<asac> \sh: i think we should file a bug ... just to document this
<asac> \sh: e.g. "feature freeze exception for flash 10 updates" ... or something
<\sh> asac: yepp...but after release we need an SRU statement anyways...
<asac> \sh: i have exception granting power for mozilla packages. we should check sispoty if that falls in that realm
<asac> \sh: well, nothing to bother now :) ... maybe we get final for final :)
<psyke83> \sh & asac: can we not convert bug #257403 to an SRU or FFe request?
<ubottu> Launchpad bug 257403 in flashplugin-nonfree "Update Flash plugin 10 to the new RC" [Wishlist,Confirmed] https://launchpad.net/bugs/257403
<psyke83> that has the debdiff for the latest release
<\sh> moins mr. kwwii :)
<lool> seb128: BTW I still have this extra /ext/xdg/menus file provided by gnome-menus; should I remove it by hand?
<seb128> lool: no, the preinst should clean those on upgrade
<lool> Ok; wasn't sure whether I'd get it as an intrepid upgrade
<\sh> psyke83: yes..please convert it to an FFe, subscribe motu-release to it
<\sh> psyke83: if you need an sponsor, I'm still at office/home until sunday...after that I'm gone for at least one week to work on new hardware in our DCs
<psyke83> \sh: forget the n00b question. Is it sufficient to edit the title & description to signify it's a FFe, then subscribe motu-release? Do I need to do anything else with the package status?
<psyke83> or "distribution" status
<\sh> psyke83: there is a link on the wiki with the howto file ;) give me sec
<psyke83> \sh: I guess this: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20for%20new%20upstream%20versions
<psyke83> \sh: well, not new upstream versions, since we grab the tarball in the script
<\sh> psyke83: yes..but you change the version to something else, or is it just a revision fix.. but no. rc2 introduces some new features, right?
<\sh> psyke83: https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze%20for%20new%20upstream%20versions <- that's the one
<psyke83> \sh: there is a changelog on the labs.adobe.com site listing improvements and bugfixes, but only listing fixes from rc1 -> rc2. The version we have currently is beta 2 (the sequence: beta 1, beta 2, rc1, rc2). I'll paste it anyway, it's better than nothing
<\sh> but more likely it's more a bug fix only update...so the paragraph under the FFe description is more correct...the bug is ok, put the changelog in it, put in debian/changelog a (LP: #<no>) and ok...
<\sh> psyke83: hmm...is there no changelog anymore from beta2 to rc1? it can be merged then
<psyke83> \sh: the changelog is removed from the site, I think... it's not archived anywhere
<psyke83> \sh: the debdiff is compliant: http://launchpadlibrarian.net/17642343/flashplugin-nonfree_10.0.12.10ubuntu1.debdiff
<psyke83> the first line of the changelog lists the LP#
<psyke83> *changelog for older releases
<psyke83> it's on a static page that's updated with each release: http://labs.adobe.com/technologies/flashplayer10/releasenotes.html#fixed
<\sh> psyke83: yes..Just paste the complete page in ;)
<psyke83> cool, thanks
<\sh> known issues+fixed issues
<psyke83> \sh & asac: I've updated bug #257403 to a FFe, if you want to give it an ack
<ubottu> Launchpad bug 257403 in flashplugin-nonfree "[Intrepid] FFe request for Flash 10 RC2 (10.0.12.10)" [Wishlist,Confirmed] https://launchpad.net/bugs/257403
<\sh> psyke83: I can't :) /me not motu-release :)
<psyke83> \sh: ah, right... heh. Well motu-release were already subscribed
<psyke83> \sh: I thought that sponsoring and giving ack were similar
<\sh> psyke83: nope..sponsoring means, uploading your package with my powers ,-)
<\sh> asac can do that too :)
<lool> seb128: Oh cool, new gtk drops the xrr call which was causing screen flickers!
<norsetto> asac, seb128: when you have some time, can you please check bug 250290?
<ubottu> Launchpad bug 250290 in devhelp "Copy to clipboard causes segfault" [Medium,Confirmed] https://launchpad.net/bugs/250290
<asac> norsetto: is #485644
<asac> the debian bug for this?
<asac> otherwise i dont see in debian changes that there is a crash fix
<norsetto> asac: yes, thats the bug that was fixed in Debian, same as our bug 250290
<ubottu> Launchpad bug 250290 in devhelp "Copy to clipboard causes segfault" [Medium,Confirmed] https://launchpad.net/bugs/250290
<norsetto> asac: you may be confused since they fixed the fix so that t won't ftbfs on alpha
<norsetto> asac: I can confirm that this also fixes bug 257272 and bug 264847
<ubottu> Launchpad bug 257272 in devhelp "devhelp crashed with SIGSEGV in dh_gecko_utils_search_find()" [Medium,Incomplete] https://launchpad.net/bugs/257272
<ubottu> Launchpad bug 264847 in devhelp "hangs on when changing font size" [Medium,Triaged] https://launchpad.net/bugs/264847
<asac> norsetto: looks ok for me then. but i think seb128 has the say about the timing of that upload
<norsetto> asac: sure, thanks
<tseliot> Riddell: does KDE 4 have a GUI to configure touchpads? If not, which part of KDE should I hack on to add such functionality?
<tseliot1> Riddell: my connection died. Did you receive my message or shall I write it again?
<stgraber> bryce: Do I understand it right that the latest fglrx still doesn't fix the new X server support issue ?
<ion_> It came through.
<tseliot1> stgraber: yes, that it correct
<tseliot1> is
<stgraber> so, no fglrx for Intrepid ?
<Riddell> tseliot1: i don't think there is a gui for touchpads it should be under mouse in system settings
<Riddell> there was once ksynaptics but i neverf used it
<tseliot1> Riddell: ok, thanks I'll have a look at it
<seb128> lool: right, I marked the bug fix commited, I've the new version ready locally
<seb128> norsetto, asac: did anybody look at updating to the current version?
<seb128> asac: feel free to upload whenever you want
<norsetto> seb128: if you mean from upstream I haven't
<seb128> norsetto: alright, there is a new version so feel free to do the update too if you want ;-)
<norsetto> seb128: willco
<superm1> stdin, tseliot1, so since fglrx looks like it's probably not going to be ready quick enough, i think this is my current plan: I'll upload 8-9 to intrepid, and then downgrade the x server on an intrepid machine to the hardy version.  hopefully still be able to test other integration pieces so that when it comes time for an SRU, everything else is ready/been tested.  sound sane?
<tseliot1> superm1: are you planning to patch the driver for kernel 2.6.27 or are you simply planning to try the driver and see how it goes?
<tseliot1> either way I don't see any problems with a new upload of the fglrx driver
<superm1> tseliot1, oh right, i forgot it didn't build on 2.6.27
<superm1> i'll have to see how difficult it is to patch for it
<tseliot1> ok
<superm1> can an archive admin comment why was gcc-3.3 demoted to universe in hardy and intrepid?
<StevenK> Presumably, because nothing in main required it
<superm1> well fglrx now needs it to build as of 8-9
<ScottK> In fact there are a determined effort to make that the case.
<ScottK> are/was
<superm1> so this is one of those things that will need to be sorted out so that an SRU will be possible when the xorg 1.5 support is in it
<Keybuk> superm1: why doesn't fglrx build with gcc 3.4 ?
<Keybuk> err 4.3
<superm1> Keybuk, it's from a binary that's already shipped with the driver
<superm1> Keybuk, libAMDXvBA.so.1.0
<superm1> requires libstdc++.so.5
<superm1> so when i say build, i'm referring to dpkg-shlibdeps borks out unless you've got libstdc++5 installed
<Keybuk> that's ... old
<Keybuk> I mean, I like outdated C++ template libraries as much as the next person, but that's still old
<jdong> do we have any AMD buddies we can poke to "fix" that?
<superm1> bryce, can you bring it up in your next discussion?
<superm1> in the event that it's not sorted out in the next driver release though, only solution for us would be to re-promote gcc-3.3 for intrepid
<s0u][ight> hello is intrepid using the drivers from compat-wireless?
<slangasek> lool: updating storm doesn't sound like a good thing to focus on
<norsetto> asac, seb128: devhelp diff.gz for 0.20 attached to bug 250290 if you prefer this to a merge with debian 0.19.1-5
<ubottu> Launchpad bug 250290 in devhelp "Copy to clipboard causes segfault" [Medium,Confirmed] https://launchpad.net/bugs/250290
<ldp> YAY ME!!
<_Zeus_> anyone know how i can roll back from kernel 2.6.27-3 to -2?
<_Zeus_> it's not in the repos
<ldp> I mean, hello..
<mathiaz> slangasek: kirkland said that update-motd has been promoted to main. This was the blocker for landscape-client to be working in the -server installer.
<mathiaz> slangasek: do you plan to respin a server iso for alpha6 or it's too late ?
<slangasek> I wasn't planning to respin, no
<slangasek> working in the installer - as an install option?
<mathiaz> slangasek: there is an install option.
<mathiaz> slangasek: one of the choice is "Configure landscape client."
<mathiaz> slangasek: if you choose it, it won't work because landscape-client cannot be installed.
<slangasek> ok
<slangasek> that seems worth respinning, for; you'd be able to test in short order?
<mathiaz> slangasek: sure.
<mathiaz> slangasek: once the isos are available I can test all of the test cases in a couple of hours.
<mathiaz> slangasek: but before you start respinning make sure that update-motd is published in main and that it will land on the -server isos.
<slangasek> tkamppeter: foomatic-db 20080918-0ubuntu1> we're in a milestone freeze right now, please don't be uploading packages in the middle of the freeze that cause out-of-dateness on the CD images
<slangasek> mathiaz: ah, well, it's not in main yet :)
<slangasek> cjwatson: were you going to promote update-motd?
<mathiaz> slangasek: pitti promoted it according to kirkland
<kirkland> https://bugs.launchpad.net/bugs/260443
<ubottu> Ubuntu bug 260443 in update-motd "main inclusion request: update-motd" [Medium,Fix released]
<kirkland> pitti wrote "Promoted to main." in his last comment.
<bryce> superm1: sure I'll email them now
<superm1> bryce, okay thanks
<slangasek> mathiaz: ah, 26 minutes ago, ok :)
<slangasek> mathiaz: so I'm looking at stale data
<bryce> superm1: do you have a bug id# btw?
<superm1> bryce, yeah bug 271794
<ubottu> Launchpad bug 271794 in fglrx-installer "Re-promote gcc-3.3 to main" [Undecided,Fix released] https://launchpad.net/bugs/271794
<bryce> thanks
<\sh> hmmm..does the last upload of fglrx-installer mean that it ati non-oss drivers are working now on intrepid? ,-)
<tjaalton> no
<\sh> I guessed
<\sh> hopefully 8.10 will have new xorg love
<tjaalton> it already has
<tjaalton> just not fglrx love
<\sh> (catalyst)
<tjaalton> or, fglrx has no love for new xorg
<superm1> \sh, it just means that it will compile against 2.6.27, so if you pin the x server at hardy's you can try to do regression testing on the other integration pieces
<superm1> for when we end up doing an SRU for fglrx
<\sh> superm1: na...I'm happy right now with the ati/radeon oss driver...I'm just waiting until AMD releases their binary only driver to the public as LGPL
<superm1> \sh, personally i'm more confident in the open driver getting more featureful that the closed driver doesn't need to be used as much
<superm1> \sh, there are closed pieces in that driver that go into realms of IP that will keep it from opening up for a very very long time
<\sh> superm1: well, if AMD is releasing the internal specs to the oss ati driver devs , cool...but it would really be an advantage when they just free the code
<Treenaks> \sh: The chance that the non-free driver has bits licensed from others in it is high
<superm1> \sh, if they ever do decide to free the code, it's only going to be portions, and i expect  those portions wouldn't be as useful
<superm1> what Treenaks said is what i was alluding to.
<Treenaks> that's why the opening of Java is taking/took so long
<slangasek> superm1: mythbuntu alternates looking any good? :)
<davmor2> slangasek: I draw the line at testing things that aren't on the tracker ;)
<\sh> most probably...but someone can dream
<tkamppeter> slangasek, I have uploaded foomatic-db as I thought that it fixes an important bug (near 400 manufacturer PPDs did not pass CUPS' sanity test for PPDs, making CUPS potentially not accepting them for print queues). I did not see any problem with the package in alpha 6 as it did not change in size (no PPDs for new models added).
<calc> davidm: good evening
<slangasek> davmor2: no objections; the community flavors really ought to be self-sustaining in this regard :/
<davidm> calc, good evening
<superm1> slangasek, well actually now that i've got vbox 2.0.2 uploaded, it will be a lot easier to test (i was wiping platforms away previously and couldn't afford to wipe them as often :))
<slangasek> tkamppeter: "I did not see any problem" - the problem is that we're in a freeze, and you're not supposed to be uploading packages during the freeze that aren't fixes for milestone-critical bugs
<calc> davidm: we're headed back to clean out the fridge and hopefully have power tomorrow morning
<slangasek> tkamppeter: for one thing, having packages uploaded to the archive after images have already been built means we have skew between the archive and the .jigdo files, making it impossible for people to use jigdo to grab images...
<tkamppeter> slangasek, sorry.
<calc> davidm: they haven't made much progress since noon on tuesday though
<slangasek> tkamppeter: no real damage done (I've had to re-roll images anyway), but please keep this in mind for future alphas
<slangasek> (you don't get a choice in the matter for beta, we'll have a hard archive freeze ;)
<slangasek> fta: <ahem> fontconfig uploads during a milestone freeze? :)
<davidm> calc, good luck, I hope you have power.
<slangasek> seb128: ah, these are your uploads... it's still Thursday, we're still in freeze...
<calc> davidm: my parents have power now so if i don't i'll have to see if the mind us staying with them, heh
<calc> in laws are always fun to be around
<davidm> :-)
 * calc pictures his mom and wife in a fight
<calc> wow new 'powershot sx10 is' is nice :)
<calc> 10mp 20x optical zoom
<tedg> calc: I was really impressed by the 5D Mark II -- I need more hard drive space first though at 21 MP. :)
<calc> tedg: the higher end powershot, apparently might not come to the US, will have a CMOS sensor also
<calc> tedg: yep large files :)
<calc> PowerShot SX1 IS with 1080p video recording and 20x zoom
<calc> it appears from pricing it is probably the replacement for the PowerShot S5 IS
<seb128> slangasek: hello, hey soft freeze though no? those are not disruptive changes
<slangasek> seb128: "please take care that any packages that you upload to main between now and the Alpha 6 release will help us in the goal of a high quality and timely alpha" - uploading packages that don't fix milestone-critical bugs hurts this by invalidating jigdo images
<slangasek> (--> "timely", as it interferes with ISO testing...)
<seb128> slangasek: does that mean I should be slacking during freeze days? ;-)
<slangasek> you could test ISOs instead, then the alpha would be out sooner and you could go back to uploading :-)
<seb128> like I had not enough work
<seb128> slangasek: the issue is that I don't want to upload changes on friday afternoon before everybody is away for the weekend
<seb128> slangasek: so we have freeze between wednesday on friday every 2 weeks basically
<seb128> a new GNOME between those
<seb128> and I need to get feedback from users to have GNOME bugs fixed in the next version
<slangasek> that's correct; and it's also not new
<seb128> that's a pretty tight schedule
<seb128> right, and I've been abusing the soft freezes this way before too
<seb128> but that's either that
<seb128> or I wait on monday and next tarballs to upload outdated things
<seb128> and don't get bug fixed in the next GNOME updates
<slangasek> would it make a difference if we were able to guarantee alphas were out of the way before Friday morning your time?
<seb128> yes
<slangasek> ok. I'm not sure I can guarantee this using soft freezes, but that's useful to know.
<seb128> I uploaded this afternoon because I figured it was late to roll new CDs
<slangasek> /this/ one is on track, though
<seb128> and that would not disturbe anything
<seb128> I spent yesterday doing hardy srus uploads
<seb128> and did bug triage this morning
<slangasek> yeah, unfortunately not; maybe it's worth pinging #ubuntu-release first in those cases?
<seb128> I know the reply, it's always "alpha is not available yet so there is still a possibility we need to roll new images"
<slangasek> then I think we need to consider going back to hard freezes.
<slangasek> (of course, we will for beta anyway, but for jaunty alphas as well.)
<seb128> what is the point exactly?
<slangasek> the point of which?
<seb128> did any of my uploads created a practical issue?
<seb128> impose hard freeze when the soft ones are usually working
 * calc hopes he will be able to get his visa for china
<seb128> I'm doing that for years now and it has not been an issue until now
<calc> most of houston is still listed as 70%+ without power
<slangasek> seb128: they invalidated all the jigdo images; that affects testing for alternate ISOs, since it impacts download time for our testers
 * calc has heard reports of power not being restored until sometime in october
<seb128> slangasek: do we need that level or testing for alphas?
<slangasek> maybe our current testers have stopped relying on jigdo working, though, I don't know :/
<slangasek> seb128: we need to have a set of usable ISOs, or else why call it an alpha?
<seb128> if you don't manage to get alpha available on time maybe we should consider having an extra week between those
<seb128> well, 3 days freeze every 2 weeks is getting in the way of getting work done that's my issue
<slangasek> well, my point is that ignoring the freeze is a factor in the freezes stretching out to 3 days, when they're supposed to only be 2...
<slangasek> (not the only factor, for sure)
<seb128> I doubt my upload from today created any issue, I've be cautious and didn't upload the new gtk for example
<seb128> as said point me to one case where I did upload which delayed an alpha and I'll be happy to consider those and how to do better
<seb128> it's just that if alpha are supposed to be available on thursday uploading on thursday afternoon should be alright since that's not the time to start a new image rolling and testing round
<slangasek> well, if that's your position, then the end result may well be that we're going to have to rule out the possibility of jigdo being usable at all for testing, and adjust the testing window to compensate
<seb128> I would like to know if jigdo is used at all, I had the impression people were rsyncing iso usually
<cjwatson> (I use jigdo for testing, at least, and it's important to me)
<cjwatson> for non-desktop images, jigdo is a lot faster for me since I keep a local mirror, and it also allows me to share downloaded bits around between images
<slangasek> this cycle I haven't been, because my mirror setup needs a bigger disk; but I have before and intended to again for jaunty
<cjwatson> as in, a large chunk of the data downloaded for alternate also applies to server, and since I don't have a very fast connection it helps me a lot to be able to share this
<cjwatson> I know it gets used by people other than developers since I get bug reports when it breaks
<seb128> slangasek: I really don't want to upload a ton on upload we queued for 3 days on friday afternoon, that's a receipe for weekend breakages
<cjwatson> jigdo also recovers better from network interruptions, IME
<seb128> and I would like to avoid blocking upload between wednesday and next monday
<cjwatson> perhaps the answer is to move milestones to Wednesdays
<cjwatson> or some other day of the week
<seb128> if we do that we need to make sure they are not on same weeks that new GNOME versions
<cjwatson> I think the beta, RC, and final work best on Thursday, but that doesn't have to match the milestones
<cjwatson> when does new GNOME arrive, Wednesday?
<slangasek> seb128: which we can't do if GNOME is every 2 weeks, and Ubuntu alphas are alternating 2/3 weeks
<seb128> but having milestones and new GNOME on alternates weeks and doing those on wednesday looks good to me
<cjwatson> we could do milestones on Fridays if you could get the new GNOME uploaded before Steve wakes up on Wednesday
<seb128> slangasek: the GNOME schedule is available early we can probably adjust to not conflict
<seb128> doing GNOME uploads before wednesday is fine, that's what we do usually
<slangasek> seb128: I'm saying that I don't think it's possible to space them to guarantee there are no collisions with GNOME, without doing some really funny padding of the Ubuntu schedule compared to what we have today
<cjwatson> the only trouble with milestones on Fridays is that if they run late then we're in trouble
<slangasek> (i.e., either larger gaps around beta time, or starting the alphas much later)
<cjwatson> Ubuntu alphas every two weeks have proven to be difficult
<cjwatson> I don't think we could sustain that reliably
<slangasek> that too
<cjwatson> the alternative could be to start earlier (if possible) and do them every four weeks, but that's quite a big gap
<seb128> can we setup a pocket for uploads which are done during freezes and that users who want to could use?
<cjwatson> PPAs
<seb128> one that everybody would use
<cjwatson> we could have an ubuntu-dev PPA
<seb128> would work for me
<slangasek> moving milestones to Wednesday seems ok; the only thing I think would need to change is the release team meeting because that doesn't leave enough time to act on anything, and that was hard to schedule to begin with
<cjwatson> it will help once they're signed; that's targeted for the next LP release at the moment
<seb128> I just don't like to queue uploads for 3 days to unlash everything on friday afternoon
<seb128> by time everything is built and available it's evening european time and nobody is around
<seb128> and that also means apt-get doesn't give us current version during freeze and we have work duplications and upload conflicts (not that often but sometimes though)
<cjwatson> I'm surprised the idea of an ubuntu-dev PPA (or maybe just ubuntu-core-dev, universe/multiverse isn't so important for freezes) hasn't come up before, actually; I don't remember it doing so
<cjwatson> I'll mail ubuntu-devel and see what people think
<slangasek> seb128: fwiw, I'm making every effort to get the alpha out yet today so it doesn't bleed over into Friday in this case; but I'm quite aware that I can't promise that in general, particularly for the earlier milestones
<seb128> slangasek: right I'm aware about that too and that's why I take the liberty to upload non disruptive change because usually they are not an issue
 * slangasek nods
<slangasek> in this case, it's specifically /because/ I'm trying to wrap things up on time that I'm making more noise about it than in the past
<seb128> slangasek: well, if I was sure I could upload on friday morning I would wait, so maybe you can better communicate on that ;-)
 * slangasek nods
<slangasek> and maybe there should be varying gradations of freeze between the earlier and later milestones... <ponder>
<mathiaz> slangasek: have you already rebuild the -server isos ?
<mathiaz> slangasek: bug 271854 will be an issue
<ubottu> Launchpad bug 271854 in landscape-client "Calls non-existent /etc/init.d/update-motd in postinstall" [Undecided,Confirmed] https://launchpad.net/bugs/271854
<slangasek> mathiaz: no - was just about to ping you to confirm you're still available to work on them
<slangasek> mathiaz: update-motd is promoted now
<slangasek> (i.e., visible in the archive)
<slangasek> 271854> that will be an issue if we /do/ reroll?
<mathiaz> slangasek: yes
<mathiaz> slangasek: so either I can fix it.
<mathiaz> slangasek: or we don't reroll.
<cjwatson> seems like you should definitely fix it, and then either we reroll or we don't
<mathiaz> slangasek: I'll still be around for a couple of hours.
<slangasek> mathiaz: ok; do you want to work on resolving that bug then, and ping me again when it's done and we'll evaluate whether it's worth trying to reroll at that point?
<mathiaz> slangasek: wfm.
<cjwatson> fixing it in the archive shouldn't hurt anything at this point, relative to the current broken state
<slangasek> yep
<seb128> slangasek: alright for now I'll wait friday morning european time to upload during freezes, if that's not good enough we need to figure what to do when freeze are stretching ;-)
<slangasek> seb128: that sounds good from my side, thanks
<calc> if the freeze is having trouble maybe make it a hard freeze at that point?
<calc> so people can upload and get it in the queue
<calc> or implement day queues like debian has (or had?)
<cjwatson> the problem about a hard freeze is that there's no notification to developers when two people upload the same version of the same package
<cjwatson> we've had difficulty with that in the past
<calc> cjwatson: oh yea thats true
<cjwatson> also doesn't really help seb128's other problem, which is getting feedback on what he's uploaded, more than just getting it off his disk
<slangasek> it's also not very satisfactory if the reason for getting the upload done is to get it tested by users so bugs can be fixed before the weekend :)
<cjwatson> I mailed ubuntu-devel@ about the ubuntu-core-dev PPA idea, we can discuss it there
<seb128> there is also the "don't accept tons of updates on friday afternoon when everybody is running away for the weekend" issue
<cjwatson> right, and all the build failures landing at once ...
<mathiaz> kirkland: re bug 271854 - the call to invoke-rc.d can just be dropped ?
<ubottu> Launchpad bug 271854 in landscape-client "Calls non-existent /etc/init.d/update-motd in postinstall" [Undecided,Confirmed] https://launchpad.net/bugs/271854
 * kirkland looks
<mathiaz> kirkland: there is nothing else to be done to integrate landscape-client with update-motd ?
<kirkland> mathiaz: right, that should definitely be dropped
<kirkland> mathiaz: right, landscape just needs update-motd to be there
<mathiaz> kirkland: so only the ln -sf are needed in the postinst.
<kirkland> mathiaz: right
<kirkland> mathiaz: cjwatson was advising me against debconf'ing everything yesterday
<mathiaz> kirkland: right - I've read the bug
<kirkland> mathiaz: cjwatson: i did add debconf support to landscape to allow an admin to change between update-motd and /etc/profile.d handling of publishing sysinfo
<kirkland> cjwatson: that, too, was done as I was learning debconf and thought i should debconf everything
<superm1> slangasek, i did an install with the mythbuntu alt, and there was a bug caused by an extraneous recommends
<superm1> slangasek, i uploaded mythbuntu-default-settings-0.71-0ubuntu2 to resolve it
<slangasek> superm1|away: shall I reroll the images?
<slangasek> ah, needs the new package published first
<Yoghurt^> Does anyone knows when Alpha 6 will be released? :)
<cjwatson> Yoghurt^: typically, on the advertised day for an alpha, the people who know are too busy to be interested in giving out exact times to people. :-)
<cjwatson> Yoghurt^: subscribe to ubuntu-devel-announce if you want to be notified as quickly as possible
<slangasek> Yoghurt^: also, you already asked this question in #ubuntu-testing...
<Yoghurt^> Yeah... but i thought that i could get an more precise answer :)
<Yoghurt^> it's getting late in Denmark, but it came out within an hour i would stay up a little longer :)
<Yoghurt^> but thanks cjwatson!
<cjwatson> if you want to make it faster, do some (more?) ISO testing ;-)
<Yoghurt^> i've already added a few bugs to launchpad :)
<qah> Hello. Is anyone here?
<Yoghurt^> I can be "anyone" :P
<fta> slangasek, ?
<slangasek> fta: I saw your name in the changelog of the latest fontconfig upload; seb128 and I discussed it
<slangasek> fta: since seb128 did the uploading, I think you're off the hook regardless ;)
<norsetto> james_w: re. bug 271881, should we rebuilt with 0.2.4 or is 0.3.2 (or 0.3.3) going to be uploaded soon?
<ubottu> Launchpad bug 271881 in packagekit-gnome "PackageKit can`t find libpackagekit.so.3 library" [Medium,Confirmed] https://launchpad.net/bugs/271881
<fta> slangasek, oh, ok. i'm not allowed to push to main anyway so i'm still on the safe side ;)
<mathiaz> slangasek: I've uploaded a new version of landscape-client that should fix the update-motd issue and an upgrade issue.
<slangasek> mathiaz: ok; I'll watch for it to be published, but I think we're on the line where I lose my support for getting website updates done today if we iterate again
<mathiaz> slangasek: ok - it's up to you. It will be in the next daily iso - so I'll be able to test it then.
<mathiaz> slangasek: we won't put a note about landscape-client in the release note then.
<slangasek> tedg: I think that pam-auth-update belongs in the System->Preferences menu for intrepid, possibly as "Authentication Management"; how would I accomplish that, and where do icons come from? :)
<tedg> slangasek: Well, there's a mommy icon and a daddy icon... haven't your parents talked to you about this?
<slangasek> how is ikkon formed
<tedg> slangasek: I'd talk to kwwii about the icon.
<slangasek> ok
<slangasek> what about the "right" way to get it added to the menu?  Do I just need to peek at an existing .desktop file for one of the other entries there?
<tedg> slangasek: Yeah, I'd steal one and change it.
 * slangasek nods
<tedg> I'm not sure how translations work there though.  You need to make sure to add it to your package's po files, but I doubt that PAM is using intltool, eh?
<slangasek> heh, indeed not
<slangasek> (oh, I guess I mean System->Administration, of course)
<tedg> Uhm, I'm not sure the best way to pull out the strings there.  Adding in intltool would be a pain, and probably overkill.
<persia> slangasek: When you create your .desktop file, please run desktop-file-validate against it as a check.
<slangasek> persia: certainly will, thanks
<persia> Translations are currently handled by brute-force inclusion of the translated strings in the .desktop files themselves.
<slangasek> tedg: I'm sure I can figure something out on that side :-)
<persia> Many upstreams will generate these from a foo.desktop.in file at build time, based on the contents of po/, but that's probably overkill if you're looking at inclusion from debian/
<tedg> persia: Yeah, but I was more concerned about the pulling out into the po files.  Most GNOME packages are using intltool.
<persia> tedg: Sure, but that's not actually a requirement.  There's only three translatable strings (Name, GenericName, and Comment).  For bunches of packages, these are just translated in the .desktop file, rather than invoking the overhead of intltool
<slangasek> this seems to be going a bit meta? we're not going to have lots of translations make their way into the pam package itself between now and release, AFAICS
<slangasek> mathiaz: btw: "It should also be noted that Samba 3.2 is licensed under the GPLv3." - I think I disagree? :)
<tedg> slangasek: No, actually we expect you to translate it into all the languages Ubuntu supports.  We're just trying to help ;)
<slangasek> tedg: my contract only requires me to provide 14% language coverage
<mathiaz> slangasek: ?
<tedg> persia: Yeah, probably.  If all you're used to using is a hammer...
<slangasek> mathiaz: the samba blurb in the technical overview; I don't agree that this should be noted :)
<persia> Not infrequently when someone generates an Ubuntu-local desktop file in universe, there will be a call for translated strings in #ubuntu-motu from a pastebin, and people will supply their local translations.  Tends to hit the top 5-10 languages.
<mathiaz> slangasek: ah ok. I though you said that samba 3.2 was *not* under GPLv3
<slangasek> no, not that :-)
<tedg> persia: Really?  That's cool.
<mathiaz> slangasek: the reason I mentionned it was because of libsmbclient that can be linked to other libraries under GPLv2 (cf kde)
<slangasek> "Authentication Management" - pff, that better get at least 20 :-)
<persia> tedg: Yep.  We started it about a year ago, as some people complained about Ubuntu-local desktop files because they weren't translated.
<mathiaz> slangasek: I noted it as it could be useful to developers. I agree that it's less important for end users.
<slangasek> mathiaz: I understand; I just don't think this is a key issue to be highlighting here
 * mathiaz nods
<slangasek> also, I think you meant â¢ or Â®, not Â© :)
<Riddell> kdelibs is GLP 3 happy now incidentally
<slangasek> Riddell: yep, we didn't push to samba 3.2 in Debian until that was resolved
<ceekay> sorry i know this is a newbie developer question- there is a new version of a package upstream (makedumpfile) that i created a package for because i need it right away. seems like the nice thing to do would be to contribute that packaging to ubuntu for potential use... what is the best channel for doing do? contact the package maintainer?
<Nafallo> #ubuntu-motu
<persia> slangasek: some number of hours ago you asked about Ubuntu Studio testing.  All cases for the 32-bit disks have been covered.  There's apparently not hardware available to those testing to reach proper coverage of the 64-bit cases (unless you want to wait several more hours).  There have been a couple statements that there would be time to test 64-bit on the weekend, but I'm not sure that helps you.
<ceekay> Nafallo: even though it's in main?
<slangasek> persia: well, it's more about helping you than about helping me; if UbuntuStudio doesn't get tested, it doesn't get included in the alpha pulse
<persia> ceekay: Despite the names, #ubuntu-motu has become the channel where developer support is offered (support with developing for Ubuntu), and #ubuntu-devel is discussion about development activity in Ubuntu (sometimes including Universe)
<slangasek> persia: which is on-time for this round, so the pulse is happening shortly
<ceekay> perfect, thanks persia ... sorry to be in the wrong channel
<slangasek> persia: I could include the tested i386 image without including the amd64 image, if you think that reflects the real needs of the userbase?
<persia> slangasek: The vast majority of users are 32-bit (anecdotally about a 10-to-1 ratio), and nearly all those who commit to testing.
<davmor2> Jo no
<persia> Having a 32-bit "Alpha" would certainly be rewarding even if the 64-bit wasn't present, and might help engage more people to hit the beta testing window.
<davmor2> slangasek: I can run a test on it
<slangasek> persia: so are you authorizing me, on behalf of the US developers, to do that?
<slangasek> davmor2: yes, but I'm not going to block the alpha waiting for those tests
<persia> slangasek: I'll go try to get an official statement of some sort, as I'm not sure I can do that.  On the other hand, given the timing, I'm not expecting 64-bit coverage.
<davmor2> slangasek: well someone has done a couple of test on xub alt so I can do a couple on that instead :)
<slangasek> persia: any ETA on that official statement?  I'm just about ready to pull triggers, here
<persia> slangasek: Real Soon Now (minutes)
<persia> slangasek: Please do include Ubuntu Studio in the pulse.  While the 64-bit is expected to work, without test coverage, it is understandable if you can't include that.
<persia> (and yes, this is now an official authorisation)
<slangasek> ok
<slangasek> pushing 32-bit, and deferring 64-bit until test results are in
<persia> Thanks.  I'll see if someone can't organise more agressive testing during the beta-freeze window.
<davmor2> 64bit is about 60% complete on whole disk  and 50% on auto resize
<davmor2> slangasek: persia: ^
<slangasek> how long does the last 40% take to do? :)
<ldp> I need a video converter
<davmor2> not too long I hope :)
<ldp> HELP
<persia> davmor2: Great news indeed.  I'm personally extremely confident that the install works, as it's the same kernel, and nearly the same desktop as Ubuntu Desktop, but less so that the standard Studio applications are all working under 64-bit today.
<slangasek> davmor2: well, can you be more specific?  I need to know whether I should wait for it before pushing, or to push in two rounds
<slangasek> ldp: this isn't a help channel; try #ubuntu, perhaps?
<ldp> k
<ldp> I know
<ldp> I did /amsg :)
<davmor2> 83% of app install 84%
<davmor2> so about 10 minutes maybe
<slangasek> ok
<persia> davmor2: That's for the full suite, or just the desktop?
<davmor2> persia: full
 * persia is envious of davmor2's machines: the Studio install usually takes a *long* time, and most users only select one of the application clusters in part for this reason
<davmor2> the other is just coming up 60% app install
<davmor2> persia: how many test on vm though ?
<davmor2> setting system clock cd ejected
<davmor2> booting
<davmor2> sweet I like the usplash :)
<persia> davmor2: about half the testers were testing in VMs for 32-bit, but nobody uses VMs for actual installs because it either introduces complexity with input devices (graphics), adds latency (audio), or has slightly slower disk throughput (video)
<davmor2> first one is up and running
<davmor2> second machine is at 70% now
<davmor2> persia: why 2 cd burners?
<persia> davmor2: Which do you mean?
<davmor2> brasero and gnome cd master
<persia> Oh, because gcdmaster can't handle data CDs, and brasero doesn't have the mastering wizards for audio CDs.
<persia> (or at least that is what I was told when I suggested removing gcdmaster to try to reduce image size)
<davmor2> persia: sorry don't you just add the audio to the cd ?  Or am I missing some major point?  Brasero has a importer not great but it is functional :-?
<davmor2> slangasek: that 2
<slangasek> "that 2"?
<davmor2> that's 2
<slangasek> ok
<sbeattie> slangasek: were you going to release the 20080918 builds of xubuntu/
<sbeattie> or stick with 20080917.1?
<persia> davmor2: I'm not someone who has ever mastered a CD, but from what I understand, you first want to use something like jamin to get your multitrack into 44.1kHz stereo 16-bit WAV, and then use GCD Master to import your WAVs, set your track markers and track information, and perhaps add "bonus" tracks (less aggressively mastered) before burning.
<slangasek> sbeattie: they were rolled in case there was enough time to cover them for testing; there wasn't, so moving on
<sbeattie> slangasek: okay. the i386 from 18 worked fine for me for a manual install
<davmor2> persia: right so the mastering is better then :)
<davmor2> Right bed
<sbeattie> davmor2: thanks much!
<persia> davmor2: I think it's also the adding of the extra non-audio data, as brasero is designed to be simple, but I'm not really sure.
<persia> Sleep well.
 * slangasek waves
<maco> where is DistUtilsExtra.command?  I'm trying to test a change to update-manager, but just realized I can't run the setup.py to test it because it can't import that python module
<TheMuso> persia: That sounds about right. While I have never used gcdmaster myself, I am well aware of how powerful it can be.
<cjwatson> $ dlocate DistUtilsExtra/command
<cjwatson> python-distutils-extra: /usr/share/pyshared/DistUtilsExtra/command
<cjwatson> maco: ^-
#ubuntu-devel 2008-09-19
<maco> cjwatson: thanks.  i must look into this dlocate thing
<pochu> good night folks
<cjwatson> maco: well, dlocate only helps because I already have it installed
<cjwatson> maco: to find files in packages you don't have installed, use http://packages.ubuntu.com/
<murdok> night pochu
<murdok> :D
<murdok> anyone know where can I find all these devices that are supported by the wl driver?
<alex-weej> anyone know if these 2 minor changes to HAL and Linux could get picked up for Intrepid to fix backlight on MacBook Pros? https://bugs.launchpad.net/ubuntu/+source/hal/+bug/226894
<ubottu> Ubuntu bug 226894 in hal "Backlight control does not work on MacBook Pro 3.1" [Undecided,Confirmed]
<cjwatson> murdok: well, I've got one, dunno if that helps you
<murdok> cjwatson, let's see:p where did you get it?
<cjwatson> murdok: it came with my Dell Latitude D830
<murdok> oh you mean a device or a list of devices?
<cjwatson> a device
<cjwatson> your question was unclear
<murdok> i mean a list of those devices supported by wl
<cjwatson> that would be in the kernel source?
<murdok> yes i'll see, I expected a sourceforge page for the driver or so
<cjwatson> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid-lrm.git;a=blob;f=ubuntu-restricted/broadcom/src/wl/sys/wl_linux.c;h=38ce6150642fcfd8a7ad34f3b26df9bd050361a4;hb=HEAD -> search for MODULE_DEVICE_TABLE and go up a bit
<Riddell> kirkland: upgrade fails with bug 271952
<ubottu> Launchpad bug 271952 in landscape-client "upgrade from 8.04 fails with landscape-common" [Undecided,New] https://launchpad.net/bugs/271952
 * kirkland checking
<murdok> Yes, more or less..
<kirkland> Riddell: ah, that's been fixes with an ln -sf
<kirkland> Riddell: ah, that's been fixed with an ln -sf
<kirkland> Riddell: fixed in https://launchpad.net/ubuntu/+source/landscape-client/1.0.18-0ubuntu4
<Riddell> kirkland: hmm, I had the error happen this afternoon
<kirkland> Riddell: see https://launchpad.net/ubuntu/+source/landscape-client/1.0.18-0ubuntu4,
<kirkland>     * Published 1 hour ago
<Riddell> oh, I see freeze getting in the way
<TheMuso> alex-weej: There is actually a kernel module that takes care of MacBook Pro backlights for 2.1, 3.1, and 4,1 revisions. That hal fdi file for the mbp needs to rewritten to take this into consideration.
<Riddell> thanks kirkland
<kirkland> Riddell: no prob ;-)
<slangasek> not freeze
<alex-weej> TheMuso: no, it doesn't need to be rewritten at all. it provides a generic interface and it's picked up by HAL's regular backlight magic.
<alex-weej> we just need to carry the new version from upstream
<TheMuso> alex-weej: That doesn't make sense. On my 4.1 generation, with the backlight module loaded, I need do nothing else. THis is because the hal fdi file responsible doesn't reference the 4.1 series.
<alex-weej> that one file is all that needs to change to stop the 3.1-and-newer machines from using the fake device
<TheMuso> alex-weej: Is the new file in upstrea mgit already?
<TheMuso> or whatever vcs is used?
<alex-weej> TheMuso: i linked it in the report. took me a lot of time to track it down too :P
<TheMuso> alex-weej: oh ok, I'll take a peak.
<alex-weej> TheMuso: FYI, 2.1 uses ATI, 3.1 uses NV
<alex-weej> TheMuso: the new FDI has the logic perfect
<TheMuso> alex-weej: Ok will take a look.
<superm1> murdok, i've got a forum post that's attempting to aggregate pci ids into marketing names for it
<superm1> murdok, FYI, the driver in intrepid and hardy-proposed supports far more than the original driver
<murdok> hey superm1: which original driver do you mean?
<superm1> murdok, the original one was included back around 2.6.24-17 or so
<superm1> and the same one that is in -19
<murdok> bc43 or so
<superm1> the newer versions of it are in -20 and -21
<superm1> 'wl'
<murdok> i think
<TheMuso> alex-weej: Ok I'll test it locally to make sure nothing breaks for me here. It works for you I presume?
<murdok> superm1, please give me the url of that thread
<superm1> http://ubuntuforums.org/showthread.php?t=880218
<alex-weej> TheMuso: yes fine on my 3.1
<murdok> i'll add mine
<superm1> murdok, okay great thanks
<alex-weej> TheMuso: although the sensors and keyboard backlights are still dead, but that's for another day
<superm1> i've got to scan through it again and update the first post again still, it's been a bit since i have
<murdok> oh you are Mario Limoncello, I wrote you yesterday
<murdok> :)
<superm1> yeah :)
<TheMuso> alex-weej: Part of that is that the aplesmc driver si probably not loaded. If its loaded, then all hal needs is an addon written to work with them.
<alex-weej> TheMuso: does it work for you on your 4.1?
<murdok> what is the usual name for the interface with wl, ethX ??
<TheMuso> alex-weej: No, but I can manually tweak things like keyboard backlight through sysfs when applesmc is loaded.
<superm1> murdok, it will come up as ethX yeah
<murdok> superm1, okay, hehe it was wierd, i had always thought that ethX was reserved for ethernet cable
<TheMuso> alex-weej: However I don't like running applesmc because it constantly polls, using too much battery. I've found patches that make it use interrupts, but I haven't yet sat down to apply them to see fi they make a difference.
<TheMuso> alex-weej: Yeah thats what I was thinking needed changing. I'll test locally, and if it works for me, I'll see about getting it into hal after the freeze lifts.
<alex-weej> TheMuso: ok we need the kernel fix too otherwise it's still out of the reach of mortals
<TheMuso> alex-weej: Ok I'll have a look at that also.
<alex-weej> it's a macro change in the driver -- the existing mod aliases were failing
<TheMuso> alex-weej: Explains why I have to load the module manually. I guess the next thing to determine is whether that patch is in a git tree somewhere...
<alex-weej> TheMuso: yes it is, that's what that mail is for... let's see if i can find the actual commit
<TheMuso> The only annoying thing is that one can't control the brightness at the gdm screen for example.
<murdok> superm1, my device is already reported, which is bcm4328 but my laptop is not the same. Shall I report it?
<murdok> superm1, it's strange.. I have added ssb to blacklist but ssb continues being loaded on boot
<murdok> :?
<TheMuso> superm1: Just wondering whether you have AirPort in that list? As the newer MacBook Pros use BCM4328.
<murdok> TheMuso, which revision? :p mine is 03
<TheMuso> murdok: 05.
<alex-weej> TheMuso: blame g-p-m architecture
<alex-weej> TheMuso: IMO it should be a systemwide service
<alex-weej> but the wind is blowing the other way, people want per-user X and everything
<TheMuso> alex-weej: I agree with that.
<murdok> TheMuso, someone has already reported that
<TheMuso> murdok: Right, thanks.
<jdong> why is brightness tied with X to begin with? is it not technically possible to map the brightness keys at a lower level?
<alex-weej> their "solution" is to add things like g-p-m and a pulseaudio daemon to the GDM environment
<jdong> same with the audio volume keys.
<alex-weej> jdong: sure it is. pommed.
<jdong> why don't we use that?
<alex-weej> pommed is entirely independent of X
<alex-weej> because it only works for apple laptops
<TheMuso> alex-weej: Yeah that fdi works for me.
<alex-weej> and it's too much of a variation from upstreams will
<jdong> alex-weej: mmm, IMO still a weak reason not to give that feature to apple laptop users in an easy manner :-/
<alex-weej> jdong: practically, the hotkeys stopped working in it since a recent X change
<jdong> (livecd space issues, I know...)
<alex-weej> so it ONLY works outside of X now
<alex-weej> :P
<jdong> alex-weej: yay.
<TheMuso> jdong: Pommed woudl also now have to be tweaked to work with the newer backlight module.
<alex-weej> TheMuso: negative
<alex-weej> Pommed had support for the NVidia chip a long time ago
<alex-weej> it does it all in userspace
<jdong> are other backlights tied to X also?
<alex-weej> none are really tied to X
<TheMuso> alex-weej: Yes but what I mean is instead of pommed having its own code, it should just use sysfs and use the kernel module instead.
<jdong> well I guess non-X usage is a fringe case in this matter and not worth too much pondering.
<alex-weej> jdong: it goes like this: hardware > linux > hal > g-p-m
<alex-weej> g-p-m is, unfortunately, a session service
<alex-weej> you can control HAL via other means if you wish
<jdong> spawning g-p-m's services at GDM would be nice though.
<alex-weej> jdong: it's on the radar AFAIK
<jdong> another related wishlist, users sharing battery calibration.
<alex-weej> TheMuso: i'm not sure to be honest. what benefits are there to having it in kernelspace?
<TheMuso> alex-weej: Well for one, so that hal controls the backlight when in GNOME which is what happens now when you are logged in.
<TheMuso> And so that gpm can control it when you are on and off battery.
<alex-weej> as it stands right now, non-pommed consumers of the code have made a bit of a mess. the ATI stuff is in userspace, wrapped up inside the hal addon, whereas the NV stuff is in a kernelspace module that doesn't autoload :P
<alex-weej> TheMuso: i think you misunderstand - pommed is a system service with the code to control the hardware in userspace
<TheMuso> alex-weej: I understand entirely.
<alex-weej> userspace doesn't mean "a user's session"
<alex-weej> pommed also listens for power events too, independently of HAL
<alex-weej> it has no dependency on HAL
<alex-weej> as far as the authors are concerned, it IS the HAL for apple laptops
<alex-weej> with its own dbus interface and everything
<TheMuso> Won't pommed conflict with hal when you are logged in?
<alex-weej> yes.
<alex-weej> well, no.
<alex-weej> it conflicts with g-p-m
<alex-weej> HAL doesn't do anything on its own, it's just another interface to the same hardware.
<alex-weej> G-P-M receives the key events inside your X session
<alex-weej> and turns those into HAL messages
<TheMuso> alex-weej: Right, but is the conflicting with gpm a possible problem area?
<alex-weej> Pommed receives the same key events via linux/input.h (i.e. NOT X)
<alex-weej> and turns those into PCI magic
<alex-weej> which i don't understand
<alex-weej> :P
<alex-weej> TheMuso: it absolutely is when everything is working. the same keypress is handled twice
<TheMuso> Right.
<Hobbsee> cjwatson: one of the reasons we don't have an ubuntu-dev PPA is that everyone gets spammed on a build failure - hence ppas for large teams don't happen much.
<jdong> that's a silly feature too
<TheMuso> alex-weej: well if key presses worked outside a user's session, then I'd say put it all in the power manager/hal, but now I am in two minds about it all.
<cjwatson> Hobbsee: we could probably get that fixed
<TheMuso> alex-weej: It would be interesting to know whether there are other laptops that only handle such stuff in software, and how they behave.
<cjwatson> but thanks, a useful point
<alex-weej> TheMuso: this is just a decision made by the G-P-M architects. it's not something we are really empowered to change.
* slangasek changed the topic of #ubuntu-devel to: alpha-6 released | archive: feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<alex-weej> exactly the same nonsense is happening with pulseaudio which is why audio STILL doesn't work with GDM.
<TheMuso> Audio does work with gdm, it uses alsa.
<Hobbsee> cjwatson: I live in hope, but am aware of how long things usually take to fix.
<Hobbsee> cjwatson: the other worry would be that users regard it as "official", due to the name of the ppa, and report bugs for it.
<cjwatson> Hobbsee: do you know if there's a bug about this? I couldn't find one
<Hobbsee> wgrant: have you seen one?
<cjwatson> Hobbsee: that would be great, since by definition (in my proposal) everything there is due to go into the main archive, just can't yet due to timing
<Hobbsee> cjwatson: unsure, wgrant should know.  I try to avoid their bugtracker.
<cjwatson> the earlier the reports, the better
 * wgrant appears.
<alex-weej> TheMuso: only thanks to a fallback
<wgrant> What are we talking about?
<Hobbsee> ah, right, i've not seen the mail yet :)
<Hobbsee> wgrant: launcphad spamming everyone when using a PPA, and the build fails - is there a bug for it yet?
<TheMuso> alex-weej: What fallback are you referring to?
<wgrant> Hobbsee: IIRC it's a feature.
<TheMuso> alex-weej: And, its not safe to run pulseaudio system wide.
<wgrant> There might have been a bug on it at some point.
<wgrant> Let me check.
<Hobbsee> wgrant: FSVO "feature".
<alex-weej> TheMuso: the default ALSA PCM is a pulseaudio PCM. a change went in a few months back to make it so that if the PA daemon isn't running it just uses the hardware directly.
<alex-weej> robust, but ugly to rely on
<Hobbsee> slangasek: congratulations!
<slangasek> Hobbsee: \o/ thanks for rustling up the testers :)
<TheMuso> alex-weej: Thats not in Ubuntu. We still use alsa by default.
<Hobbsee> slangasek: you're welcome.  Give me more warning next time, please :)
<alex-weej> TheMuso: that's pretty silly.
<TheMuso> alex-weej: No, its not.
<TheMuso> alex-weej: KDE and XFCE do not use pulseaudio.
<slangasek> Hobbsee: "beta is October 2" ;)
<alex-weej> TheMuso: neither does GNOME
<cjwatson> wgrant: I assume it's part of the general conflict between the desire to notify a team of things and the desire to only have some members of a team notified. This crops up all over Launchpad.
<TheMuso> alex-weej: Not upstream they don't afaik.
<alex-weej> TheMuso: i'm intrigued... why is pulseaudio unsafe to run systemwide?
<Hobbsee> slangasek: heh, right.  I meant for when you had images you thought worked :P
<slangasek> Hobbsee: ok, noted. :)
<alex-weej> i believe there are current issues with the design allowing users to "listen" to other users
<TheMuso> alex-weej: The author of pulseaudio only meant pulseaudio to be used system wide for embedded devices/special application devices.
<wgrant> Hobbsee: Can't find the bug.
<alex-weej> but that's not something that can't be alleviated with proper policy
<alex-weej> TheMuso: again, an architects decision.
<wgrant> cjwatson: The lack of configurability on Launchpad is somewhat concerning.
<Hobbsee> wgrant: darn.  cjwatson, then apparently there is no bug.
<TheMuso> He does not recommend it be run system wide of standard use.
<alex-weej> one which i disagree with. it means i still can't have my logout sound as usplash is shutting down
<TheMuso> alex-weej: That is known, and if 0.9.11/0.9.12 of pulse were ready, that version would have a consolekit module to help take care of that.
<cjwatson> Hobbsee: OK, thanks, I've made a note to file one when I'm a bit more awake
<TheMuso> ready == stable enough, and no major user regressions.
<Hobbsee> cjwatson: cool, OK.
<alex-weej> TheMuso: aside -- are we going to have ANOTHER release with PulseAudio shipped but not the default PCM?
<alex-weej> i thought we had learnt that lesson from Hardy
<alex-weej> but if we still aren't shipping the change by Alpha 6...
<slangasek> what do you mean, "not the default"?
<TheMuso> alex-weej: It just so happens that I am working on a resolution to the pulse by default issue.
<alex-weej> does it involve DMix?
<TheMuso> alex-weej: When pulse is running, alsa apps will use it, but if its not running, alsa will be used.
<alex-weej> TheMuso: what, you mean like with the pulse PCM as it is now?
<alex-weej> because that's exactly what it does given the aforementioned fallback
<TheMuso> alex-weej: No dmix will not be used.
<alex-weej> good :)
<TheMuso> alex-weej: And there is no fallback. If you happen to have pulse as your default alsa device and pulse is not running, it won't work.
<TheMuso> Unless you are using pulse => 0.9.11, which is supposed to start if required.
<TheMuso> alex-weej: THere is a chance that the backlight patch may be in the next RC.
<TheMuso> Or 2.6.27 final.
<alex-weej> i wasn't able to track down which tree that even meant. i don't understand LKML as much as I thought I did.
<alex-weej> mjg59 said it might be in .28
<alex-weej> which didn't give me the best of hope for it being in .27
<TheMuso> Right.
<alex-weej> TheMuso: with applesmc loaded, looks like i get a myriad of sensors. that's good!
<alex-weej> so many, in fact, that it's destroyed my panel.
<TheMuso> alex-weej: Yes but you will notice that if you are on battery, it will eat battery very quickly, as well as filling up dmesg.
<TheMuso> As its always polling the hardware for the laptop's position, etc.
<alex-weej> TheMuso: "position"? as in accelerometer readings?
<TheMuso> alex-weej: yes.
<alex-weej> insane. ok had better unload. none of these sensors have descriptions anyway :(
<alex-weej> you say you saw an interrupts-based branch?
<TheMuso> I've found patches to make that use interrupts, as well as park the hd heads when the laptop is moved suddenly. I need to ask the author whether they will be in a kernel any time soon, and if they are in a git tree somewhere.
<alex-weej> why is this all in one module?
<alex-weej> i just want keyboard backlights :(
<TheMuso> I don't know.
<TheMuso> Probably because its all to do with apple sensing hardware.
<alex-weej> do you know what the SMC stands for?
<jdong> hmm where I worked this summer it stood for serious machine carnage....
<TheMuso> lol
<TheMuso> alex-weej: No clue.
<jdong> it's one of those "what happens when you wrongly assume zero-centered velocity commands on a 45-ton armored vehicle controller" puzzles
<jdong> I think that was the end of indoor testing though.
<slangasek> are we talking about a kernel module?
<slangasek> (if so, I have a better question: why does it poll? :)
<NCommander> jdong, launchpad staff are now reviewing the spam to the tracker and are working to despam it
<TheMuso> slangasek: Yes, and I guess the author originally wanted to make sure it worked. As I said, there are patches to make it use interrupts floating around.
<maco> slangasek: you around?
<slangasek> maco: yep
<maco> slangasek: i changed update-manager's string to match update-notifier's for the bug you filed.  is that ok or would the opposite direction be better?
<slangasek> maco: I expect the opposite direction would be what's intended
<maco> slangasek: ok
<calc> so i'm not headed back tomorrow after all, i will be headed back saturday, i managed to get UPS to put a hold on a package due tomorrow
<DBO> hey all.  Is it possible to know if bug #265119 is going to see action before releasE?
<ubottu> Launchpad bug 265119 in xserver-xorg-video-intel "intel 2.4 / X4500 black screen crash" [Undecided,Incomplete] https://launchpad.net/bugs/265119
<RAOF> bryce, tjaalton: re bug #265119 - is there a special X process for package sponsorship, or does it follow the standard main sponsorship process.  There's a debdiff on that bug applying upstream's patch.
<ubottu> Launchpad bug 265119 in xserver-xorg-video-intel "intel 2.4 / X4500 black screen crash" [Undecided,Incomplete] https://launchpad.net/bugs/265119
<bryce> RAOF, no special process, just ping me (or timo) if it seems to be taking us a while to get to it
<RAOF> Ok.  I'll subscribe u-m-s and throw it on the queue.
<bryce> cool.  If it's still open tomorrow morning I'll do it then
<RAOF> Ah.  So there's no special process, you're just really fast :)
<dholbach> good morning
<Hobbsee> afternoon dholbach!
<dholbach> hi Hobbsee
<user_> how can I get an application ported over to ubuntu?
<user_> what's the best way to help with ubuntu? I was thinking about going through the bugs and submitting patches for fixes
<user_> is that the general idea?
<wgrant> That's always good.
<wgrant> Particularly at this stage of the release cycle.
<user_> okay.  sounds good.
<dholbach> user_: sounds like a good idea - https://wiki.ubuntu.com/MOTU/GettingStarted links to all important docs on the wiki
<user_> thanks
<dholbach> (Packaging Guide, how to get patches included in Ubuntu, lists of stuff that needs work, etc :-))
<slytherin> crimsun: I saw that you marked bug #64792 as fix released. Can you please tell me where are the files available or which package was synced?
<ubottu> Launchpad bug 64792 in linux-restricted-modules "missing firmware for bcm2033" [Undecided,Fix released] https://launchpad.net/bugs/64792
<\sh> asac: bug #192888 <- I don't think that has something to do with PA or ia32-libs now...could it be, that it's something else we are running in...
<ubottu> Launchpad bug 192888 in libflashsupport "firefox crashes on flash contents when using libflashsupport" [High,Confirmed] https://launchpad.net/bugs/192888
<davmor2> Should the encrypted folder ask for a password before being accessible?
<cjwatson> davmor2: no, it's handled by single-sign-on using your user password
<cjwatson> davmor2: your user password is used to encrypt the password for the encrypted directory itself
<davmor2> cjwatson: right Okay just thought I'd check it wasn't a bug :)
<asac> \sh: hard to say for sure.
<\sh> asac: and I can't reproduce it now
<asac> \sh: maybe you run a new flash 10 version than the one we have multiverse atm?
<asac> s/new/more recent/
 * torkel still can't use flash because of npviewer.bin crashes everytime
<\sh> asac: nope
<asac> \sh: you are on amd or 32-bit?
<\sh> asac: 64bit
<mvo> hey seb128!
<seb128> hello mvo
<seb128> mvo: btw the compiz update works correctly, it fixes the white screen issue when starting an another session
<mvo> seb128: excellent, thanks for testing it
<mvo> does anyone has a idea what "godkjennelsen mislyktes" (that comes from PAM) means? (bug #271441)
<ubottu> Launchpad bug 271441 in update-manager "update-manager failed to install / upgrade 17 packages" [Undecided,Incomplete] https://launchpad.net/bugs/271441
<persia> mvo: Google says "approval failed".  If nobody has a better answer, grepping the .po files might help.
<mvo> persia: thanks, that makes perfect sense in this context
 * mvo should have tried google first
<persia> The tricky part is determining it is Norwegian.  After than, the language tools aren't so bad for one or two word phrases.
<Mithrandir> "godkjennelsen mislyktes" is probably authorisation failed in the context of PAM
<mvo> Mithrandir: thanks, that fits with the bug, adduser fails when trying to add the pulseaudio daemon
<frafu> Hello, could anybody please tell me who created the possibility to stop the fsck at startup with the esc-key? I would like to contact him in order to ask whether he could for accessibility reasons enhance that function and also listen for mouse button clicks? Thanks in advance for any help in finding the appropriate contact person.
<cjwatson> frafu: that was pitti. However usplash doesn't have any mouse support at the moment so that might not be all that straightforward
<frafu> cjwatson: Thanks for your reply. You confirmed my fear about the mouse support. Do you know where I can find pitti's contact information?
<cjwatson> frafu: https://launchpad.net/~pitti
<frafu> cjwatson: I found him on the Ubuntu wiki.
<frafu> cjwatson: thanks
<cjwatson> normally he's around here, but he's at a conference at the moment
<frafu> cjwatson: ok
<mvo> davmor2: hello! just a quick question on #261423 - is this still a issue? I was not able to reproduce that with the alpha-6 livecd
<davmor2> mvo 2 ticks
<mvo> davmor2: no problem :)
<davmor2> mvo: yes it is try typing in empathy
<davmor2> mvo: or telepathy
<davmor2> mvo: you still there?
<mvo> davmor2: yes, I was just testing it
<mvo> davmor2: on the livecd the reason might be that we don't have universe enabled there
<mvo> davmor2: on the installed system it probably takes until the first apt-get update (done nightly) until those show up. does that make sense or do you see it for other packages too?
<davmor2> mvo: hang on then I'll do apt get update
<davmor2> mvo: same thing is there something that update xapain?
<davmor2> mvo: try gedit
<davmor2> that should be in regardless right?
<mvo> yes
<davmor2> mvo: ged is enough for everything to vanish
<mvo> davmor2: thanks, I boot a fresh version of the CD to test that
<davmor2> mvo: this is on an installed system after an apt-get update
<mvo> davmor2: I see here that it does not do partial searches, i.e. it does not find gedit when ged is searched, but it does find it (for me) when gedit is fully written. I remember that I worked on the code that would fix that, I wonder if its still buggy
<davmor2> mvo: confirmed
<mvo> davmor2: thanks a lot!
<davmor2> mvo: how does G-A-install get roung it?
<davmor2> s/roung/round
<mvo> davmor2: g-a-i does currently not use xapian, the data it searches is a magnitude smaller (~2000 package vs. 20.000 pkgs in synaptic)
<davmor2> mvo: ah okay I wondered if it was using similar code to do the searching :)
<mvo> but xapian in g-a-i would be good, that would make it much snappier (the search)
<davmor2> mvo: I've update the bug to add the works with full name
<norsetto> asac, seb128: I uploaded a new version of devhelp 0.20 to bug 250290 that includes today's change from 0.19.1-6
<ubottu> Launchpad bug 250290 in devhelp "Copy to clipboard causes segfault" [Medium,Confirmed] https://launchpad.net/bugs/250290
<seb128> norsetto: good, I'll have a look after lunch!
<norsetto> seb128: thx, bon appetit
<seb128> thanks, you too if you didn't have lunch yet ;-)
<norsetto> seb128: now I understand why my stomach was growling!
<terminator_> tseliot, Are the Nvidia drivers working yet for Legacy cards.  I am running a GeForce FX5200
<tseliot> terminator_: no, not yet
<terminator_> Just wondering,  I guess I'll just have to wait.
<Cheery> hi
<Cheery> how could I get the latest bleeding edge ubuntu to my machine?
<Cheery> I think the current stable is somewhat broken with pulseaudio and bunch of other new additions.
 * ogra points Cheery to #ubuntu+1
<Cheery> I sort of like improvement, but don't you fear you will introduce bunch of legacy behind you and eventually get dragged down by it?
<cjwatson> Cheery: we're often looking to clear stuff out as well as introducing new features
<cjwatson> Cheery: there's little alternative though; we can't remain static forever :-)
<Cheery> that's good to hear
<cjwatson> most of our conferences include some kind of reducing-duplication session
<Cheery> hm. have had one thing in mind for a while: I tend to do some software occassionally, how to get them into ubuntu repositories?
<Cheery> and what do you require it to contain inside?
<cjwatson> Cheery: #ubuntu-motu is usually happy to help out with that sort of thing
<cjwatson> https://wiki.ubuntu.com/MOTU/TODO/NewSoftware
<liw> Cheery, the best thing for you to do is to a) make a clean upstream release, with a working build system using standard parts and then b) what cjwatson said
<cjwatson> right, anything that's built in a standard way will probably not be hugely difficult; autotools for C programs, ExtUtils::MakeMaker or similar for perl, distutils for python, etc.
<liw> the other thing is then to work with whoever is creating the package, and be responsive to suggestions, patches, and bug reports
<cjwatson> pretty much anything can be packaged with a smart enough packager, though, so that's not mandatory; underlying quality (e.g. competently written C code written with an eye to avoiding standard security vulnerabilities) is more important than the build system
<Cheery> also would like to know: has there been monetary interest to port some apps get some new apps into ubuntu, and do you know anything about it?
<cjwatson> some companies work with Canonical's ISV team to get applications into our partner repository
<cjwatson> there have been some contracts that have involved getting packages into Ubuntu, yes, although for obvious reasons I can't discuss the details; they still have to meet general quality requirements
<dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages too
<Cheery> hm. I have yet one question, how big the ubuntu community is?
<Hobbsee> very
<Cheery> is it already counted in millions? I can see the whole effort put into ubuntu has grown huge.
<cjwatson> millions of users, but I think millions that you'd count as part of the community is probably an exaggeration. Certainly thousands though.
<cjwatson> we really have no easy way to count, which is a good place to be in IMO :)
<Cheery> it's hard to count that kind of things anyway. So you think there's thousands of devs already.
<cjwatson> Cheery: you said community, not developers
<Cheery> oh, so you included people who have committed something to ubuntu?
<cjwatson> no, community to us means documentation, advocacy, translation, bug triage, ...
<cjwatson> as well as development
<Cheery> ah. so there's much less devs than that, but still lot of people
<cjwatson> there are 110 people with direct upload access to Ubuntu, but of course there are a lot more who contribute smaller units of code, not to mention all the upstream developers who don't consider themselves part of Ubuntu but who still write the vast majority of code we use
<Cheery> hmm. perhaps I will look into it at one point and contribute something next month or so. Fix some bugs etc.
<Cheery> now I go though, I'm not fond of staying too long on huge channels
<Cheery> cya
<mvo> davmor2: the search bug should be fixed in bzr, thanks again for bringing it up
<davmor2> mvo: no probs :)
<IdleOne> http://brainstorm.ubuntu.com/latest_ideas/
<tjaalton> "gnome panel widow list"
<tjaalton> I like that one
<torkel> tjaalton: an applet for wife murders? :-)
<wgrant> "Recover OpenPGP Key from Launchpad"
<wgrant> Somebody seems to be missing the point of OpenPGP keys.
<wgrant> How does one gain moderator rights to destory such stupidity?
<tjaalton> torkel: "check.." ;)
<ldp> hello
<stefanlsd> Why dont all fields have place for a comment on - http://qa.ubuntuwire.com/bugs/rcbugs/
<james_w> stefanlsd: there is only one comment field per package
<stefanlsd> james_w: im looking next to wordpress - and i dont see a comment line...
<james_w> stefanlsd: it's against 497216, which is a different severity and so in a different place
<stefanlsd> james_w: aah ok. thanks. i see it
* herb changed the topic of #ubuntu-devel to: Launchpad is going down from 16:00 UTC until 17:00 UTC for a code update. | alpha-6 released | archive: feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.co
<Adri2000> slangasek: do you still have my vsftpd FFe request on your radar?
<mathiaz> radix: I don't see the smart cronjob implemented in landscape-client 1.0.21
* herb changed the topic of #ubuntu-devel to: alpha-6 released | archive: feature freeze | Development of Ubuntu (not support, not application development on Ubuntu) | #ubuntu for support and generaldiscussion for dapper/feisty/gutsy/hardy, #ubuntu+1 for intrepid | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<slangasek> Adri2000: yes, it's second on my list now
<youareno6> For an AMD64 system, how can I get the 32-bit version of libpcre.so.3?
<youareno6> It was not installed with the rest of the lib32 files
<stgraber> bryce: hey, how am I supposed to make X+hal detect and configure an elotouch serial touchscreen (xserver-xorg-input-elographics) ?
<superm1> stgraber, you'll need to have an FDI file that matches it
<superm1> stgraber, at this point the easiest way is to look at lshal output, and find the keys that match your event file
<superm1> stgraber, and then you'll need to craft the FDI file based on the vendor/product/capabilities/etc
<stgraber> hmm, let's hope I can get something unique for a serial device, I have some doubts about that
<bryce> stgraber: I wrote up some hints for customizing hal files at wiki.ubuntu.com/X/Config
<stgraber> yeah, though I'm not sure I can detect my touchscreen at all
<stgraber> it's not like if serial devices send a lot of attributes :)
<_MMA_> Can any one tell me if aptitude is in the -desktop seed?
<cjwatson> no, it's in standard
<cjwatson> $ apt-cache show aptitude | grep ^Task:
<cjwatson> Task: standard
<_MMA_> Noted.
<_MMA_> Hmm... I wonder why Studio isn't pulling it. (I only know 2nd hand) I am doing another VM install now.
<_MMA_> cjwatson: Nevermind. "/pool/main/a/aptitude/aptitude_0.4.11.3-1ubuntu3_i386.deb" from our list.
<mathiaz> radix: so why does landscape-config need to start landscape-client ?
<mathiaz> kirkland: do you use bzr-builddeb for update-motd ?
<kirkland> mathiaz: i've never heard of bzr-builddeb ....
<kirkland> mathiaz: does it do magic for me?
<mathiaz> kirkland: bzr bd -> build a deb package directly from the bzr branch
<radix> mathiaz: because landscape-client does the registration
<kirkland> mathiaz: nice
<mathiaz> radix: heh - I though landscape-config did the registration process.
<radix> mathiaz: landscape-config requests it via DBUS
<kirkland> mathiaz: i just pushed a set of commits to https://code.launchpad.net/~kirkland/update-motd/main
<radix> and landscape-client actually does the HTTP communication, etc
<kirkland> mathiaz: with each of the changes from 1.1 - 1.6 as a separate commit
<kirkland> mathiaz: for history's sake ;-)
<mathiaz> kirkland: great.
<kirkland> mathiaz: gimme a few minutes to apply those other changes, and the license change, build, and test it
<mathiaz> kirkland: have a look at the bzr-builddeb documentation
<kirkland> will do
<mathiaz> radix: ha - ok.
<psyke83> asac: I sent you a mail anyway, but just to let you know: I opened bug #272286 re: the nspluginwrapper problem
<kirkland> mathiaz: okay, so I should remove debian/copyright altogether then?
<mathiaz> kirkland: no no. That file has to be ther.
<mathiaz> kirkland: remove the Ubuntu packaging section from the copyright file.
<asac> psyke83: looking
<asac> darn ... LP is still slow
<kirkland> mathiaz: oh
<psyke83> asac: yep, that's why it took a while to open the bug
<asac> psyke83: we have a branch for nspluginwrapper
<asac> its better to request a merge than providing an old-style debdiff ;)
<asac> actually i am not for including that patch right now. its certainly an option and i already tested it once
<asac> so for release we should definitly take it
<asac> i am not sure if for beta
<psyke83> asac: if the flashplugin-nonfree package stays at the current version for beta, nspluginwrapper should work ok. It seems the regression with windowless mode occurred with the release candidate of flash (probably some new functions not yet implemented in nspluginwrapper)
<asac> psyke83: for me windowless mode in nspluginwrapper has always been quite buggy
<asac> well ... since 1.1.0 is in the archive - before there was no such thing
<mathiaz> slangasek: in the case of a native package, should the debian/copyright have a section about the packaging licensing ?
<psyke83> asac: yes, but there was also a bug in firefox itself, it's only been stable since 3.0.2
<psyke83> the firefox bug impacted 32 bit users too (without nspluginwrapper)
<mathiaz> radix: is there a way to run the test suite when building the landscape-client package ?
<radix> mathiaz: trial -r glib2 landscape
<kirkland> mathiaz: http://pastebin.ubuntu.com/48411/
<radix> mathiaz: though it depends on a DBUS session database to be running
<radix> as the landscape-client README file describes
<mathiaz> radix: hm - ok.
<mathiaz> radix: it would be great if the test suite could be run once the package is build.
<mathiaz> kirkland: wfm - you may wanna see what slangasek will say about it.
<mathiaz> kirkland: see above.
<kirkland> mathiaz: how far above?
<mathiaz> kirkland: 10 minutes ago
<radix> mathiaz: yeah unfortunately we haven't automated the dbus wrangling in the test suite itself, and it still depends on it already running
<radix> we'd like to fix that. do you think it's necessary in the intrepid timeframe?
<kirkland> mathiaz: i see your question, but no response from slangasek
<mathiaz> radix: I don't think so.
<Laney> Gah. No sound any more
<mathiaz> radix: I've pushed a bzr branch for landscape-client: lp:~ubuntu-core-dev/landscape-client/ubuntu
<mathiaz> radix: that's where the code for the ubuntu archive should be pushed to.
<kirkland> Keybuk: udevsettle question for you, if you're around
<mathiaz> kirkland: is your update-motd trunk branch up-to-date ?
<mathiaz> kirkland: https://code.launchpad.net/~kirkland/update-motd/main
<mathiaz> kirkland: and what you want to be sponsored ?
<kirkland> mathiaz: yes, rev 8 of lp:update-motd
<Keybuk> kirkland: sure, what's up?
<kirkland> Keybuk: http://people.ubuntu.com/~brian/tmp/cryptmount-message.png
<kirkland> Keybuk: cryptroot is calling /sbin/udevsettle
<kirkland> Keybuk: not found, presumably not in the initramfs?
<Keybuk> yes, well ... :)
<Keybuk> it should be /sbin/udevadm settle
<cjwatson> on #ubuntu-installer I pointed out that it should probably be udevadm settle now
<kirkland> cjwatson: Keybuk: aha!
<kirkland> cjwatson: Keybuk: cool, thanks guys, this should be a trivial one then
<Keybuk> kirkland: it probably shouldn't call it at all
<Keybuk> but since it does, that's a simple fix to have the right path
<nxvl> Keybuk: hi! is there any known date when the sposoring should be replied/published?
<nxvl> (for UDS)
<Keybuk> nxvl: it says there, October 2nd I think
<mathiaz> kirkland: hm - are you sure you've done all what you've said in the changelog ?
<mathiaz> kirkland: cause prerm is still there
<mathiaz> kirkland: the cron file disappeared
<kirkland> mathiaz: hmm, let me see
<nxvl> Keybuk: there where? i've only jono's post as reference
<kirkland> mathiaz: it has been moved to debian/update-motd.cron.d
<Keybuk> nxvl: the last page of summit.ubuntu.com when you applied
<kirkland> mathiaz: such that dh_installcron will take care of it
<mathiaz> kirkland: it's not your branch though.
<nxvl> Keybuk: oh, ok, thank you!
<kirkland> mathiaz: i must have skipped bzr add
<cjwatson> (bzr mv is your friend if you're moving a file)
<mathiaz> kirkland: right - bzr move is even better in that case
<kirkland> mathiaz: ah, well, i was importing each of the last few revisions
<kirkland> mathiaz: by applying the diffs between each deb released
<cjwatson> kirkland: if you find you have to do that again, bzr-builddeb has a 'bzr import-dsc' plugin
<cjwatson> you just do 'bzr import-dsc --distribution=ubuntu *.dsc' and it gives you a branch
<kirkland> cjwatson: wow, that's cool
<mathiaz> kirkland: while you're changing the bzr branch, could you setup bzr-builddeb in native mode ?
<mathiaz> kirkland: add a file named .bzr-builddeb/default.conf
<kirkland> mathiaz: sure... i also wanted to add a VCS thing to the control file too
<mathiaz> kirkland: http://paste.ubuntu.com/48424/ <- content of the default.conf file
<kirkland> mathiaz: XS-Vcs-Bzr: https://code.launchpad.net/~kirkland/update-motd/main
<kirkland> mathiaz: is that correct?
<cjwatson> no need for the XS-
<cjwatson> that used to be needed, but it was made an official field
<kirkland> cjwatson: k
<mathiaz> kirkland: hm - I've used lp:~ in landscape-client.
<mathiaz> I'm not sure what's the correct usage though.
<cjwatson> I recommend Vcs-Bzr: http://bazaar.launchpad.net/~kirkland/update-motd/main
<cjwatson> that way anyone can paste it into a web browser and see the contents of the branch without necessarily having to learn how to use bzr
<mathiaz> cjwatson: right - isn't that the meaning of Vcs-Browser ?
<cjwatson> more direct than code.launchpad.net
<cjwatson> mathiaz: for systems where you have to use a different URL for both, sure; but in bzr's case the same URL can do double duty
<kirkland> mathiaz: cjwatson: and all of that is preferred to just "lp:update-motd" ?
<cjwatson> kirkland: yes
<kirkland> k
<mathiaz> cjwatson: I thought that Vcs-Bzr would point to the url that can be used to co the actual branch.
<cjwatson> mathiaz: and so it does, in my example.]
<cjwatson> mathiaz: feel free to try it ...
<kirkland> speaking of, i have a related Launchpad/bzr question....
 * mathiaz tries
<cjwatson> mathiaz: it won't get you something you can write to if you happen to have permission to write to the branch, that's true
<kirkland> i'm co-maintaining ecryptfs now; git.kernel.org is going to continue being the source repo for now, but we're going to move the mailing lists, bugs, etc. from Sourceforge to Launchpad
<cjwatson> mathiaz: but we have tools to address that, like debcheckout -a
<mathiaz> cjwatson: right.
<mathiaz> cjwatson: I'll update the Vcs-Bzr header for landscape-client. I've lp:~... instead of http.
<kirkland> we need a place to publish the versioned, released tarballs.  sourceforge just had an FTP site.  i'm using a bzr branch, http://bazaar.launchpad.net/~kirkland/ecryptfs/release_tarballs/files?sort=filename
<cjwatson> mathiaz: for the moment, while lp: is really useful in lots of contexts, I think it's too opaque for the control metadata, and duplicating Vcs-Bzr and Vcs-Browser to provide the paste-into-web-browser feature is a pain
<kirkland> cjwatson: does that fly?
<cjwatson> kirkland: LP has an upload-your-tarball feature too
<kirkland> cjwatson: really?  i swear i looked for just that....
<cjwatson> kirkland: you may have to be the project driver
<kirkland> cjwatson: i am
<cjwatson> ah, you are
<cjwatson> kirkland: go to https://launchpad.net/ecryptfs/trunk
<cjwatson> kirkland: "Register a release"
<kirkland> cjwatson: lookey there....
<kirkland> cjwatson: cool, thanks.
<cjwatson> kirkland: once you've gone through that, you'll have a "Releases" widget on https://launchpad.net/ecryptfs/trunk
<kirkland> cjwatson: nice, i'll play with it
<cjwatson> kirkland: pick the release from that, and then "Add download file"
<kirkland> cjwatson: cool, thanks.
<kirkland> mathiaz: okay, now am I supposed to use something other than debuild to build this?  bzr builddeb or something?
<mathiaz> kirkland: bzr bd
<mathiaz> kirkland: try bzr bd --help
<kirkland> bzr: ERROR: unknown command "bd"
<mathiaz> kirkland: ok - have you installed the bzr-builddeb package ?
<kirkland> nope, installing....done
<mathiaz> kirkland: I usually use bzr bd -S to build the source package
<mathiaz> kirkland: and then sbuild to build the package.
<kirkland> mathiaz: yup, i just found that one
<mathiaz> kirkland: if you use bzr bd, it will export your branch to ../build-area/ and build it there.
<kirkland> mathiaz: i'm testing the binary now
<mathiaz> kirkland: that way it won't clutter your bzr branch.
<cjwatson> FWIW you can generally use plain 'debuild -S' too
<cjwatson> bzr bd has some nicer features but there's no real reason to deprecate debuild -S AFAICS
<kirkland> cjwatson: i think i ran into a situation where debuild or debuild -S left some cruft around when I did the bzr commit.....
 * kirkland can't clearly remember wait that was, vague memory
<cjwatson> so why weren't you using bzr status to see what you were committing before bzr commit? :)
<cjwatson> usually, at worst, debuild -S leaves some unknown files in the branch, which bzr will pay no attention to unless you add them
<cjwatson> it's very rare for it to actually modify files already in the branch, and usually indicates a bug in the build system
<cjwatson> sometimes 'debian/rules clean' will update po files and such, and in that case chances are you might actually want to commit that
<kirkland> k
<cjwatson> (but I'm not saying don't use bzr bd -S if it works for you)
<kirkland> mathiaz: okay, i think rev 13 is ready to go
<kirkland> mathiaz: you wanna give it a sanity check?
<mathiaz> kirkland: sure (considering that I'll sponsor it) :)
<kirkland> mathiaz: ;-)
<mathiaz> how can you from a system that is in oldrease now (ie edgy -> feisty) ?
#ubuntu-devel 2008-09-20
<kirkland> cjwatson: and the UNRELEASED thing that you do... is that just an accounting mechanism you use to keep track of what's been pushed and what hasn't?
<mathiaz> kirkland: it's a way to notifies other devs that it hasnt' been uploaded yet.
<mathiaz> kirkland: but you still need a way to say that a new release of the package has started and is being worked on.
<bryce> soren: could you comment on #237164 - these are the kvm xorg.conf bits we added a while back.  Are they still needed?  Sounds like maybe not.
<kirkland> mathiaz: k
<kirkland> mathiaz: i'll do that next time
<kirkland> bryce: soren's basically on paternity leave
<bryce> gotcha
<kirkland> bryce: i'm going to be backing him up on kvm'age
<bryce> kirkland: cool
<kirkland> bryce: :-)  i guesss
<kirkland> bryce: no really, i'm looking forward to it, just not sure where to begin.....
<bryce> kirkland: could you test with kvm if running with no /etc/X11/xorg.conf still allows X to work under kvm correctly?
<kirkland> bryce: graphical desktop, i presume?
<bryce> kirkland: righto
<kirkland> bryce: (that's a joke)
<kirkland> bryce: i have an old intrepid desktop kvm... let me bring her up to date
<kirkland> bryce: sweet, only 303 packages to upgrade :-)
<bryce> hehe
<mathiaz> kirkland: you haven't documented your VCS-* changes in the debian changelog
<mathiaz> kirkland: you should also add VCS-Browser to debian/control.
<kirkland> mathiaz: what is the syntax of this VCS-Browser bit?
<cjwatson> please don't add vcs-browser. it's a waste of effort. just add vcs-bzr with an http url
<cjwatson> for example no installer package uses vcs-browser but practically all of them use vcs-bzr. It works fine.
<kirkland> mathiaz: updated changelog in rev 14; didn't add vcs-browser per cjwatson's input
<cjwatson> vcs-browser is for vcsen like CVS (and to some extent Subversion) where the browseable URL cannot be mechanically guessed from the vcs url itself
<cjwatson> see e.g. http://packages.qa.debian.org/b/base-passwd.html (search for VCS) for an example of how this is rendered by the only web UI I know of that parses Vcs-*
<mathiaz> kirkland: a debdiff between 1.6 and 1.7 shows that one of the changelog entry had its date changed.
<mathiaz> kirkland: Fri, 22 Aug 2008 17:16:41
<mathiaz> kirkland: http://paste.ubuntu.com/48433/
<kirkland> mathiaz: relic of my semi-manual import of the deb changes into bzr
<kirkland> mathiaz: wish i had know about the magic import plugin cjwatson mentioned
<mathiaz> kirkland: okay -  that's easy to change then. (I don't have commit access to the branch :p )
<kirkland> cjwatson: Keybuk: patch posted to https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/272301, tested, silences the error messages that bdmurray reported and i reproduced
<ubottu> Launchpad bug 272301 in cryptsetup "udevsettle and init-functions missing from initramfs" [Low,In progress]
<kirkland> mathiaz: got the upload notice, thanks ;-)
<NCommander> lamont, hi
<kirkland> bryce: geez, upgrades on the desktop take a lot longer than on the server :-P
<kirkland> bryce: upgrading gnome + office = snooze for a while
<slangasek> mathiaz: if it's a native package, surely the licensing on the packaging should match the licensing of the package as a whole?
<bryce> kirkland: heh yep
<sleepster> I would like to add a package to apt.. how do I go about doing that?
<kirkland> slangasek: it certainly does in this case
<kirkland> slangasek: misunderstanding on my part, as I was cloning the licensing information from other packages
<mathiaz> slangasek: sure - to be more precise, do you need to have an explicit note in debian/copyright about the packaging license ?
<kirkland> Daviey: hiya
<kirkland> Daviey: saw your ping the other day, sorry i missed you
<Daviey> kirkland: no worries
<Daviey> kirkland: you got a mention in the ubuntu uk podcast we recorded tonight.. only brief - but still :)
<kirkland> Daviey: woohoo :-)
<cjwatson> mathiaz: personally, I take the line that if the packaging doesn't have an explicit licence then the intent is clearly for it to be under the same licence as the rest of it
<cjwatson> I have no idea whether this is legally sound ...
<kirkland> Daviey: regarding?
<kirkland> bryce: lesson learned....  install from scratch is probably faster than an upgrade
<kirkland> woohoo, 31st most popular blog of the day on WordPress (GregKH rant response) ...  http://botd.wordpress.com/2008/09/20/top-posts-876/
<Keybuk> gregkh had a rant? :)
<elmo> greg who?
<slangasek> kirkland: so I don't think there needs to be an explicit note about the packaging license, no
<kirkland> slangasek: thanks, i removed it at mathiaz' request
<slangasek> elmo: greg "kh", I think his last name is Tajik or something, yes?
<Keybuk> he looks like lurch from the addams family ;)
 * slangasek snorts
<slangasek> Keybuk: so I'm sure you'll be starting the we-love-gregkh team in LP soon
<Keybuk> actually I get along with him just fine ;)
<kirkland> watch it...  he might just turn off your usb without warning
<kirkland> bryce: my desktop kvm is *now* upgraded and dist-upgraded :-)
<bryce> kirkland: cool
<kirkland> and now, for my final performance of the evening, i will boot a kvm *without* an xorg.conf....
<bryce> kirkland: yay
<kirkland> followed by partying into the night :-)
<_Zeus_> :P
<kirkland> bryce: gnome came up just fine, though in 800x600 rather than 1024x768
<kirkland> for a minor encore, i will attempt to switch resolutions via System->Preferences->Screen Resolution .....
<bryce> ok, so sounds like we still need the kvm bits in dexconf
<kirkland> no love
<kirkland> bryce: anything else you need at the moment?
<bryce> nope, that confirms it, thanks
<kirkland> bryce: np.
<kirkland> adios all
 * kirkland turns off his pirate filter
<bryce> kirkland: btw bug in question is 237164; I've bumped it over to kvm and closed the xorg task.
<Keybuk>       read 2283 modules : new(0)  missing(93)
<Keybuk> EE: Missing modules (start begging for mercy)
<Keybuk> *blink*
<Keybuk> to whom should I beg, and should I go fetch my collar?
<bryce> heh
<NCommander> argh
<NCommander> Someone please hit me
<NCommander> I'm considering writing a brainf?ck compiler
<ldp> :|
<ldp> hehe
<YokoZar> Hmm, I'm not registered for ubuntu-users so my email to that list got in the moderator queue, even though I am an Ubuntu developer...
<alien> hello, is it known yet what kernel version will be shipped with intrepid?
<Mez> !info linux-image
<ubottu> linux-image (source: linux-meta): Generic Linux kernel image.. In component main, is optional. Version 2.6.24.19.21 (hardy), package size 25 kB, installed size 52 kB
<alien> that's hardy
<Mez> stupid thing doesnt pick up intrepid yet
<wgrant> !info linux intrepid
<ubottu> linux (source: linux-meta): Generic complete Linux kernel.. In component restricted, is optional. Version 2.6.27.3.3 (intrepid), package size 2 kB, installed size 32 kB
<alien> okay, so 2.6.27
<wgrant> Yes.
<alien> great
<Mez> http://packages.ubuntu.com/intrepid/linux-image
<wgrant> Mez: It defaults to the latest stable.
<alien> thanks
<alien> i was interested if it's going to be greater 2.6.27.5, since my webcam is supported starting with that version
<wgrant> Erm.
<alien> and i think we may get to 2.6.27.5
<wgrant> 2.6.27 isn't out yet.
<terminator> I am trying to setup my Geforce FX5200 video card with the nvidia 173 drivers and I get nothing but low video mode.  What am I doing wrong?
<ogra-Q1> terminator, #ubuntu is the place to ask such questions
<ogra-Q1> (see topic)
<terminator> Sorry new to this irc stuff and don't really know where to go
<xfamousbabiiboy_> hey
<Adri2000> slangasek or another member of the release-team: I know it's week-end, but it would be cool to review the vsftpd FFe asap, so that it gets as much testing as possible
<poningru> ok so sshfs is kinda broken right now in hardy and intrepid
<poningru> I can automount sshfs using just fstab
<poningru> err cant*
<pitti> hi
 * sebner winks mighty pitti 
 * pitti hugs sebner
<sebner> :)
<bryce> heya pitti
<NCommander> Hey pitti, got a moment to answer a packaging question
 * NCommander figures you should know
<pitti> NCommander: sure
<NCommander> pitti, if I need to install something with special permissions (i.e. setuid, or something similar), how do I do it so upgrades don't clobber said permissions
<NCommander> pitti, I assume you do it in post/pre scripts, but I have that gut feeling there has to be a better way
<pitti> NCommander: two ways really
<pitti> NCommander: if the owner and group of the file are static (< 100), then you should just do it in debian/rules
<NCommander> after getting base-files updated, right?
<pitti> NCommander: i. e. chmod/chown them approprietly and dh_fixperms -X them
<pitti> NCommander: but if you need to chgrp it to a dynamic system group, the postinst needs to chmod/chown them, after making sure that there is no dpkg-statoverride for the file already
<pitti> NCommander: base-files?
<pitti> NCommander: what are you trying to do exactly?
<NCommander> No
<NCommander> Question on NM :-)
<NCommander> I'm not actively packaging anything
<NCommander> Debian policy manual says that if you need a static group assignment, you need to ask the maintainer of base-files to add it
<NCommander> er
<pitti> oh
<pitti> that's usually not how it's done
<NCommander> yeah
<pitti> adding static groups is a PITA
<NCommander> (there is a big note saying it should be avoided if possible ;-))
<pitti> so usually packages create their own system users/groups and chmod in postinst
<NCommander> Right, that's fine if its dymanic
<NCommander> (you just need to clear it by the maintainer to make sure that name isn't used anywhere else in the system)
<NCommander> Thanks :-)
 * NCommander is one small step closer to DD
<NCommander> \o/!
<NCommander> and once I reach DD status, I shall apply to join Utunbtu
 * NCommander thinks he spelled that right
<Laney> NCommander: utnubu (read it backwards)
<NCommander> I know its utubu in reverse
<NCommander> Er
<NCommander> ...
<NCommander> .....
 * Laney titters
 * NCommander takes a gun and shoots his brain
<Laney> What do Totem, Banshee and Rhythmbox have in common that they don't with adobe flash and VLC?
<Laney> (broken sound in the former)
<pitti> Laney: gstreamer?
<pitti> Laney: might be that the former use pulseaudio, while the latter don't
<Laney> VLC definitely does
<pecisk> PulseAudio provides ALSA and Esound support, so theoretically Flash and VLC shouldn't care. However Flash is very picky about this.
<Laney> I had to install vlc-plugin-pulse for it to output sound, but it works now
<pitti> Laney: try "killall pulseaudio" and restart totem/rb
<pitti> Laney: didn't you just say that sound worked in vlc, but not in rb?
<Laney> pitti: Yes, that's right
<Laney> pitti: Good call, works now
<NCommander> hey lamont
<calc> hello
<calc> it looks like they aren't expecting to fully fix power in our zip code until after thu sept 25 (so sometime after 2 weeks with no power)
<xMassi1986x> Hi
<xMassi1986x> The next release is scheduled for 31 th October?
<xMassi1986x> ZzZzZzZz
<bigon> https://wiki.ubuntu.com/IntrepidReleaseSchedule
<Yoghurt^> xMassi1986x no
<xMassi1986x> Yoghurt^: wtf?
<xMassi1986x> Yoghurt^: wtf?
<Yoghurt^> the next release will be a beta
<Yoghurt^> 2008-10-02
<Yoghurt^> and ubuntu 8.10 will hit the internet 2008-10-30
<haker3> come to #antynonsensopedia
#ubuntu-devel 2008-09-21
<cjwatson> NCommander: it's the base-passwd maintainer you need to ask (aka me :-)), not base-files
<NCommander> ack
 * NCommander hides from cjwatson's all mightly passwd-foo
<cjwatson> I get about one mail every couple of months asking for new static assignments, I think
<cjwatson> I probably accept about half of them, and advise the rest that they can use dynamic ids instead
<NCommander> cjwatson, the question was for NM, not because I was packaging anything ;-)
<cjwatson> so a homework question, you mean? ;-)
<TheMuso> slangasek: ardour already had an upload done for that, but ardour FTBF for crazy scons reasons.
<TheMuso> FTBFs
<slangasek> TheMuso: hrm; I didn't notice that it was out of date on all archs :/
<slangasek> TheMuso: so, how do we fix it to not use scons? :-)
<TheMuso> slangasek: Yeah, persia previsouly did an upload for that same thing, but it FTBFs, which we are still trying to work out.
<TheMuso> slangasek: Rewrite the build system for the package? :)
 * TheMuso notes that it used to use autoconf, but that was a few years ago.
<TheMuso> slangasek: I was pondering simply not using scons for the install, but scons still builds important package files in that state, such as translation files etc, which IMO really should be done in the build stage. So I am not sure where to go from here atht emoment.
<slangasek> I still like "replace the build system" better than the alternatives :-P
<TheMuso> slangasek: So do I, but I don't think thats realistic before beta.
<slangasek> pitti: when you say hal has "tons of fdi files"... were are they?  I only see vendor-specific laptop fdi files for macbooks and dells
<slangasek> s/were/where/
<slangasek> pitti: oh, perhaps they're all in the hal-info package
<slangasek> TheMuso: so I might've tred to switch it over to autotools, except a 1400-line SConstruct file makes me weep
<slangasek> TheMuso: "tried"
<StevenK> slangasek: The fdi files could be in hal-info?
<slangasek> StevenK: yes, I noticed. :)
<StevenK> Heh
<rom1v> hi
<rom1v> in intrepid alpha 6, the version of pulseaudio is :  0.9.10-2ubuntu3
<rom1v> do you plan to upgrade to 0.9.11 or 0.9.12?
<rom1v> for intrepid final?
<rom1v> http://www.pulseaudio.org/ticket/364 (a bug corrected on .11 or .12)
<torkel> rom1v: If you want to test pulseaudio 0.9.12 see https://lists.ubuntu.com/archives/ubuntu-devel/2008-September/026470.html
<TheMuso> rom1v: We will be sticking with 0.9.10. Too many users with issues with either 0.9.11 or 0.9.12, including myself.
<Treenaks> TheMuso: you'll get a lot of grief from the allcaps('but the latest version is always the bestest') crowds
<pecisk> why NetworkManager is left alone without network-admin? So far it's config guis and functionality is huge regression
<ogra> njpatel, do you thnk bug 269150 can be fixed before intrepid ? (i'd nominate it for the release then)
<ubottu> Launchpad bug 269150 in netbook-launcher "No text under icons with Intrepid alpha 5" [Undecided,New] https://launchpad.net/bugs/269150
<ogra> (so it shows up on the relese managers radar)
<njpatel> ogra: yeah, i'll try and get it done tomorrow/tuesday. Didn't get a chance last week
<ogra> no hurry, if we make it critical for release applying fixes wont be blocked at least
<ogra> pecisk, what do you not like about the new UI for setting up static IPs etc ... i think its far more advanced
<ogra> (and offers a lot more options network-admin didnt even tak into account)
<ogra> *take
<pecisk> ogra: but that is not what I need
<ogra> ??
<pecisk> I don't need advance side of it
<pecisk> it is overblown
<pecisk> haotic
<pecisk> it never appealed me
<pecisk> I don't know guys, but you need a beter consulation with real users of Ubuntu before making decisions like that
<pecisk> because Ubuntu isn't used by geeks anymore
<ogra> the two dont work properly together
<ogra> and having the manual configuration in the same UI is easier to understand imho
<pecisk> ogra: it isn't easier
<pecisk> you tried to do it?
<ogra> i agree thats its harder to find since oyu need to right click to reach it
<pecisk> not only
<pecisk> better was to fix network-admin and leave NM for what it is good at - switching connections and easy wifi connecting
<ogra> i disagree
<ogra> (as well as the UI design team does afaik)
<pecisk> well, I haven't heard any public disscusion or read decisions about this
<ogra> though i see your point, it seems to offer an 802.11 security tab for wider here
<ogra> *wired
<ogra> that shouldnt be shown for cards not being able to use it
<ogra> but i really dont see much difference in the IPv4 settings if i compare to network-dmin
<ogra> *admin
<ogra> well, what do you need a public discussion for ? upstream drops network-admin in favor of the new stuff
<ogra> so whats the point in keeping obsolete stuff around ?
<pecisk> ok, not a public discussion
<pecisk> can I read what was basis of such decision?
<ogra> ikely on some gnome upstream ML
<ogra> *likely
<pecisk> propblem is that NetworkManager is written "PulseAudio" all over again
<ogra> the upstream plan is to have all network handling centralized afaik
<ogra> ???
<pecisk> it is broking things which shouldn't be touched with 10 foot pole if you have really good reason to do so
<pecisk> well, then NM isn't that tool to centralize to
<pecisk> sorry about being harsh, but I was really upset about this
<pecisk> I deploy Ubuntu to users in every day basis and this affects me
<ogra> i didnt make that decision, but i see it working with DSL, wider, wireless and 3G connections
<ogra> s/wider/wired
<ogra> what is missing in your opinion ?
<pecisk> NM configuration dialogs are not up to their jobs
<ogra> (i missed VPN above, but i dont have any VPN to test that setup)
<pecisk> for now
<pecisk> it can be fixed, to be sure
<ogra> they are not different to network-admin
<pecisk> they are very different
<pecisk> there are no profile switching, for example
<ogra> i dont see any difference between the n-a and n-m dialogs for ipv4 wired settigs at all actually
<pecisk> network-admin gui was very simplified and actually was done right. NM looks like all features have exposure on GUI, which is huge no no
<pecisk> you don't, user will see
<Treenaks> pecisk: It's not a no-no if it's the only way to configure
<ogra> i have them both open side by side here
<Treenaks> pecisk: some things HAVE to be configured
<ogra> there is only a "routes" button added to the n-m dialog
<ogra> apart from that they are 100% identical
<ogra> and i see it as an improvement that you now finally have a gui way to configure DSL
<pecisk> Treenaks: at least have some sections for Advanced stuff then
<ogra> which n-a didnt offer at all
<ogra> same goes for 3G modems connections
<pecisk> if you have to configure DSL, then it is really something wrong with system
<pecisk> ok
<pecisk> anyway
<pecisk> ogra: I am all about additional functionality, but let's not destroy old one
<Treenaks> pecisk: Uhr.. PPPoE DSL won't configure itself
<pecisk> ok, I stand corrected then
<ogra> yeah, i was about to ask pecisk how he would use DSL without configuration :)
<ogra> most of the 5 protocols used over the world wont work without configuration
<pecisk> anyway, I am really happy about NM functionality, and propably Ibex is right time to switch on it, but I would like to see huge improvements in configuration, because I really miss old stuff
<pecisk> that's all
<ogra> file bugs ;)
<ogra> its not to late for fixes
<ogra> i agree that the menu option should be in the left and not the right click menu for example
<ogra> so its easier to reach
<pecisk> it should be in System => Administration too
<pecisk> :)
<pecisk> maybe it is now, I haven't touched Ibex for two weeks
<ogra> well, it requires NM to run
<pecisk> uhh ohh
 * RainCT asks from his ignorancy: does NM work if I don't use gnome-panel? :P
<ogra> so i'm not sure it would work in System => Administration if you dont at least have the dbus backend in place
<ogra> RainCT, sure
<pecisk> nm is independent
<ogra> the applet needs any kind of systray though
<pecisk> nm-applet is what you see in gnome-panel
<ogra> which also pypanel, xfce panel and kde offer
<pecisk> ogra: well, that's not right, but I hope they will change it
<pecisk> ogra: I about NM must run when you use configure dialog
<ogra> well, to change the config the toool writing the config must run
<RainCT> alright, thanks :)
<ldng> Just in case someone care as it broke the bulletproof X : Bug #272755: X broken by missing xf86GetPciDomain function in DRI module
<ubottu> Launchpad bug 272755 in xorg "X broken by missing xf86GetPciDomain function in DRI module" [Undecided,New] https://launchpad.net/bugs/272755
<jcristau> ldng: attaching plain text files is way better than random tarballs...
<ldng> jcristau: ok, sorry
<ldng> if I can help let me know
<ldng> yet the first attachment is a tar created by the failsafe session, I've just compress it; For my information, does launchpad untar automatically them ?
<jcristau> ldng: looks like you have leftover crap from fglrx
<ldng> jcristau: hum, I didn't see that, I'll purge it to see if it solves something
<ldng> jcristau: indeed it solved it. I didn't think just having it around but not in use could affect the whole X. Should I change the status to invalid in your opinion ?
<superm1> tseliot, thanks for the patch, i've uploaded it
<tseliot> superm1: thanks for the upload ;)
<seanh> Hey, does anyone know a good little web server I can install on my laptop for web development (python, cgi)? I don't really want to install something like apache. I'm thinking more along the lines of the convenient development servers that frameworks like django come with, where you just run the server in a terminal not even as root, and just kill the process when you're done
<Nafallo> seanh: hi. this channel is not for support. you might want to try your luck in #ubuntu :-)
<seanh> Yeah I know, sorry. I thought this question probably too difficult for #ubuntu, but developers may be able to answer it. Perhaps I wanted the devel-discuss channel
<oni> hi
<oni> hi
<oni> where can i send a displayhotplug script to
<Keybuk> a what?
<oni> a little script that polls the connection of displays and run commands when connect and disconnect
<oni> for example to activate dualhead when two displays are connected
<Keybuk> why poll?
<Keybuk> you get events for that kind of thing, and the X server handles it
<oni> but why is there no programm that uses this events
<Keybuk> X does
<Keybuk> if you plug in a display, and run xrandr, you'll see that it has noticed the new display
<jcristau> it only notices because you ran xrandr
<oni> i think so too
<jcristau> but still, don't poll
<Keybuk> jcristau: I do not believe that is true
<oni> jcristau: better ideas?
<Keybuk> jcristau: the xrandr tool simply queries the currently known outputs
<Keybuk> it's true that you have to run xrandr --auto to *configure* outputs
<Keybuk> (or xrandr --output VGA --mode ...)
<jcristau> Keybuk: no, plain xrandr does all the load detection and probing
<Keybuk> but I'm pretty sure (and could be wrong :p) that X does the detection
<Keybuk> jcristau: do you have a reference for that?  because I'm reading the source ...
<sebner> Keybuk: hey :) short question. why did you tell me that it's better to use a 32bit ubuntu also with 4gb ram?
<Keybuk> sebner: ?
<sebner> Keybuk: yeah, you told me that while you helped me with a usb/boot problem, remember?
<Keybuk> nope
<sebner> Keybuk: nope = you can't remember or you didn't tell me that ^^
<Keybuk> sebner: can't remember saying that
<Keybuk> I generally recommend 32-bit
<Keybuk> you may not have mentioned the 4GB of RAM bit
<sebner> Keybuk: ah I asked you if it's a problem to use 32bit with 4gb since only 3 are really used
<Keybuk> well, it's not a problem :)
<sebner> Keybuk: but in case of 4gb you recommend 64bit version, right?
<jcristau> Keybuk: ProcRRGetScreenResources calls RRGetInfo, which calls into the driver's probe functions
<Keybuk> sebner: if you want to use the 4gb
<Keybuk> jcristau: but xrandr doesn't call that?
<jcristau> Keybuk: and the first thing xrandr does is XRRGetScreenResources
<Keybuk> oh, yes it does
<Keybuk> fair enough ;)
 * Keybuk stands corrected
<sebner> Keybuk: now is the question if I care about this 1 missing GB or I care because I *have* 4 gb
<Keybuk> sebner: ?
<jcristau> oni: have the user press some key
<sebner> Keybuk: if I have 4gb this doesn't mean that I have to use the 64bit version because of this
<Keybuk> sebner: I don't understand what you mean, sorry
<Keybuk> sebner: you don't have to, no
<oni> no it is hotpulg
<Keybuk> sebner: you don't _have_ to do anything ;)
<Keybuk> the 32-bit version will still boot, it just won't use all your ram
<sebner> Keybuk: I know but I still can't decide if I should use 32bit or 64bit. Do I need only the 3gb ram (sure) or should I use the 64bit version just because I *have* 4gb :)
<Keybuk> 64-bit may be faster for some operations, and may be slower for others
<Keybuk> programs use more memory in 64-bit
<Keybuk> proprietary software (ie. flash) generally fails to work
<sebner> Keybuk: ah I forgot. Ok then the 32 bit versino :)
<sebner> *version
<Keybuk> I'm unsure what the general wisdom is about 64-bit on Intel Core 2
 * Laney runs it
<sebner> Keybuk: and sorry, I didn't want to confuse you but if I use the 32 bit version I somehow *Waste* 1 gb because it doesn't appear that was the thing that made me thinking
<Keybuk> On AMD64, it certainly seems to make a big improvement on speed
<Keybuk> sebner: well, you'll have 1GB less addressable memory
<Keybuk> but all your programs will be roughly half the size ;)
<sebner> I know ^^ .. but it's still a waste =) I'll build the pc by myself. maybe I should only buy 3gb but 4 sounds better :P
 * Keybuk runs 32-bit on his core 2, but 64-bit on his amd64
<Keybuk> I think the former was simply which disk I had to hand at the time :p
<sebner> Keybuk: It will be a quadcore :D
<Keybuk> hmm, at that point I think there are other 64-bit features you might want
<sebner> Keybuk: well, the pc is for my parents and they would also be happy with a single core ^^^
<Keybuk> you give your parents a quad core machine with 4GB of RAM?!
<Keybuk> I give mine the address of Dell's website and tell them to buy something cheap
<sebner> Keybuk: sure. Very cheap that stuff at the moment and ok for the next 3-4 years
<sebner> Keybuk: the pc won't cost more than 400-500â¬ ;)
<Keybuk> Keybuk's 42nd rule of technology: the average lifetime of hardware is roughly half that it was expected to last
<sebner> Keybuk: I also want my parents to be "cool" :P
<Keybuk> you'll end up doing tech support for them
<sebner> Keybuk: I'm doing tech support since years (windows xp) ;) and I *really* think with ubuntu it'll become less :D
<Keybuk> ubuntu as well? :)  brave man!
<sebner> Keybuk: of course. Otherwise I wouldn't ask :P
<sebner> Keybuk: and btw, what does make a quadcore and 4gb ram sense with windows xp? (vista ... no ... really)
<Keybuk> sure
<sebner> Keybuk: I still don't know if I should buy now 4gb or only 3 ^^
<ion_> My dadâs computer uses my puppetmaster just like all my computers, so i can do some configuration without even having to visit them. :-) Not that i donât mind visiting them, but i rather visit *them* instead of *their computer*. :-)
<sebner> ion_: I still live with them ^^
<Keybuk> my parents computers run windows, and they know not to ask me for help :p
<sebner> hrhr
<sebner> Keybuk: btw, you big to make the swap partition with 4gb ram? 4gb? ^^
<Keybuk> err?
<sebner> though I think no swap necessary with 4gb ram ^^
<Keybuk> swap is always useful
<Keybuk> otherwise how will they hibernate, for one?
<sebner> they never do ...
<sebner> nor I'm doing that xD
<Keybuk> swap means unused apps can be moved to swap to make room for more page cache
<sebner> Keybuk: sure but I read that swap should be as big as the ram
<Keybuk> indeed
<Keybuk> I think the rule used to be "twice as big"
<Keybuk> then it was "as big, or 2GB, which ever is larger"
<sebner> Keybuk: so the swap should be 2gb?
<Keybuk> no, size of ram
<Keybuk> just use the installer
<Keybuk> it does all this for you :p
<oni> better dubble size of ram
<sebner> No I'm seperating /home  ;)
<sebner> oni: so 8gb ? ^^
<Keybuk> oh, gods, WHY!?
<oni> yes
<Keybuk> every other week I get very tempted to simply make split filesystems not work
<sebner> Keybuk: /me has no problem with it and it's great if I reinstall ubuntu :)
<oni> a java-man:"disks are cheap"
<sebner> oni: well the pc will have 500gb harddrive
<oni> so why not 8gb swap
<sebner> oni: the question is if 8gb are really usefull or are 4gb enough
<ion_> Puppet is quite nice for managing computers. For instance, i have this module for fixing Ubuntuâs fonts (main file: http://gitweb.heh.fi/?p=ion/puppet/sharp-fonts.git;a=blob;f=manifests/init.pp, templates referenced by it: http://gitweb.heh.fi/?p=ion/puppet/sharp-fonts.git;a=tree;f=templates). If i wanted my dadâs box to use that config, iâd just add the class to his node. Or the default node, which is what iâve done.
<Keybuk> I sat next to someone who was a Puppet developer at the LPC Speakers Dinner
<ion_> The computers pull the settings from puppetmaster, so i donât have to allow connectivity from me to my dadâs laptop.
<oni> if they will ever suspend 8gb are usefull
<sebner> oni: why? They only use firefox or that stuff
<sebner> Keybuk: I decided to buy 4gb so I have 1gb in stock if one breaks down :D
<ion_> sebner: The Ubuntu installer handles /home even if itâs on the root partition.
<Keybuk> a quad core, 4GB RAM, 64-bit box ...
<Keybuk> ... to run FIREFOX?!
<Keybuk> it's crap, but not *that* crap! :p
<sebner> Keybuk: office :D
<azeem> Firefox office FTW
<Keybuk> actually, you do want it 32-bit if it's for parents
<Keybuk> and with the windows dlls and stuff
<sebner> Keybuk: yes I know
<Keybuk> otherwise they won't be able to do flash, or watch movies they download
<sebner> Keybuk: they don't download movies O_o
<oni> sebner: i think your qustion ist allready answered
<Keybuk> yes, I used to think my parents didn't look at porn either -- then I opened the bookmarks
 * sebner has no cyperpirates at home xD
<sebner> Keybuk: omg xD
<sebner> oni: yes?
<oni> sebner: yes, you said "firefox"
<sebner> Keybuk: as I said. things are cheap now. The last pc (without screen) were 800â¬. and now I'll make one with half the price and a lot more power :D
<sebner> oni: so 8gb are usefull?
<sebner> -l
<oni> i would do so
<sebner> oni: and 4gb aren
<sebner> oni: aren't enough because .... ?
<oni> it is enough but not recommended
<sebner> oni: also for parents?
<Keybuk> *baffled*
<ion_> :-)
<Keybuk> I only have 2GB in any of my machines
<sebner> because I actually have 500mb used from 2gb ram and 2mb swap from 2gb :)
<sebner> Keybuk: ram or swap?
<Keybuk> sebner: ram
<sebner> Keybuk: cheap! :D
<oni> sebner: don't know my parents don't have swap in their head
<sebner> Keybuk: I could also buy a singlecore and use 1gb ram. so the pc is new but crap ^^
<Keybuk> right, time for flight
<Keybuk> l8r
<sebner> and for me it's time for bed :D
<sebner> gn8 folks
<sebner> oni: and thx for the tipps
<oni> n8
<oni> np
<TheMuso> Treenaks: I'll admit I was once like that, but experience has taught me otherwise.
#ubuntu-devel 2009-09-14
<TheMuso> crimsun: Right.
<bluefoxicy> for fucking fuck's sake >_<
<bluefoxicy> there should NOT
<bluefoxicy> SHOULD NOT
<bluefoxicy> be lock contention in production kernel code >:O
<bluefoxicy> this stupid argh
<bluefoxicy> there is NO WAY to debug this
<bluefoxicy> the damn
<bluefoxicy> it
<bluefoxicy> damnit
<bluefoxicy> it fucking HANGS
<bluefoxicy> and sometimes, SOMETIMES comes back
<bluefoxicy> sometimes the WHOLE DAMN SYSTEM locks up eventually
<bluefoxicy> things start hanging when they try to access disk
<bluefoxicy> network activity?  Sure.
<bluefoxicy> write to a log file?  Hold on *application window becomes a white blob*
<bluefoxicy> oops, X wants to touch the disk
<bluefoxicy> nevermind, we're just going to go fuck ourselves now so please hit reset
<bluefoxicy> oh, and if you use magic keys, you can still umount and sync disks and not have to fsck the next boot
<bluefoxicy> so what the hell
<bluefoxicy> apparently the whole kernel isn't locking up, but the application disk scheduler is hosed
<bluefoxicy> oddly, setting elevator=as makes it less likely (on the order of every several weeks instead of every few hours or maybe 5 minutes after boot), but it STILL happens
<bluefoxicy> oh and since NO APPLICATION can write to disk, or read from disk (I can't run programs), I can't pull ANY debugging information
<bluefoxicy> AT ALL
<bluefoxicy> wtf is the next release
<bluefoxicy> maybe a shiny new kernel will have a distinct lack of fucktarded stupidity
<TheMuso> !ohmy | bluefoxicy
<ubottu> bluefoxicy: Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others.
<NCommander> sebner, vtk built on armel
<ScottK> \o/
<ScottK> That'll help with NBS.
<ScottK> EtienneG, soren, and mdz: Just accepted Eucalyptus.  It should be in the archive after the next publisher run.
<L33ckma> hi there
<L33ckma> i'm searching for ubuntu kernel 2.6.28-11-generic with debugging symbol
<L33ckma> any help?
<NCommander> L33ckma, install the kernel debug package (the name escapes me, but there should be a kernel-image-2.6.28-11-dbg or something like that)
<L33ckma> NCommander, from what repository?
<NCommander> L33ckma, main
<L33ckma> hmm
<L33ckma> NCommander, i didnt find any kernel-* similar to dbg
<L33ckma> but in ddebs I found linux-image-debug-2.6.28-15-generic_2.6.28-15.51_i386.ddeb
<L33ckma> at http://ddebs.ubuntu.com/pool/main/l/linux/
<L33ckma> which doesn't help me so much
<mdz> ScottK: thanks!
<dholbach> good morning
<dholbach> who can help me debug a not-booting system?
<dholbach> the last thing when I boot on the other machine is "ACPI: I/O resource nForce2_smbus [0x1c40-0x1c7f] conflicts with ACPI region SM01 ............. Error probing SMB2"
<dholbach> but I get the feeling that that message has nothing to do with the hang on the machine I'm seeing
<dholbach> if I boot with bin=/bin/bash the last thing I see is "bash: cannot set terminal process group (-1): Inappropriate iotcl for device" "bash: no job control in this shell"
<dholbach> this is the latest karmic with the ubuntu-boot ppa enabled
<dholbach> Keybuk: ^ any idea what I could do?
<liw> dholbach, did you already boot from a livecd and run fsck on all filesystems, and smartctl on all hard disks?
<dholbach> liw: I'll try that now :)
 * dholbach does some sponsoring in the meantime
 * TheMuso notes that the latest daily livecd reboots itself for some reason, i.e it doesn't get to the desktop, the splash starts showing activity, then things go in reverse, and it asks to press enter after ejecting the disk.
<dholbach> TheMuso: oh wow - I'll alpha5 then
<liw> TheMuso, might be #429003
<TheMuso> liw: Doesn't make sense on a live CD where the nv driver gets used.
<soren> ScottK: Ta very much.
<ttx> Good morning
<NCommander> Can anyone explain to me how the tasks are updated?
<dholbach> NCommander: what are you referring to?
<NCommander> dholbach, the tasks used by livecd-rootfs and friends; basically the set of packages you get when you do: apt-get install minimal^
<dholbach> ah ok
<TheMuso> NCommander: afaik the seeds are responsible for that, at least for tasks on disks.
<NCommander> TheMuso, I'm just figuring out how long it takes before they are updated from the seed changes
<TheMuso> NCommander: As for the archive, I don't know what happens there, probably something in launchpad.
<AnAnt_> Hello, debian made a new release of mutt that Recommend default-mta instead of exim4, which means, that it no more needs merge, but sync
<soren> ttx: Dude! Welcome back!
<ttx> soren: Dude!
<pitti> Good morning
<pitti> cody-somerville: what is a DCD file?
<ttx> soren: how is it going ?
<pitti> lool: I saw, thanks
<ttx> pitti: good morning !
<soren> ttx: Not too bad, not too bad. Good holidays?
<pitti> ogra_: sabayon> he mailed me, and said that it's in much better shape, so we'll keep it
<pitti> hey ttx
<ttx> soren: first I recovered from jetlag, then spent a few days working on the house, finally I travelled for a wedding party. Now I'm back in recovery mode :)
<cody-somerville> pitti, Distribution channel descriptor
<soren> ttx: Just in time for the Alpha6 rush. Yay.
<ttx> soren: yes, best timing ever :)
<pitti> cody-somerville: hm, and what is that?
<cody-somerville> pitti, https://wiki.ubuntu.com/FoundationsTeam/Specs/OemTrackingId
<AnAnt> so, should a sync request be filed for mutt ?
<AnAnt> or should that wait till karmic+1 ?
<pitti> cody-somerville: hm, first time I hear about that TBH; I don't have that file either, do you?
<pitti> cody-somerville: but easy enough to include into Apport
<lool> pitti: np
<cody-somerville> pitti, I think OEM team is currently the only ones with the spec implemented.
<dholbach> liw: the disk and partitions seem to be fine :-/
<pitti> cody-somerville: pushed to bzr, thanks
<dholbach> if anybody has some more ideas how I could debug my not-booting system, I'd appreciate it
<cody-somerville> pitti, I'm curious as to what prompted you to ask me about DCD files.
<pitti> cody-somerville| [19:27:10] pitti, Does apport include the
<pitti> [...]
<pitti> cody-somerville: you asked me over the weekend
<cody-somerville> odd, I don't remember doing that. lol
<pitti> cody-somerville: my IRC proxy never forgets!!11!
<pitti> StevenK: oh, I just stumbled over bug 427709;  is ubuntu-mir supposed to be subscribed there, or is the report not finished yet?
<ubottu> Launchpad bug 427709 in insserv "[MIR] insserv" [Critical,Triaged] https://launchpad.net/bugs/427709
<tseliot> doko: upgrading libc6 from 2.10.1-0ubuntu8 to 2.10.1-0ubuntu11 makes my X.org segfault with nvidia and I can't open applications if I enter the gnome-session (with the nv driver). Is it a known problem?
<liw> tseliot, might be #429003 ?
<tseliot> let me check
<tseliot> liw: aah, it was filed against elibc. Now I see why I couldn't find it
<StevenK> pitti: I thought lool was handling it, but I'm happy to subscribe ubuntu-mir
<pitti> StevenK: last time I started to review such a bug, the reporter told me that "it wasn't ready yet", so I better ask before starting to work on it :)
<StevenK> I thought I saw lool attach an MIR to it
<StevenK> Hm, no, I'm on crack.
<AnAnt> seriously ?
<pitti> no, he's just on Vegemite, which is by and large the same
<StevenK> Hmph
<AnAnt> ok, so should I file a sync request for mutt ?
<pitti> AnAnt: Debian took the default-mta change?
<AnAnt> yeah
<lool> pitti: Report is not complete
<lool> pitti: I took responsability to drive it forward and poked Keybuk on Friday hoping he would handle it but I guess he's busy with boot stuff
<doko> tseliot: gah ... not owning a nvidia card
<lool> StevenK: Happy if you pick it up though
<tseliot> doko: even when I used the open source driver I couldn't launch nautilus. Is there anything I can do to help?
<tseliot> slangasek: are these paragraphs ok for the release notes? https://wiki.ubuntu.com/X/Config/DontZap#Using GNOME https://wiki.ubuntu.com/X/Config/DontZap#Using KDE or do you want me to rewrite them?
<doko> tseliot: please could you install the packages from https://launchpad.net/~doko/+archive/toolchain and see if these work? just one more data point
<tseliot> doko: sure
<didrocks> slangasek: hey o/ Here is the MIR we talked last week: bug #428793
<ubottu> Launchpad bug 428793 in goocanvas "MIR for goocanvas" [Wishlist,Triaged] https://launchpad.net/bugs/428793
<tseliot> doko: I can't reproduce the problem with libc6 from the toolchain. Does this help?
<doko> tseliot: one more data point, let me build some test packages for you to test
<tseliot> doko: ok
<doko> tseliot: i386 or amd64?
<sebner> tseliot: ah I just wanted to ask you if the libc upgrade br0ke the nvidia driver ;D
<tseliot> doko: i386
<apw> Keybuk, if an mmc card is being detected by the kernel and udev is makeing the mmcblk0p1 devices etc, but then gnome isn't noticing it and mounting and offering it in a window ... what bit is broke... ie where should i file a bug?
<AnAnt> LP 429237
<ubottu> Launchpad bug 429237 in mutt "Sync mutt 1.5.20-3 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/429237
<zyga-work> mvo: hello
<mvo> hey zyga-work! I saw your changes :)
<mvo> zyga-work: before I can merge, you would have to sign the canonical-contribuors agreement, see http://www.canonical.com/contributors
<zyga-work> mvo: gladly
<zyga-work> mvo: I'd like to talk to you about two more things: api for search is crappy ATM, I'd like to refine it to be usable without keeping xapian around
<zyga-work> mvo: second thing: transaction API
<zyga-work> mvo: I didn't do it (I only had one night hacking time) but I plan to today
<zyga-work> mvo: I also like talk about merging, I noticed there are many branches and I fear I could diverge too much fast
<mvo> zyga-work: ok, I'm about to head for lunch, but I'm happy to talk about it aftewards :)
<zyga-work> mvo: great, please ping me then
<mvo> ok
<mvo> will do
<zyga-work> I'll setup notification (I hope it works correctly)
<mvo> :)
<soren> Err... Where did removals.txt go?
<james_w> soren: Debian's?
<soren> james_w: No, ours.
<cjwatson> replaced by Launchpad
<soren> james_w: http://people.ubuntu.com/~ubuntu-archive/removals.txt used to be the URL, no?
<james_w> LP knows why individual package was removed
<soren> Oh.
<james_w> if you want the list you have to do some work
<soren> Ngh...
<soren> Ok, thanks.
<cjwatson> bug 159585
<james_w> what are you looking for?
<ubottu> Launchpad bug 159585 in soyuz "lp-remove-package.py does not log removals to our standard place" [Medium,Fix released] https://launchpad.net/bugs/159585
<soren> james_w: Not sure. I'm trying to piece some stuff together.
<doko> tseliot: deb http://people.canonical.com/~doko/tmp/eglibc/test1 ./
<tseliot> doko: ok, let me try the new packages
<tseliot> doko: I can reproduce the problem with revision 12, therefore I had to switch back to revision 9
<doko> tseliot: ok, thanks, building another one
<tseliot> ok
<cjwatson> gah, somebody broke devscripts to always use the most recent thing in debian/changelog, which is wrong for Ubuntu
<cjwatson> just because it was last uploaded to jaunty doesn't mean that's the right thing to do now
<Laney> which part of devscripts?
<cjwatson> dch
<cjwatson> bug 429288
<ubottu> Launchpad bug 429288 in devscripts "debchange distribution default for Ubuntu broken" [Undecided,New] https://launchpad.net/bugs/429288
<asac> YokoZar: thanks for ia32libs update. you think you could check the glib patch i prepared?
<YokoZar> asac: I'll test by adding your glib to ppa then adding a hook for it into a new ia32-libs in the same ppa
<YokoZar> It'll take me a while to do the uploads though, ia32-libs doesn't like to get uploaded from my house so I need to borrow the a friend's internet
<asac> YokoZar: if you could just check that it works i would upload the fix to karmic first
<asac> so no hurry ;)
<asac> do we want a new bug?
<YokoZar> nah I'll just reopen the current one
<asac> ok cool
<asac> thx
<soren> cjwatson: I just tried installing eucalyptus-cc with dpkg (it was not previously installed). I was missing some dependencies, so I went to fix that with "apt-get -f install". It fetched all the packages, installed, and configured. I was never asked about the name of my cluster.
<soren> cjwatson: I have this in my /var/log/dpkg.log: 2009-09-14 12:48:10 configure eucalyptus-cc 1.6~bzr672-0ubuntu3 1.6~bzr672-0ubuntu3
<soren> cjwatson: That suggests that dpkg considered it an upgrade from the same version, but the check in .config checks for -z "$2".
<soren> cjwatson: I'm not sure if dpkg is wrong, your check is wrong, or if everything is intended. I'm almost sure it's not the latter.
<cjwatson> soren: are you sure that it wasn't removed-but-not-purged?
<soren> cjwatson: /me checks scrollback
<cjwatson> the check is standard form for a first-install-only operation, I think ...
<soren> cjwatson: dpkg -l euca'*' did not even list it.
<soren> cjwatson: I agree.
<cjwatson> dpkg.log should say; can I see the whole thing?
<soren> cjwatson: My entire dpkg.log? sure.
<soren> cjwatson: Will "| grep eucalyptus-cc" do?
<cjwatson> yeah
<soren> cjwatson: http://paste.ubuntu.com/270820/
<soren> cjwatson: From 2009-09-14 13:13:55 onward is me trying to reproduce it.
<soren> cjwatson: ...which I can.t
<soren> can't, even.
<soren> cjwatson: I can't reproduce it now. Very, very annoying.
<cjwatson> soren: mm. I don't see any evidence of what might have been wrong. :(
<cjwatson> but as long as it works on initial installation, it's ok, right?
<soren> Well, that's the thing. It was a fresh install (of that package). It only ended up being a two-stage thing due to a missing dependency (and my using dpkg since I had the deb right there).
<soren> But seeing as I can't reproduce it, it's pointless to try to hunt it down.
<soren> Bah. Maybe I just got confused. It /does/ happen occasionally.
<lool> cjwatson: Hey; we have an issue with the UNR seed / task: abrowser-3.5 has Task: ubuntu-netbook-remix; I downgraded the webfav Depends: abrowser-3.0 | abrowser-3.5 | firefox-3.0 | firefox-3.5 | iceweasel to a recommends a couple of publisher cycles ago
<lool> cjwatson: firefox is seeded before webfav in the unr.karmic/netbook-remix seed, and then webfav with a Recommends on abrowser*|firefox*
<lool> cjwatson: So I wondered whether there was something clean we could do or whether we should simply seed firefox-3.5 as a workaround?
<cjwatson> lool: any reason why webfav's recommends alternatives aren't ordered by desirability?
<lool> cjwatson: No reason but they are autogenerated
<lool> From xpi:Depends
<cjwatson> failing that, seeding firefox-3.5 explicitly is ok
<lool> Ok that's what I guessed as well and I dont think it's clean to change the xpi:Depends generation to have the concept of preferred package since it's used in all extensions
<lool> asac: ^ but feel free to object
<doko> tseliot: deb http://people.canonical.com/~doko/tmp/eglibc/test2 ./
<lool> cjwatson: Hmm this is in the seed used for the metapackage; we didn't have germinate workarounds in metas so far and I understand it means that firefox-3.5 will be listed in the dependencies; too bad  :-/
<cjwatson> lool: right, but unless firefox-3.5 is listed in the metapackage dependencies, I think there's some chance that apt will do the wrong thing
<cjwatson> so you do actually want that to match up
<lool> cjwatson: apt-get install ubuntu-netbook-remix worked and apt-get install ubuntu-netbook-remix^ didn't
<lool> But yeah
<lool> I agree
<lool> cjwatson: thanks for your help
<soren> How can I dynamically provide a list of Choices for a debconf template?
<soren> Ah, db_subst!
<soren> Got it.
<cjwatson> anyone happen to know offhand a quick way of detecting (unmounted) luks partitions? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546546
<ubottu> Debian bug 546546 in grub-pc "grub-pc: hangs configuring if luks partions are present" [Important,Open]
<hyperair> hmm? i wasn't aware that it hung while configuring
<hyperair> cjwatson: go through /proc/partitions and run cryptsetup luksDump on all of them
<cjwatson> apparently when os-prober tries to mount them, that produces a password prompt
<cjwatson> you might not get it if the partitions were already mounted somewhere
<hyperair> i see
<hyperair> my luks partition holds a LVM PV
<cjwatson> actually, do you happen to know what 'blkid -o value -s TYPE /dev/whatever' says for a luks partition?
<soren> cjwatson: I can check.
<cjwatson> since we're already running that
<hyperair> cjwatson: nothing.
<cjwatson> boo.
<hyperair> mmhmm
<hyperair> perhaps we should fix blkid then?
<soren> Err.. not so?
<hyperair> soren: what does it say for you?
<soren> Mine says: crypto_LUKS
<hyperair> exits with error 2
<cjwatson> mm, that is indeed what current code in util-linux would suggest
<cjwatson> libs/blkid/src/probers/luks.c
<soren> hyperair: cryptsetup luksUUID /same/path/to/the/device?
<hyperair> hmm strace says that blkid looks in /dev/.blkid.tab
<soren> Yes, it caches the info.
<soren> -p overrides the cache
<hyperair> soren: d201ccfd-6d90-4663-a426-fc14896bdd14
<soren> bypasses the cache, I mean.
<soren> What about "blkid -o value -s TYPE -p /dev/whatever"?
<soren> (i.e. add the "-p" option)
<soren> Does that make a difference?
<cjwatson> soren's output implies http://paste.ubuntu.com/270858/, which is nice and concise
<hyperair> soren: /dev/sda2: ambivalent result (probably more filesystems on the device)
<soren> hyperair: How'd you end up with that? :)
<hyperair> soren: LVM-on-LUKS
<soren> hyperair: Same here.
<hyperair> well that's strange
<soren> Oh, hang on. That's not true. Not on this box.
<soren> I have another one like that, though.
 * soren checks there.
<soren> /dev/sdb1: UUID="8c555e9d-15fc-4d0c-bc18-267fd2573fe8" TYPE="crypto_LUKS"
<soren> That's a LUKS partition that holds an LVM PV.
<hyperair> strange.
<soren> I wonder what else gets detected on yours.
<cjwatson> it may differ depending on whether the LUKS partition has been cryptsetup'ed or not?
<cjwatson> I only really care about the ones that haven't been
<soren> Keybuk: How to make blkid output all the stuff it detected?
<soren> cjwatson: This one has.
<soren> cjwatson: and vgchange -ay'ed and mounted, etc.
<soren> Keybuk: Instead of just: 12:33:19 < hyperair> soren: /dev/sda2: ambivalent result (probably more filesystems on the device)
<hyperair> this one is a root-on-LVM-on-cryptsetup
<hyperair> /dev/sda1 is /boot, ext4.
<cjwatson> I'm going to go ahead and use the crypto_LUKS check for now, I think
<hyperair> cjwatson: could you use cryptsetup luksDump?
<soren> hyperair: Mine wasn't cryptsetup'ed from initramfs.
<cjwatson> I'd rather not, there are performance concerns here
<soren> maybe that makes a difference.
<cjwatson> the quicker the check the better
<hyperair> cjwatson: is calling cryptsetup that resource hungrry?
<cjwatson> people already complain about os-prober being too slow
<hyperair> hmm
<cjwatson> and calling it on every partition ...
<hyperair> i see
<hyperair> that's a pain..
<cjwatson> admittedly it is pretty quick
<cjwatson> (cryptsetup)
<soren> Nice:
<soren> real	0m0.008s
<soren> user	0m0.000s
<soren> sys	0m0.010s
<cjwatson> maybe I could try that after the existing checks
<soren> It spent more time in the kernel than passed in real time.
<cjwatson> does luksDump reliably exit 0 for a luks partition?
<hyperair> $ sudo blkid -p -u nofilesystem /dev/sda2
<hyperair> /dev/sda2: UUID="d201ccfd-6d90-4663-a426-fc14896bdd14" VERSION="256" TYPE="crypto_LUKS" USAGE="crypto"
<hyperair> perhaps luksUUID might be faster
<cjwatson> I guess I'm OK with using luksDump/luksUUID since it does seem to be quick
<hyperair> mmhmm
<hyperair> imo it'd be faster than doing a mount
<hyperair> very much faster
<cjwatson> http://paste.ubuntu.com/270871/
<cjwatson> I'll go with that, then. Thanks!
<rgreening> pitti: any luck/progress on bug 427358? :)
<hyperair> hyperair@ipwn:~$ sudo blkid -p -u nocrypto /dev/sda2
<ubottu> Launchpad bug 427358 in python-distutils-extra "extracting strings from KDE *.ui files to the POT doesn't work, and needs intltool support" [Undecided,New] https://launchpad.net/bugs/427358
<hyperair> /dev/sda2: UUID="791218bf-ae9f-4330-bdd8-f9efce03a495" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem"
<hyperair> soren: ^^
<hyperair> soren: with nocrypto, it thinks it's ext3. why is that, i wonder? =\
<hyperair> i have no more ext3 partitions
<hyperair> only ext4
<hyperair> hmm actually come to think of it..
<soren> Ah, the plot thickens.
<hyperair> before i switched /dev/sda2 to a luks partition, it was ext3, i think.
<hyperair> is the ext3 superblock in front or behind?
<hyperair> luks's is in front, at least
<liw> ext[234] have copies of the superblock all over the filesystem
<liw> often at every 8192 blocks
<hyperair> heh
<hyperair> okay, that means it's everywhere
<liw> it's a bit! it's a byte! no, it's superblock!
<hyperair> haha
<hyperair> i guess if i pvmove things around i'd erase the old superblock =\
<hyperair> unless it's sitting around in the middle of the cryptsetup superblock
<asac> lool: yes thats ok i think
<hyperair> cjwatson: blkid -u crypto or -u nofilesystem works.
<cjwatson> I just went for cryptsetup in the end
<hyperair> heheh
<cody-somerville> pitti, speaking of apport, apport incorrectly detects the window manager and GTK theme. I'll file a bug for you.
<loic-m> My Karmic fails at boot since a few hours updates, then next boot is an fsck issue (Superblock last time is in the future - ext4 fs), rinse and repeat - what errors logs should I look at to troubleshoot the issue?
<loic-m> Is that it? > gdm-simple-slave[4684]: DEBUG(+): GdmSimpleSlave: server died with signal 11, (Erreur de segmentation)
<ogra> sounds like your hwclock is broken somehow
<ogra> *hwclock
<cjwatson> loic-m: probably bug 427822
<ubottu> Launchpad bug 427822 in linux "fsck says last write time in future" [Critical,Triaged] https://launchpad.net/bugs/427822
<pitti> rgreening: sorry, I didn't work on this yet
<pitti> cody-somerville: apport detects a theme?
<cody-somerville> pitti, bug #429357
<ubottu> Launchpad bug 429357 in apport "Apport incorrectly detects window manager and GTK theme" [Undecided,New] https://launchpad.net/bugs/429357
<cody-somerville> pitti, bug #428969 for an example
<ubottu> Bug 428969 on http://launchpad.net/bugs/428969 is private
<loic-m> cjwatson: thanks. That wouldn't explain why it fails to boot at restart after an fsck though, would it?
<cjwatson> why would it not?
<pitti> cody-somerville: could you please make bug 428969 public?
<ubottu> Bug 428969 on http://launchpad.net/bugs/428969 is private
<loic-m> because there's no fsck pb afterwards, the boot seem normal but the screen blanks just before gdm should start (and no console access either)
<cody-somerville> pitti, sure
<cjwatson> loic-m: that I don't know
<cjwatson> I imagine you have two separate bugs
<loic-m> ok, thanks
<james_w> could an archive-admin more knowledgeable than me please confirm my assessment of the spring packages that I just sent to ubuntu-archive@?
<rgreening> pitti: any chance you could take a peek today? :) I'd really appreciate it :)
<james_w> or refute it for that matter :-)
<pitti> rgreening: I wouldn't hold my breath for it; figuring out the intltool changes and getting them upstream will take a while
<pitti> rgreening: is there a tool you know of which extracts translatable strings from KDE .ui files?
<cjwatson> soren: opinions on http://paste.ubuntu.com/270894/, re bug 425922?
<ubottu> Launchpad bug 425922 in eucalyptus "Eucalyptus component registration process is manual " [Medium,Triaged] https://launchpad.net/bugs/425922
<jpds> Is compiz being removed for anyone else on Karmic? http://paste.ubuntu.com/270895/
<rgreening> pitti: using a seperate Messahe.sh and calling extract-messages.sh in the update-po of the makefile, however, how to I ensure merging of the gtk generated po and the kde one? that's where I am stuck now...
<ogra> hmm, yelp seems to have exploded on all arches
<rgreening> Messages.sh ... ^
<pitti> rgreening: msgcat doesn't work?
<rgreening> pitti: I admit I only tried quickly, but I had no success...
<jpds> mvo: Have seen this? http://paste.ubuntu.com/270895/
<Riddell> pitti, rgreening: I just committed a way of extracting the KDE strings in usb-creator
<rgreening> oh.. and merges with the gtk?
<Riddell> rgreening: yes, you were calling msgcat wrong
<rgreening> wheeee
<rgreening> :)
<cjwatson> compiz was in binary NEW until a couple of hours ago - wouldn't be something to do with that, plus an out-of-date mirror?
 * rgreening gets so confused with translations.. 
<free> hi folks, I'm looking for the LP bzr branch of the source package of "smart", it's not in lp:ubuntu/karmic/smart, maybe it hasn't been imported at all?
<cjwatson> actually, no, just looks like nobody's uploaded libcompizconfig to match yet
<cjwatson> free: in many cases there simply isn't a branch yet
<jpds> cjwatson: I'm using gb.archive personally, and it looks like the last upload was 5 hours ago.
<rgreening> Riddell: ty. have you tested also?
<cjwatson> yeah, hence my next comment :)
<free> cjwatson: I see
<Riddell> rgreening: nope
<rgreening> ha
<Riddell> rgreening: but when you're as good as me you don't need to test right? :)
<rgreening> oh my
<free> cjwatson: so the import must be somehow triggered by hand? at least at first
<cjwatson> free: I don't believe so, more likely to be either a bug in the importer or just that it's running behind - but james_w would know better
<james_w> hi free
<james_w> I'll have a look in a minute for you
<free> hey james_w
<free> james_w: thanks!
<free> james_w: (in this specific case I'd need the branches from intrepid and jaunty, for an SRU)
<dpm> hi mvo. We're having an Ubuntu Global Jam in October, and one of the activities locos will be involved in will be translation jams. I suggested some translations teams could focus on, and the DDTP were some of them. They are a good target, since I thought we could sync them to Debian once the jam is finished. I'm assuming this still works and that I could simply ask you to perform a sync when the time comes. Is that still the case? (I've just been talk
<dpm> ing about this with sianis, who's now in the channel as well)
<tseliot> pitti: any ideas as to why hal seems to ignore my fdi file? /usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi   In particular this doesn't seem to work <match key="/org/freedesktop/Hal/devices/computer:system.hardware.product" string="Inspiron 1011">
<pitti> tseliot: did you check that info.capabilities has "input.touchpad" and input.x11_driver == 'synaptics'?
<tseliot> pitti: yes, I did and it has both
<pitti> cody-somerville: followed up
<mvo> dpm: hey! ddtp sync is working, but debian asked me a while ago to not send the sync stuff back because there is a missing feature in the ddtp scripts in debian to avoid duplicated entries
<mvo> dpm: I need to inquire grisu about it, my side is ready otherwise
<tseliot> mvo: I can't get the size of the temporary file which dkms creates but you should make sure that there's enough space for /var/lib/dkms/$MODULE_NAME (whose size can range from ~3MB to ~49MB)
<tseliot> mvo: but it can be even bigger
<tseliot> pitti: is there some log I can look at to see what hal does?
<mvo> tseliot: thanks - is there no way to say that it should not clean its build-dir? (I assume it does build in /tmp? I got a bugreport about that)
<pitti> tseliot: you can start it in debug mode, see https://wiki.ubuntu.com/DebuggingHal
<tseliot> mvo: it does that in  /var/lib/dkms/$MODULE/$VERSION/build e.g. /var/lib/dkms/nvidia/185.18.36/build
<tseliot> pitti: nice, thanks
<mvo> tseliot: thanks
<tseliot> mvo: also, dkms will create a directory about the current kernel with the modules it builds (in /var/lib/dkms/$MODULE/$VERSION/$(uname -r) )
<pitti> tseliot: so, admittedly I don't have an off-hand idea why it doesn't match
<pitti> tseliot: the rule looks fine
<pitti> james_w: hm, is "are requested" a "must" or a "should"? I think a "should" would be okay
<pitti> james_w: also, the MD5 clause sounds more like a trademark restriction to me
<pitti> james_w: but I'm not sure about this at all, I'm afraid
<tseliot> pitti: ok thanks. This is weird as I'm sure it used to work (at least when I uploaded the synaptics driver)
<james_w> pitti: it's in the middle of the license, which is always a risky area. I would read it as a "should", but I'm not sure what the legal reading would be
<pitti> james_w: my feeling is that the "plz send patches" thing is okay, but I don't feel confident enough to judge the trademark issue
 * YokoZar thinks its kind of late in the dev cycle for nautilus to be crashing...
<soren> cjwatson: --register-sc doesn't look right.
<dpm> mvo: thanks for the info. Do you think you could contact grisu before the jam to clear this out? It would be quite cool we could give a lot of translations back to Debian. Or perhaps is there any way the translations team can help?
<dpm> sianis: ^
<sebner> james_w: would a source package which got renamed in Debian (still same upstream sources) and synced over to ubuntu need a FFe?
<cjwatson> soren: oh?
<mvo> dpm: I will ping him and see what is the status - he is usually very busy unfortunately
<soren> cjwatson: Sorry, my mistake.
<dpm> mvo: thanks for that
<mvo> dpm: I send him a IM now :)
<ogra> mvo, compiz-fusion-plugins-extra not building and breaking the livefs builds is on your radar i assume ?
<cjwatson> soren: can you follow up to RT#35130 with an answer to Paul's question?
<mvo> ogra: is it in depwait still?
<soren> cjwatson: /me looks
<mvo> ogra: hm, bugger - I check it out
<mvo> ogra: thanks
<ogra> http://qa.ubuntuwire.com/ftbfs/ seems not
<james_w> sebner: I don't think so, but check with the release team
<soren> cjwatson: Oh, right. I will.
<sebner> james_w: kk, thx
<mvo> pitti: could the build-score for compiz-fusion-plugins-extra be pimped please? its really in depwait for compiz-fusion-plugins-main (but it thinks its ftbfs)
 * pitti sobs at lazr.restfulclient.errors.HTTPError: HTTP Error 503: Service Unavailable
<pitti> mvo: ^ hm, I get LP errors, too, when I rescore in the web UI, sorry
<pitti> oddly enough it does work for some archies
<seb128> use non edge?
<pitti> doesn't help
<seb128> ok, no luck for mvo ;-)
<pitti> mvo: so, I rescored it on everything but i386 and amd64, those keep failing
<pitti> I mean, rescoring fails
<mvo> pitti: thanks for trying it :/ so we have to wait a bit longer I guess
<pitti> mvo: hah, it worked now (don't ask me why)
<zyga-work> mvo: about the contributor agreement, I piped the document thru samsung legal dept, I'll keep you updated but it should be accepted in a couple of days
<mvo> zyga-work: cool, thanks
<mvo> zyga-work: its a good one, I hope its uncontroversial
<ScottK> pitti: Looks to me like no new builds have been started in quite some time (~an hour at least, I'd guess)
<pitti> argh, again?
<pitti> lamont: ^ help please
<zyga-work> mvo: can we talk about the stuff I said earlier?
<mvo> zyga-work: the search api, give me a sec, I look at the diff
<zyga-work> mvo: cool, thanks
<ArneGoetje> Hey guys! What would be a good language fallback setting for en_CA? Is en_US or en_GB preferred by Canadian users?
<zyga-work> mvo: basically please give me some feedback on the changes I did
<mvo> btw, has anyone seen a autotools releated failure like this: http://launchpadlibrarian.net/31687373/buildlog_ubuntu-karmic-i386.kexec-tools_20090000-2.0.0ubuntu12_FAILEDTOBUILD.txt.gz ? that used to work with the previous auto*
<tseliot> pitti: it looks like the line about the Dell in the fdi works only if I comment out the one about the HP Mininote
<superm1> pitti, in #ubuntu-motu we were trying to figure out the root cause of why image-size got pulled from the archive on 9-11. it caused some unnecessary churn with requiring to pull in a new source package, because it got renamed in debian and there were still rdepends on it that broke.  it looks like you had requested deletion according to https://edge.launchpad.net/ubuntu/+source/image-size/3.2-1/+publishinghistory .  was this an oversight th
<superm1> at it got pulled with rdepends after the autosync phase was up, or is there possibly an error with a script?
<sistpoty|work> mvo: while I haven't seen that yet, this somewow smells like a missing quote or bracket somewhere
<free> james_w: had a chance to check for that LP bzr branch for the smart source package?
<mvo> sistpoty|work: thanks, that is a good hint, my autofoo is weak unfortunately
<zyga-work> mvo: if you can open the configure file in some editor it's easy to check, just seek to the place where it prints that stuff and check for stuff sistpoty|work mentioned
<pitti> superm1: right, seems we need to sync libimage-size-perl source from Debian?
<pitti> superm1: just an oversight
<ScottK> pitti: I did it yesterday.
<superm1> pitti, yeah, we did this over the weekend as it broke live cd builds
<mvo> zyga-work: thanks, I check, but oyur branch first :)
<ScottK> It's now more a question of doing an autopsy so it doesn't repeat.
<pitti> ScottK: thanks
<pitti> sorry for the trouble
<zyga-work> mvo: I'd really like the api to be sensible because then we can experiment with the backend and have everything else use it
<zyga-work> and besides: model got detached from the view :-)
<mvo> zyga-work: about the interface, I like it so far, I think for ISearchQuery the from_partial_term is not strictly needed, from_text sounds like it is enough for now
<mvo> zyga-work: yeah, the decoupling is a important step
<zyga-work> mvo: yeah ISearchQuery sucks right now - it's just what I created based on the GUI
<zyga-work> I think we should have something like;
<zyga-work> ISearchQuery.from_text(text, flags=[])
 * mvo nods
<mvo> yeah, flags sounds like the right solution
<zyga-work> and flags can have stuff like ISearchQuery.FLAG_APPLICATION FLAG_PACKAGE
<mvo> ++
<zyga-work> because the only use case of from_query_and_query is to create a query for applications and then a second query for the name of the application
<zyga-work> that is just low level  - I realized that on the following day (finished coding in the morning)
<zyga-work> I really like xapian but I don't feel it's good to expose full xapian API in the interface
<mvo> zyga-work: we will also need "get_applications_for_package()" in the store
<mvo> zyga-work: xapian> agreed
<zyga-work> if we ever switch to packagekit or some other infrastructure it will be a pain
<zyga-work> mvo: IApplication?
<zyga-work> mvo: right now IPackage is both - in a way
<zyga-work> mvo: IPackage.pkgname i is the package itself while IPackage.name is "application name"
<zyga-work> mvo: do we have a true list of applications in our database/
<mvo> zyga-work: yes, we know what packages provide desktop files and consider those "applications"
<mvo> zyga-work: we also have the pkges in the DB
<mvo> zyga-work: a package may contain multiple "applications" (e.g. gnome-games)
<zyga-work> mvo: what information we have about an application?
<zyga-work> mvo: do we have any unique id?
<zyga-work> I'd like to have something like org.gnome.games.somegame
<zyga-work> (even though all of them are in one package0
<mvo> zyga-work: right now they are not uniq, but they will be (today or tomorrow)
<zyga-work> tomorrow? like 24hrs?
<mvo> zyga-work: its going to be something like (appname##pkgname) for the internal id
<zyga-work> mvo: oh, good
<mvo> zyga-work: yeah, its a pretty anoying bug in the system right now
<mvo> and I marked it for alpha6 I think
<zyga-work> mvo: appname is "full name with spaces?"
<mvo> yes
<zyga-work> mvo: this could be ugly - what about translations and package renames?
<zyga-work> mvo: I realize we don't have that data for each app but I think we could encourage unique application name based on domain name or something similar
<mvo> zyga-work: its just internal to make sure its uniq, the translated name is stored as a additioanl field in the db
<zyga-work> hmm
<zyga-work> mvo: sorry I'm a bit ignorant on what is in xapian right now (or how it actually works)
<mvo> zyga-work: right, that would be great (and a prefered way). but it would requiring adding that data to all desktop files
<zyga-work> mvo: could you please give me a 3 minute intro into what we currently have and how xapian links it together?
<mvo> zyga-work: its a document database. we currently store "name from desktop file" as data. we also add "values" for pkgname, archive section, category, type, repository (e.g. archive.canonical.com), gettext-domain, ppocon
<zyga-work> is it like a big python dictionary? from string keys to "documents" (objects
<mvo> zyga-work: right now it queries using the application name (e.g. Terminal) but that is buggy because its not uniq, so I need to fix that to make it uniq
<zyga-work> and documents are again dicts?
<mvo> zyga-work: its like a list of items (documents) that you can query very fast for certain terms (like packagename, appname)
<zyga-work> so you can find a document and then get a property from that document fast, right?
<zyga-work> (or basically do that for a list of documents that match some query)
 * ojwb is reminded that a good introduction to Xapian's "data model" would be useful...
<mvo> zyga-work: yes
<zyga-work> what about "joins"?
<zyga-work> or
<zyga-work> indices
<zyga-work> let's say you want to find an app that has the translated name "Termina"
<mvo> ojwb: if you want to give that, that would be great, I'm sure I did a very clumsy job here
<zyga-work> do you just search for that property in the "database" of all "application documents" ?
 * ojwb meant a document doing that
<mvo> zyga-work: you can chain queries
<zyga-work> is it anything like coutchdb?
<mvo> ojwb: aha, ok :)
<zyga-work> couch-db
<mvo> I don't know enough about counch-db to judge
 * ojwb neither
<zyga-work> okay let's skip this - I'll read more about it
<ojwb> it's not (and doesn't strive to be) an RDBMS
<zyga-work> it's just an implementation issue now
<mvo> zyga-work: you can search for "all applications AND termina in name"
<zyga-work> I'm asking because I wanted to know if the code behind UbuntuSoftwarePackage is sensible
<zyga-work> I'll read about it later and we can fix anything
<zyga-work> real question: do we need IApplication and if so what should it contain?
<mvo> zyga-work: my gut feeling is that it would be nice to have, then it would contain a ref to ISoftwarePackage
<mvo> zyga-work: and we could ask a ISoftwarePackage for its applications
<zyga-work> right
<zyga-work> okay I'll fix that
<mvo> zyga-work: thanks
<mvo> zyga-work: unfortuantely I can only merge when I got the contributor agreement :(
<zyga-work> I see, well I hope it will be there soon
<zyga-work> in the meantime I'll be a fork :-)
<mvo> :)
<zyga-work> what about transaction API?
<zyga-work> I wanted to hide aptdaemon behind the store backend too
<zyga-work> I was thinking about registering callbacks for transaction changes
<zyga-work> and add some API for doing things
<zyga-work> so that you could get ISoftwarePackage.install()
<mvo> I think that is a good thing, so that we could more than just aptdaemon
<zyga-work> and it would give you an IPackageManagerTransaction or something smilar
<zyga-work> that would map nicely to pkgkit later
<mvo> I like that
<zyga-work> I should probably look at their api because it's probably sensible already
<mvo> it would start right away by default
<james_w> free: the branches should show up in a few minutes
<zyga-work> I was thinking about two things: downloading/installing/removing, other stuff is useless for the "store level api"
<free> james_w: nice! tnx
<zyga-work> mvo: yeah - transactions are running in their own "time"
<zyga-work> mvo: I noticed there is some code that allows you to stop a transaction but I didn't read it carefull enough
<zyga-work> can I assume that you can only stop the download phase?
<mvo> zyga-work: all we need here I think is a cancel() method to the IPackageManagerTransaction
<zyga-work> (so install/remove are atomic at transaction level)
<mvo> zyga-work: yes
<zyga-work> mvo: and UniterruptibleTransactionError
<mvo> zyga-work: cancel should fail then
<zyga-work> right
<zyga-work> ok
<mvo> mvo: aptdaemon emits a signal when a transaction stops being interruptable
<zyga-work> do you want to show separate "transactions" for getting dependencies?
<mvo> no
<zyga-work> does aptdaemon show this information in some way?
<mvo> I think that is too granular, it should be one thing "get FOO installed"
<zyga-work> show -> expose
<mvo> I don't think it exposes it to that level
 * mvo need to be away for 5min 
<mvo> (doorbell)
 * mvo is back
<zyga-work> mvo: can aptdaemon say how much stuff is going to be downloaded for installing FOO?
<mvo> zyga-work: yes, it got its own api for this, its pretty cool, it will emit signals for the current status and in what "role" its currently working
<zyga-work> so I can do aptdaemon.install("foo")
<zyga-work> and it will signal like ("downloading", some-bytes)
<zyga-work> ("installing", some-progress-level)
<zyga-work> etc?
<mvo> zyga-work: yes, that will give you a tansaction and you can connect signals to that
<mvo> zyga-work: yes
<mvo> zyga-work: (on the transaction level, not on the client level)
<zyga-work> ok
<zyga-work> I think I know enough now, I'll update the rest of the app to support apps and transactions
<zyga-work> cool
<zyga-work> this hints back at one more thing
<zyga-work> remember our discussion last time:
<zyga-work> maybe packages vs stuff you install can be cleaned up easier now
<zyga-work> packages provide stuff
<zyga-work> and stuff are (right now) IApplications
<zyga-work> later on we could do services
<mvo> right
<zyga-work> or developer libraries
<mvo> or just packages :)
<tseliot> pitti: it turns out the fdi was correct but the fdi cache wasn't updated, maybe because the mtimes were preserved (?)
<zyga-work> so a developer could use the store to get what they want
<mvo> zyga-work: for people who want to get all the details
<pitti> tseliot: oh, that again :-(
<zyga-work> well just packages is not good for apps :-)
<tseliot> pitti: is it a known problem?
<pitti> tseliot: we have a workaround in the postinst to delete it when another package ships another fdi file
<zyga-work> but then you need synaptic _again_ and that is ugly
<pitti> tseliot: I got some reports about it
<zyga-work> you have to have "normal view" that shows applicatios
<zyga-work> and "advanced" view that shows packages
<tseliot> pitti: ok
<pitti> tseliot: but nobody really is interested in fixing those small issues any more, since most things moved away from hal
<mvo> zyga-work: yeah, the end should be to be able to deal with packages if you want, but the default should be apps (and maybe services)
<zyga-work> and you _will_ have to show packages in some corner cases so the user is not shielded from package management anymore
<tseliot> pitti: apart from X :-(
<tseliot> except for X
<pitti> yeah, that's still on the list
 * mvo nods
<mvo> zyga-work: great, I think it all fits together now
<zyga-work> mvo: will the store ever show the terminal ?
<zyga-work> like what snaptic currently does to configure some mess and to show you apt output?
<mvo> zyga-work: probably not, it will deal with debconf/conffile however
<zyga-work> oh, how?
<mvo> zyga-work: aptdaemon supports terminals, but I don't think we want
<zyga-work> silent mode?
<mvo> well, most stuff is done via debconf nowdays, that a terminal is needed is a exception
 * zyga-work thinks that we should be terminal-less at all costs
<mvo> but conffile+debconf is important
<mvo> terminal-less> absolutely agreed :)
<zyga-work> mvo: what do you think about showing "delta" view by default, like most users see on typical windows system in add/remove programs
<zyga-work> the stuff I added to my system since clean install
<zyga-work> (I'm not sure about the stuff that the user removed)
<mvo> zyga-work: I think there should be such a view, not sure if it should be default
<zyga-work> does any apt infrastructure provide such data now?
<mvo> zyga-work: we will have the installer write out some info then, but I think that is perfectly doable
<zyga-work> like what was installed, when etc?
<zyga-work> installer?
<mvo> zyga-work: sort-of, but not in the level of detail/machine-readability that we need
<zyga-work> hmm
<zyga-work> pkgkit maintains its own data I guess
<zyga-work> does the 2 year plan for the store include the pkgkit transition, if it happens?
<mvo> the problem with packagekit is really that upstream is unwilling to support debconf and conffiles
<mvo> that is a pretty big problem for us, otherwise we would have selected it
<mvo> right from the start
<zyga-work> I see
<zyga-work> I remember some debian issues in general when I last inspected pkgkit
<zyga-work> but debconf is going to be switched to "silent" mode right?
<zyga-work> so the store never configures packages at install time by asking the user questions, right?
<kagou> hi
<mvo> zyga-work: yes, siwtches to noninteractive and uses --conf-old
<cjwatson> noninteractive doesn't always work
<zyga-work> well let's not think about that too much
<mvo> zyga-work: well, aptdaemon does support debconf, so for that we are fine
<zyga-work> if debian switches
<zyga-work> or ubuntu
<zyga-work> we'll reiterate
<cjwatson> in particular packages that use the standard approach for licence questions will just fail with noninteractive
<zyga-work> I think that we have an API close enough for making this possible
<mvo> and the way we do it for aptdaemon would work fine for packagekit
<mvo> but its not wanted (unfortunately)
<cjwatson> and there are plenty of upgrade cases where zapping debconf will produce a broken system
<kagou> I don't know who to contact, but since 2 days, daily-live iso have a problem. (squashf error)
<zyga-work> cjwatson: I think that the store could have support for EULAs
<zyga-work> and support installing such stuff
<cjwatson> you can't handle the upgrade cases sanely
<cjwatson> not without debconf
<zyga-work> if you ever want to be a _store_ not a _pile_ of software for free ;-)
<cjwatson> of course if the store never upgrades anything then that may not matter :)
<cjwatson> but it sort of sucks to have to reimplement the EULA code already in the packages, doesn't it?
<zyga-work> upgrades are a separate issue but I agree that debconf fills an important requirement
<zyga-work> cjwatson: already present?
<zyga-work> cjwatson: I think there is only a handful of apps that have eulas
<cjwatson> yes
<zyga-work> and the really proprietary apps could just standardize on the store API
<cjwatson> small but non-zero
<cjwatson> they need to still work with apt-get
<cjwatson> for those in multiverse or whatever
<zyga-work> cjwatson: I think that it's better to describe the EULA in some metadata
<zyga-work> and allow the apt or any other frontend to display the EULA or not
<zyga-work> so that the store just shows the same EULA in a nice way
<zyga-work> and then install the package with some --eula-accepted switch
<cjwatson> sure, but with the basic package management tools, the only sane approach is with debconf
<zyga-work> so then the store needs to have a hook for debconf, EULA mode, and expose it somehow
<zyga-work> does debconf support EULA or just random questions 'yes no' ?
<james_w> it's just a "yes no" question
<cjwatson> man debconf-devel
<zyga-work> then it sucks and doing it right is better
<cjwatson> I think we differ on our suck index
<zyga-work> to have a good gui for EULA case you need to understand that it's really an EULA, not some yes/no question
<zyga-work> I think that the store touches many technical and perhaps ideological issues with package managemenet in general
<zyga-work> and unless we want to just make a better synaptic or some other thing we need to be able to change at the low level
<zyga-work> otherwise the user experience is just going to stay the same
<cjwatson> that's fine - but if you want to be able to integrate properly with things like the installer, attention to backward compatibility as well will pay dividends
<mathiaz> james_w: hi!
<james_w> hey mathiaz
<mathiaz> james_w: I'm trying to import a new package from a new upstream tarball and ran into this error: http://paste.ubuntu.com/270995/
 * james_w thinks he knows what this will be about
<james_w> oh
<mathiaz> james_w: this is on karmic with 2.2~ubuntu2
<zyga-work> cjwatson: I fully agree with making changes in a compatible (at least upwards) and sensible way
<james_w> mathiaz: I'm sure I uploaded the fix for that :-/
<james_w> mathiaz: I'll check that it is indeed fixed, and then upload current trunk to karmic
<james_w> mathiaz: sorry for the trouble
<mathiaz> james_w: I'm running with a 2a loca repo - if that matters
<james_w> not for this
<mathiaz> james_w: np - I'll workaround it
<james_w> it's just a simple programming bug
<mvo> cjwatson: a quick question, I want to solve #387112 by providing generic patching support in u-m - because patch is not in the default install I will use "patch --ed" and run ed on from within the release-upgrade. or can you think of a better way to solve it?
<cjwatson> mvo: are you not concerned about the lack of context in ed diffs causing misapplications?
<mvo> cjwatson: the format is "_path_to_file.$md5sum" (or sha1 I guess these days). it does only apply if the hash matches
<mvo> cjwatson: the format I want to use I should say
<cjwatson> mvo: I think in this specific case sed would be usable and probably better - in general, if you're going to have to change u-m anyway is it not possible to depend on patch? or is it in the blob downloaded from the archive?
<mvo> cjwatson: its a blob downloaded from the archive, I could make it install patch before anything else, but that would be a bit ugly as well (from a UI POV)
<cjwatson> 'sed -i s/^use I18N::Langinfo;/d' or whatever seems simpler
<mvo> cjwatson: ok, I think that is fine. my initial plan was to have a generic patch facility because there is a similar problem with install-docs that we will have to deal with for the next lts upgrade
<mvo> cjwatson: but then, that can be done with sed as well :)
<pitti> cjwatson: btw, seb128 and I reviewed ~ubuntu-desktop, and cleaned it up, so that the remaining members are all trusted by us to upload packages (just in case you want to flip the uploaders soon)
<mvo> cjwatson: many thanks, I will implement it using the sed approach)
<cjwatson> pitti: thanks, I've sent mail
<cjwatson> mvo: cool
<cjwatson> superm1: mythbuntu rebuilt
<superm1> cjwatson, great thanks.
<free> james_w: bzr checkout lp:ubuntu/intrepid/smart still fails, should I just wait a bit more?
<james_w> bzrlib.errors.DuplicateKey: Key new-338 is already present in map
<james_w> so there's something funky going on here
<james_w> you may be better off going the old source package route, as I wouldn't want you to have to wait until I figure that out to get on with your work
<free> james_w: sure
<sladen> kirkland: rumour has it there's a virtualisation survey doing the rounds.  How do you get a link that can be posted to a mailing list (to many people)
<free> james_w: anyway, bzr branches for source packages are very cool to have, so I hope this gets eventually sorted
<james_w> free: I agree :-)
<free> james_w: if you wish I can open a bug for it
<james_w> it will get sorted, it's just that I have no idea what would be causing that error, it will require me to read some bzr source code
<free> alright
<kirkland> sladen: round 1 is directed toward Canonical Ubuntu engineers, as a fairly small sample set;  based on the feedback, we're going to refine the questions and send out to the rest of the community
<james_w> free: it's on a list already, so a bug isn't necessary
<james_w> thanks though
<kirkland> sladen: ie, it's not yet ready for consumption on a massive scale
<kees> soren: what, exactly was the reason for the testsuite fix in axis2c?  msg[10] isn't big enough for that strcpy...
<LaserJock> anybody know what the timezone on cdimage.ubuntu.com is?
<cjwatson> LaserJock: London, IIRC
<LaserJock> cjwatson: I don't suppose the .iso builds put the bzr branch revision they were created from anywhere do they?
<mathiaz> slangasek: hi!
<mathiaz> slangasek: could you have a look at bug 423865?
<ubottu> Launchpad bug 423865 in eucalyptus "[FFE] Image Store UI in Eucalyptus needs local proxy" [Undecided,In progress] https://launchpad.net/bugs/423865
<mathiaz> slangasek: and let me know if there is any information missing for the FFe request?
<cjwatson> LaserJock: no, sorry
<rickspencer3> hi cjwatson
<rickspencer3> I see that you are assigned to bug #424541
<ubottu> Launchpad bug 424541 in eucalyptus "When installing a node controller, a bridge device should be created" [Medium,Triaged] https://launchpad.net/bugs/424541
<rickspencer3> cjwatson, is this on your list for A6?
<LaserJock> cjwatson: np. the manifest files seem to be time-stamped ~ 2 days prior to the .isos, is there some lag on those or are the timestamps somehow wrong?
<cjwatson> LaserJock: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ start here
<cjwatson> rickspencer3: I hope so but I'm not sure yet - why do you ask?
<rickspencer3> cjwatson, because I'm supposed to be tracking this list for mdz while he is gone
<rickspencer3> cjwatson, is it just your workload, or is there something I can do to unblock it?
<cjwatson> ah
<slangasek> mathiaz: hrm, that bug doesn't tell me what the changes are that are being made, what the possible risks are of those changes
<cjwatson> just my workload, I'm juggling eucalyptus and grub2
<rickspencer3> (this list, btw: https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=eucalyptus)
<rickspencer3> cjwatson, ok
<rickspencer3> thanks for the update
<rickspencer3> :)
<cjwatson> and euca is generally a right pain to test, multiple vms etc.
<cjwatson> so tends to take a while :(
<cjwatson> I'll try to move it up a bit
<rickspencer3> cjwatson, ok
<rickspencer3> I see you have a few assigned to you
<rickspencer3> is there anything I can do to make the testing less of a pita?
<cjwatson> that's more a reflection of the fact that I need to do some clearout of my assigned list
<rickspencer3> :)
<LaserJock> cjwatson: so is http://people.canonical.com/~ubuntu-archive/livefs-build-logs/karmic/edubuntu/latest/livecd-20090914-i386.out a bad sign?
<cjwatson> LaserJock: yes, but I understand that was fixed by a bash upload
<cjwatson> rickspencer3: thanks for the offer, but probably not really
<mathiaz> niemeyer: 12:56 < slangasek> mathiaz: hrm, that bug doesn't tell me what the changes are that are being made, what the possible risks are of those changes
<niemeyer> slangasek: This is a new feature being introduced to add support in Eucalyptus to download and register images automatically through the Eucalyptus admin interface itself
<cjwatson> LaserJock: I expect the next rebuild will clear that particular one up, but I'm holding off on rebuilds at the moment as compiz has been busted today
<cjwatson> LaserJock: live filesystem builds tend to be pretty sensitive to breakage unfortunately
<niemeyer> slangasek: A bad scenario for this feature is to not work at all, but this won't mean that other parts of the system would stop working
<slangasek> niemeyer: well, which parts are new?  The bug description talks a lot about "system requirements", but I'm pretty sure most of these are already present by default?
<niemeyer> slangasek: So the risk is self-contained, IMO
<niemeyer> slangasek: Right.. the only new part is the image-store-proxy itself
<slangasek> niemeyer: and that's going to be shipping where?  in the server images?
<niemeyer> slangasek: Right, next to Eucalyptus
<niemeyer> slangasek: For the Image Store UI that is now in Eucalyptus to work at all, this proxy is needed
<niemeyer> slangasek: So there should be a mutual dependency between them
<mathiaz> niemeyer: does image-store-proxy daemonize correclty?
<mathiaz> niemeyer: or is it just meant to run in the foreground?
<niemeyer> mathiaz: Hmm, at the moment I believe it can only be run in foreground by itself
<mathiaz> niemeyer: ok
<niemeyer> mathiaz: Does it need to do daemonization by itself, or can you handle this in the initscript for now?
<mathiaz> niemeyer: I'm looking into handling it via the initscript
<niemeyer> mathiaz: Awesome, thanks!
<slangasek> niemeyer: which twisted modules are used, specifically?
<slangasek> mathiaz: use an upstart job instead, then you don't have to worry about handling it? :)
<mathiaz> slangasek: hm - oh - good idea
<mathiaz> slangasek: are there any examples I could look at?
<niemeyer> slangasek: twisted.web, twisted.internet.defer, twisted.internet.threads, twisted.python.failure,  twisted.internet.address, twisted.trial.unittest
<niemeyer> I believe that's it
<slangasek> ok
<slangasek> mathiaz: whatever's in the ubuntu-boot PPA, I think :)
<Matt_91> HI every one
<Matt_91> I'm Italian and my Italian is very bad.
<Matt_91>  when the file system for ubuntu (only the partition where the OS is installed) is full, instead of coming out a message
<Matt_91>  ! attention to the file system is full!
<Matt_91> (says nothing and there is tremendous slowdown, problems some programs are crap and you lose initilmente time (me) to know what the hell's got into Ubuntu, then go and find out that my sister had put a folder on film Desktop and filled the partition, I do not know if it makes the idea, but the user does not know that the devil takes to his computer, but if you make him appear a notification message, then the user knows what he and his computer solv
<ubottu> Error: I am only a bot, please don't think I'm intelligent :)
<Matt_91> Sorry I made a mistake, I rewrite
<Matt_91>  when the file system for ubuntu (only the partition where the OS is installed) is full, instead of coming out a message
<Matt_91>  ! attention to the file system is full!
<Matt_91> (says nothing and there is tremendous slowdown, problems some programs are crap and you lose time in vain (I) to find out what the hell's got into Ubuntu, then go and find out that my sister had put a folder on film Desktop and filled the partition, I do not know if it makes the idea, but the user does not know that the devil takes to his computer, but if you make him appear a notification message, then the user knows what he and his computer solve
<directhex> there should be a notify-osd message
<directhex> i thought there was anyway
<LaserJock> cjwatson: if the livefs build fails does the .iso build just use the latest one? I'm wondering why I have a DVD for the 14th when the livefs build failed.
<ScottK> KDE has a warning.  I get pinged at 200mb left
<Matt_91> no, ubuntu don't coming out a message
<Matt_91> and I don't undestand te cause of my problems
<Matt_91> directhex: ^^
<Matt_91> I use GNOME
<zyga> mv
<zyga> ls
<NCommander> slangasek, james_w did either of you just do NBS recently? My rootfs's just stopped being able to be built within the last hour or so with the kernel headers going poof
<slangasek> not I
<pitti> not me
<slangasek> and such packages generally only get NBSed when they have no more reverse-deps?
<Matt_91> My question was this: is possible insert a warning system (Windows is it) that when the user fills in the file system warns ubuntu?
<NCommander> slangasek, right, sorry, stupid quesiton, but I can't see a package disappearing from the archive randomyl except via NBS :-/. Currently debugging
<NCommander> thanks
<slangasek> you didn't mention a package name?
<Matt_91> ciao->hello!!
<NCommander> slangasek, linux-mvl-dove-headers-2.6.31-204
<slangasek> NCommander: hum, ok
<NCommander> slangasek, the kernel is depending on that is a bug in its own right, but it doesn't explain why my rootfs's suddenly went poof
<kees> Keybuk: what tool can I use to ready labels and uuids from filesystems now that vol_id has vanished?
<ion> Warez at launchpad.net :-) https://bugs.edge.launchpad.net/ubuntu/+source/picard/+bug/357279
<ubottu> Launchpad bug 357279 in picard "picard crashed with SIGSEGV in avcodec_decode_audio2()" [Undecided,Confirmed]
<slangasek> kees: 'blkid'
<kees> slangasek: ah-ha!
<Keybuk> kees: blkid ;)
<Keybuk> kees: btw, I have absolutely no idea what you did, but your udev update never hit the archive
<kees> Keybuk: I was noticing that this morning as my karmic VMs hung again.
<kees> Keybuk: anyway, since you didn't want it uploaded anyway, I guess that's good.  Shall I revert the bzr tree or re-upload?
<ion> kees: Would you say your VMs are well hung?
<kees> ion: more with every ssh connection
<Keybuk> kees: I'll handle the bzr tree, it'll get smashed when I git update anyway
<kees> okay cool
<Keybuk> we need some testing before doing a udev 147, so I'll release current git head to the ubuntu-boot PPA
 * robbiew straps in for Keybuk's ude release
<robbiew> :P
<robbiew> s/ude/udev
<sebner> NCommander: still around?
<NCommander> sebner, yes
<sebner> NCommander: what about vtk? the armel fix seems to work. Are you capable of fixing the other FTBFS or shall we upload to the archive?
<NCommander> sebner, just upload, I won't be able to look at it for quite awhile
<sebner> NCommander: kk, thx
<kees> ogra: do you have any more details about the chroot issue?  or a machine I can see it happening on?  I couldn't reproduce it.
<ogra> kees, you need an i386 machine, use qemu-arm-static to build an armel chroot, chroot into that and install a mono package
<ogra> mono fires off its assembly installer from postinst of any -cil package
<ogra> and usually hangs then with no return
<kees> ogra: is it specific to the armel chroot?
<ogra> yes, its specific to stacked binfmt execution
<kees> "stacked"?
<ogra> i have an armel chroot in which every binary is executed through binfmt with qemu-arm-static
<kees> ogra: is there documentation on setting up the armel chroot?
<ogra> if i execute a mono package in this chroot it executes the i386 mono
<ogra> i added it to the bug this morning
<ogra> install qemu-arm-static, run build-arm-chroot (its a wrapper to debootstrap and takes identical args)
<ogra> then just chroot into the chroot you built
<jono> hey
<jono> I just dist-upgraded and I have no panels, no window manager
<jono> anyone else getting this?
<smoser> given a package name and consistent apt-cache data how can i figure out what packages came from universe, multiverse, or main
<smoser> i want to do a "for package in installed_packages() { print "$package:${where-it-came-from}\n"; }
<pochu> smoser: apt-cache show $package | grep ^Section
<jono> seb128, I am not getting any panels after a recent upgrade in karmic, is this known?
<jono> and I see compiz is held back
<slytherin> Can anyone help me debug this problem. Commercial DVD (CSS protected) is not getting mounted at all on karmic. This is dmesg output - http://paste.ubuntu.com/271106/
<kirkland> cjwatson: https://bugs.edge.launchpad.net/ubuntu/+source/qemu-kvm/+bug/429443 again ...
<ubottu> Launchpad bug 429443 in qemu-kvm "/usr/bin/kvm-ok should be disassociated from kvm" [Wishlist,Confirmed]
<kirkland> cjwatson: what do you think about /usr/bin/kvm-ok -> util-linux ?
<kirkland> cjwatson: Daviey suggested util-linux, i took a quick look, and it seems reasonable to me
<kirkland> cjwatson: i thought you might weigh in;  if you're at least +0, I'll upload a fix from Daviey
<Daviey> \o/
<Amaranth> waiting for a build on ia64 wouldn't stop publishing a new version of a package, would it?
<Amaranth> since ia64 isn't supported or whatever
<slytherin> Amaranth: publish on other architectures?
<Amaranth> slytherin: right, compiz is uninstallable because compiz-fusion-plugins-main update is missing
<Amaranth> but it built like 6 hours ago on everything except ia64
<slytherin> Amaranth: Then probably the archive mirror you are using has not yet updated.
<Amaranth> slytherin: Well the guy having problems is using archive.ubuntu.com
<Amaranth> I was using our PPA so it doesn't bother me that my mirror is outdated
<Amaranth> hmm, lauchpad says it was published though
<slytherin> Amaranth: Then probably it is problem with packages.
<jono> how on earth do I make a bug that I reported as private (apport crash) public?
<Amaranth> so he must be mistaken and is using a mirror
<Amaranth> slytherin: nope, it built fine and didn't have to go through binary NEW or anything
<Amaranth> guy is just using a mirror and doesn't know it or hasn't updated his Packages recently
<Amaranth> jono: I can do it for you if you give me the number
<Laney> jono: there's a box somewhere on the right
<slytherin> Amaranth: If he is using us.archive.ubuntu.com then that mirror is known to cause problem from time to time.
<Laney> "this bug is private" or so
<Amaranth> jono: otherwise there should be a little yellow symbol next to where it says it is private
<jono> Amaranth, odd I dont see the symbol
<jono> Amaranth, https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/429566
<ubottu> Error: This bug is private
<Amaranth> oh man, compiz bug
 * Amaranth leaves it private :P
<Amaranth> huh, won't let me see it at all
<Amaranth> that would me it's marked as a security issue, not a regular private bug
<seb128> jono, not a known issue and should not be due to compiz
<Laney> because the crash bug triagers aren't subscribed yet
<Amaranth> s/me/mean/
<Laney> i bet
<Amaranth> or that
<seb128> jono, is the guest session working? or do you get the panel if using alt-f1 or clicking?
<jono> seb128, if I kill the panel process it reloads
<kees> wow, I can't see that bug either
<jono> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/429570
<ubottu> Launchpad bug 429570 in gnome-panel "GNOME panel not starting" [Undecided,New]
<seb128> jono, it's not a gnome-panel issue for pretty sure
<jono> seb128, could it be because of the panel background I am using?
<seb128> jono, can you click on those? if you start a non GNOME session from gdm can you run gnome-panel manually?
<jono> there were bugs with panel backgrounds, right?
<seb128> nothing recent
<seb128> gnome-panel didn't change for a week
<jono> odd
<jono> the only other session I have in gdm is xterm I believe
<jono> seb128, I emailed kenvandine my .xsession-errors too if that helps
<Amaranth> jono: you should be able to start gnome-panel from the xterm session, see if it is working
<jono> I cant check right now, have to head to a call
<jono> will test in a bit
 * Amaranth has a feeling compiz is involved somewhere, cries a little
<Amaranth> don't we still have the failsafe GNOME session?
<seb128> jono, try dist-upgrading again current compiz updates should be there
<seb128> Amaranth, there is no such entry in the new gdm in karmic
<jono> seb128, I am not sure if they are on my mirror yet
<seb128> use the main archive rather than a mirror and upgrade? ;-)
<Amaranth> seb128: hrm, that's bad
<Amaranth> failsafe GNOME would start without compiz, was a great way to see if compiz was at fault
<seb128> Amaranth, not sure the failsafe session is really useful but patches are welcome
<Amaranth> seb128: the only thing it did was start without compiz because compiz-wrapper checks for the failsafe ENV variable and falls back to metacity
<GobiTheGoblin> Hi all! =) I kinda messed my 9.10 netbook-remix totally. Metacity wont start, I have to run progs, with alt-f2. Is this place to ask help how I can fix this?
<GobiTheGoblin> Problem is my my estimate the nvidia drivers, which I installed, and after latest updates it didn't work no more
<GobiTheGoblin> problem is in*
<GobiTheGoblin> no one?
<GobiTheGoblin> well... it was kinda a long shot
<GobiTheGoblin> bb
<soren> kees: I /removed/ that msg[10].
<soren> kees: I have no clue what it was doing there. It's part of the upstream test suite.
<soren> kees: Yes, they added a msg[10], copy a static string into it (which is IIRC 13 characters long) with strcpy and don't check anything about it. It's got "WTF" written all over it.
<kees> soren: no, it seems that it got into the diff.gz (and then got patched out).  take a look at the diff.gz.  :P
<soren> ?!?
<soren> kees: It was there to begin with from upstream.
<soren> I certainly didn't add it :)
<kees> soren: http://launchpadlibrarian.net/31785577/axis2c_1.6.0-0ubuntu4_1.6.0-0ubuntu5.diff.gz
<kees> that diff shows it being added?
 * kees goes to download
<soren> kees: Ah, that's apparantly just me messing around with quilt.
<soren> kees: The first I heard about this was lool trying to enable the test suite, which then failed at that line.
<kees> soren: Ah!  I see now
<kees> soren: the diff.gz contains:
<soren> kees: Sorry about the confusion.
<kees> --- axis2c-1.6.0.orig/util/test/util/test_util.c
<kees> +++ axis2c-1.6.0/util/test/util/test_util.c
<kees> -    char msg[10];
<kees> so, it still needs to be cleaned up?
<kees> oh, no, I unpacked ubuntu4
<kees> wheee
<soren> kees: I was under the impression that ttx fixed it all today?
<kees> soren: all is well, it seems I radically confused myself by only looking at the diff between ubuntu4 and ubuntu5
<soren> Heh :)
<soren> It really is a puzzling little artifact, that msg[10].
<kees> soren: yeah, that's _really_ weird.  should ask upstream about that.  Likely just a debugging hiccup that fortify caught
<soren> "Oh, let's add this completely unrelated and useless thing so that our test suite will fail horribly."
<smoser> slangasek, so if everything is working under xen, should 'ldd' in bash indicate a usage of stuff in /lib/tls/i686/nosegneg
<slangasek> smoser: yes
<smoser> regarding bug 427288. i'm not seeing that.
<slangasek> smoser: and you should not get the dmesg noise
<ubottu> Launchpad bug 427288 in eglibc "Karmic i386 EC2 kernel emulating unsupported memory accesses" [High,Fix released] https://launchpad.net/bugs/427288
<smoser> i do not get dmesg noise
<slangasek> smoser: you have libc6-xen and libc6-i686 installed?
<slangasek> smoser: at what versions?
<smoser> http://paste.ubuntu.com/271157/
<smoser> slangasek,
<slangasek> smoser: cat /etc/ld.so.conf.d/xen.conf?
<slangasek> smoser: also, ldconfig -p | grep nosegneg?
<slangasek> smoser: finally, ls -l /etc/ld.so.nohwcap
<smoser> /etc/ld.so.conf.d/xen.conf has
<smoser> hwcap 1 nosegneg
<smoser> ' ldconfig -p | grep nosegneg' output is empty
<smoser> $ ls -l /etc/ld.so.nohwcap
<smoser> -rw-r--r-- 1 root root 0 2009-09-14 18:39 /etc/ld.so.nohwcap
<smoser> (zero length file)
<slangasek> hmm
<cjwatson> kirkland: I guess that's ok ... I'd recommend trying to get it upstream though
<slangasek> smoser: so, that file is disabling all hwcap extensions; it's added during package upgrade, and supposed to be removed once all the libc6-* variants are back at the same version
<slangasek> smoser: do you have any other libc6-* packages that are *not* in state 'ii'?
<smoser> dpkg -l 'libc6-*' shows only those 2
<slangasek> smoser: gar, buggy maintainer scripts, missing substitution in libc6-xen.postinst
<slangasek> (it says "CURRENT_VER", where it's supposed to actually give the version :P)
<smoser> whoops.
<slangasek> smoser: please sudo rm /etc/ld.so.nohwcap and double-check both ec2 and uec
<slangasek> I'll work on fixing the package
<kirkland> cjwatson: understood, and I agree
<kirkland> Daviey: okay, util-linux sounds reasonable; please forward you changes upstream as well
<smoser> slangasek, removed the file, then immediate 'ldd /bin/bash' shows
<smoser> libc.so.6 => /lib/tls/i686/cmov/libc.so.6
<Daviey> kirkland: wilco
<slangasek> smoser: that's ec2 or uec?
<smoser> ec2
<smoser> i dont have a uec up at the moment, (and will likely just test this under kvm -- which is what uec is)
<slangasek> smoser: ok; please do a sudo ldconfig as well
<smoser> that fixed it
<slangasek> (that's the sequence things are supposed to happen in the postinst; rm -f /etc/ld.so.nohwcap, then ldconfig)
<slangasek> ok
<slangasek> then once we fix the maintainer script, we should be golden
<smoser> updated bug
<slangasek> smoser: different bug, technically; this was fixed, then eglibc got merged from Debian and regressed :P
<smoser> so you want a new bug opened ? i'm fine with whatever.
<slangasek> "technically"
<smoser> so do you technically want a new bug or do you want a new bug
<slangasek> I may be venting rather than talking about anything that matters
<smoser> i really dont care. i'll flip that back to fix-released and open a new bug, or leave it as 'in-progress' . slangasek its your call.
<smoser> (since you're the one doing the work)
<slangasek> smoser: well, it's not worth /your/ time to open a new bug if the other bug's already been reopened
<smoser> then we leave it.
<cjwatson> bug 424541 - does the address of the node's bridge interface need to be unique across the cluster, or is it not visible outside that one machine?
<ubottu> Launchpad bug 424541 in eucalyptus "When installing a node controller, a bridge device should be created" [Medium,Triaged] https://launchpad.net/bugs/424541
<nxvl> lamont: hi!
<nxvl> lamont: xdelta is unstalable in karmic
<nxvl> lamont: it's depending on libglib1.2ldbl, which isn't in the archive anymore
<mathiaz> bdmurray: hi
<mathiaz> bdmurray: I've written some more scripts based on the multi-package-fixed-bug script you gave me at the sprint
<mathiaz> bdmurray: and I'd like to run these on a regular basis (ie cron job)
<mathiaz> bdmurray: what would it take to have these scripts run on qa.ubuntu.com?
<mathiaz> bdmurray: (or the server when other launchpadlib scripts are run)?
<nxvl> slangasek: did you know what is the reemplacement for glib1.2?
<bdmurray> mathiaz: do you see them changing much or at all?  If not I could set them up / run them for you there.
<slangasek> nxvl: ... glib2.0?
<mathiaz> bdmurray: I don't expect a lot of change in the long term
<nxvl> slangasek: but it has no ldbl  binary
<mathiaz> bdmurray: may be a few details to be updated while we're testing their lists in the few weeks
<mathiaz> bdmurray: in the coming weeks
<slangasek> nxvl: what problem are you trying to solve?
<cjwatson> nxvl: forget ldbl
<slangasek> nxvl: glib1.2 is obsolete, and anything that depends on it needs to be ported to a modern library or dropped
<cjwatson> ldbl was an ABI breakage in libglib1.2 that needed a new package name as a result - it isn't relevant to glib2.0
<nxvl> slangasek: Bug #429619
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=490257
<ubottu> Launchpad bug 429619 in xdelta "xdelta uninstalable in karmic" [Undecided,New] https://launchpad.net/bugs/429619
<ubottu> Debian bug 490257 in unknown "xdelta: Switch from glib1.2 to glib2.0" [Wishlist,Closed]
<cjwatson> so it probably just needs bug 429493 to be actioned
<ubottu> Launchpad bug 429493 in xdelta "Sync xdelta 1.1.3-9 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/429493
<cjwatson> which I'll take care of now
 * nxvl HUGS cjwatson 
<slangasek> Keybuk: er, you're missing the point
<slangasek> Keybuk: the LSB headers *document* what the dependencies are - I'm asking whether these dependencies are still being *satisfied* in UpstartLand
<Keybuk> slangasek: in the sense that those services, if converted to Upstart, are already started before rc2 is run, yes
<slangasek> ok, that was the question
<slangasek> thanks for confirming :)
<Keybuk> Upstart runs the sysv-rc stuff as a "I'm done, what about you" kinda thing
<slangasek> ok
<slangasek> I thought that was the plan, but didn't want to make any assumptions
<slangasek> Keybuk: uploading, then? :)
<bdmurray> mathiaz: okay, I think I could do that for you
<Keybuk> slangasek: have a couple of bits to fix, another test run
<Keybuk> then yes
<slangasek> ok
<Keybuk> certainly will be uploading this evening
<mathiaz> bdmurray: great - I'll clean my scripts and push it lp
<mathiaz> bdmurray: I'll let you know when I have a branch ready
<slangasek> Keybuk: so cryptsetup itself doesn't seem to be on your list for the freeze exception; are you planning an upload there for alpha 6, or should I pick that up if I want my own boot to not regress? :)
<Keybuk> slangasek: it shouldn't regress
<Keybuk> you should still get a prompt, just not via usplash
<slangasek> ugly == regression
<slangasek> :-)
<Keybuk> no ugly != regression
<slangasek> right, so I should upload
<Keybuk> if you like
<Keybuk> you need to ship a file in /etc/initramfs/conf.d with USPLASH=y in it
<slangasek> yep
<Keybuk> I can add it to the FFe for tracking purposes
 * slangasek makes noncommittal hand-wavy gestures
<Keybuk> also on the "cryptsetup implies usplash" issue ...
<Keybuk> cryptsetup implies a slow boot as everything gets decrypted too
<Keybuk> so you probably want it anyway <g>
<slangasek> heh
<Keybuk> (the missing bit for auto-starting usplash btw is that I want it to show up with "status usplash"
<Keybuk>  and that requires a bit of a hack :p)
<mathiaz> bdmurray: https://code.launchpad.net/~mathiaz/+junk/multi-package-bugs-fixed/
<mathiaz> bdmurray: these are the scripts
<ion> keybuk: Did i get this right, you want Upstart to start usplash on âstatus usplashâ?
<Keybuk> ion: no, report its pid with status usplash
<Keybuk> ie. think it's running with the pid that was started from the initramfs
<Keybuk> so "stop usplash" will work
<Keybuk> and, more importantly
<ion> Ok
<mathiaz> bdmurray: I'll send you an email outlining which scripts should be run and how often
<Keybuk> "stop on starting (gdm or kdm)" in the usplash.conf file will work :p
<kirkland> pitti: ping
<kirkland> pitti: i've been pulled in different directions
<slangasek> the kirkland taffy pull
<kirkland> slangasek: heh :-)
<slangasek> smoser: and is libc6-xen being installed by default now in the UEC builds?
<pdf> Hello, can someone tell me if the last ubuntu dist-upgrade break something    ?
<Keybuk> pdf: how about you tell us that the last ubuntu dist-upgrade you did broke something? :)
<pdf> the last one was nice
<pdf> just noticed that it removes compiz
<james_w> well don't do that then
<james_w> you caught it at a bad time, and the point of dist-upgrade is that you are supposed to check what will be removed
<dan4dm> hi folks, i have a question about how i can fix a farm build on launchpad. is this the right channel?
<slangasek> doko: you know that core-dev isn't a member of ubuntu-toolchain?
<mathiaz> kirkland: hey - I've got a new package ready for your review: http://people.canonical.com/~mathiaz/packages/
<doko> slangasek: should it be?
<doko> we don't have a ubuntu-foundations ...
<slangasek> doko: you complained about people not committing their changes to bzr :)
<slangasek> core-dev has access to upload the package - core-dev should have access to commit
<doko> hmm, I added you, I don't like the idea of whole core-dev ...
<Keybuk> doko: why not?
<Keybuk> they can upload
<Keybuk> if you'd like to change the permissions of who can upload the toolchain, you'd need to talk to the Ubuntu Technical Board
<Keybuk> kirkland: do you plan to send kvm-ok to util-linux upstream?
<kirkland> Keybuk: yes, absolutely
<Keybuk> ok, shiny
<Keybuk> if you need any help, I'm happy to review for you etc.
<doko> Keybuk: yes, but let's delay that for the next uds
<Keybuk> actually, now would be better, since the discussion about the formation of package sets is ongoing *right now*
<doko> Keybuk: pointer?
<Keybuk> doko: tech board meeting minutes
<doko> let's see if I find some time ...
<Keybuk> doko: in the meantime, you should do ask slangasek suggests and add ubuntu-core-dev to your bzr tree
<Keybuk> otherwise you're just making work for yourself, since you'll have to check the archive for any upload, and merge them in, and commit every time you want to commit to bzr
<doko> Keybuk: I disagree, non-membership doesn't hinder anybody to check pending changes and upload these
<slangasek> well, no; in this case what hindered that was that it was a blatant violation of the feature freeze
<Keybuk> doko: why should they bother to help you if you're not bothering to help them
<doko> no, I don't consider a package split a violation of feature freeze
<kirkland> Keybuk: what we really need is a sanity check on the replaces/conflicts
<Keybuk> kirkland: first get the tool upstream
<Keybuk> then we'll consider the packaging
<kirkland> Keybuk: ah
<Caesar> Sanity check: you have to restart udev when you add or change the rules, don't you?
<Keybuk> Caesar: no
<slangasek> doko: then you should reconsider, because it is, and *you introduced a regression* when you did it
<slangasek> see latest bzr commit
<robbiew> doko: The Release Team makes the call of whether or not something violated FeatureFreeze
<kirkland> Keybuk: hmm, okay, so is this conceivable to get upstreamed, and into karmic?
<Caesar> Keybuk: it just automagically deals with the rule change?
<kirkland> Daviey: note Keybuk's comments; he wants to see it upstreamed first
<Keybuk> kirkland: it's one of the set of packages that we (along with other distros) promise not to ship patches or extras for that are not upstreamed
<Keybuk> Caesar: yes
<Caesar> Keybuk: thanks
<robbiew> doko: which is why they process the FFEs
<kirkland> Keybuk: fair enough, good to know ;-)
<Daviey> Keybuk / kirkland: noted
<doko> robbiew: in this case every change has to be approved by the release team, unless there are clear guidelines. and I still don't see that a package split is a violation of feature freeze
<Daviey> Keybuk: are you aware util-linux currenty FTBFS on karmic?
<Keybuk> Daviey: it built for me
<robbiew> doko: "At this point we stop introducing new features, *packages*, and APIs, and concentrate on fixing bugs in the development release. "
<Keybuk> it looks like it's built in the archive too
<Daviey> Keybuk: try it now.. i've tried the archive version in both LP ppa and cowbuilder
<Keybuk> Daviey: why don't you tell me how it failed instead?
<robbiew> so with this split...did we get a new package? or just update an existing one?
<Daviey> Keybuk: that isn't the arcive versio.. but shows the same error
<Daviey> http://launchpadlibrarian.net/31797090/buildlog_ubuntu-karmic-amd64.util-linux_2.16-1ubuntu2_FAILEDTOBUILD.txt.gz
<Keybuk> Daviey: that's a glibc bug
<Daviey> Keybuk: i reverted a patch, and it works
<slangasek> robbiew: it's a new binary package, a split that only benefits multiarch... which we're obviously not doing for karmic
<Daviey> Keybuk: wait for glibc to fix, or suggest a patch?
<Keybuk> Daviey: glibc changed the API of a bunch of functions "to match POSIX", breaking a large number of things
<Keybuk> Daviey: afaik, glibc refuse to accept that it's a bug
<Daviey> Keybuk: nice!
<robbiew> slangasek: okay...so by definitiion (https://wiki.ubuntu.com/FeatureFreeze)...the upload broke the freeze
<robbiew> right?
<slangasek> yes
 * ScottK grumbles about Eucalyptus.
<Daviey> Keybuk: reverting debian carried patch in mount/lomount.c #ifndef HAVE_VERSIONSORT solves it.. but perhaps fixing the def HAVE_VERSIONSORT would be cleaner.
<slangasek> the upload also merged in a variety of /other/ things that don't pass for bugfixes
<Keybuk> Daviey: you're barking up the wrong tree
<soren> ScottK-desktop: What's up?
<Daviey> *woof*
<soren> ScottK: What's up?
<ScottK> soren: There was grumbling about late splitting of packages.  I thought I'd toss it on the pile.
<ScottK> Not a big deal.  I gather it worked out.
 * soren reads a bit of scrollback for context
<Daviey> Keybuk: got a suggestion for a tree i should raise my leg on.. or would you prefer i left it with you?
<soren> ScottK: Ah. Hm. Yes, I suppose an FFe would have been in order.
<Keybuk> Daviey: I'm not going to do anything about it
<Keybuk> it's a glibc bug
<doko> robbiew, slangasek: well, ok, I wasn't ware of the "packages"
<Daviey> Keybuk: if i get this kvm-ok into Debian, won't that leave us in a bad position - or do you suspect glibc will get a grip before then?
<Keybuk> Daviey: what's Debian got to do with it?
<Keybuk> I said *UPSTREAM*
<Daviey> oh, sorry..
<Keybuk> util-linux-ng@vger.kernel.org FWIW
<Daviey> Keybuk: thanks
<doko> slangasek: do you refer to 429003 by mentioning the regression?
<slangasek> doko: no, not that one; there was a regression directly related to the libc-bin package split, which I just found by reviewing diffs
<slangasek> doko: libc-bin holds the trigger, but the postinst handling was still in the libc6 package
<doko> ack
<slangasek> so ldconfig would never be triggered
<dtchen> i was just going to mention that!
<ccheney> shtylman: ping
<ccheney> has the location for the next UDS been determined yet?
<soren> No.
<soren> I know I really should have figured this out by now, but when does the soft freeze for A6 kick in?
<slangasek> soren: 0000UTC tonight
<pwnguin> need a calendar for evolution for this ;)
<ccheney> so in 1:40
<soren> slangasek: ah.
<soren> slangasek: Ok. Well, as long as any uploads I do from then until Thursday is bringing us closer to a good alpha, I'm in the clear, right?
<soren> slangasek: Also, should I change the status of bug 425914 to catch the release team's attention, or is it only "In progress" that you guys ignore?
<ubottu> Launchpad bug 425914 in eucalyptus "[FFe] CC and NC networking mode is set to 'SYSTEM' by default" [Medium,Triaged] https://launchpad.net/bugs/425914
<slangasek> soren: the definition of "bring us closer to a good alpha" is "fix milestoned bugs, uninstallables, or out-of-date packages and not disrupt the CD builds" :)
<soren> slangasek: I can work with that :)
<soren> slangasek: Do you think there's any hope I can get that FFe approved within the next 10-15 minutes? Otherwise, I'll go pass out.
<slangasek> soren: sorry, what FFe?
<soren> 22:23:51 < soren> slangasek: Also, should I change the status of bug 425914 to catch the release team's attention, or is it only "In  progress" that you guys ignore?
<ubottu> Launchpad bug 425914 in eucalyptus "[FFe] CC and NC networking mode is set to 'SYSTEM' by default" [Medium,Triaged] https://launchpad.net/bugs/425914
<soren> That one :)
<soren> Sorry, I
<soren> m really not being very clear today.
 * soren is feeling a bit under the weather.
<slangasek> soren: heh - yes, I ignore anything "confirmed" or above
<soren> slangasek: /me sets it "new"
<soren> There.
<soren> slangasek: So.. Do you think there's any hope I can get that FFe approved within the next 10-15 minutes? :)
 * soren guesses not and goes to pass out
<slangasek> soren: oof, sorry
<slangasek> soren: if you're still around: what are the risks of this change?
<cjwatson> the alphasort thing is a POSIX regression, sadly, not a glibc regression. http://austingroupbugs.net/view.php?id=142
<cjwatson> I suspect they're caught between rock and hard place because this appears to be a BSD vs. SysV thing
<cjwatson> or at any rate Solaris is on the side of the coin we're currently on
#ubuntu-devel 2009-09-15
<shtylman> ccheney: pong
<mathiaz> slangasek: I've upload image-store-proxy (bug https://bugs.launchpad.net/ubuntu/+source/eucalyptus/+bug/423865) to karmic
<ubottu> Launchpad bug 423865 in eucalyptus "[FFE] Image Store UI in Eucalyptus needs local proxy" [High,In progress]
<mathiaz> slangasek: it's waiting in the NEW queue for AA review
<slangasek> mathiaz: cheers
<cjwatson> gah, axis2c has been broken so that eucalyptus no longer builds, and I wanted to upload the latter ...
<mathiaz> slangasek: I'm writing the MIR now
 * cjwatson sighs and embarks on yak-shaving
 * slangasek passes the curry brush
<cjwatson> oh, it's probably upgrade madness. bug 426752
<ubottu> Launchpad bug 426752 in rampart "libaxis2c symlinks madness makes for a bad upgrade experience" [Medium,In progress] https://launchpad.net/bugs/426752
<cjwatson> ... no, I think it's just busted.
<ccheney> shtylman: sorry was away for a bit
<shtylman> ccheney: all good
<ccheney> shtylman: ok just normal submission is fine
<shtylman> ccheney: by normal you mean ? :)
<shtylman> git patches to list?
<ccheney> yea
<shtylman> ok..no prob
<cjwatson> ah, fixed, had to remove *everything* that owned /usr/lib/axis2
<shtylman> is the next uds gonna be in the states?
<cjwatson> shtylman: yes, one way or another
<cjwatson> (so I hear anyway)
<shtylman> cjwatson: gotcha
<slangasek> cjwatson: even if we have to annex territory to do it? :)
<mathiaz> slangasek: do you plan to process the NEW source package queue today (ie before alpha6 soft freeze)?
<slangasek> mathiaz: yes
<cjwatson> slangasek: I don't *think* we'll have to go that far, unless there have been recent secessions I haven't heard of :-)
<slangasek> Texas's flirtation with secession seems to have petered out
<mathiaz> slangasek: cool. Let me know if you run into issues with image-store-proxy
<mathiaz> cr3: http://paste.ubuntu.com/271278/
<mathiaz> cr3: ^^ testing checkbox-cli in a vm - ran into this error
<cr3> mathiaz: thanks, will fix and resubmit
<mathiaz> cr3: well - do what the problem is?
<mathiaz> cr3: I'm not sure if it's in checkbox - let me try again
<Keybuk> cjwatson: I still disagree
<mathiaz> cr3: hm yes - it seems to be checkbox related
<Keybuk> any library that changes its API in its header files in a non-backwards compatible way should take steps to ensure applications can be upgraded
<Keybuk> e.g. by changing SONAMEs, bumping major versions, etc.
<mathiaz> cr3: moreover I had only selected disk and network tests - and got this user applet test in a vm
<Keybuk> this is a non-backwards compatible header change
<Keybuk> it should be handled better
<cjwatson> what I mean is that it is better to resolve the issue at the furthest upstream point and then trickle down, to ensure that we're not just constantly flip-flopping
<mathiaz> cr3: I'm not sure if this is the expected behavior
<mathiaz> cr3: as I have the option to skip it, it's ok.
<cjwatson> I never disagreed that it's a bug - I just disagree with you about where it's best to start handling it
<Keybuk> cjwatson: I don't disagree
<cjwatson> (or seem to ...)
<cjwatson> largely because I'm entirely certain that if we file a glibc bug, Ulrich will just close it, and then our only recourse is to make Ubuntu incompatible with the rest of the glibc 2.10 world
<Keybuk> likewise there's no point fixing code until it's resolved upstream
<Keybuk> cjwatson: wasn't that the reason we switched to eglibc?
<cjwatson> no, it was one of the straw-men
<cr3> mathiaz: it's not expected, I would like to look into this problem
<cjwatson> it explicitly wasn't a way to get us out of maintaining compatibility
<Keybuk> cjwatson: really? because I'm pretty sure having read everything that the entire reason for eglibc's existance is "Ulrich"
<cjwatson> eglibc means that somebody else is handling the integration of ports for us
<Keybuk> you realise that we're in the wrong seats again though? :)
<cjwatson> I think that's 90% of the reason Debian moved to it
<cjwatson> I do :-)
<Keybuk> you're the one defending an API breakage that I'm complaining about <g>
<Keybuk> we must stop doing this :p
<cjwatson> of course BSD people I talked to took the pragmatic approach and said "just use a wrapper function already"
<cjwatson> no doubt because they've seen the function with both prototypes in the wild :)
<Keybuk> I'd just nih it instead and not use the library function ;)
<cjwatson> changing SONAME would be wrong, BTW, it's not an ABI-significant change
<Keybuk> the weird thing is that things only fail sometimes
<Keybuk> I can't work that out yet
<Keybuk> sometimes gcc/glibc are quite happy with one prototype matching the other
<Keybuk> and other times they are not
<cjwatson> oh, and unfortunately you have to register with austingroupbugs.net in order to do so, but I'd appreciate it if you would provide real-world examples of breakage in the POSIX defect I filed
<Keybuk> doesn't seem much point
<cjwatson> or send them to me and I'll pass them on
<Keybuk> that's in the 10-year fix timescale
<Keybuk> ;)
<Keybuk> "we'll fix that in POSIX 2017"
<Keybuk> it'd probably be better just to change the qsort() manpage, etc. and just move on
<cjwatson> if it's on the list to be fixed in the next version of POSIX, I think it'd be much easier to persuade Ulrich to make it a POSIXLY_CORRECT thing
<Keybuk> that's what I mean
<Keybuk> the "next version of POSIX" is likely to *be* 2017 :p
<Keybuk> ironically this is a fall-out from the version of POSIX that can be largely be described as "catch up with linux/glibc"
<cjwatson> sure, but that doesn't necessarily mean we won't get an answer to the defect before that, which we can quote
<cjwatson> and have the header change versioned with the usual feature test defines, etc.
<Keybuk> I'm inclined though, still
<Keybuk> to suggest this is a C bug
<cjwatson> my brain dribbled out my ears trying to parse the relevant bit of the standard
<Keybuk> int (const void *, const void *) and int (const char *, const char *) should really be compatible
<Keybuk> if they were, it wouldn't matter
<cjwatson> I'm still not sure I was reading it correctly
<Keybuk> and you could pass strcmp and other useful things there too
<cjwatson> yeah, I agree
<Keybuk> and then you could do standard glib-style
<Keybuk>   int (void *, other args here)
<Keybuk> but pass a function in that takes
<Keybuk>  int (SomeOtherStruct *, other args here)
<Keybuk> without casting
<Keybuk> and thus still be typesafe
<cjwatson> yes, it would be much more convenient
<Keybuk> otherwise you basically end up casting all function pointers
<Keybuk> and lose all point of having them at all
<cjwatson> if I could understand the relevant bit of the standard well enough, I'd file a defect report with the C committee as well :-)
<cjwatson> well, the usual answer is not actually to cast, but to do int (void *first, other args here) { char *thingiactuallywanted = first; ... }
<cjwatson> but that's tedious
<Keybuk> that's horrendously inefficient
<Keybuk> especially if you're using generic functions, which it's very common to pass, like free()
<Keybuk> wrapping every single one costs you a PLT entry, a relocation, multiple stack frames, etc.
<mathiaz> cr3: and what about the first bug I've seen?
<mathiaz> cr3: (http://paste.ubuntu.com/271278/)
<cjwatson> hmm, a clever enough compiler could perhaps notice that it was just a wrapper to get the types right and optimise it away; although it might have to do some analysis on what you were doing with the function pointers to do that
<Keybuk> actually, I don't think it's *permitted* to optimise that away
<Keybuk> you'll probably find that kind of thing isn't allowed
<Keybuk> and, let's be fair about this
<Keybuk> there are many terms we can use to describe gcc
<Keybuk> I would not include "clever compiler" in them
<cjwatson> hah
 * Keybuk contemplates Build-Depends: llvm-clang
<Keybuk> http://0pointer.de/public/keybuk
<Keybuk> are those not the most *gorgeous* warning outputs
<Keybuk> file.c:623:41: warning: incompatible pointer types passing 'int (struct dirent const **, struct dirent const **)', expected '__compar_fn_t' (aka 'int (*)(void const *, void const *)')
<Keybuk>         qsort (paths, npaths, sizeof (char *), alphasort);
<Keybuk>                                                ^~~~~~~~~
<ion> keybuk: clangâs warnings are awesome when they exist. For some things, warnings have yet to be implemented. :-)
<Keybuk> ion: well, yes
<Keybuk> and the fact I use a few too many GCC Extensions for clang right now
<mathiaz> cr3: I've uploaded checkbox 0.8.3 and reported bug 429764
<ubottu> Launchpad bug 429764 in checkbox "checkbox-cli doesn't respond to key answers" [Undecided,New] https://launchpad.net/bugs/429764
<mathiaz> cr3: it wasn't working in 0.8.2 too
<mathiaz> cr3: and bug 429767
<ubottu> Launchpad bug 429767 in checkbox "Running checkbox-cli in a vm prompts for the Fingerprint unlock test" [Undecided,New] https://launchpad.net/bugs/429767
<superm1> Keybuk, why are the start levels in /etc/rc*.d all changed now to 0-6?
<Keybuk> superm1: -v
<Keybuk> superm1: ?
<superm1> Keybuk, i just made sense of it, it's because of the change to dependency based in sysvinit
<Keybuk> but we didn't make that change
<superm1> um. debian appears to have done so, and then you merged their package?
<Keybuk> yes, but I explicitly disabled that
<superm1> Hmm, then why is it taking effect for me on a mythbuntu live disk?
<superm1> how was it disabled?
<Keybuk> stat /etc/init.d/.legacy-bootordering
<superm1> no such file or directory
<Keybuk> err, ok
<Keybuk> dpkg-query -W sysv-rc
<superm1> sysv-rc 2.87dsf-4ubuntu1
<Keybuk> stat /var/lib/insserv/using-insserv
<superm1> no such file or directory
<Keybuk> dpkg -s sysv-rc | grep Status
<superm1> Status: install ok installed
<Keybuk> grep "upgrade sysv-rc" /var/log/dpkg.log
<superm1> no results.  it's a fresh install
<Keybuk> ah
<Keybuk> I think you just found a bug ;)
<Keybuk> thx, will fix
<superm1> yays
<superm1> okay then i wont go and modify my init scripts to set dependencies right
<Keybuk> touch /etc/init.d/.legacy-bootordering
<Keybuk> that should revert things back to old behaviour
<Keybuk> though it's possible that your install is broken
<superm1> well it's a throwaway vm that i was just trying to identify some other bugs, so no big deal
<Keybuk> fix uploaded
<superm1> cool thanks
<cr3> mathiaz: thanks for the bug reports!
<cr3> mathiaz: by the way, in 429767, you mean "However there is *no* option to Skip the test", right?
<mathiaz> cr3: oh - there *is* one
<cr3> mathiaz: I understand what you mean though: the skip option doesn't actually skip the test, right?
<mathiaz> cr3: right - this is the first bug actually
<mathiaz> cr3: for the second, the fact that there is a skip option doesn't make it so important
<mathiaz> cr3: the best user experience would be to *not* have the fingerprint test shown at all (since there isn't a fingerprint ready in the vm guest)
<mathiaz> cr3: and moreover there isn't any GUI environment
<mathiaz> cr3: so following the testing procedure isn't possible  in a vm -server guest
<mathiaz> cr3: since there is a skip option it's not that bad - as one can just skip the test
<mathiaz> cr3: (which doesn't work right now because of bug 429764)
<ubottu> Launchpad bug 429764 in checkbox "checkbox-cli doesn't respond to key answers" [Undecided,New] https://launchpad.net/bugs/429764
<cr3> mathiaz: gotcha, these will be fixed shortly. if I didn't have my hands full tonight, they'd be done already :(
<mathiaz> cr3: that's fine - they're not a blocker for alpha6
<mathiaz> cr3: I've already uploaded 0.8.3 to karmic
<mathiaz> cr3: if you could mark the branch as merged, that would conclude the review cycle
<tedg> Uhm, this error is too big for me.  "dpkg-shlibdeps: error: no dependency information found for /lib/libc.so.6 (used by debian/indicator-session/usr/lib/indicator-session/gtk-logout-helper)."  How could libc not have dependency information?
<slangasek> tedg: is this in a build log?
<tedg> slangasek: No, local machine.
<slangasek> tedg: what version of libc6-dev?
<tedg> I have 2.10.1-0ubuntu8 installed
<tedg> Apparently there is a newer one on the archive.  ubuntu11.  Probably should grab that.
<slangasek> ah; I was worried about a regression in a more recent version; I doubt it'll change anything, but yes, please retest with the latest
<tedg> Hmmm... not pretty.  I think it's something with my dpkg db.  "unrecoverable fatal error, aborting: files list file for package 'libxklavier15' is missing final newline"
<slangasek> oh yes, that'd do it :)
<slangasek> disk full?
<slangasek> mv /var/lib/dpkg/status{,-busted} && mv /var/lib/dpkg/status{-old,} ?
<tedg> Nope, but "/var/lib/dpkg/info/libxklavier15.list" is trashed.
<cr3> mathiaz: done, thanks again
* slangasek changed the topic of #ubuntu-devel to: Archive: frozen for alpha-6, FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<dholbach> good morning
<soren> cjwatson: If you have input on how to fix up the axis2c problem, I'm very open to suggestions. The problem is that older versions of axis2c shipped some directory symlinks, and when upgrading, dpkg respects those symlinks, so a lot of stuff ended up in all the wrong places.
<soren> zul_: Go to bed.
<zul_> soren: cant if liam keeps waking up every half hour
<soren> zul_: Give him some nyquil. I took some last night, and passed out almost immediately and could hardly wake up this morning.
<soren> (I'm not a doctor, though)
<zul_> heh
<soren> Wow. You know you've spent too much time in the US, when you feel the need add disclaimers to stuff like that.
<soren> This occurred to me the other day as well.. I was in a restaurant and the menu said they recommended you order your steak rare or medium rare, because it tastes better/more that way. That would never happen in the US. They'd be too scared to be sued if someone got sick from eating undercooked meat. :)
<zul> soren: I dont like drugging him up either
<slangasek> soren: 425914> so what can go wrong here?  Eucalyptus packages failing to configure in cases where it configured before (e.g., if the admin provides no input on the new debconf questions)?  Things breaking on upgrade?
<zul> soren: alrighty talk to you in a couple of hours
<soren> slangasek: This only applies for fresh installs.
<soren> slangasek: The primary risk is the default values for the network we provide, really. If they match a subnet the admin already uses, things are going to be odd.
<soren> Not horrible, just odd :)
<slangasek> ok
<ttx> soren: where can I find the manifest for packages in the current EC2 images ?
<soren> ttx: Err.. Good question.
<ttx> soren: I suspect Scott's list of universe packages overlooks some multiverse ones.
<soren> ttx: I suspect you're right.
<pitti> Good morning
<pitti> hi kirkland
<ttx> pitti: o/
<pitti> hey ttx
<ttx> soren: I just wanted to get the list right. I'll fire up an instance and look.
<ttx> soren: the question of manifests generation still holds, though, especially in contaxt of alpha6 release goals :)
<soren> ttx: I hear you, I hear you.
<wgrant> pitti: Hi. I'm currently gluing bits and pieces together to get Soyuz to manage ddebs itself. I've two pkg-create-dbgsyms branches which go part of the way to that goal. Can you have a look at them?
<tkamppeter> pitti, hi
<tkamppeter> pitti, can you have a look at bug 429880?
<ubottu> Launchpad bug 429880 in splix "udevadm trigger is not permitted while udev is unconfigured." [Undecided,New] https://launchpad.net/bugs/429880
<tkamppeter> First it seems that we need to add something to debian/control so that CUPS is only started after udev, should be a "Depends: udev". Am I right?
<tkamppeter> pitti, second, it seems that the postinst scripts of the drivers are executed even with CUPS' postinst having failed. Is "Depends: cups" there not enough?
<mvo> cjwatson: re bug #387112 - do you want me to do the matching debconf change as well (or do you have it prepared already)?
<ubottu> Launchpad bug 387112 in debconf "package cups-pdf 2.4.6-4ubuntu2 failed to install/upgrade: " [Undecided,Confirmed] https://launchpad.net/bugs/387112
<pitti> tkamppeter: depends cups: should be enough, it ensures that all the dependencies are configured before the package is configured
<pitti> tkamppeter: one problem in bug 429880 is that the new apparmor doesn't work with the jaunty kernel, and thus reloading AA doesn't work
<ubottu> Launchpad bug 429880 in splix "udevadm trigger is not permitted while udev is unconfigured." [Undecided,New] https://launchpad.net/bugs/429880
<pitti> tkamppeter: that's why cupsd fails to start
<MindVirus> Hello.
<MindVirus> Does startupmanager work with grub2, and, if so, why does it depend on grub?
<MindVirus> AFAIK startupmanager does work with grub2.
<pitti> tkamppeter: I added the analysis to the bug report and assigned it to me
<tkamppeter> pitti, are bug 429872 and bug 429880 duplicates then?
<ubottu> Launchpad bug 429872 in tcpdump "/sbin/apparmor_parser: ... Profile doesn't conform to protocol" [Undecided,New] https://launchpad.net/bugs/429872
<ubottu> Launchpad bug 429880 in splix "udevadm trigger is not permitted while udev is unconfigured." [Undecided,New] https://launchpad.net/bugs/429880
<MindVirus> ...?
<pitti> tkamppeter: sounds like
<pitti> tkamppeter: for the AA issue, this should probably be fixed in apparmor itself rather
<seb128> pitti, since you seems aa knowledgable, any clue about bug #429863?
<ubottu> Launchpad bug 429863 in evince "/etc/apparmor.d/usr.bin.evince at line 679: Could not open '(null)'" [Undecided,New] https://launchpad.net/bugs/429863
<mr_pouit> Why was gdm-2.20 finally accepted into karmic? Since we finally agreed on keeping the new one for Xubuntu, I don't really understand. Because of that, people are doing some unneeded changes like <https://lists.ubuntu.com/archives/karmic-changes/2009-September/008727.html>â¦
<tkamppeter> pitti, I think about adding "-h localhost" to all calls of CUPS CLI tools in the postinst scripts of printer driver packages, to address the problem of uses having a client.conf.
<pitti> tkamppeter: hm, I already did that in the previous upload; did I miss something still?
<pitti> tkamppeter: I tested it here, could reproduce the hang, and the current version now works just fine
<pitti> tkamppeter: oh, sorry, printer _driver_ packages
<pitti> right
<pitti> seb128: looking
<tkamppeter> Now the problem is, if a user has only "Listen /var/run/cups/cups.sock" and no other "Listen ..." or "Port ..." lines in cupsd.conf, does calling CLI tools with "-h localhost" still work?
<tkamppeter> pitti: ^^
<pitti> seb128: looks very familiar, like bug 429880
<pitti> seb128: I'll shuffle that around a bit
<ubottu> Launchpad bug 429880 in splix "fails to start on jaunty->karmic upgrade, missing udev dependency" [Undecided,Invalid] https://launchpad.net/bugs/429880
<MindVirus> Does anyone know why startupmanager depends on grub only?
<seb128> pitti, thanks
<pitti> tkamppeter: I didn't test that; does it work to do -h /var/run/cups/cups.sock by any chance?
<pitti> tkamppeter: hah, seems like
<pitti> tkamppeter: I don't have a printer on my laptop, but does "lpstat -p -h /var/run/cups/cups.sock" work for you?
<tkamppeter> pitti, it works. Seems that everything which appears as output of "lpstat -H" can be used for the "-h" option.
<pitti> splendid
<tkamppeter> pitti, the "-h" must come first.
<pitti> so this should be done in cups' scripts, too
<tkamppeter> lpstat -h /var/run/cups/cups.sock -p
<tkamppeter> works for me.
<tkamppeter> pitti, Supplying non-existing host names or files with -h gives an error, so my test did not simply work due to -h being ignored.
<pitti> tkamppeter: btw, trunk has 1.4.1 now, but the test suite fails due to some d-bus issue; I'm still investigating this
<pitti> I'll upload it after alpha-6
 * YokoZar wonders if the other default games are coming back to ubuntu-desktop
<tkamppeter> pitti, have a look at Fedora's CUPS package, if they have already packaged 1.4.1, they have perhaps fixed the test suite problem. Especially you should also take a fresh Avahi patch for the dnssd backend from there. Our current patch makes dnssd not discovering device IDs.
<tkamppeter> pitti, "lpstat -h localhost -p" does not work if there if "Listen /var/..." is the only "Listen ..."/"Port ..." line.
<pitti> tkamppeter: fresh avahi patch> right, will do
<pitti> tkamppeter: changing -h localhost to -h /var/run/cups/cups.sock in the scripts then
<pitti> tkamppeter: right, http://cvs.fedoraproject.org/viewvc/devel/cups/cups-avahi.patch?view=log was updated 10 days ago
<pitti> tkamppeter: all done in bzr now
<tkamppeter> pitti, only possible way to break it now is that a user removes the "Listen /var/..." line (probability VERY low), but then we simply live without auto update of the PPDs.
<pitti> tkamppeter: *nod*
<tkamppeter> pitti, we must only check everywhere that the maintainer scripts ignore errors of CLI tools of CUPS.
<tkamppeter> pitti, and this way we get only errors of CLI tools, not hangs due to a password prompt.
<MindVirus> Anyone know why startupmanager depends on grub and not grub || grub-pc?
<tkamppeter> pitti, I have seen that you have replaced signal numbers by signal names in the "trap" command line of the PPD updater in cups.postinst. One question: What is an "ILL" signal? Or is this a typo and should be "KILL".
<pitti> tkamppeter: SIGILL is raised for "illegal instruction"
<pitti> tkamppeter: signal numbers are a bashism, I converted them to signal names to be POSIX compliant and work with dash, etc.
<pitti> tkamppeter: anything else which should go into the current cups upload? otherwise I'd upload it to karmic/sid now
<tkamppeter> pitti, I have found another bug:
<tkamppeter> if lpstat -h /var/run/cups/cups.sock -r > /dev/null 2>&1; then echo x; fi
<tkamppeter> is not a valid test, "lpstat -r" always does "exit 0" even in an error case, like
<tkamppeter> if lpstat -h /var/run/cups/cups.soc -r > /dev/null 2>&1; then echo x; fi
<tkamppeter> (see the typo in the file name).
<tkamppeter> pitti, we must grep the output here.
<dholbach> ttx is reviewing in #ubuntu-reviews
<tkamppeter> pitti, it must be
<tkamppeter> if lpstat -h /var/run/cups/cups.sock -r | grep -v not > /dev/null 2>&1; then echo x; fi
<tkamppeter> pitti, then it works.
<tkamppeter> pitti, I am fixing it currently, wait for my "bzr push".
<pitti> tkamppeter: please set LC_MESSAGES=C for that
<pitti> tkamppeter: so that translations don't break it
<pitti> tkamppeter: also, are you sure that the error goes to stdout, not to stderr?
<tkamppeter> pitti, I have tested it, and I have set LC_ALL=C
<pitti> tkamppeter: cool, thanks
<tkamppeter> LC_ALL=C should be set automatically for system scripts, I hate bug reports with russion ot chinese error messages in log files.
<apachelogger> james_w: quite possibly mercurial's convert plugin is at fault of messed up names ... it seems to translate bzr's committer field to the mercurial user field ... then again if bzr-fast-export|git-fast-import was not broken I would not have used hg to begin with ;)
<tkamppeter> pitti, I am also fixing the PPD auto update now, as the PPDs coming with CUPS are dynamic now.
<sivang> hi all
<sivang> any muse users here?
<tkamppeter> pitti, my fixes are committed now.
<pitti> tkamppeter: thanks
<MindVirus> Anyone know why startupmanager depends on grub and not grub || grub-pc?
<tseliot> mdz: can you still reproduce bug 388357 ? If so, are you available to test a new patch?
<ubottu> Launchpad bug 388357 in xserver-xorg-video-intel "[i965] X freeze on karmic after resume from full screen application: i915_gem_retire_work_handler() / finish_task_switch()" [High,Fix released] https://launchpad.net/bugs/388357
<soren> slangasek: Oh, you approved the FFe? Thanks!
<lool> pitti: Hey I have an ugly pkgbinarymangler + pkg-create-dbgsym issue I'd like to discuss with you
<lool> pitti: Here's my understanding of the issue: pkgstriptranslations will create the translation tarball in a single pass at dh_builddep time (when dpkg-deb --build is called) assuming that stuff has been dh_install-ed or similar before that
<lool> pitti: But pkg-create-dbgsym breaks this assumption since it creates a temporary .deb tree with DEBIAN/control etc. and runs at dh_strip time
<lool> pitti: I can reproduce a case here where pkgstriptranslations creates the translations tarball at dh_strip time (processes the *-dbgsym package)
<lool> Sorry, the assumption is a bit more subtle than that
<pitti> hi lool
<lool> pkgstriptranslations needs DEBIAN/control files to be ready, so needs to be run after dh_gencontrol
<pitti> lool: sorry, I fail to see the problem -- striptranslations andd dbgsym do wildly different things?
<lool> pitti: http://launchpadlibrarian.net/31599040/buildlog_ubuntu-karmic-i386.netbook-launcher_2.1.8-0ubuntu1_FULLYBUILT.txt.gz is an example of the issue
<lool> pitti: They do wildly different things except that dbgsym calls dpkg-deb --build
<lool> pitti: Which triggers striptranslations too early in the build
<pitti> aah, I see what you mean
<lool> and I end up without some translations in the translations tarball
<pitti> lool: uh, really? the po files should really be complete
<pitti> but it could end up with some unstripped .mo files in the .deb
<lool> pitti: the .pos are picked up but not the .mos
<pitti> lool: right; we don't use the .mo files from _translations.tar.gz anyway, but that's indeed a bug
<lool> pitti: We dont?  I think we do
<pitti> lool: I think binarymangler should just ignore -dbgsym
<pitti> lool: well, Rosetta _should_ use them really, but AFAIK it still doesn't
<lool> pitti: Well the reason I'm chasing that is because I have no translations in netbook-launcher
<sebner> pitti: mighty pitty! I think fedora don't like us :(
<lool> pitti: We did the translations in the upstream project
<lool> pitti: disabling translations in ubuntu in the mean time
<pitti> sebner: ?
<lool> pitti: then updated .pos in the upstream tarball and reenabled translations in ubuntu
<sebner> pitti: libatasmart
<lool> pitti: https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=pot
<sebner> pitti: did you read latest comment?
<lool> pitti: https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher
<pitti> sebner: right, Lennart asked for some additional debug output, I'll forward it to the LP bug soon; but feel free to already respond with it upstream
<pitti> sebner: I did
<lool> pitti: So the template is picked up, but not the mos
<pitti> lool: hm, Rosetta only picks up .po files
<pitti> .mo files aren't (and shouldn't ever) be imported
<pitti> they are useful for mapping domains, but not for importing translations
<sebner> pitti: yeah but "disable it for all" and "blacklist" doesn't sound that good to me though :\
<lool> pitti: Ok then I guess there's also a bug in rosetta
<pitti> sebner: well, better than causing kernel oopses; it'll just disable smart monitoring, which wouldn't be a regression from jaunty (that didn't have it at all)
<lool> pitti: Or do you see a reason why .pos aren't used to seed Rosetta here?
<pitti> lool: perhaps it still needs to be approved?
<pitti> lool: new translation templates need to go through a queue first
<lool> pitti: Well dpm told me the import queue was empty
<sebner> pitti: oh, kk. I'll try to give some debug information later but I'll add it to LP if you don't mind
<dpm> pitti: yeah, they've been approved
<pitti> lool: the build log shows that it grabbed 55 files, presumably the *.po and some *.mo files
<lool> dpm: Are the strings seeded from .mos or .pos?
<lool> pitti: No, just the .pos
<lool> and .pot
<lool> pitti: I have a local build with the resulting netbook-launcher_2.1.8-0ubuntu1_amd64_translations.tar.gz
<dpm> lool: AFAIK, the POs, as pitti says
<lool> pitti: If I dont install pkg-create-dbgsym I get 111 or so translations
<lool> dpm: Ok so it looks like there's a bug in Rosetta then?
<pitti> dpm, lool: hm, ter_status=NEEDS_REVIEW&field.filter_extension=pot has a lot of "blocked"; why's that?
<pitti> sorry
<pitti> lool: https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+imports?field.filter_status=all&field.filter_extension=all
<lool> dpm: ^
<pitti> I think it picked the wrong *.po naming scheme
<pitti>    po/netbook-launcher-it.po is a really broken name
<pitti> perhaps that one should be blocked, and all others approved?
<lool> pitti: The translation tarball seems to fix that though
<lool> -rw-r--r-- root/root      4441 2009-09-15 12:09 ./source/po/nb.po
<lool> -rw-r--r-- root/root      3728 2009-09-15 12:09 ./source/po/nds.po
<lool> ...
<pitti> lool: ok, so I'll change pkgbinarymangler to just silently ignore *-dbgsym
<lool> pitti: I had a look at the source code
<pitti> lool: I really don't think that it actually breaks anything ATM, but still better to have complete tarballs
<lool> pitti: And I didn't find that very clean to do
<pitti> lool: yeah, unfortuantely nothing in that divert-mania is clean to do :-(
<lool> pitti: But what we could easily do is export NO_PKG_MANGLE in the dpkg-deb invocation in create-dbgsym
<pitti> this is an utter hack
<lool> Or actually doing the ignoring in the diverted /usr/bin/dpkg-deb would work too I guess
<dpm> lool: pitti: the templates were blocked at some point in order to allow only upstream translation. That caused the PO files to be blocked automatically. I then approved the templates, which should auto-approve any translations, but the latest upload didn't seem to upload any translations. The blocked PO files are from 2009-08-07, whereas the latest upload was a few days ago
<lool> dpm: Well the LP build log indicates 55 translations were picked up
<pitti> lool: either setting NO_PKG_MANGLE in -create-dbgsym or in dpkg-deb (similar to where it's set for PPA, autotest, or partner)
<lool> And my local builds, even with the bug we are discussing, show them too
<lool> pitti: We could do both
<pitti> lool: I think I'll just add it to p-c-d
<lool> pitti: http://paste.ubuntu.com/271405/
<pitti> lool: right, got the same patch; do you want to commit/upload, since you already have the changelog?
<lool> pitti: Oh there's a bzr?
<lool> pitti: I'm happy to upload as a reward for chasing that down  ;-)
<pitti> lool: eww, no Vcs-Bzr: indeed
<lool> pitti: Ok will commit and upload
<pitti> lool: lp:~ubuntu-core-dev/pkg-create-dbgsym/ubuntu
<pitti> lool: perhaps you can add Vcs-Bzr:
<lool> of course
 * pitti hugs lool, thanks!
<wgrant> That conflicts with one of my branches :(
<pitti> wgrant: pkg-create-dbgsym?
<wgrant> pitti: Yeah.
<wgrant> Trivial resolution, just amusing that that part was modified twice in one day.
<pitti> what did you change?
<dpm> lool: I can't see any PO files from the last upload on the 10th in the imports queue (https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+imports?field.filter_status=all&field.filter_extension=po). Do you mind coming over to #launchpad and continuing the conversation with the LP devs, in case it's a problem with rosetta?
<pitti> lool: for full love, please install pkgbinarymangler and then run tests/run in p-c-d, just to be sure
<lool> wgrant: Are your branches good to merge?
<wgrant> pitti: Stuff related to Soyuz ddeb support. I thought I pinged you about it earlier.
<lool> wgrant: They seem to relate to corresponding LP changes
<pitti> !!!!
<pitti> wgrant: soyuz can digest .ddebs now?
<wgrant> lool: No. I'm just getting reviews for all the bits in the various systems first.
<tkamppeter> pitti, I tried to build CUPS 1.4.1 on my local box but it fails the tests. I get the following extra warning:
<wgrant> pitti: Yes.
<tkamppeter> W [15/Sep/2009:12:43:03.898501 +0200] [CGI] Unhandled message: interface=org.freedesktop.DBus.Introspectable, path=/, member=Introspect
<wgrant> pitti: Possibly for 3.0, but more likely for 3.1.10.
<lool> Cool
<lool> wgrant, pitti: I think we should upload wgrant's stuff after A6
<wgrant> pitti: Most of the work was done a couple of cycles ago, but the whole stack needs to be glued together now.
<lool> rather than now
<wgrant> lool: Certainly.
<wgrant> pitti: So, those two branches really should go into older series too (mainly for PPA ddebs). It has been suggested that they just be stuffed into the chroots, rather than going through SRU. What do you think is best?
<pitti> tkamppeter: that's what I get locally under karmic, but it doesn't happen in my sid chroot, nor on the buildds
<pitti> wgrant: I'd put it into -updates TBH, seems cleaner to me
<wgrant> pitti: That's what I thought.
<wgrant> pitti: But it doesn't look like it has been done in the past.
<lool> pitti: There's no bzr branch for pkgbinarymangler though?
<pitti> lool: no, there isn't
<wgrant> pitti: Can you look over those branches? I need to make compatible changes in a few separate places, so it'd be nice to know now if something's wrong.
<lool> pitti: tests pass
<pitti> wgrant: meh, bazaar.lp.net times out for me
<pitti> lool: \o/
<lool> pitti: I'm adding a README mentionning the tests/run thingie
<wgrant> pitti: Ew.
 * pitti uses bzr diff --new lp:...
<pitti> wgrant: dpkg -I $ddeb | grep -q "Source: $src"
<pitti> wgrant: where do you get $src from?
<pitti> wgrant: it seems to grep for "Source: " only, which will probably work, but not assert a correct value?
<wgrant> pitti: Oops. I mean $s.
<wgrant> But yes, it still works..
 * wgrant fixes and retests.
<tkamppeter> pitti, I have tested the new dnssd backend now (manually installed) and PPDs get correctly auto-assigned. Now it needs only some fine-tuning in s-c-p, so that the different entries for the same printer are put together and URLs pointing to a CUPS queue get set up as raw queue by default.
<pitti> wgrant: otherwise, add-missing-source-field looks good
<wgrant> pitti: So, Soyuz will get a 'Build-Debug-Symbols: yes' into /CurrentlyBuilding, if the archive allows ddeb creation.
<wgrant> pitti: Unfortunately the logic gets a bit messy, as we also have to handle the old case where Soyuz doesn't know to do that yet.
<pitti> wgrant: respect-sbuild-dbgsym-config -> that needs a check whether /CurrentlyBuilding exists in the first place
<pitti> wgrant: the old code does "if grep -qs", which is False if the file doesn't exist, and thus behaves correctly
<lool> pitti: (Fixes the netbook-launcher .mo issue, uploaded)
<pitti> wgrant: fir you do "if ! grep -qs /CurrentlyBuilding"?
<pitti> ("fir"? "but")
<pitti> wgrant: hm, should be fine, though; nevermind
<pitti> wgrant: that branch looks good
<wgrant> pitti: Great, thanks.
<pitti> thanks to you
<wgrant> pitti: The code to copy dbgsyms to public_html will remain for now, but it would be nice to kill it eventually.
<wgrant> (the translations stuff is still there from 2006!)
<pitti> wgrant: I'd love to kill it
<lool> pitti: I just realized something relatively unfortunate: the only way to distinguish -dbgsym from other packages is their name and pkg-create-dbgsym ends with the same suffix
<pitti> lool: what do you need this for?
<lool> pitti: Well in cases like this for instance, when trying to identify -dbgsym packages in pkgbinarymangler
<lool> pitti: Perhaps they should use a special section?
 * lool goes to lunch &
<pitti> lool: but why do you need to now?
<pitti> lool: section> they could be in "debug", I guess
<cjwatson> mvo: I already committed the matching debconf change upstream; I'll make sure it gets into karmic
<wgrant> pitti: http://pastebin.ubuntu.com/271413/ (r126 and r127)
<wgrant> A few of the test sources needed their names fixed.
<wgrant> Though most were OK.
<pitti> wgrant: $s$ -> $s\$
<pitti> wgrant: otherwise looks fine, thanks
<wgrant> pitti: Hm. It worked as expected without the backslash.
<wgrant> Oh.
<wgrant> I see.
<wgrant> Duh.
<LaserJock> cjwatson: I need some help with the Edubuntu DVD .iso regarding seeds, is there a separate channel for that sort of discussion?
 * ogra hopes there isnt ... the amount of channel fragmentation we have nowadays is insane
<LaserJock> ogra: agreed
<davmor2> ogra: what do you mean.  There are only 30+ ubuntu channels, anyone would think it was hard to follow :)
<dpm> lool: ok, the netbook-launcher translations seem to have now correctly been imported -> https://translations.edge.launchpad.net/ubuntu/karmic/+source/netbook-launcher/+pots/netbook-launcher/ I'll get on to the rest of the UNR translatable packages during the day
<ogra> davmor2, yeah, i'm coming from a time where only #ubuntu-devel and #ubuntu-motu existed
<davmor2> ogra: :)
<wubbbi> I got a question. In ubuntu 9.10 netbook-remix. Are there any 3D effects enabled by default? oO my Compiz is off but there are till effects!
<wubbbi> still
<ogra> Keybuk, you like freezes for uploads eh ?
<Keybuk> ogra: technically I had them queued for upload last night before Steve sent the mail
<Keybuk> but my line went down for work half way through
<ogra> yeah yeah :)
<Keybuk> so there were things stuck in dep-wait
<Keybuk> and it came back up, and the uploads continued by themselves :)
<cjwatson> LaserJock: what's up?
<lool> pitti: Well I just thought at a high level it was useful to have the info available when needed
<ogra> Keybuk, whats that initramfs-tools thing ?
<ogra> "Make usplash-related components optional, you need to set USPLASH=y"
<lool> pitti: But I dont need it anymore; I just wondered how to do a clean -dbgsym check in pkgbinarymangler
<ogra> Keybuk, does that affect the "splash" cmdline option in any way ?
<LaserJock> cjwatson: well, it just doesn't look like my changes are making any effect
<Keybuk> ogra: in the sense that usplash is not normally started, sure
<LaserJock> cjwatson: I copied over ubuntu.karmic's dvd and dvd-live seed, I had to change STRUCTURE a little to reflect that we don't have a Desktop CD
<ogra> Keybuk, "not normally started" ? you mean even if splash is set it wont start ?
<LaserJock> cjwatson: I then added * edubuntu-desktop to dvd-live and waited for a rebuild. Looking at the latest one that really should have it, I don't see any real difference, no edubuntu stuff at all in the .manifest
<Keybuk> ogra: right
<ogra> Keybuk, grmbl
<ogra> Keybuk, how does that act on live images ? do we leave the user without a splash ?
<ogra> Keybuk, and how do i enable it on my arm setups where i have 1.5min bootime ?
<Keybuk> for now, yes
 * ogra feels like he wasted a lot of time this cycle by making usplash work on arm :/
<Keybuk> we still want to start usplash if it takes more time than expected to start X
<Keybuk> that bit is still to do though
<ogra> Keybuk, well, i'D like to enforce it on arches where i know i'll never match the quick boot criteria
<ogra> beyond that casper will always need it
<Keybuk> ogra: you don't need to enforce it
<Keybuk> it'll appear by itself
<Keybuk> (it will appear, I should say)
<ogra> ok
<Keybuk> it's a good point though that casper probably should set it
<ogra> unless we clean up casper :)
<ogra> which i would prefer
<ogra> it really has a lot of old cruft
<Keybuk> well, that would be nice too
<Keybuk> I'm really going to push for karmic+1 to use dracut
<ogra> thigs were added over the years and nobody ever cared for them
<Keybuk> complete with having a test ready for UDS to demo
<Keybuk> that should massively help with the cleanup
<ogra> as casper replacement ?
<ogra> or just for initramfs-tools
<Keybuk> initramfs-tools
<ogra> yeah
<Keybuk> so obviously inherently casper things too
<soren> Keybuk: dracut? What's that?
<soren> Keybuk: Google claims it's a place in Massachussets. :/
<ogra> soren, a new and shiny way of building initramfs
<Keybuk> it's a project to write an initramfs-tools/yaird/etc. variant "upstream"
<Keybuk> it's very modular, and very configurable
<Keybuk> e.g. just about everything can be overridden on the kernel command-line
<soren> I see.
<LaserJock> cjwatson: any thoughts?
<cjwatson> LaserJock: looking
<LaserJock> cjwatson: thanks
<cjwatson> LaserJock: I think http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/285 should fix it
<LaserJock> cjwatson: ahhh, I see
<LaserJock> cjwatson: thanks for that, I thought I was doing something horribly wrong
<LaserJock> which I suppose I still might, but at least it wouldn't be *just* me :-)
<pitti> Keybuk: I committed your upstart changes to hal, apport, gdm bzr FYI
<pitti> Keybuk: didn't you have a change for cups as well?
<Keybuk> err, I have the committed
<Keybuk> I just need to push
<Keybuk> did you already push?
<Keybuk> if there's nothing else in there, do you mind if I --overwrite yours
<Keybuk> as otherwise it'll make things tricky for me in following up with other changes
<LaserJock> cjwatson: what's the difference between LIST and LIVELIST in livecd.sh?
<jdstrand> jjohansen1: hi! when you come online can we talk about bug #429872?
<ubottu> Launchpad bug 429872 in tcpdump "/sbin/apparmor_parser: ... Profile doesn't conform to protocol" [Undecided,New] https://launchpad.net/bugs/429872
<Keybuk> pitti: cups: yes, but you sneaked in a big update so my changes were rejected ;)
<cjwatson> LaserJock: LIST remains installed on the target system if you use ubiquity; LIVELIST doesn't
<Keybuk> pitti: err
<Keybuk> pitti: apport - why did you drop the dh_installinit call?
<LaserJock> cjwatson: so anything in the edubuntu-live seed is removed from the target system after the image is copied over?
<cjwatson> LaserJock: that's the intent, ys
<cjwatson> yes
<lool> wgrant: Just a note that I pushed some packaging changes to pkg-create-dbgsym; shouldn't cause more conflicts with your branches except for changelog since I guess you touch mostly the actual code, but wanted to mention it just in case
<Keybuk> pitti: oh, sorry, I see - cdbs will call it anyway
<lool> ArneGoetje: Around?
<lool> ArneGoetje: kasumi breaks the dvd build
<lool> ArneGoetje: The following packages have unmet dependencies:                                  language-support-input-ja: Depends: kasumi but it is not installable
<lool> ArneGoetje: Would you mind commenting on the MIR?
<lool> ArneGoetje: If the plan is to include kasumi in karmic main for sure, then we could prepromote it and finish the MIR stuff before release
<lool> ArneGoetje: But if you think we can do without I'd like to relax the dep so allow the dvd livefs to build
<ogra> cjwatson, did NCommander contact you for the dove stuff he wants in ubiquity ?
<ogra> (two changed lines)
<oreon> sera
<cjwatson> ogra: I'm aware of the bug, but I have not seen the flash-kernel patch yet
<Keybuk> pitti: I'm going to defer cups
<Keybuk> I want to sort that udev-configure-printer mess out as well
<Keybuk> since afaict, they should not be udev rules but upstart jobs anyway
<cjwatson> ogra: I'm looking at the ubiquity branch now
<cjwatson> ... which is of course fine
<ogra> cjwatson, 3437 and 3439 are needed anyway
<ogra> thanks :)
<ogra> CIA-33 is fun :)
<ogra> lool, ^^^ we should steal that bot for mobile and arm branches :)
<lool> You can set it up on cia.vc
<cjwatson> see http://wiki.ubuntu.com/Installer/Development for the client-side setup (adjust to taste)
 * ogra will take a look, its really helpful
<cjwatson> ogra: what's happening with the targeted flash-kernel task on that bug?
<cjwatson> if flash-kernel is going to change, I don't want to upload ubiquity until that's in place
<lool> cjwatson: Last I heard NCommander had fixed the remaining issues but wanted to do a full install test
<lool> cjwatson: Is it ok to upload flash-kernel + ubiquity tomorrow?
<lool> or later today?
<lool> cjwatson: Let me ask differently, until what time is it reasonnable to push them for A6?
<cjwatson> the earlier the better, I don't want to delay CD builds
<cjwatson> the later it lands, the more stressed davmor2 will be
<ogra> lool, ubiquity is needed anyway
<lool> cjwatson: I understand; I dont have the changes yet and have been harassing to get them; we will check with you when they appear
<ogra> with or without flash-kernel
<ogra> we should imho upload ubiquity ASAP ...
<ogra> flash-kernel will only affect armel
<lool> ogra: flash-kernel is copied in ubiquity
<cjwatson> indeed
<cjwatson> if I upload ubiquity now, I'm just going to have to upload it again when flash-kernel lands
<ogra> oh, damned, yes, i forgot about that
<ogra> well, NCommander has to run the meeting in 7 min so he should show up soon :)
<MacSlow> pitti, what could I try to do (with jockey) to force it to detect the proprietary nvidia-driver being installed on the system?
<cjwatson> soren: has anyone had a chance to look over my branch in bug 425922? it'd be awfully nice to get that into alpha 6 if possible
<ubottu> Launchpad bug 425922 in eucalyptus "Eucalyptus component registration process is manual " [Medium,Triaged] https://launchpad.net/bugs/425922
<soren> cjwatson: I thought I saw you push that to the main branch?
<cjwatson> no
<cjwatson> I pushed the bridge device change
<soren> Oh.
<soren> Well, I'm perfectly happy with the change.
<MacSlow> pitti, right now it does not show up in the windowed opened up "jockey-gtk" and I'm running on "nv" instead of "nvidia"
<cjwatson> soren: I haven't been able to test it, that's all ...
<soren> cjwatson: Oh.
<cjwatson> that's why I'm asking for extra eyeballs :)
<soren> cjwatson: I thought you had a cdimage building rig locally :)
<cjwatson> I have some disk space problems
<soren> Oh, that.
<soren> right.
<cjwatson> I try to avoid building locally unless I have to
<cjwatson> I can give it another try and see if I can squeeze it in somewhere ...
<davmor2> cjwatson: ubuntu has issues with oem ubi-timezone so there maybe a respin to fix that yet :(
<soren> Well, it /looks/ good to me. :) I haven't tested it either.
<cjwatson> davmor2: yes, I followed up to your bug
<pitti> Keybuk: apport dh_installinit> me? you dropped it, you commented it out; I just removed it completely
<pitti> Keybuk: cups> okay
<pitti> MacSlow: hm, but you have it installed? from where?
<MacSlow> pitti, via synaptic "nvidia-glx-185"
<davmor2> cjwatson: I think there is something wrong, could be that it is halfway through being configured.  But apport-collect say Error connecting to Launchpad yadda yadda yadda
<MacSlow> pitti, trying to force its use via xorg.conf causes a crash of Xorg (without a recoverable stacktrace)
<soren> cjwatson: Do you have an opinion on https://bugs.edge.launchpad.net/ubuntu/+source/eucalyptus/+bug/429087 ? Dan's suggestion seems reasonable enough to me.
<ubottu> Launchpad bug 429087 in eucalyptus "after UEC front-end (cluster) install, key sync stage of registration cannot proceed without entering a password " [Undecided,New]
<pitti> MacSlow: hm, perhaps 185 is just not supported on your card?
<MacSlow> pitti, my guess is, that the crash is caused by loading the glx-module
<soren> cjwatson: (without it, your stuff will likely fail)
<cjwatson> davmor2: please have a look around for other logs, then - syslog doesn't have the stuff I need
<MacSlow> pitti, I'm pretty sure the GeForce 8800 GT is supported by nvidia-glx-185
<cjwatson> davmor2: /var/log/installer/debug or /var/log/oem-config.log perhaps
<pitti> MacSlow: can you please send me /var/log/jockey.log? (pastebin or mail)
<davmor2> cjwatson: the popup says further info may be found in /var/log/syslog
<davmor2> I've add oem-config.log
<cjwatson> soren: oh, yeah, that should be straightforward to fix, I'll do that
<soren> cjwatson: Lovely, thanks.
<cjwatson> davmor2: ok, will look after food
<soren> cjwatson: If you want to roll a new revision and upload, I'm cool with that.
<MacSlow> pitti, http://paste.ubuntu.com/271444
<Keybuk> pitti: yeah just misinterpreted the comment
<Keybuk> thought for a second you'd gone "oh, no more init script" and deleted the dh_installinit not realising that dh_installinit is what installs debian/*.upstart ;)
<pitti> MacSlow: a-ha: ImportError: No module named NvidiaDetector.nvidiadetector
<pitti> MacSlow: do you have the "nvidia-common" package installed?
<blackxored> hello
<MacSlow> pitti, checking...
<MacSlow> pitti, ah ok... installed "nvidia-common" and depedencies and did "jockey-gtk -c -u", next call to "jockey-gtk" now does list the proprietary nvidia-driver
<MacSlow> pitti, I wonder why this (nvidia-common) did not survive the dist-upgrade (from jaunty to karmic)
<pitti> MacSlow: sometimes packages get slightly out of sync, and people accidentally uninstall them instead of holding them back
<pitti> but I don't know for sure, of course, what happened to your's
<Keybuk> pitti: interesting FTBFS on apport
<Keybuk> not sure whether it's just archive churn
<MacSlow> pitti, could a "apt-get autoremove" have been the reason for unintalling "nvidia-common"?
<MacSlow> pitti, that's the only "out of the ordinary" thing I did in between
<pitti> Keybuk: lol
<pitti> Keybuk: 2.10 < 2.2 ...
<pitti> Keybuk: will fix
<Keybuk> ok, thanks
<pitti> hm, ssh to the DC just fell of the planet
<pitti> oh, it's just ronne
<soren> works for me.
<pitti> damn, I just wanted to fix the retracers
<soren> pitti: Looks like it crashed. :(
 * pitti sobs in the IS channel
<cjwatson> urk, buildds are busted
<cjwatson> http://launchpadlibrarian.net/31841882/buildlog_ubuntu-karmic-i386.os-prober_1.33_CHROOTWAIT.txt.gz
<cjwatson> Keybuk: ^-
<cjwatson> hmm, I wonder why 2.86.ds1-61ubuntu16 is still being used
<cjwatson> lamont: can the above ^- be fixed by a chroot refresh? karmic has sysvinit 2.87dsf-4ubuntu3
<smoser> slangasek, ping
<robbiew> slangesek: did you get access to nectarine yet?
<Keybuk> cjwatson: yeah I had that with the PPA system last night
<Keybuk> I have *no* idea what they're up to
<kirkland> pitti: howdy
<pitti> hey kirkland
<kirkland> pitti: hey man
<Keybuk> the strange thing is that version of initscripts has been superseded at least 3 times now
<Keybuk> and isn't even in the pool anymore
<cjwatson> yeah, I wonder if it's in the chroot and is being held back
<elops> a mount keeps being added to my mtab file
<Keybuk> that was my guess
<cjwatson> would /var/lib/dpkg from the chroot help?
<elops> any idea why this might be? i may have added something somewhere a while back that did this, but i cant remember where... it is not in fstab
<Keybuk> what's odd is that it started last night
<Keybuk> cjwatson: it might
<cjwatson> I think I can manage to extract it
<Keybuk> elops: ?  that's what your mtab file is for
<elops> the mount i do not want is identified in there.
<elops> what to do?
<Keybuk> elops: is the mount you do not want in your /etc/fstab ?
<elops> no, i removed it (actually, changed its location)
<elops> but the location that i do not want remains in the mtab and the /proc/mounts
<Keybuk> did you reboot since?
<kirkland> pitti: were you looking for me?
<elops> yes, several times
<pitti> kirkland: not particularly, I just answered some scrollback from overnight
<kirkland> pitti: ah
<Keybuk> elops: curious, can you pastebin your /etc/fstab and /etc/mtab files
<Keybuk> and /proc/self/mountinfo too
<kirkland> pitti: so the .face thing i've solved
<kirkland> pitti: .dmrc is subtlely more difficult
<cjwatson> Keybuk: cocoplum:/tmp/cjwatson/karmic-i386.tar.gz
<elops> Keybuk: Sure.
<pitti> kirkland: oh, not just an alternative path?
<Keybuk> cjwatson: ITYM bz2
<kirkland> pitti: because in the place where the path is build, there isn't already immediate access to the username
<kirkland> pitti: needs a pwd call
<kirkland> pitti: i just haven't gotten around to it
<pitti> kirkland: oh, is the user name path of the .ecryptfs/.../.../.dmrc trail?
<slangasek> smoser: ribbit
<kirkland> pitti: /home/.ecryptfs/$USER/
<pitti> ah, I see
<kirkland> pitti: it's okay... i have a user object in the places where .face is called
<Keybuk> cjwatson: did I tell you that I had a *total* epiphany about the hwclock stuff last night?
<cjwatson> no?
<Keybuk> you know that we do the system clock stepping in a udev rule when we see the first rtc device
<evand> pitti: If I wanted to say "authorization is contingent on the request coming from the same physical console a specific USB disk is used on", do you know how I'd express that in policykit?  I'm not sure what the correct approach is, reading the current documentation.
<Keybuk> I realised that was pointless
<Keybuk> we deliberately designed that to *not* need the hardware ;)
<Keybuk> so it can be done as an ordinary upstart job before mounting the root filesystem
<pitti> evand: I don't think you can build relationships like that
<pitti> evand: just "anyone", "local console", "active console"
<elops> Keybuk: http://pastebin.com/d27473af
<Keybuk> there's also a bug when UTC=yes at the moment
<cjwatson> well, it needs the hardware, but the kernel has already read it on initialisation?
<Keybuk> cjwatson: right, exactly
<Keybuk> we don't set the system timezone if UTC=yes
<evand> argh, okay
<evand> pitti: thanks
<Keybuk> so FAT timestamps are written in UTC instead of localtime
<cjwatson> yum
<elops> Keybuk: i dont have a mountinfo
<cjwatson> bet that breaks subtlely
<Keybuk> elops: /proc/self/mountinfo
<cjwatson> subtly?
<ogra> with subtitles ?
<Keybuk> cjwatson: it doesn't break, it just annoys people because the times/dates on their cameras aren't right when they look in nautilus
<elops> Keybuk: http://pastebin.com/d27473af
<Keybuk> well, it annoyed one person so far
<elops> Keybuk; there is only mounts and mountstats
<Keybuk> elops: what kernel version?
<Keybuk> elops: I'd say that whatever is mounting that icebox thing isn't reading fstab
<elops> 2.6.22-14-server
<Keybuk> your mtab is "correct"
<Keybuk> in that it matches the kernel mount table
<elops> i wonder where the hell i put the damn mount command at :(
<elops> How can I fix this sir?
<Keybuk> rc.local?
<elops> what do you suggest I do?
<elops> Keybuk: nope, not there
<cjwatson> soren: I noticed that eucalyptus-{walrus,sc} weren't in main, which doesn't seem good - I promoted them and stuck them in the eucalyptus-simple-cluster seed
<elops> Keybuk, i think i googled solutions to automounting a network drive when i tried this originally
<cjwatson> elops: I'd 'grep -rs icebox /etc' if I were you
<elops> its not a cronjob either
<Keybuk> cjwatson: so there's nothing strange in status
<elops> and i must've buried it in something on someone's advice, and now i have no idea where it is
<elops> smb.conf of course
<elops> lol
<Keybuk> cjwatson: this is from the chroot itself?
<Keybuk> rather than at the failure point, right?
<cjwatson> Keybuk: that's the image stored in LP
<Keybuk> *nods* just checking
<elops> Keybuk: smb.conf of course
<Keybuk> wondered if you knew some magic way of extracting failed build images
<elops> hmm. i dunno if that's doing it.
<cjwatson> Keybuk: I don't think they're stored
<elops> can that be affecting it?
<elops> please suggest anything.. im alsmot about to cry
<cjwatson> Keybuk: I was wondering if it might be possible to do a trial apt-get dist-upgrade using something like chdist
<evand> pitti: in your opinion, would it then be okay to set allow_active to yes in polkit for a method that modifies non-system internal devices, following the lead of devicekit-disks?
<Keybuk> cjwatson: that's what I'm trying
<elops> Keybuk: that can't cause it to mount, could it? i think that just sets up shares.
<Keybuk> ogra: you didn't commit your usplash changes to bzr
<Keybuk> elops: no idea, sorry
<elops> the smb.conf I mean
<evand> (org.freedesktop.devicekit.disks.change being what I'm referring to in devicekit)
<elops> samba doesn't mount things for you
<pitti> evand: with auth_admin? sure
<pitti> evand: erm, "yes"? DK_disks doesn't do that, does it?
<evand> pitti: It seems to: http://pastebin.ubuntu.com/271488/
<pitti> evand: hm, indeed, that looks weird; I'm not sure what "change" means actually
<evand> pitti: amongst other things, write a new partition table
<pitti> evand: oh
<pitti> evand: that's for removable devices
<evand> indeed
<pitti> org.freedesktop.devicekit.disks.change-system-internal is for fixed disks
<pitti> and auth_admin
<evand> correct
<pitti> *phew*
<evand> haha, sorry to scare you
<pitti> evand: perhaps I misunderstood you
<pitti> did you want to say non-(system internal)
<pitti> or (non-system) internal
<pitti> ?
<evand> the former
<evand> usb disks
<pitti> aah
<pitti> that's fine
<evand> this is for usb-creator
<evand> great
<pitti> evand: right, that's fine
<evand> thanks for the help!  Greatly appreciated
<pitti> heh, I did't do anything :)
<pitti> except for jumping and getting pale :)
<evand> hahaha
<Keybuk>   sysv-rc: Breaks: initscripts (< 2.86.ds1-63) but 2.86.ds1-61ubuntu16 is to be installed
<Keybuk> cjwatson: yes, I see this
<Keybuk> The following packages have been kept back:
<Keybuk>   initscripts libc6 libc6-dev sysv-rc
<seb128> hum, Keybuk broken the buildds!
<seb128> broke
<Keybuk> this is weird
<Keybuk> ah
<Keybuk>   initscripts: Breaks: upstart (< 0.6.3-2~boot4) but 0.6.3-1 is to be installed
<Keybuk> and why hasn't upstart 0.6.3-2 been built?
<Keybuk> dep-wait on debhelper
<Keybuk> hmm, no, it has been built
<Keybuk> just an hour ago
<seb128> it's probably not published yet
<Keybuk> right
<seb128> wait another 25 minutes
<Keybuk> cjwatson: this problem will likely cure itself :)
<Keybuk> as soon as initscripts and upstart don't break each other
<cjwatson> Keybuk: aha, ok, cool
<Keybuk> lpia is going to need manual fixing though
<cjwatson> thanks for investigating
<Keybuk> since upstart can't build on that because the breaking initscripts is installed
<cjwatson> upstart build arrived too late?
<Keybuk> no, debhelper arrived too late
<Keybuk> my internet line went down for maintenance last night *mid* uploads
<Keybuk> and didn't come back up until noon today
<cjwatson> looks like only amd64 armel i386 sparc have built
<Keybuk> I've bumped the score of powerpc to rush upstart through before sysvinit
<cjwatson> Keybuk: BTW, bug 320822 should buy another second or so on some boot workloads, although not the default
<ubottu> Launchpad bug 320822 in binfmt-support "update-binfmts is slow on boot" [Wishlist,Fix committed] https://launchpad.net/bugs/320822
<Keybuk> iirc, upstart and dbus don't build on ia64 anyway
<cjwatson> Keybuk: I'll take care of a mass give-back of stuff that broke in the meantime
<cjwatson> probably not huge amounts but it'll be easier to do by script than by hand
<Keybuk> fair enough
<EtienneG> Can someone look at bug #430075?  It is probably a dupe, I would just like to know if there is a temporary workaround so that I can continue testing eucalyptus (it is kind of urgent)
<ubottu> Launchpad bug 430075 in ubuntu "eucalyptus-nc fail to upgrade to 1.6~bzr746-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/430075
<cjwatson> NCommander: what's happening with this flash-kernel change?
<cjwatson> Keybuk: ^- 430075 looks like yours
<cjwatson> EtienneG: might be something to do with:
<cjwatson> sysvinit (2.87dsf-4ubuntu2) karmic; urgency=low
<cjwatson>   * Use legacy boot ordering on fresh installs too.  Ooops.
<cjwatson>  -- Scott James Remnant <scott@ubuntu.com>  Tue, 15 Sep 2009 02:44:35 +0100
<cjwatson> (at a guess)
<cjwatson> EtienneG: how recent was your installation?
<EtienneG> cjwatson, yesterday's daily
<EtienneG> cjwatson, that being said, it is indeed a prob with eucalyptus
<EtienneG> cjwatson, I think the verbiage about insserv may just be cosmetic (or unrelated ot my problem)
<cjwatson> yes, "EUCALYPTUS not configured!" is the direct breakage
<EtienneG> cjwatson, a new version of euca conf file was shipped in the latest package, and it was not installed (might be because of the insserv package)
<EtienneG> if eucalyptus do not have the new config, it will fail with "EUCALYPTUS not configured!"
<EtienneG> I am adding info to the bug
<cjwatson> I wouldn't expect that to have anything to do with insserv
<Keybuk> I think the insserv stuff is just a different way of complaining about something that would fail anyway
<Keybuk> the fact that insserv is there at all is a fixed bug
<cjwatson> and I don't think that the new configuration file is relevant
<EtienneG> Keybuk, thanks, that confirms what I think
<cjwatson> that error is emitted when EUCALYPTUS is set to "not_configured" in /etc/eucalyptus/eucalyptus.conf
<Keybuk> the Debian entente is that we have insserv installed, and anyone can chose to activate it if they can make it work, but not enabled by default
<cjwatson> which probably actually happened because you accepted the entire new configuration file from the package rather than merging it
<cjwatson> it's a slightly unfortunate state of affairs that it's so easy for this to happen
<cjwatson> soren: any particular reason why EUCALYPTUS doesn't have a better default in our package? the current value seems ... unfriendly
<cjwatson> Keybuk: sorry, I should have read that bug in a bit more detail before tossing it in your direction, I missed the crucial line
<Keybuk> cjwatson: np
<Keybuk>   * debian/control: Add udev dependency, since the init script calls udevadm.
<Keybuk>     (LP: #429880)
<Keybuk> pitti: (re cups) &
<Keybuk> ARGH
<Keybuk> WHY DOES THE INIT SCRIPT CALL UDEVADM!?!?!?!?!
 * pitti looks
<pitti> coldplug_usb_printers() {
<pitti>     udevadm trigger --subsystem-match=usb \
<Keybuk> I consider that a critical bug
<pitti>                     --attr-match=bInterfaceClass=07 \
<pitti>                     --attr-match=bInterfaceSubClass=01
<Keybuk> please remove that at once
<pitti> }
<pitti> tkamppeter: ^ why was that necessary again?
<pitti> ah, I guess to detect USB printers which were plugged in at boot, but not configured yet
<slangasek> Keybuk: the init scripts sysvinit has dropped moved where?  Shouldn't sysvinit declare a pre-depends on the packages they've moved to?
<pitti> Keybuk: out of interst, what does it break?
<Keybuk> slangasek: it does, via upstart
<Keybuk> pitti: boot performance
<Keybuk> pitti: nothing should *ever* call udevadm trigger
<Keybuk> I don't care whether or not it works in Mandriva
<pitti> Keybuk: what's the correct way to do that then?
<Keybuk> *do* *not* *do* *it*
<Keybuk> pitti: libudev provides a udev_enumerate function set for enumerating the existing devices
<slangasek> Keybuk: initscripts doesn't appear to have any dependencies on upstart
<pitti> Keybuk: well, we can certainly rewrite it in some way with iteration, I just would expect this to be much slower than a precise trigger
<Keybuk> slangasek: it does via sysv-rc no?
<Keybuk> pitti: no, quite the opposite
<Keybuk> and trigger can have entirely unexpected side-effects
<Keybuk> trigger is *ONLY* used for catching up *udev*
<Keybuk> not any other application
<slangasek> Keybuk: sysv-rc also doesn't depend on upstart AFAICS
<Keybuk> slangasek: this is one of those situations where dependencies won't make any difference no?
<soren> cjwatson: What is it now? I forget.
<soren> cjwatson: /?
<Keybuk> everything depends on each other, and dpkg won't do anything useful anyway
<slangasek> Keybuk: I'm trying to ascertain that things really do depend on each other in a useful manner, such that users don't have all their critical init scripts removed for a period during upgrade :-)
<Keybuk> slangasek: doesn't the Breaks ensure that?
<pitti> Keybuk: is it ok to call it with --dry-run, to get the affected devices?
<slangasek> Keybuk: which breaks where?
<Keybuk> pitti: yes
<cjwatson> soren: yeah
<pitti> Keybuk: good, thanks
<Keybuk> slangasek: initscripts breaks the version of upstart that doesn't have the right support
<soren> cjwatson: What would you suggest instead? ""?
<Keybuk> which should force the upgrade
<cjwatson> soren: um
<slangasek> Keybuk: ah, ok; that might do it, let me meditate on that a bit
<Keybuk> remember that upstart pre-depends initscripts
<cjwatson> soren: no, what I mean is that *in the package* it's currently EUCALYPTUS="not_configured"
<Keybuk> so it all gets very messy ;)
<slangasek> right... :)
<Keybuk> upstart -pre-depends-> initscripts -depends-> upstart
<Keybuk> won't work
<Keybuk> but I think (and tested) that
<soren> cjwatson: It gets set by eucalypus-common in the postinst.
<Keybuk> upstart -pre-depends-> initscripts -breaks-> upstart
<Keybuk> does the right thing
<soren> cjwatson: ...which is another thing I need to take care of.
<soren> cjwatson: I.e. the whole conffile thing.
<Keybuk> since it's upstart that depends on initscripts, which would not otherwise be installed, I think this is right
<cjwatson> soren: yes. but this means that upgraders get it set back to EUCALYPTUS="not_configured" if they incautiously accept the change, and the postinst never undoes that.
<cjwatson> soren: pending the whole conffile fix, why not just make it EUCALYPTUS="/" in the package?
<soren> cjwatson: No particular reason anymore.
<soren> cjwatson: And hypervisor could be set to KVM.
<ArneGoetje> lool: I've taken kasumi out of the language-support-input-ja Depends: for now until the MIR is done...
<jjohansen1> jdstrand: ping
<cjwatson> soren: ok, this is odd. java -version is failing for me, saying it can't find libjli.so. do you see the same thing?
<jdstrand> jjohansen1: so regarding bug #429872, it is causing some upgrade issues. Upgrades don't fail because of how we call apparmor_parser, but they are noisy and confusing due to the 'Profile doesn't conform to protocol' messages
<tkamppeter> pitti, the udevadm call in the CUPS init script is to send a "plugged-in" signal for all USB printers. It takes care of re-enabling or setting up USB printers which where already plugged before the start of udev and cups.
<ubottu> Launchpad bug 429872 in tcpdump "/sbin/apparmor_parser: ... Profile doesn't conform to protocol" [Undecided,New] https://launchpad.net/bugs/429872
<pitti> tkamppeter: right, seems we need to rewrite that
<pitti> tkamppeter: can I commit a rewrite to bzr, and you can test it?
<jdstrand> jjohansen1: we talked about this a bit the other day with kees and mdeslaur, but I don't recall what the resolution was
<tkamppeter> pitti, OK.
<soren> cjwatson: Nope, works for me.
<jdstrand> jjohansen1: well, we tangentially talked about it
<tkamppeter> pitti, why can one not use these udevadm calls in the init script?
<pitti> tkamppeter: Keybuk says it kills kittens and slows down boot
<jjohansen1> jdstrand: it is a related issue,  yes
<tkamppeter> It kills kittens?
<Keybuk> tkamppeter: udevadm is for udev, not for cups
<tkamppeter> pitti: Let us obsolete kittens and use another method.
<jjohansen1> jdstrand: it happens because you are loading profiles under a newer kernel with an older parser
<Keybuk> tkamppeter: is this to re-trigger udev-configure-printer ?
<Keybuk> or does the cups daemon itself need it?
<jjohansen1> jdstrand: but it shouldn't be happening from a jaunty userspace
<pitti> tkamppeter: by discarding kittens so easily you aren't playing by the rules :)
<jdstrand> jjohansen1: well, this is for people upgrading from jaunty to karmic
<pitti> Keybuk: the former
<Keybuk> pitti: right
<Keybuk> as I've been saying for the past few weeks
<pitti> Keybuk: I thought about using --dry-run and just calling udev-configure-printer in a loop
<Keybuk> those should be called from Upstart, not from udev
<jdstrand> jjohansen1: apparmor userspace will get upgraded and restarted first
<tkamppeter> Keybuk: It is to retrigger udev-configure-printer, for printers which got already plugged before udev and cups got started.
<Keybuk> then that solves your problem
<jdstrand> jjohansen1: and then the packages with profiles come along and their postinst runs
<jjohansen1> ah, okay - other way then
<jdstrand> jjohansen1: so apparmor userspace is new on a jaunty kernel
<jdstrand> jjohansen1: as soon as they reboot, it is all fine of cours
<jjohansen1> jdstrand: right
<kees> jjohansen1, jdstrand: what do you think about making the parser kernel-version aware?
<jjohansen1> kees: that is the plan
<kees> jjohansen1: well, that plan is *really* aware, I mean just "oh, wrong version *fail*"
<jdstrand> kees: I'd actually rather like that. it seems a little odd that the parser is so closely tied to a particular kernel version-- and we aren't expressing that dependency anywhere
<kees> jdstrand: *nod*
<jjohansen1> yep
<cjwatson> soren: ah. weirdness. /proc needs to be mounted or java gets its search path wrong ...
<mdeslaur> kees: parser or just modify the init script for now?
<soren> cjwatson: Ah, yes, I've seen this before.
<kees> mdeslaur: parser
<Keybuk> pitti, tkamppeter: if we start udev-configure-printer from an Upstart job, we can do things like
<jdstrand> modifying the initscript would be valid as a last resort though
<pitti> Keybuk: is that better? http://paste.ubuntu.com/271508/
<Keybuk>   start on started cups and lp-device-added
<Keybuk> ie. udev-configure-printer is *delayed* until cups is started
<Keybuk> pitti: that will do for now.  I'll rip all this out post-alpha-6
<slangasek> pitti: seen thta language-support-input-ja Depends: kasumi, which is in universe?  can we pre-promote that (MIR is open), or revert this in language-support-input-ja, so we can have DVDs build for A6?
<jjohansen1> jdstrand: modifying the parser is easy
<jjohansen1> jdstrand: there is already code doing some "version" checking, we just need to augment it
<jdstrand> jjohansen1: I assigned the bug to you for now, based on my recollection of the conversation the other day. if someone else will be doing the modification, please reassign
<pitti> Keybuk: right, it's just a quick fix; separate upstart job sounds good (but introduces a delta to Debian)
<Keybuk> pitti: delta to Debian are not bad
<pitti> tkamppeter: could you please verify that this http://paste.ubuntu.com/271508/ still works?
<Keybuk> they're inevitable when shipping anything involving init or udev for the time being
<Keybuk> though Debian is catching up :)
<jjohansen1> jdstrand, kees: what kind of failure message are you looking for
<slangasek> is the sysvinit upstart-job coming together?
<Keybuk> slangasek: ?
<pitti> Keybuk: well, in the case of cups I care, since I maintain it in Debian as well :) but we can certainly figure something out with lsb_release checking (as I already do on some other places)
<slangasek> Keybuk: the compat wrapper that's the blocker for starting to ship upstart jobs in Debian packages?
<Keybuk> pitti: right, that's what I was thinking
<Keybuk> slangasek: nothing to do with me
<jdstrand> jjohansen1: I don't suppose it is possible to run in a degraded mode, is it? (we talked a bit about that too I thought)
<slangasek> well, you said Debian is catching up, so I thought you might know :P
<slangasek> apparently it was just an empty platitude though :-P
<Keybuk> slangasek: according to linux news sources, Debian have announced that they'll switch to Upstart
<Keybuk> this is "catching up"
<Keybuk> ie. we won't have a significant delta in the choice of our init system ;)
<slangasek> yes, they'll switch once upstart-job is done. :)
<jjohansen1> jdstrand: for karmic to jaunty, almost
<Keybuk> slangasek: which is something someone in Debian is doing
<Keybuk> I'm not a Debian Developer
<jjohansen1> jdstrand: there are just a couple little things that can cause problems
<Keybuk> nor do I follow Debian development
<Keybuk> I have far too much Ubuntu development to follow ;)
<jjohansen1> jdstrand: it is possible to do a simple degraded mode
<jdstrand> jjohansen1: I ask because, while it is cryptic, we already have an error message. I wouldn't want the new message to be equally confusing
<jjohansen1> jdstrand: yeah
<jdstrand> we could probably come up with something though...
<jdstrand> kees, mdeslaur: what do you think? ^
<jjohansen1> jdstrand: I think the only thing that would have to fail would be the regexp based profile names, and that could be silent or a warning
<kees> jjohansen1: "Current kernel version does not support Xyz, ignoring." or something?
<jjohansen1> kees: no
<jdstrand> kees: well, it fails for *all* profiles afaict
<jdstrand> if we fail, it should be for profiles using unsupported features
<jjohansen1> jdstrand: that is because the parser is putting caps64 in each profile
<jjohansen1> jdstrand: it doesn't have to do that
<pitti> slangasek: pre-promoting kasumi sounds fine (done), I'll update the MIR bug
<jdstrand> the others should theoretically be made to work
<slangasek> pitti: thanks
<EtienneG> cjwatson, re: default config in eucalyptus; I think the previous situation was a bug (and a regression from jaunty).  Config *used* to have sensible default, but that was set in the postinst postinst
<jjohansen1> jdstrand: yep without caps64 they do
<jdstrand> jjohansen1: ah! so we can do a kernel check and add caps64 if it is supported?
<tkamppeter> pitti,
<tkamppeter> udevadm trigger --dry-run --subsystem-match=usb --attr-match=bInterfaceClass=07 --attr-match=bInterfaceSubClass=01
<cjwatson> EtienneG: I can't figure out whether you're agreeing with what I said or not :-)
<jjohansen1> jdstrand: yes
<tkamppeter> has no output for me.
<jdstrand> jjohansen1: could we then fail (with an appropriate message) for profiles that use an unsupported feature?
<jjohansen1> jdstrand: yes
<pitti> tkamppeter: ooh, of course; can you please add --verbose ?
<mdeslaur> jjohansen1: are there any unsupported features besides caps64 in the current profiles?
<mdeslaur> jdstrand: ^
<jdstrand> jjohansen1: would it be possible to also list in the error message the feature that isn't supported?
<jjohansen1> mdeslaur: yeah, pux, regexp profile names
<jdstrand> mdeslaur: yes, pux and binary globbing/regex
<jdstrand> basically, evince and firefox
<mdeslaur> jdstrand: oh, ok. so why don't we just bomb out with the clear error message kees gave. I'll only log it once.
<jdstrand> jjohansen1: I'm actually quite ok with failing gracefully in this way. if people are running an unsupported kernel, the error should let them know to adjust the profile if they are using an unsupported kernel
<jjohansen1> jdstrand: yeah it should be able to list what isn't supported.
<jdstrand> jjohansen1: the message just needs to be clear enough so that it isn't confusing on upgrade
<jdstrand> jjohansen1: I think kees' suggestion does that well
<mdeslaur> jdstrand: only logging once instead of logging for each profile would be nice
<jjohansen1> mdeslaur: that is harder
<jjohansen1> mdeslaur: we could modify the init scipt to quite after the first failure
<jdstrand> I actually think it needs to be for each profile
<jdstrand> that way, someone running an older kernel will know what is going on
<mdeslaur> jjohansen1: oh, I though it was the parser that now went through the directory. my bad.
<lool> ArneGoetje: ok thanks
<ogra> Keybuk, ??
<ogra> Keybuk, i committed before i even rolled the package
<jjohansen1> jdstrand: yeah, I think it is cleaner and you get exactly what failed, as opposed to a single failure killing all profiles
<jdstrand> also keep in mind, it should only be two profiles for jaunty -> karmic, and only one of those will be enabled
<jdstrand> (be default)
<jdstrand> s/be/by/
<slangasek> pitti, tkamppeter: any time we can stop getting conffile changes on /etc/cups/cupsd.conf would be lovely
<jjohansen1> jdstrand: uh isn't this case trying to load karmic profiles onto jaunty kernel
<jdstrand> jjohansen1: yes
<jjohansen1> so aren't we in the case of trying to load the full karmic profile set not just the 2 jaunty profiles
<jdstrand> jjohansen1: jaunty upgrade to karmic. apparmor userspace is upgraded, profiles load for everything else after. only evince will have an unsupported feature by default
<jdstrand> jjohansen1: all the other profiles aren't affected (once caps64 is fixed)
<jjohansen1> jdstrand: right, cause firefox is not enabled by default
<jdstrand> jjohansen1: exactly
<jdstrand> jjohansen1: I was assuming fixing caps64 was a given. sorry for the confusion
<ogra> Keybuk, hmm, i definately have the push in my bash history as well, but you are right, it doesnt show up on LP
<jjohansen1> jdstrand: yeah its a given
<mdeslaur> so, 1- kernel detection to fix caps64, and 2- more clear error message is profile is unsupported
<mdeslaur> s/is/if/
<jdstrand> that sounds perfect to me
<jdstrand> (sans typo :P)
<jjohansen1> mdeslaur: 1 - kernel detection, 2 caps64, pux, regexp profile name
<jjohansen1> mdeslaur, jdstrand: caps64 will have failure message if a profile uses cap mac_override
<jdstrand> jjohansen1: ok. we don't use it currently
<pitti> slangasek: perhaps we shouldn't make it a conffile any more at all; we can't really stop cupsd from writing it, we just try to not change it over time
<slangasek> pitti: I'm not concerned about cupsd writing it, I'm concerned about the fact that this is where I declare all my ACLs
<slangasek> so I get a conffile prompt every time
<slangasek> if there's another place that I can declare my ACLs that's not a conffile, I'll be happy to move them
<pitti> tkamppeter: does it work with --verbose?
<cjwatson> soren: eucalyptus-{sc,walrus} init scripts seem kind of busted. they just start/stop the cloud, as far as I can see!
<cjwatson> what are they supposed to do?
<soren> cjwatson: You might be fooled by the fact that eucalyptus-cloud is the bootstrapping thingamabob for all the java things?
 * soren takes a look, though.
<cjwatson> why are there three init scripts then?
<cjwatson> it's not called with substantially different arguments or anything
<cjwatson> it even uses the same pidfile in all three init scripts
<soren> The -sc script sets JAR_NAME=/usr/share/eucalyptus/eucalyptus-storagecontroller-1.6-devel.jar
<soren> Walrus sets it to something walrusy, I imagine.
 * soren checks that.
<cjwatson> yes, but it doesn't actually do anything with that other than checking that it's present
<soren> Oh.
<soren> Oh, dear.
 * soren facepalms hesitantly.
<soren> cjwatson: From the looks of it... "eucalyptus-walrus start" will copy the walrus jars to somewhere magical, and restart "the container".
<soren> cjwatson: Similarly for the other java based things.
<cjwatson> I don't see it copying anything
<cjwatson> oh, enable_disable_service
<cjwatson> wow, that's special
<soren> Yes.
<soren> Yes, it is.
<cjwatson> do_stop is really quite wrong though, it stops the whole cloud
<cjwatson> I'd argue that if there's a local cloud controller then do_stop should probably do nothing for the other Java components
<cjwatson> unless there's some other way to stop the components independently
<nixternal> any idea on how long the sysv, upstart, initscripts, and mountall will be fixed?
<cjwatson> nixternal: I think they should already be fixed ...?
<cjwatson> nixternal: -v
<nixternal> just waiting for them to build then...groovy
<cjwatson> they should already be built
<cjwatson> what is your problem?
<nixternal> amd64
<nixternal> mountall isn't building according to LP
<cjwatson> always pays to be specific :)
<soren> cjwatson: Yes, do_stop is definitely wrong.
<cjwatson> nixternal: I'm about to do a mass give-back of all the packages affected by this breakage
<tkamppeter> pitti, now I have added --verbose, and udev-config-printer gets started for each USB printer, but with the following error:
<tkamppeter> Sep 15 17:43:31 till-laptop udev-configure-printer: add /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.2/3-1.4.2:1.0
<tkamppeter> Sep 15 17:43:31 till-laptop udev-configure-printer: unable to access /sys/sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.2/3-1.4.2:1.0
<nixternal> cjwatson: sounds like a ton of fun :)
<cjwatson> nixternal: automatic
<nixternal> well then, that is no fun
<cjwatson> or at least it will be if I can find the relevant script
<nixternal> hehe
<pitti> re; sorry, dist-upgrade killed my session and then I had to repair apt and packages
<cjwatson> Keybuk: is there a MIR for mountall? we'll need to get that reviewed quickly
<pitti> tkamppeter: oh, it seems it doesn't like getting the full path
<pitti> tkamppeter: if you replace "$printer" with ${printer#/sys} does it work then?
<Keybuk> cjwatson: does it need one?
<Keybuk> "I wrotez it, itz gud ya?"
<ion> keybuk: I installed a local build of mountall and upgraded. It seems the rcS.d fsck/mount scripts are active now and clash badly with mountall.
<Keybuk> ion: update initscripts too then, duh :p
<cjwatson> Keybuk: I'm not actually overly bothered myself ...
<cjwatson> pitti: do you care about a MIR for mountall?
<pitti> cjwatson: not really
<cjwatson> alright then
<pitti> I noticed that it was missing and holds back upstart, but I didn't see it in the archive, nor in NEW
<cjwatson> it's awaiting builds
<pitti> ah
<ion> keybuk: I should have the most recent versions of everything. initscripts 2.87dsf-4ubuntu2
<cjwatson> which is awaiting me beating ubuntu-dev-tools over the head suitably
<Keybuk> ion: 4ubuntu3 is the latest
<ion> Ah, mirror lag probably.
<Keybuk> ion: no, we're still picking pieces of the archive off the floor
<Keybuk> the buildds did their thing in a, err, sub-optimal order
<ion> Heh
<ion> Ok, apt-get update, and the new initscripts package is available now.
<cjwatson> Keybuk: what architectures is it safe to retry on?
<cjwatson> amd64 i386 sparc at least
<cjwatson> armel and powerpc look ok too
<Keybuk> i386 looks ok
<cjwatson> I'm guessing not lpia
<Keybuk> amd64 should be ok too
<Keybuk> lpia looks fucked yeah
<Keybuk> ia64 probably won't build upstart anyway still
<cjwatson> no, it's still stuck on 0.3.10 by the looks of things
<Keybuk> all the others look good to me
<Keybuk> cjwatson: yeah ;)  I had a strange feeling earlier, I thought I was caring about ia64, but then I realised I was just hungry
<NCommander> Keybuk, O_O;
<NCommander> Keybuk, aw, you should care about ia64, I like my desktop :-/
<pitti> Keybuk: odd, when I'm hungry I stop caring about i386 as well..
<tkamppeter> pitti, still does not work, I get now
<tkamppeter> Sep 15 18:02:36 till-laptop udev-configure-printer: add /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.3/3-1.4.3.3:1.0
<tkamppeter> Sep 15 18:02:36 till-laptop udev-configure-printer: parent devpath is /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.4/3-1.4.3/3-1.4.3.3
<pitti> tkamppeter: and that's wrong?
<tkamppeter> for each printer. A printer, manually disabled with the reason "Unplugged or turned off" does not get re-enabled by starting CUPS.
<NCommander> cjwatson, ubiquity question, ubiquity normally copies the vmlinuz files from the /casper directory, but on Dove, we currently don't have a vmlinuz file available for it to copy (we have a uImage which we can strip down to a vmlinuz). How the best way to deal with this; I'm kinda tempted to just have livecd-rootfs leave the vmlinuz files in place on dove as we did with older ubiquities, but there may be a better way to deal with it
<Keybuk> pitti: strangely, I still tend to use i386 rather than amd64
<pitti> Keybuk: new apport uploaded, should build now
<cjwatson> NCommander: can we just copy the uImage instead?
<NCommander> cjwatson, I'll have to extend install.py to strip the first 64 bites off the file to remove the header
<cjwatson> NCommander: ia64> port upstart, then ;-)
<pitti> Keybuk: at least, it won't FTBFS due to the broken version check
<cjwatson> NCommander: ick
<cjwatson> NCommander: you know, all of this is just a space optimisation
<Keybuk> pitti: :D
<cjwatson> NCommander: if it's simpler to have livecd-rootfs leave the vmlinuz in place, then I'd recommend doing that
<NCommander> cjwatson, thats probably ideally what we want to do, but this is "OMG, NEED IMAGE." mode right now
<NCommander> (that is, with stripping the header)
<Keybuk> cjwatson: actually it's deep pthready/libc issue
<Keybuk> ../dbus/.libs/libdbus-convenience.a(dbus-sysdeps-pthread.o): In function `_dbus_pthread_condvar_wait_timeout':
<Keybuk> ../dbus/.libs/libdbus-convenience.a(dbus-sysdeps-pthread.o): In function `check_monotonic_clock':
<Keybuk> /build/buildd/dbus-1.2.16/dbus/dbus-sysdeps-pthread.c:353: undefined reference to `clock_getres'
<Keybuk> /build/buildd/dbus-1.2.16/dbus/dbus-sysdeps-pthread.c:273: undefined reference to `clock_gettime'
<cjwatson> NCommander: then just hack it in livecd-rootfs
<Keybuk> (this is with -lrt)
<pitti> tkamppeter: hm, did that really work with the previous rule (without --dry-run)? It's doing exactly the same call to the script as the udev rule..
<NCommander> cjwatson, cool, just wanted to make sure ubiquity would still be happy in this configuration (I had checked the code, but wanted to make sure I didn't overlook something)
<tkamppeter> pitti, I do not really know whether the old rule worked. What should happen is http://paste.ubuntu.com/271539/
<EtienneG> cjwatson, total agreement, no worry there!
<EtienneG> anyway, gotta go!
<cjwatson> NCommander: yeah, it ought to be fine
<pitti> tkamppeter: if you revert to the old init script, stop your printers, and restart cups, it works?
<cjwatson> soren: also, uh, shouldn't do_stop actually kill $pid before it goes into the timeout loop?
<cjwatson> (in tools/eucalyptus-java-ws.in)
<tkamppeter> pitti, it seems that the "manual" call of "/lib/udev/udev-configure-printer add /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1.2/3-1.2:1.0" does nothing (manually on command line, with sudo, or from the CUPS init script), but the call done by udev has the desired effect of re-enabvling the printer.
<pitti> tkamppeter: does udev-configure-printer check any environment variables which might be set by udev? (it really shouldn't, though)
<soren> cjwatson: It really should do a lot of things differently, if you ask me..
<tseliot> slangasek: would it be possible to include a fix for bug 429241 in mesa despite the freeze?
<ubottu> Launchpad bug 429241 in xserver-xorg-video-intel "[GM45E] i915 graphics corruption and hang" [High,Confirmed] https://launchpad.net/bugs/429241
<tseliot> I wouldn't ask if it wasn't such a nasty bug
<cjwatson> soren: I'll fix that particular bug, but it sort of needs torn up and rewritten :-(
<soren> cjwatson: I agree.
<soren> cjwatson: Will you file a bug on the subject?
<slangasek> tseliot: if the upload is ready to go right now, yes please
<cjwatson> soren: ok
<tseliot> slangasek: yes, it is. I was waiting for your reply. Thanks
<soren> cjwatson: Thanks very much.
<tkamppeter> pitti, I have found the problem: There is the file /var/run/udev-configure-printer/usb-uris holding all device files and URIs of printers which are turned on, so doing a faked turn-off with cupsdisable does not work.
<pitti> tkamppeter: ah, so it was just a testing error?
<tkamppeter> Yes, pitti, now after also manually editing /var/run/udev-configure-printer/usb-uris to correctly fake the turn-off of the printer the start of CUPS enables it correctly.
<pitti> tkamppeter: rock, then I'll commit that; thanks a lot for testing!
<tkamppeter> pitti, so the correct coldplug function is http://paste.ubuntu.com/271554/
<pitti> tkamppeter: right, that's what I have now
<pitti> tkamppeter: pushed (thanks for your help, Keybuk)
<tkamppeter> pitti, slangasek told that there is always a conffile change in /etc/cups/cupsd.conf.
<pitti> tkamppeter: we should probably just stop treating this as a conffile
<tkamppeter> It seems that it is not such a good idea to use cupsctl in the initscript. Usually this should change the conffile only once, as the user does not change the ammount of memory in the computer all the time.
<pitti> tkamppeter: cupsd itself also changes it all the time, though
<tkamppeter> pitti, then this one cupsctl call should not be a problem.
<tkamppeter> How does CUPS itself change cupsd.conf (except of using cupsctl and similar user-initiated config tools).
<pitti> tkamppeter: the web UI, s-c-p configuration, etc.
<tkamppeter> pitti, but these are all configuration actions. The user changes the configuration, only he uses a GUI frontend.
<pitti> tkamppeter: right, I'm just saying that I doubt that there are many users out there who have an unchanged cupsd.conf
<tkamppeter> So then we must keep it being considered a conffile, as otherwise every CUPS update would reset it.
<pitti> tkamppeter: no, to the contrary
<pitti> tkamppeter: cups updates wouldn't update it any more, even if we change defaults (unless we explicitly use seddery)
<tkamppeter> pitti, how does this work? Does cups not contain cupsd.conf as a file?
<pitti> tkamppeter: we'd need to install it in /usr/share/cups/cupsd.conf.default, and only copy it to /etc on first installation
<tkamppeter> pitti, will this not cause any problem on a major version change (ex: 1.3.x -> 1.4.x) of CUPS?
<pitti> tkamppeter: well, it will cause problems either way, if the user keeps the old version and it becomes incompatible, he loses
 * apw wonders where the OSD people hang out
<int0x0c> I'm almost positive that last night's udev upgrade in karmic broke udev (effectively no modules are being loaded; e.g. intel_agp and psmouse are two notable cases)
<cjwatson> soren: bug 430163
<ubottu> Launchpad bug 430163 in eucalyptus "Cloud/Walrus/SC init script confusing" [Undecided,New] https://launchpad.net/bugs/430163
<int0x0c> that is udev-147~-1
<zyga> mvo: hey
<zyga> mvo: yesterday I managed to finish the stuff at API level, implementation is still lacking in the new areas we talked about yesterday but should be fully done by today
<zyga> mvo: I noticed that main got frozen today, that probably means that all the code done since then is not going to hit the master right? I'm fine with that because I hobby and deadlines dont mix very well, I'd like to track you with development and help however I can
<ion> keybuk: http://heh.fi/patches/mountall/ rebased onto the current mountall. Thereâs also a new patch that fixes a bug: if a udev event triggers a check for a device that has already been checked but that is waiting for the parent partition to be mounted, itâs possible for another check to be started.
<elops> Anyone know why file timestamps would be showing up as 'Ã Â¸.Ã Â¸' on an ext3 partition?
<ion> Your locales contain such characters and your terminal prints UTF-8 incorrectly.
<cjwatson> soren: is bug 426514 fixed now?
<ubottu> Launchpad bug 426514 in eucalyptus "eucalyptus-cc package (1.6~bzr645-0ubuntu2) code generated from older wsdl, causing runInstances and describeInstances to fail" [Undecided,New] https://launchpad.net/bugs/426514
<cjwatson> soren: it seems unlikely that that sort of thing would have survived an upstream update, but I'm not sure ...
<cjwatson> soren: huh - actually, I don't see a definition of adb_ccInstanceType_set_networkIndex here?
<elops> I thought it just showed question marks when the x attribute isn't set
<cjwatson> does debian/patches/01-wsdl-stubs.patch need to be updated?
<int0x0c> Can the udev scott james remnant ever be found around here?
<int0x0c> s/the udev//
<cjwatson> Keybuk: ^-
<cjwatson> (your friendly answering machine)
<ogra> you didnt beep :)
<cjwatson> BEEP
<ogra> heh
<cjwatson> int0x0c: (do be patient, BTW, IRC is not as real-time as it looks and it's fairly normal to have conversations with long time lags)
<madmike77_eee> I'm with a friend with a karmic alpha installation. We got a '/var/run/dbus/...' not found. Upon starting gdm manually we get a xorg-server but mouse and keyboard don't respond
<int0x0c> Is there any way to force dpkg to mark a package as configured?
<madmike77_eee> Also we have some packages on 'apt-get upgrade' (among those is upstart) that won't install because of missing dependancies
<cjwatson> int0x0c: in theory yes, but please don't - better to give Keybuk a chance to find out what's wrong with your system, when he's around
<cjwatson> madmike77_eee: upstart> that's known, we're in the process of fixing it
<madmike77_eee> cjwatson: okay
<Keybuk> int0x0c: what package is not configured?
<cjwatson> (I don't know about dbus)
<int0x0c> cjwatson: well, I'm fairly certain it's a completely recoverable failure
<madmike77_eee> cjwatson: do you think the problem with dbus is related to upstart?
<int0x0c> Keybuk: udev. It wants to `service restart udev`
<cjwatson> madmike77_eee: I don't know
<int0x0c> which is failing (which is clearly an issue)
<Keybuk> int0x0c: what wants to do that?
<int0x0c> Keybuk: udev's configure stage
<int0x0c> really throws a wrench into things
<Keybuk> int0x0c: yes, but if that does not succeed, it will not fail to configure
<Keybuk> int0x0c: grep restart /var/lib/dpkg/info/udev.postinst
<int0x0c> unfortunately, that doesn't seem to be true
<madmike77_eee> cjwatson: is it not fixed yet or just released yet? I guess my friend here would be willing to install a pre-release
<cjwatson> madmike77_eee: your friend will get it in karmic at the same time as everyone else :)
<cjwatson> madmike77_eee: the build process went a bit awry, and we're having to unstick the build servers by hand
<madmike77_eee> cjwatson: good news then :)
<int0x0c> Keybuk: msg'd
<int0x0c> Keybuk: sorry for the delay, not used to using irssi
<Keybuk> int0x0c: you have an old version of the udev package
<Keybuk> I'm not sure why it fails for you
<int0x0c> Keybuk: Yes, I tried downgrading after 147 failed
<int0x0c> Keybuk: I'll revert to 147
<MindVirus> You guys know that the latest update in karmic removes ubuntu-minimal, yes?
<Keybuk> yeah I think you fluffed the downgrade as well
<cjwatson> MindVirus: yep, it's being sorted
* Topic unset by Keybuk on #ubuntu-devel
<Keybuk> argh
<cjwatson> MindVirus: I hope it goes without saying that you should always carefully review the list of packages to be removed on any upgrade within a development release
<MindVirus> cjwatson: OK. What is approximate TTL?
<cjwatson> MindVirus: a few hours
<MindVirus> cjwatson: I am very aware. :)
* Keybuk changed the topic of #ubuntu-devel to: Archive: frozen for alpha-6,
<int0x0c> Keybuk: alright, yeah. My bad. I've reverted to 147
<cjwatson> well, depending on when my wife gets back and drags me off for dinner :)
* Keybuk changed the topic of #ubuntu-devel to: Archive: frozen for alpha-6, FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app developmen
* cjwatson changed the topic of #ubuntu-devel to: Archive: frozen for alpha-6, FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Keybuk> ah thanks
<int0x0c> Keybuk: configured succesfully
<MindVirus> cjwatson: great news.
<ion> keybuk: Did you notice my message? :-)
 * ogra grins
<MindVirus> cjwatson: thanks for your help. :)
<int0x0c> Keybuk: allow me to reboot and i'll see if this install went any better
* Keybuk changed the topic of #ubuntu-devel to: Neither karmic nor the buildds are in a happy place right now, things are being sorted | Archive: frozen for alpha-6, FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Keybuk> int0x0c: WAIT!
<Keybuk> oh, he left
<ogra> heh
<Keybuk> still, he won't be back
<ion> Hehe
<ogra> probably from the livecd he installed from
<directhex> i'm glad i didn't use last weekend to update to karmic!
<mvo> zyga: hey! yeah, main is frozen, I will do a upload today, but it will not include your work yet. I can only merge when I get the contribuor agreement
<zyga> mvo: I fully understand, arghh
<zyga> (corporate world issues)
<int0x0c> Keybuk: alright, we it seems that udev-147 is just generally broken when it comes to module probing
<int0x0c> Keybuk: Unfortunately, I can't directly confirm that as the downgrade path is broken
<Keybuk> int0x0c: no, just karmic is incomplete right now
<int0x0c> Keybuk: But it's the only package that has been touched recently that would cause this sort of failure, as far as I can see
<zyga> mvo: are you going to keep on hacking software-store even though we're past freeze?
<int0x0c> Keybuk: How so?
<zyga> (targeting +1)
<mvo> zyga: yes, a little bit at least, bugfixing is sitll permited :)
<Keybuk> int0x0c: don't worry about the why, it's just broken right now
<int0x0c> Keybuk: I don't mean to be difficult, but I am almost certain this is a udev issue
<Keybuk> it isn't
<int0x0c> Keybuk: Things are generally fine after I modprobe the missing modules
<int0x0c> Keybuk: Then what is the issue?
<ogra> flux :)
<int0x0c> Keybuk: I don't mind sitting down and debugging, but I need a little more to work with that "it's broken"
<zyga> mvo: and feature development/major stuff as outlined by the wiki/roadmap?
<Keybuk> we don't need you to debug
<madmike77_eee> do i have a chance to get the dbus up by hand?
<mvo> zyga: no, that will not be possible anymore
<ogra> int0x0c, there is a transition going on, its simply not complate yet
<ogra> *complete
<int0x0c> a transition from/to?
<ion> keybuk: In fact, you might want to apply the bug fix to mountall before Î±6, if thatâs possible. Itâs just af small additional check. Without it, it was possible for a second fsck to be launched in parallel with mount for a device, causing nasty errors.
<zyga> mvo: I'm not talking about stuff that goes for the release
<int0x0c> Is there a timeframe for completion?
<zyga> mvo: I'm strictly interested in stuff for +1, even +2
<cjwatson> int0x0c: we should get a lot more of it sorted out today
<int0x0c> the issue is, I'm trying to finish up an intel graphics patchset which will hopefully make it in before the merge window closes
<int0x0c> so time is a little tight
<mvo> zyga: oh, sorry. I don't have the capacity to work in parallel on two branches, but we can branch off a +1 and see how it goes :)
<int0x0c> cjwatson: alright
<cjwatson> once we get mountall built, things should trickle into place fairly quickly
<Keybuk> ion: what's the patch?
<int0x0c> cjwatson: ahh, alright
<ion> ti200151 < ion> keybuk: http://heh.fi/patches/mountall/ rebased onto the current mountall. Thereâs also a new patch that fixes a bug: if a udev event triggers a check for a  device that has already been checked but that is waiting for the parent partition to be mounted, itâs possible for another check to be started.
<ion> 0003
<zyga> mvo: I see, I think I'm happy with that answer, I was just interested in knowing if you are going to stop working on this because it's past freeze time and +1 opens in so-many-months from now that you don't care yet
<Keybuk> int0x0c: sorry, I don't mean to be rude, but we're very busy trying to sort out the problem
<int0x0c> I completely understand
<Keybuk> stopping to explain it, in detail, to everyone on IRC means we won't sort it out
<int0x0c> I'm satisfied
<int0x0c> sure
<Keybuk> it's karmic
<Keybuk> you're lucky it even boots
<int0x0c> yep, certainly
<Keybuk> in fact, you're lucky it doesn't run off with your daughter to the middle east
<mvo> zyga: its really a problem of time, if there are some people interessted in working on +1 while the current one is in fixing mode, that is absolutely fine
<int0x0c> thankfully, I don't have a daughter to run off with (that I know of)
<madmike77_eee> well since today it worked fine!
<Keybuk> ion: I don't see how you can get into that condition
<Keybuk> ion: it can double-check a partition, but I don't see that it can mount it?
<nixternal> 12:34:46 [    Keybuk] in fact, you're lucky it doesn't run off with your daughter to the middle east
<nixternal> ahh, so that's where she went
<ion> keybuk: run_mount doesnât seem to check whether a fsck is running. The first check calls device_ready(), later a udev event triggers the second check. Then the *parent* partition happens to get mounted and mountpoint_ready() is called. Now run_mount happily mounts the partition in question, with the second check running in background. That actually happened consistently and repatedly in my virtual machine.
<Keybuk> ah
<Keybuk> I see
<Keybuk> sure, will apply and upload once it's built and the mess has settled down
<Keybuk> thanks ;)
<madmike77_eee> is the build server back alive?
<tormod> keybuk, (boot ppa) there is no visual feedback when fsck is running
<ion> tormod: Thatâs a TODO item.
<cjwatson> oh, come ON launchpad
<cjwatson> madmike77_eee: working on it
<madmike77_eee> (dang it firend is chatting for me...)
<Keybuk> tormod: there should be in karmic proper, as a temporary measure I turned on output
<cjwatson> mountall publishing. dinnertime
<tormod> keybuk, stop cups is hanging here during package upgrade, want debugging?
<cr3> does dpkg -i file.deb, where an earlier version of file.deb was installed, do the same as apt-get upgrade or does it remove/install the package?
<slangasek> tormod: hmm, /stopping/ is hanging?
<maxb> cr3: it's pretty much the same
<cr3> maxb: ah, I was trying to reproduce an upgrade problem and it seems to only occur when a configuration file was changed from the maintainer version, so I wasn't actually testing the right problem. dpkg should indeed enable me to reproduce the problem if I modify the configuration file too :)
<tormod> slangasek: yes there was no cups process, but "stop cups" was hanging
<slangasek> tormod: after the init script has been replaced with a symlink, or before?
<tormod> later in the upgrade process X died (gdm restart?) so here I am in Jaunty :)
<tormod> slangasek: I lost patience and killed the "stop cups" so I can not tell
<slangasek> gdm restart> fagh, the maintainer script is supposed to do a reload
<slangasek> tormod: difficult to debug, then.  I'll check whether it's reproducible here
<slangasek> well, no
<tormod> last thing in dpkg.log is "status unpacked cups 1.4.1-1"
<slangasek> the version of cups in the archive is still 1.4.1-1
<slangasek> which doesn't include the upstart job
<slangasek> so look to pitti/tkamppeter for answers, not Keybuk :)
<madmike77_eee> is there a dbus update avaliable?
<tormod> ok I thought I had cups from the boot ppa...
<slangasek> tormod: oh
<slangasek> in that case, no debugging needed
<slangasek> because cups in karmic is supposed to be replaced shortly with one that switches it back to the upstart job, and upgrading from the boot-ppa to a non-upstart cups package isn't really supported
<tormod> yes that seems like what happened
<tormod> same goes for gdm...
<tormod> it is not so easy to upgrade stuff in a chroot any longer... "start: Unable to connect to Upstart:"
<slangasek> tormod: oh, ick
<slangasek> tormod: workaround: install a /usr/sbin/policy-rc.d in the chroot which consists of "#!/bin/sh\n\nexit 101"
<slangasek> (and executable)
<tormod> thanks!
<slangasek> tormod: but please file a bug against upstart about this blowing up in chroot
<slangasek> upstart-job will need to handle that case gracefully
<pitti> tormod: that's what might have happened to me, too
<pitti> got the boot PPA, then installed a local non-upstartified cups again for testing, then got re-upstartified
<tormod> is the policy-rc.d used only when upgrading or should I remove it again before trying to boot?
<lool> pitti: Just a heads up on my latest comment on kasumi in 424238
<slangasek> tormod: the policy-rc.d is only used by invoke-rc.d, which is specific to maintainer scripts, yes
<slangasek> tormod: you /should/ remove it so that future upgrades work correctly, but it won't prevent you from booting
<tormod> slangasek: filed bug #430224
<ubottu> Launchpad bug 430224 in upstart "blows up package upgrades in a chroot" [Undecided,New] https://launchpad.net/bugs/430224
<Keybuk> in chroots, divert initctl to /bin/true much as you'd direct invoke-rc.d
<Keybuk> I thought lamont had already done the update to make that happen
<Keybuk> it's certainly been applied to buildds
<mathiaz> pitti: thanks! :)
<slangasek> Keybuk: "the update"?
<Keybuk> slangasek: whatever one needs to change to make that true
<slangasek> Keybuk: upstart needs to work in arbitrary end-user chroots, not just on the buildds
<lamont> yep...  applied to the builds
<slangasek> (including, in this case, when one is chrooted to the root system for rescue)
<Keybuk> slangasek: like I said, divert initctl to /bin/true
<Keybuk> that disables starting or stopping like policy-rc.d does
<slangasek> Keybuk: ... no
<madmike77_eee> the new upstart packages and mount all gives karmic  the rest...
<lamont>         dpkg-divert --local --rename --divert /sbin/initctl.real /sbin/initctl
<lamont>         ln -s /bin/true /sbin/initctl
<Keybuk> slangasek: I'm not sure what you mean by "no", it works
<madmike77_eee> uhm
<lamont> slangasek: and then policyrcd-script-zg2 ++ for the rest of the love
<madmike77_eee> we got a black screen without a working terminal after the latest upstart mountall upgrade
 * madmike77_eee is open for ideas
<Keybuk> madmike77_eee: see topic.
<slangasek> Keybuk: I mean I don't think it's acceptable for upgrades in chroots to /fail/ without using policy-rc.d or diverting initctl
<Keybuk> slangasek: err, I still don't follow, sorry
<slangasek> Keybuk: AFAICS you're saying the solution to upgrades in chroots breaking is "do this manual thing in the chroot"
<slangasek> I'm saying it's a bug in upstart that this is necessary
<Keybuk> slangasek: you have to do the same for sysvinit ?
<slangasek> nope
<Keybuk> you do, otherwise policy-rc.d doesn't exist
<slangasek> you only have to do that for sysvinit if you want services to not be started in the chroot
<Keybuk> oh, you mean that Upstart in general can't run services inside a chroot?
<Keybuk> that's a known flaw - and on the todo to fix
<slangasek> right, that :)
<Keybuk> it's no different than sysvinit really
<Keybuk> sysvinit can't start getty in a chroot
<slangasek> or, barring that, divining that it's in a chroot and failing gracefully when called by upstart-job
<slangasek> Keybuk: I don't start getties from maintainer scripts on upgrade either, though :)
<Keybuk> the problem is that Upstart itself doesn't support services in chroots
<Keybuk> it can't see the conf files, for a start
<Keybuk> and wouldn't know to "chroot" them
<Keybuk> likewise, it has the same problem with services in different pid namespaces
<madmike77_eee> Keybuk: any chance to revive this currently bricked netbook? Any magic Keyboard-foo?
<Keybuk> madmike77_eee: I'm busy.
<tag> What version of evolution and libmapi are in the latest ubuntu?
<tag> karamic koala, as it is
<bgamari> tag: http://packages.ubuntu.com/
<bgamari> use it
<Keybuk> slangasek: I've given everything back now
<Keybuk> hopefully this lot will build ;)
<Keybuk> I shall go and eat some dinner
<Keybuk> and then I'll come back, and put out any more fires that I find ;)
<bgamari> Keybuk: Thanks for your work
<bgamari> It's appreciated
<Keybuk> madmike77_eee: without knowing why it's hung, it's hard to debug - best thing is to plug a wired network cable in
<Keybuk> madmike77_eee: boot with "init=/bin/bash" instead of "quiet splash"
<soren> cjwatson: bug 426514 should be fixed, yes.
<ubottu> Launchpad bug 426514 in eucalyptus "eucalyptus-cc package (1.6~bzr645-0ubuntu2) code generated from older wsdl, causing runInstances and describeInstances to fail" [Undecided,New] https://launchpad.net/bugs/426514
<Keybuk> madmike77_eee: mount -o ro,remount / ... modprobe <your network card> ... dhclient eth0 ... apt-get update ... apt-get dist-upgrade
<madmike77_eee> Keybuk: Right now we can't enter into the grub2 menu
<Keybuk> madmike77_eee: (in a few hours when the archive settles)
<Keybuk> madmike77_eee: hold down SHIFT
<bgamari> Keybuk: These built packages won't be directly incorporated into the archive, right?
<Keybuk> bgamari: yes
<soren> cjwatson: Thing is, we regenerate the C stubs for their wsdl's until they release an actual tarball, and sometimes they update the wsdl without notifying me, so I didn't regenereate the C stubs.
<Keybuk> they will
<bgamari> ahh, alright. Thanks.
<Keybuk> from german import doch
<Keybuk> ;)
<cjwatson> soren: we can't do it at build time?
<soren> cjwatson: No. That would pull a ton of stuff into main that we don't want.
<soren> cjwatson: As I said: This is only until they release an actual tarball.
<soren> cjwatson: It's a mess, I know.
<J_P> hi all
<J_P> people, I want change time 60s when  power button is pressed. Or just power down without wait anytime. I try System > Preferences > Power Management (or Screensaver > Power management) > General > Select what to do "when power button is pressed" I select (shutdown). but not works. I press power button and show message 60s to shutodown.
<J_P> any idea?
<J_P> Or just, where i configure that 60s ?
<mneptok> J_P: this channel is ot for Ubuntu support.
<mneptok> *not
<mneptok> J_P: please read the /topic, as Pici asked.
<J_P> mneptok: Pici tell to go here.. So, what is correct channel to this question?
<mneptok> J_P: this one.
<J_P> mneptok: I think any developer know where that 60s is configurable.
<mneptok> J_P: it's not the job of developers to answer support questions from end users
<J_P> mneptok: ok, sorry
<cjwatson> personally I have no idea where that is configurable :-) I'd have to spend a fair amount of time looking it up
<cjwatson> no doubt *somebody* knows offhand
<soren> J_P: I'm a developer and I have no clue where to configure that.
 * Keybuk doesn't even know whether it *is* configurable
<cjwatson> we don't necessarily all know the ins and outs of every single package in the archive, although given time we can usually find out
<cjwatson> but really support channels are better for that
<J_P> ok, thanks all :-)
<kirkland> NetworkMangler appears foobar'd
<J_P> good works for all :-)
<Keybuk> kirkland: see /topic
<kirkland> Keybuk: gotcha, thanks.
<Daviey> you could update the po to remove the timer :)
<cjwatson> Keybuk: initscripts is still kept back here
<cjwatson> though mountall is now installable
<sebner> cjwatson: you can force install and remove half of the system though :P
<cjwatson> sebner: thanks, can I talk with the relevant developer to actually fix the problem now?
 * cjwatson doesn't really need clever remarks
<sebner> sure
 * sebner hides
<cjwatson> we know the archive is busted
<cjwatson> sorry, it's just getting into my evening and I don't want to finish until the archive is working again
 * Keybuk looks forlornly at his uncooked dinner
<cjwatson> ah, probably need to get udev built
<Keybuk> possibly
<Keybuk> I gave everything back about 20 minutes ago
<cjwatson> yeah, but the chroots need to be fixed first
<Keybuk> yes
<cjwatson> lamont's doing that
<Keybuk> initscripts Breaks udev
<Keybuk> the chroots seem fine now
<cjwatson> will udev be able to build without manual intervention?
<cjwatson> by "fixed", I mean "put back to non-frobbed state"
<Keybuk> let's see
 * Keybuk bumps the score
<Keybuk> util-linux certainly built ok
<Keybuk> Please try again
<Keybuk> Sorry, there was a problem connecting to the Launchpad server.
<cjwatson> when we have to build stuff manually, we (1) put buildds on manual (2) upload frobbed chroots that behave however we want (3) build ONLY the things that we need to build (4) put the chroots back (5) test run something (6) put buildds back on auto
<Keybuk> GODS DAMNIT LAUNCHPAD
<cjwatson> we're at (4)
<cjwatson> so please don't push packages through until that's done
<Keybuk> oh, too late ;)
<cjwatson> are you putting buildds back on auto?
<Keybuk> no, not touching them
<cjwatson> ok, don't :-)
<Keybuk> I just queued things for when they were
<cjwatson> right, that's fine
<Keybuk> that's what I thought
<cjwatson> as long as they stay on manual until the chroots are restored to normal
<Keybuk> phew ;)  you had me worried there
<lamont> cjwatson: the normal chroots are all active now
<cjwatson> excellent
<cjwatson> Keybuk: what did you score up, and to what?
 * cjwatson wants to make sure he has the ordering right
<Keybuk> there shouldn't be an ordering now
<Keybuk> once upstart, sysvinit and debhelper are built, everything else will work ok
<cjwatson> ok, why don't we do udev first since it's actually breaking stuff
<Keybuk> err I mean mountall
<Keybuk> it was just the unexpected problem with sysvinit being upgraded while trying to build upstart ;)
<Keybuk> "21000" ?! :)
<Keybuk> is that Colin priority
 * lamont uses 5555555
<cjwatson> 20000 is my usual "build FIRST, damnit"
<Keybuk> I tend to use 10000, and it doesn't give me a value less than a minute, 100000 ;)
<cjwatson> but I'd already used that
<cjwatson> oh, the times are sometimes a bit made up
<pitti> "sometimes" is a neat euphemism
<Keybuk> yeah but they're a good indication
<cjwatson> gah, os-prober is building anyway
<cjwatson> oh well
<Keybuk> armel failed - chroot problem
<Keybuk> lpia failed - chroot problem
<Keybuk> sparc failed - chroot problem
<lamont> udev?
<Keybuk> lamont: yes
<Keybuk> powerpc looks like it's building
 * Keybuk sees apt output
<cjwatson> right, so the arches that fail will need manual bootstrapping again
<cjwatson> sysv-rc back on hold ...
<Keybuk> WTF powerpc failed
<Keybuk> dpkg-source: error: Files field contains invalid filename `udev_147~-1.tar.gz'
<cjwatson> lamont: would you do the honours?
<lamont> cjwatson: I'm lazy.  all of them have it on hold, as of about 60 sec from now
<lamont> the script kinda prefers to do all 7
 * Keybuk declares this to be dinner time
<cjwatson> Keybuk: double wtf, I can't see that message in dpkg
<Keybuk> no, quite
 * cjwatson tries on i386
<Keybuk> amd64 seemed to build it ok ;)
<lamont> all held
<lamont> well, now that I look, I see they are, anyway... prolly for a few
<cjwatson> Keybuk: oh, that's the dpkg-source in the base
<cjwatson> lamont: don't suppose we can do anything about powerpc's old base system? its dpkg-source doesn't like udev's version number
<cjwatson> Keybuk: powerpc may be a tad buggered for a while but this is a powerpc-specific problem
<lamont> cjwatson: not easily, no.
<lamont> unless you wanna claim support for hardy/ppc... :-)
<ikonia> poison challace
<lamont> or bless a dapper backport of apt and enough else...
<lamont> OTOH, I thought apt was just running inside the chroot at this point
<cjwatson> it appears not to be when unpacking the source package
<cjwatson> maybe it is when installing build-dependencies?
<lamont> quite possible, that
<cjwatson> dear huito, get on with it
<lamont> it has to _THINK_ about thinking
<cjwatson> does it require integral calculus or something?
<cjwatson> udev/i386 built anyway
<lamont> well, it is armel.  with swap-over-USB
<cjwatson> lamont: do I need to try a different buildd? it's been five minutes ...
 * lamont looks in on hito
<cjwatson> and now it starts building util-linux!
<cjwatson> silly thing
<lamont> well... it's that download of all the packages that are out-of-date
<cjwatson> we'll need rsyslog as well, I'll score it up
<lamont>  41 upgraded, 4 newly installed, 0 to remove and 3 not upgraded.
<lamont> cjwatson: hence once we get this all sorted, I'd like to dist-upgrade the chroots while it's fresh-n-unbroken-and-known-goodish
<lamont> it doesn't make much of a diff on amd64, but it definitely makes armel slower
<cjwatson> err, jambul is building udev
<cjwatson> I didn't touch it. why's it on auto?
<lamont> gar.  that's my bad
 * cjwatson manuals it
<lamont> me too.
<smoser> has anyone done a fresh install today ?
<lamont> it was down/deactivated due to being cranky.  that got fixed a bit ago and I activated it, _thought_ it was already manual
<lamont> smoser: I wouldn't recommend it
<davmor2> smoser: yes thanks
<smoser> i'm trying to do a vmbuilder build, and its failing
<smoser> 2009-09-15 20:41:11,392 DEBUG   : I: Configuring libc-bin...
<smoser> 2009-09-15 20:41:11,574 DEBUG   : W: Failure while configuring base packages.  This will be attempted 5 times.
<lamont> smoser: see /topic
<cjwatson> smoser: the world is broken, too many things known broken to make it worth debugging :)
<cjwatson> we'll fix the things we know about and then see what's left
<smoser> but i need to do something :)
<davmor2> :)
<smoser> thanks everyone
<lamont> cjwatson: /usr/bin/xsltproc -o udev/udevadm.8 -nonet http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ../udev/udevadm.xml <-- there's a certain amount of eye stabbing there.
<cjwatson> lamont: is that breaking something?
<lamont> no
<lamont> I just generally find eye-stabbing in builds referencing URLs outside the world
<cjwatson> it's -nonet though
<lamont> OTOH, sourceforge.net is NXDOMAIN for the buildds...  so I WIN in any case
<lamont> and through it all, openjdk slogs along
<lamont> Keybuk: what's the util-linux change?
<madmike77_eee> Keybuk: Just for the record: we installed the packages from the ubuntu-boot ppa and everything is up and running now. Thanks for the help ;)
<Keybuk> lamont: will tell you later, or read ubuntu-devel scrollback
<fta> could someone please help with bug 399938? it doesn't seem to be bzr-builddeb at all, not even python. all pipes seem broken in some situations
<ubottu> Launchpad bug 399938 in bzr-builddeb "unpacking the upstream tarball not working" [Undecided,Fix released] https://launchpad.net/bugs/399938
<cjwatson> udev/rsyslog publishing now on as many architectures as I could manage
<lamont> cjwatson: actually, I'm going to need to run and fetch my daughter in about 20 min - will the publisher be done by then?
<slangasek> unlikely
<lamont> hrmpf.  well, I'll be back online at around 2240 london for about 20 min, then hard EOD
 * slangasek nods
<cjwatson> lamont: anything we can do without you?
<cjwatson> e.g. with a different GSA?
<cjwatson> lamont: actually, maybe you could put the chroots back now
<cjwatson> I'm expecting to at least try some normal builds after this publisher run finishes
<lamont> cjwatson: yeah - I spewed the command sequence in the other channel
<lamont> with new== held, old == normal
<lamont> so... normal chroots uploading
<cjwatson> ok, so we can flip back and forward
<cjwatson> cool
<lamont> cjwatson: yeah... I'm to familiar with this to not have both sitting around
<bgamari> seems like initscripts is still being held hack here; is this expected?
<cjwatson> bgamari: yes
<cjwatson> lamont: hmm, amd64 armel lpia sparc still need hostname fixed. any chance at all of using the held chroots on just those architectures?
<bgamari> alright, fair enough
<cjwatson> I'd like to get i386 moving if possible, you see ...
<lamont> hostname the package?
<lamont> cjwatson: I find that letting arch-all get ahead is sometimes hurtufl
<lamont> but yeah, we could do htat
<cjwatson> hmm
<cjwatson> I guess I don't mind another <hour
<cjwatson> ok, just slam all arches back to held please :-/
<cjwatson> lamont: can you brief the other GSAs that I'm likely to need some stuff done on cesium as well, please?
<lamont> yeah - been chatting some
<Mabo> hi
<cjwatson> lamont: can you confirm that all architectures are now using the held chroots?
<cjwatson> just before you go ...
<lamont> everything is using the unheld
<lamont> did you need it back to held?
<cjwatson> yes please
<lamont> cjwatson: I didn't prep them with the smarts around only hold/unholding a subset of architectures, though looking at the script should make it obvious... :-)
<lamont> cjwatson: and any GSA or LOSA
<lamont> all are held version now
<cjwatson> nah, we'll just do all arches concurrently
<cjwatson> thanks
<lamont> yeah - I figured as much, so didn't worry
<lamont> SUITE=${SUITE:-karmic}
<lamont> ARCH=${ARCH:-"amd64 armel i386 ia64 lpia powerpc sparc"}
<lamont> total hack
<lamont> cjwatson: and on that note, off to stay out of trouble with my wife and kids
<cjwatson> do :)
<cjwatson> thanks for your help
<Keybuk> lamont: still having trouble with the builds? :)
<slangasek> he is not, he's left the trouble to others. :)
<cjwatson> I'm still hand-holding
<cjwatson> but we're getting there
<Keybuk> oh, sorry, I'd read that *you* were playing with your wife and kids ;)
<Keybuk> I'm honestly surprised they've dug themselves this deep into the ground
<cjwatson> I'm watching Angel, as it happens, but that doesn't prevent a laptop beside me :)
<cjwatson> it's just that most of initscripts' Breaks weren't satisfied
<cjwatson> the last of them (I hope ...) is publishing now
<Keybuk> I guess a more interesting question is how to avoid doing this next time ;)
<slangasek> there's going to be a next time?
<slangasek> :P
<robbiew> heh
 * robbiew gets up off the floor
<Keybuk> slangasek: well, yes.  there's more of sysvinit to be replaced between now and karmic+1
<robbiew> oh...whew
<Keybuk> at the moment it looks like that both upstart and sysvinit have to go in the same publishing run?
<Caesar> slangasek: has a decision been made on if 10.04 will be LTS yet?
<slangasek> Caesar: yes, 10.04 is the LTS
<Caesar> Great, thanks
<samba> hi all - i'm new around these parts - anyone here knowledgable about the inner workings of Casper, for Live media installations? (Or should I go looking elsewhere?)
<robbiew> samba: #ubuntu-installer
<samba> robbiew, thanks
<robbiew> np
<samba> (what i'm looking for isn't specifically installation, but they'll likely know a bit anyway...)
<pimbuntu> hi... i read in the topic there are issues with karmic
<pimbuntu> however i already rendered my system unuseable with safe-upgrade
<pimbuntu> is there a way to revert back to a specific release-point to get a useable system?
<pimbuntu> i have a live-cd booted right now and some hint on using aptitude would be enough
<slangasek> pimbuntu: best way out is forward, but that will require a bit of patience as the packages needed to fix it aren't all published yet
<pimbuntu> slangasek, can you estimate the time it'll take? More in the range of minutes, hours or days?
<slangasek> pimbuntu: hours
<pimbuntu> as i need the box quite urgently
<pimbuntu> ok
<pimbuntu> can i help? :)
<Keybuk> pimbuntu: there's not much anyone can do to help
<Keybuk> the problem is that a set of packages needed to be updated as a group
<Keybuk> and our build daemons can only update them one at a time
<Keybuk> so after the first package, they broke in such a way that they couldn't build the rest of the group
<pimbuntu> ok...
<pimbuntu> is there a way/trick to tell aptitude/apt-get to install whatever version it finds on the cd of those packages installed?
<Keybuk> pimbuntu: yes you can use pinning
<Keybuk> pimbuntu: another trick people are using is to install from the ubuntu-boot PPA
<Keybuk> that has the packages that went into the archive
<Keybuk> but already built
<ion> pimbuntu: For a box that might be needed urgently, a development version of a distro might not be the best choice.
<pimbuntu> yes, i know
<sebner> Keybuk: udev, initscripts, rsyslog just came over update fYI
<pimbuntu> ion: it's a long story, but in the end, the latest version of the fglrx-driver crashed and somehow rendered my encrypted pv unusable. Therefor i gave karmic a try and it looked quite stable until now.
<ScottK> ion: Thanks.  I was resisting making such a comment.
<Keybuk> huh
<Keybuk> I'm so used to Ubuntu, I just plugged an ethernet cable into a Windows laptop and *expected* it to do the right thing
<sebner> lol
<sebner> Keybuk: is there anything else to come over update or can I safely shut down my laptop? ;)
<Keybuk> sebner: quite a bit yet
<sebner> so it'll break?
<Keybuk> no idea
<sebner> heh
<sebner> does hibernating avoids that?
<cjwatson> I *think* we may be able to start autobuilding again now, but I want to verify that
<ion> If it breaks, you should be able to fix it the usual way. :-)
<pimbuntu> Keybuk, i added the ubuntu-boot ppa and now it's installing so i hope for the best. :)
 * Keybuk debates trying to install Slow Leopard onto an XPS m1330
<apw> Keybuk, heh a few problems remain then huh
 * cjwatson test-builds springlobby
<cjwatson> powerpc is still going to be broken for some time, unless we can get a udev release without ~ in its version :)
<squirrelpimp> <- pimbuntu : It did not work
<squirrelpimp> :(
<Keybuk> cjwatson: we'll have one of those next week
<cjwatson> (or somebody arranges for launchpad-buildd to extract the source in the chroot rather than in the dapper base system ...)
<Keybuk> the plan is that we're testing udev 147, kay and I will fix the issues next week then release
<cjwatson> a respectable selection of buildds are now back on auto, and I've asked IS to flip the switch en masse
<cjwatson> since there are some that seem to break when I try to do it in the UI
<cjwatson> publisher is back on auto
 * Keybuk adjusts some priorities
<squirrelpimp> what else can i try, if dist-upgrade from ppa didn't work?
<Keybuk> squirrelpimp: patience
<squirrelpimp> ah, i saw that one coming
<squirrelpimp> :)
<Keybuk> cor
<Keybuk> I think that was everything i386 built then
<davmor2> Keybuk: I refuse to believe you until I see iso's
<Keybuk> davmor2: that's Thursday
<davmor2> NNNNNNNOOOOOOOO!!!!!!!!!!
<slangasek> ISOs better be here before Thursday :-P
<maxb> so how long for amd64 then?
<maxb> Any chance of getting the second builder off manual sooner rather than later? :-)
<davmor2> maxb: well 64 is twice 32 so twice as long ;)
<cjwatson> maxb: IS is on it
<cjwatson> maxb: I couldn't make it work via the UI
<jdub> where's the "zomg, new init, eek!" conversation happening? :-)
<cjwatson> jdub: everywhere
<jdub> :-)
<jdub> oh, buildds not happy either? perfect storm!
<Keybuk> cjwatson: it would be SO NICE if we could just copy packages from PPA to archive like we can between PPAs
<Keybuk> jdub: the buildds not being happy is the basic source of the problems
<cjwatson> actually, the buildds are moderately sorted now
<cjwatson> Keybuk: yeah, the problem is that PPAs can build with all kinds of sources
* cjwatson changed the topic of #ubuntu-devel to: karmic is not in a happy place right now, things are being sorted | Archive: frozen for alpha-6, FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<Daviey> PPA's can also use itself as a build deps.
<jdub> Keybuk: is this a useful spot to report problems along the way?
<Keybuk> jdub: no, not really ;)
<cjwatson> maxb: they should all be back on auto now
<cjwatson> http://paste.ubuntu.com/271737/ fixes the dpkg problem on powerpc, fed to lamont
<jdub> Keybuk: just noise in general at this point, or is there a better spot?
<Keybuk> jdub: noise in general
<jdub> ok
<Keybuk> if you rebooted without all the bits, I can believe that things didn't work out for you
<maxb> :-)
<jdub> pretty sure i have all the bits (no depends issues), but mountall is failing
<Keybuk> how is mountall failing?
<jdub> (which was described as general failure, returned 1)
<Keybuk> what is on screen above that?
<jdub> sec, just switching to irssi on tv
<jdub> moutnall start/running, process 1628
<jdub> init: moutnall main process (1628) terminated with status 1
<Keybuk> no output from mountall itself?
<jdub> not after ctrl-d at least... i'll reboot again
<Keybuk> also dpkg-query -W mountall
<jdub> (fading usplash is spiffy, btw)
<jdub> nothing above that
<jdub> mountall 0.1.3
<Keybuk> odd
<Keybuk> run mountall --verbose from your own shell
<Keybuk> anything?
<jdub> virtual fs finished
<jdub> remote finished
<jdub> (btw, i'm dumped to a ro root which is marked as rw, but otherwise correct)
<Keybuk> does that exit?
<jdub> yes
<Keybuk> what's the message before it exists?
<jdub> 1 as status
<Keybuk> exits I mean
<jdub> nothing, that was all the output
<ion> --debug?
<Keybuk> try --debug ?
<jdub> aha :-)
<cjwatson> oh, hmm, I'd better put powerpc back on manual I guess
<Keybuk> cjwatson: could we not put powerpc under six feet of dirt with daisies growing on top?
<jdub> well, that's very verbose
<cjwatson> *blink* it seems to be building, actually
<cjwatson> I guess I'll let it
<Keybuk> cjwatson: what could *possibly* go wrong? :)
<cjwatson> well, if it builds at all, it's probably ok
<cjwatson> if anything's wrong it'll just fail to upgrade right at the start
<jdub> Keybuk: what can i provide from the --debug output?
<Keybuk> jdub: can you take a picture?
<jdub> oh, i can bring up network and put it somewhere
<jdub> http://www.gnome.org/~jdub/2009/mountall-debug.txt
<Keybuk> interesting point to fail
<Keybuk> jdub: stupid question, did you boot with an initramfs
<Keybuk> ?
<jdub> yeah
<Keybuk> ls /dev/.initramfs/varrun
<Keybuk> do you have that directory?
<jdub> nup
<Keybuk> ah
<Keybuk> make it
<jdub> only usplash_*
<jdub> then ctrl-d?
<Keybuk> yes
<jdub> mountall start/running
<jdub> but it's just sitting there
<Keybuk> ok, good
<Keybuk> I forgot to mention something
<Keybuk> ;)
<jdub> could be best to reboot and try same without udev up?
<Keybuk> yup
<Keybuk> stop udev first ;)
<jdub> ;-)
<Keybuk> (using "stop udev", kill won't work :p)
<jdub> ok, that looks good
<Keybuk> thanks!
<Keybuk> could you also tell me what I'm talking about next week ;)
<jdub> goodness, gdm starts quickly
<jono> hey jdong
<jono> oops
<jono> jdub,
<jono> long time!
<jdub> (sadly this is a T42 with radeon, so it *starts* quickly but doesn't actually do anything quickly)
<jdub> hey jono
<nixternal> Keybuk: do I need to anything similar there? I had to run to a *cough*vista*cough* machine to find out what is going on...i have a useless karmic box right now
<jdong> jono: well, it's good to see you too ;-)
<Keybuk> jdub: but at least you get to see xsplashy goodness
<nixternal> need to do*
<jdub> Keybuk: well, the abstract sounded lovely
<jono> jdong, :)
<squirrelpimp> nixternal: be patient
<Keybuk> jdub: that's what I meant - what *was* the abstract ?
 * jono is logged in with a live CD as his system won't start X :(
<jdub> Keybuk: heh
<nixternal> squirrelpimp: patient would be great if there wasn't work that had to be done
<jdub> Keybuk: mmm, though xsplash takes a long time to start
<ion> Here, too.
<Keybuk> nixternal: if there was work to be done, you wouldn't have karmic on your box
<squirrelpimp> nixternal: hehe... same here, but it looks like it's broken and waiting will fix it
<nixternal> sure i would, especially this late in the game
<pwnguin> Keybuk: alternatively, everyone would have karmic on their box
<nixternal> squirrelpimp: waiting isn't going to fix it, cuz that would mean I would have to log in somewhere somehow to do an upgrade :)
<jdub> everyone should have karmic -> it's what's for breakfast!
<squirrelpimp> nixternal: yeah, of course
<Keybuk> nixternal: "this late"?  six weeks before we release yet, that's quarter of the development cycle!
<nixternal> jdub: +1 :)
<nixternal> hahaha Keybuk, no more excuses! :D
<[reed]> jdub: Koala Flakes?
<ion> nixternal: The usual, boot with init=/bin/bash, get network up if needed, upgrade.
<jdub> karmic has been very exciting compared to other recent releases
<nixternal> ion: that works with my one machine with ol' skewl grub...the other machine is new grub, and damnit I can't hit escape fast enough it seems :)
<ion> nixternal: Hold shift
<nixternal> i shall give that a whirl
<jdub> heh: init, upstart-udev-bridge, dbus-daemon, hald, gdm-binary -> win.
<Keybuk> jdub: it'd be more win if X didn't need HAL :p
<jdub> maybe next cycle.
<jdub> *swoon*
<Keybuk> yeah
<Keybuk> then it'll be
<Keybuk> init, mountall, gdm-binary
<Keybuk>     , udev
<TheMuso> So what exactly is the issue that caused Karmic to be in this unhappy place?
<cjwatson> nixternal: certainly no point trying to hit Escape, as it's not checked if GRUB_HIDDEN_TIMEOUT=0
<jdub> oh yes, i missed udevd between dbus and hald too
<Keybuk> TheMuso: the buildds built sysvinit, and then couldn't update it for any further builds, because it hadn't built upstart yet
<davmor2> TheMuso: the koala feel out of the tree
<Keybuk> TheMuso: but if it'd built upstart, it wouldn't be able to update it because it hadn't built sysvinit yet
<TheMuso> Keybuk: ah ok.
<Keybuk> it's ok, I'll make sure I break leopard even harder
<nixternal> haha
 * squirrelpimp dances from one foot to the other in impatience
<squirrelpimp> :)
<jdub> mmm, karmic is a bit of a dropbear today
<davmor2> Keybuk: Oh that easy just change it's spots
<cjwatson> rickspencer3-afk: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=eucalyptus should be a bit less scary now ...
<Keybuk> right
<Keybuk> publisher finished
<jdub> squirrelpimp: you can go to the toilet. the buildds will take a while. ;-)
<squirrelpimp> well, i already added the ubuntu-boot ppa without any luck. Will the newly built packages fix that too, or did i already break more of it?
<squirrelpimp> the system hangs right after mounting / on startup.
<squirrelpimp> but i can access it using a live-cd and lvm2...
<Keybuk> squirrelpimp: that I can't answer yet
<Keybuk> how do you know it's mounting / ?
<Keybuk> jdub: ah, memories
<ion> keybuk: /etc/init/apport.conf: 0) Is âreturn 1â intended at all? 1) Even though dash accepts it as exit, one probably should use exit instead of return from top-level sh code.
<Keybuk> ion: you're right
<squirrelpimp> i can see the output produced by mount (nr of files etc) due to nosplash and noquiet
<Keybuk> let's fix that after Î±6 though since it's minor
<squirrelpimp> i also see udev failing for hdparm and ppc files with some syntax-errors
<Keybuk> squirrelpimp: does mountall fail, or just sit there?
<Keybuk> (the last i386 packages missed that publisher run :-()
<maxb> This round of updates have stopped switching my console to KMS niceness ASAP :-/
<Keybuk> maxb: correct
<maxb> that is a shame
<Keybuk> cjwatson: on the bright side, amd64 has now built
<cjwatson> Keybuk: built which?
<Keybuk> so after the next publish, we should have a complete i386 and amd64 set
<Keybuk> cjwatson: all of my uploads ;)
<cjwatson> ah :)
<squirrelpimp> i can't see anything related to mountall
 * cjwatson will be in bed by then
<squirrelpimp> udev complains a lot
<Keybuk> squirrelpimp: this implies that you do not have a working installed set
<squirrelpimp> installed set?
<Keybuk> update in roughly an hour's time
<cjwatson> squirrelpimp: are you on powerpc?
<squirrelpimp> amd64
<cjwatson> ah
 * davmor2 is going to bed now, but if there aren't cd's tomorrow will go and pay Keybuk a visit till there are :)
<cjwatson> (you said "ppc files" so I wondered)
<squirrelpimp> yeah, i did too
<Keybuk> davmor2: you're always welcome to hack here ;)
<davmor2> Keybuk: with an axe ;)
<squirrelpimp> i applied some pinning hackery to make it install udev from ubuntu-boot ppa, but apparently that didn't do the trick
<jdub> /lib/udev/rules.d/40-ppc.rules <- this one
<squirrelpimp> first one to fail with "unknown key 'SYMLINK{unique}'" is 50-udev-default.rules
<Keybuk> that's not a fail
<Keybuk> that's just a message
<squirrelpimp> ah, ok
<squirrelpimp> sounds serious though
<Keybuk> no
<Keybuk> udev: OMG! THE COMPUTER IS ON FIRE! QUICK! EVACUATE THE BUILDING!
<ion> You shouldnât need any pinning hackery. Just upgrade to the latest everything. If that fails or the system still doesnât work, wait and redo. :-)
<Keybuk> would sound serious
<squirrelpimp> next one is "NAME="%k" is superflous" from 40-ppc.rules
<jdub> udev: failed to load lp
<squirrelpimp> yeah, but waiting always implies doing nothing
<ion> keybuk: Iâd suggest replacing the âunknown keyâ message string with that one. :-)
<cjwatson> launchpad-udev
<squirrelpimp> so instead, i could try to somehow make it work.
<Keybuk> udevadm giveback --distro-match=ubuntu
<jdub> cjwatson: that's a scarier thought than was intended by my joke. yikes.
<squirrelpimp> however this time i think it's beyond my knowledge of the ubuntu startup process
<slangasek> 'giveback' is an alias for 'trigger', right?
<Keybuk> squirrelpimp: only one person in the world knows how the udev startup process works right now
<Keybuk> and he's desperate for the loo, and is being harassed by his two border collies who are similarly desperate
<Keybuk> so, err
<Keybuk> brb
<jdub> which is why Novell is investing in a fleet of buses
<squirrelpimp> yeah... udev is the new cups
<squirrelpimp> :)
<ion> No-one can be told how the udev startup process works. You have to see it for yourself.
<squirrelpimp> i wonder why there aren't more udev-related chuck norris jokes
<pwnguin> udev-related chuck norris jokes cure cancer. Too bad nobody makes them.
<rickspencer3> cjwatson, I <3 the euc bug list
<lool> cjwatson: Anything I can help with for the current buildd situation?
 * lool realizes he offers help after the battle but was busy
<cjwatson> lool: not any more, really :)
<cjwatson> it should just churn through now
<Keybuk> yeah
<lool> Cool
<Keybuk> this publish run should solve amd64 and i386
<jono> Keybuk, so this will get us up and booting again?
#ubuntu-devel 2009-09-16
<Keybuk> yes
<Keybuk> any problems after >1hr are real problems ;)
<jono> Keybuk, thanks for your work on this :)
<Keybuk> jono: thank slangasek, cjwatson and lamont more than me
<maxb> Is there a package we can watch for to know we've got all the updates that are expected to make things work again?
<jono> thanks slangasek, cjwatson :)
<jono> right, gonna go buy an ethernet cable so I can upgrade in a bit :)
 * maxb wonders what this means:
<maxb> Setting up rsyslog (4.2.0-2ubuntu3) ...
<maxb> restart: Unknown instance:
<Keybuk> it's upstart's way of saying "not running"
<squirrelpimp> will the changes be published on the xy.archive.ubuntu.com mirrors? Or only on some master servers?
<Keybuk> squirrelpimp: in the usual fashion
<squirrelpimp> which i don't know :(
<Keybuk> squirrelpimp: the changes are published to a master archive, from which the primary mirrors sync from
<Keybuk> other mirrors may sync from other mirros
<squirrelpimp> ok
<slangasek> jono: thank cjwatson and lamont, I'm just watching and waiting to be able to start CD builds :)
<squirrelpimp> and that master-archive it the one without any country-code in front of it i guess...
<Keybuk> slangasek: I'd like to sneak in a couple of bug fixes before you do that
<squirrelpimp> i think i'll go to bed and test it in the morning
<jono> cheers lamont too :)
<Keybuk> (you can say "no" if you like, and we'll just release note them <g>)
<lool> slangasek: Do you know at what time livecd-rootfs is updated by any chance?
<slangasek> Keybuk: what are they?
<Keybuk> slangasek: mountall can run fsck and mount simultaneously on raid devices that change
<Keybuk> X crashes during updates that reload D-Bus
<slangasek> I still have to get software-store binaries into main before I can rebuild ubuntu-meta before I can start CD builds, so you have a bit of time
<Keybuk> mountall won't work if you don't have /dev/.initramfs/varrun
<Keybuk> ok, cool
<Keybuk> I have the uploads ready, just wanted to wait for a full publish and your ok ;)
<cjwatson> slangasek: d-i needs to be built against the new linux, which hasn't built yet
<Keybuk> oh, and n-m shouldn't depend on HAL
<slangasek> Keybuk: heh - yes, go ahead with them
<Keybuk> (and shouldn't be restarted when HAL is)
<slangasek> Keybuk: ^^ ah, cjwatson says you've got plenty of time
<cjwatson> slangasek: unless you want to relax the rule about d-i being up-to-date with the kenrel
<cjwatson> kernel
<Keybuk> given that the kernel in question has the ext3/4 fixes ... does that make a difference ?
<slangasek> cjwatson: would rather not, no :)
<cjwatson> Keybuk: that isn't the only change
<cjwatson> I confess I don't know what all the others do
<cjwatson> d-i is also several kernel revisions old, I think
<slangasek> cjwatson: I can take care of the d-i rebuild once the kernel's available
<cjwatson> thanks
<slangasek> cjwatson: anything else I should put on my todo list so you can have some time away? :)
<cjwatson> I think that's actually about it, I cleared up my pending eucalyptus stuff earlier, and did a ubiquity upload
<cjwatson> yeah, don't expect me in too early tomorrow :)
 * slangasek grins
<andersk> Is it known that the initscripts upgrade does not actually remove the old init.d scripts (see http://wiki.debian.org/DpkgConffileHandling )?
<Keybuk> andersk: yes, they're still there for now so it's possible to rescue things that way
<Keybuk> but if you could file a bug to remind me to remove them lest I forget
<andersk> Will do.
<jdub> Keybuk: i still have usplash bits in my initramfs
<Keybuk> jdub: possible
<Keybuk> try the next update
<jdub> ok
<jdub> also, there's a fly in my soup.
<pochu> try the next libsoup
<Keybuk> ok
<Keybuk> I'm out of here for a bit, going to chill out while the publisher runs
<Keybuk> will come back in an hour so, do some testing, and upload the three bug fixes
<maxb> Is something supposed to remove the old scripts from /etc/init.d/ ?
<ion> maxb: Look a few centimeters above this line.
<maxb> ah :-)
<maxb> Something weird is happening with karmic for me - supposedly clean shutdowns don't seem to be unmounting my root partition cleanly, and ext3 journal recovery happens on boot
<maxb> has anyone else noticed that one?
<TheMuso> 8/c
<jpds> maxb: Maybe bug #427822 ?
<ubottu> Launchpad bug 427822 in linux "fsck says last write time in future" [Critical,Fix committed] https://launchpad.net/bugs/427822
<maxb> No, that's something that goes wrong in *response* to a dirty unmount, not a cause thereof
 * kees wonders when it will be safe to dist-upgrade
<slangasek> kees: half hour, maybe?
<kees> slangasek: ok, cool.
<chrisccoulson> heh, i probably should have waited
<kees> i'm curious how apparmor and ufw will turn out.
<slangasek> chrisccoulson: just don't reboot until the next upgrade :)
<chrisccoulson> slangasek - too late, i already did that ;)
 * chrisccoulson is glad for live CD's
<maxb> i386 seems ok already
<maxb> amd64 looked like it might be, but I don't want to reboot yet
<chrisccoulson> maxb - i run amd64 here;)
<squirrelpimp> maxb: i just tried amd64 with no luck
<cjwatson> archive and gb.archive appear to have the complete set noww
<cjwatson> -w
<cjwatson> other mirrors may have to wait longer
<cjwatson> depending on network distance etc.
<LaserJock> ugg, edubuntu's livefs build died a horrible death
<cjwatson> yes, along with the rest of the world
<cjwatson> don't worry about it, it should be fixed tomorrow
<chrisccoulson> my machine is pretty screwed then, it still doesn't boot with the full set of packages
<chrisccoulson> i'll have to look at that tomorrow though
<squirrelpimp> cjwatson: yes, lot's of packages arrived here as well
<squirrelpimp> still no booting :(
<cjwatson> ok, Keybuk will have to follow up on that when he gets back I guess
 * cjwatson &
<jdub> Keybuk: changing initramfs to MODULES=dep is pretty winful too
<jdub> Keybuk: is that more or less aggressive than your proposed changes?
<bgamari> NetworkManager seems to fail to start at boot
<bgamari> On newly fixed karmic system
<bgamari> Starting manually works fine
<bgamari> How is NetworkManager supposed to be started at this point?
<bgamari> ahh, never mind; init.d
<ion> /etc/init/network-manager
 * Keybuk returns
<squirrelpimp> wb
 * ion gosubs
<squirrelpimp> still the last line i get is "/dev/mapper/vg0-root: clean, ... files..."
<Keybuk> squirrelpimp: you're running an up-to-date karmic system
<Keybuk> amd64?
<squirrelpimp> yes
<Keybuk> can you get files from that system to IRC?
<Keybuk> (without just typing them)
<Keybuk> ie. upload them somewhere, or get them to pastebin, etc.
<squirrelpimp> yes, i can boot it with a livecd
<Keybuk> ok
<Keybuk> I need you to try booting with init=/bin/bash
<squirrelpimp> before i do that, shall i copy something from the hung up boot process
<squirrelpimp> ok, i'll try that
<Keybuk> then at the shell, run mountall --debug > /dev/mountall.log
<Keybuk> (you may want an & there too)
<Keybuk> then try running "udevd --daemon" and "udevadm trigger"
<Keybuk> after that, move the log to the root filesystem if you can, and upload it so I can read it
<Keybuk> (usb key is another option, btw)
<ion> IIRC, the last time i tried, mountall refused to start from init=/bin/bash because it failed to connect to Upstart. Itâs been a while from that attempt, though.
<Keybuk> oh
<Keybuk> right
<Keybuk> that will probably happen
<Keybuk> d'oh
<Keybuk> err
 * Keybuk thinks
<Keybuk> you may have to write an upstart job to give you a shell ;)
<Keybuk> start on startup
<Keybuk> console owner
<Keybuk> exec /bin/bash
<Keybuk> ;-)
<squirrelpimp> where should i place that?
<Keybuk> squirrelpimp: in /etc/init
<squirrelpimp> there's already a script called mountall-shell
<Keybuk> yes, but that will only fire if mountall exits with a failure
<Keybuk> you're reporting "hanging"
<squirrelpimp> right
<Keybuk> that to me implies that mountall is still waiting for something
<Keybuk> another option, btw
<Keybuk> is to change mountall.conf and put the --debug there
<Keybuk> and if you can, take a photo of the screen at the point it hangs and upload that somewhere
<squirrelpimp> i'll prefer pastebin if that's ok
<Keybuk> sure
<squirrelpimp> in the file goes: start on startup\n console owner\n exec /bin/bash\n
<ion> Probably should also comment out âconsole outputâ and remove --daemon, since daemonize^H^Hse reopens std{out,err} to /dev/null IIRC.
<ion> Er
<Keybuk> ion: mountall doesn't use daemonize ;)
<ion> comment out âexpect demonâ. Brainfart.
<squirrelpimp> ctrl+d gave me a kernel panic
<Keybuk> squirrelpimp: yes.
<ion> Ah
<squirrelpimp> k, reboot
<squirrelpimp> do i have to change kernel line?
<Keybuk> shouldn't need to
<squirrelpimp> k, i have the shell again
<Keybuk> squirrelpimp: "status mountall" from that shell
<squirrelpimp> ok, i started mountall to a logfile with &
<squirrelpimp> running 1322
<squirrelpimp> but pidof gives 2 pids
<Keybuk> sure, because you just started a second copy
<Keybuk> but that's ok
<squirrelpimp> yes
<Keybuk> do "start udevtrigger"
<Keybuk> (rather than the other udev stuff I mentioned)
<squirrelpimp> sits there doing nothing
<squirrelpimp> not returning to shell
<Keybuk> the udevtrigger doesn't return to the shell?
<squirrelpimp> no
<Keybuk> you should be able to ^C it
<squirrelpimp> i was
<Keybuk> status udevtrigger says?
<squirrelpimp> udevtrigger start/starting
<Keybuk> that's weird
<Keybuk> ps ax | grep udev
<Keybuk> what do you see?
<squirrelpimp> upstart-udev-bridge --daemon, 3 times udevd --daemon, bluetoothd --udev
<Keybuk> ok
<Keybuk> if you run "udevadm trigger" what happens?
<squirrelpimp> returns to shell
<Keybuk> anything else?
<squirrelpimp> exited with 0
<squirrelpimp> nothing alse
<Keybuk> ok
<Keybuk> send your mountall SIGTERM now
<Keybuk> and then copy the log out of /dev
<Keybuk> reboot into your live cd, and upload the log somewhere
<squirrelpimp> SIGTERM to both mountalls?
<squirrelpimp> i put it on the usbstick
<Keybuk> if you like
<squirrelpimp> http://pastebin.com/d3d904e3e
<squirrelpimp> there you go
<squirrelpimp> Keybuk: how does it look to you?
<squirrelpimp> as it doesn't seem to be mentioned in that file, my /home is encrypted using luks
<Keybuk> right
<Keybuk> it looks like it's waiting for your /home and /boot to show up
<squirrelpimp> ok
<Keybuk> and they haven't
<squirrelpimp> i can comment /home and encrypted swap as well
<squirrelpimp> boot is sda1 ext2
<Keybuk> can you run blkid -p /dev/sda1 for me
<Keybuk> and paste the output
<squirrelpimp> ambivalent result (Probably more filesystems on the device)
<Keybuk> eep
<Keybuk> ok
<Keybuk> so that's why it's refusing that
<Keybuk> I've no idea about the LUKS stuff
<squirrelpimp> how can that happen?
<Keybuk> how does it work? ?p
<squirrelpimp> the volumes are configured in /etc/crypttab and setup by /etc/init.d/cryptdisks-early and /etc/init.d/cryptdisks
<slangasek> Keybuk: using an init script that's not converted over yet
<squirrelpimp> after that they are used like regular devices in /dev/mapper
<Keybuk> that explains it then
<slangasek> hmm, this is that use case we discussed in the bug :-P
<Keybuk> huh?
<squirrelpimp> so will it help to fix the sda1 problem?
<Keybuk> squirrelpimp: no
<slangasek> Keybuk: the "you can use cryptsetup in a way that doesn't actually prompt you for a passhprase" :)
<slangasek> ("but why would you want to")
<Keybuk> slangasek: it still should be a udev rule not an init script ;)  I've been telling them that for years
<Keybuk> I thought they were using udev rules
<slangasek> Keybuk: oh, absolutely
<Keybuk> in fact, I remember writing them
 * slangasek shrugs helplessly
<squirrelpimp> there goes my encryption
<squirrelpimp> what can i do to prevent the sda1 error ?
<Keybuk> squirrelpimp: is your /dev/sda1 secretly part of a RAID?
<squirrelpimp> nope
<squirrelpimp> it was created during karmic setup and not changed
<squirrelpimp> karmic from sept 10
<Keybuk> strange that it has multiple signatures
<squirrelpimp> so for now, karmic won't work with encryption? then i'll copy over the files to unencrypted partitions and leave that for now
<squirrelpimp> if i can fix the sda1 thing
<slangasek> it should work for encrypted rootfs; just not for encrypted (separate) /usr
<Keybuk> sda1 you can fix the same way, just copy the files elsewhere, mkfs the device again, and copy back
<squirrelpimp> ok, i'll give that a try
<squirrelpimp> first however i should get some sleep.:)
<squirrelpimp> I'll come back with my findings
<squirrelpimp> slangasek: so setting up cryptsetup for the whole physical volume will work?
<squirrelpimp> Keybuk: thanks for all the help. if you happen to be near karlsruhe germany, i'll make you a pizza.
<squirrelpimp> :)
<Keybuk> squirrelpimp: thanks for the testing!
<slangasek> squirrelpimp: *should*, yes; I haven't tested yet myself (my test comes after the next publisher run)
<Keybuk> slangasek: I'll look into cryptsetup interaction tomorrow
<Keybuk> do you think we should RN it or fix it?
<slangasek> Keybuk: fix it
<Keybuk> ok
<squirrelpimp> HEH..
<squirrelpimp> err
<squirrelpimp> heh... the rescue-shell failed on me after mkfs.ext4 /dev/sda1
<squirrelpimp> now it has to wait till tomorrow
<squirrelpimp> night
<YokoZar> Is mpt on vacation?
<Keybuk> ion: thought, for physical disks, specified by name, we shouldn't bother with what udev thinks
<Keybuk> if someone puts /dev/sda1 in their fstab, blkid output should be irrelevant?
<Keybuk> (probably only true for hdX and sdX though)
<chrisccoulson> hmmm, it seems that mountall does not like the bindfs mounts i have in my fstab
<slangasek> Keybuk, lamont: do you know why util-linux is failing to configure as part of the bootstrap in livefs builds? that seems to be the only thing failing presently
<robbiew> slangasek: I think Keybuk has passed out for the evening ;)
<slangasek> yeah
<slangasek> shot in the dark, but it's going to take me a while to sort through without him
<TheMuso> slangasek: I have a new RT kernel to upload for studio. The mainline rt patch came out overnight, and I've had to do some test building and running today before I can upload it. Unfortunately its an ABI bump due to being against mainline.
<TheMuso> Unfortunately this is needed, as the current RT kernel doesn't boot which is why we didn't do alpha 5, and I'd prefer to get this in for alpha 6.
<robbiew-afk> slangasek: I suppose karmic is now a little happier of a place ;)
<ScottK> TheMuso: Sounds like the downside risk of updating is low.
<TheMuso> ScottK: My thoughts as well.
<lifeless> is there a mips/mipsel machine we can log into ?
<lifeless> friend of mine writes some audio codec stuff and has a bug report for mipsel, but he can't reproduce etc...
<ScottK> lifeless: I think NCommander has some.  Dunno if it can be remotely logged into.
<lifeless> NCommander: ^
<lifeless> ScottK: thanks
<StevenK> lifeless: mahler.debian.org ? :-)
<lifeless> down?
<NCommander> lifeless, at the moment is completely dead, I ripped its HDD out for beta testing ;-)
<HenryLoke> hahah
<HenryLoke> dearest ubuntu chat room
<HenryLoke> need your guy help me a bit
<slangasek> TheMuso: yes, please upload; you don't need to clear such things with me before uploading, the studio-specific packages are frozen for your sake, not mine. :)
<dholbach> good morning
<TheMuso> slangasek: More as a heads up, since binary newnig will be required.
<squirrelpimp> good morning
<slangasek> TheMuso: ok - I'll try to keep an eye out for it, but if the binaries show up in the queue while I'm asleep, don't wait for me :)
<TheMuso> slangasek: ok
<pitti> Good morning
<TheMuso> Morning pitti.
<pitti> hey TheMuso
 * slangasek waves
<squirrelpimp> oh, new packages for upstart and mountall again
<dholbach> james_w: what do we do about bug 414298?
<ubottu> Launchpad bug 414298 in devscripts "Please merge devscripts_2.10.53 from Debian unstable" [Undecided,Confirmed] https://launchpad.net/bugs/414298
<slangasek> Keybuk, lamont: util-linux sorted
<slangasek> Keybuk: wrt debhelper, why is it necessary to diverge from Debian and add an update-rc.d -f remove call?  I can't see how that would be necessary unless there's a bug elsewhere, and that sounds like a bug that'll be a blocker for getting Debian changed over once someone stumbles across it
<squirrelpimp> well.. i have the exact same behaviour with unencrypted /home and swap
<squirrelpimp> Keybuk is still sleeping i guess
 * slangasek wonders why netbase only recommends: ifupdown, when it ships an init script that doesn't work without it
<slangasek> squirrelpimp: what's the behavior you're seeing?
<slangasek> I think I only caught part of that conversation before
<squirrelpimp> the system hangs during startup, on the console i can see the mount of / and then it stops
<slangasek> hmm, ok
<squirrelpimp> Keybuk directed me to run mountall --debug and to make a log of that
<squirrelpimp> then he figured out, that it was encrypted swap and /home and a wrongly labeled sda1 on /boot, which prevented mountall from succeeding
<squirrelpimp> i removed swap, /home and recreated sda1
<slangasek> so what does running mountall --debug now do?
<squirrelpimp> i made another logfile
<squirrelpimp> http://pastebin.com/d5232464d
<squirrelpimp> are the live-cds already built with the new system btw?
<squirrelpimp> not yet it seems
<squirrelpimp> i copied home to a new volume called "home", which is not encrypted
<squirrelpimp> i also tried commenting swap, home and tmpfs in fstab, so there was only /root (and the other default stuff) left
<squirrelpimp> again, no luck
<slangasek> hmm, the log doesn't give me any insight
<slangasek> I guess we'll have to wait for keb
<squirrelpimp> and the behaviour is the same as last night. "start udevtrigger" does not return to the shell
<slangasek> for Keybuk, even
<squirrelpimp> i'm tempted to just reinstall the box from a live-cd as it was a pretty fresh install and i did a backup before running the update in the first place
<squirrelpimp> so keybuk or livecd, whoever comes first
<squirrelpimp> :)
<slangasek> the liveCD is about 40 minutes out
<squirrelpimp> + download and burn it'd 70 minutes to wait
<squirrelpimp> :)
<pitti> slangasek: FYI, I cleaned up the translation related mess on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<squirrelpimp> slangasek: now the system bootet to some further point, despite the shell.conf in /etc/init/ still being present
<squirrelpimp> how can i remove that file, if it boots beyond /bin/bash
<squirrelpimp> ?
<squirrelpimp> ah, i can appent init=/bin/bash in grub
<squirrelpimp> never mint
<\sh> Keybuk: start on (filesystem and started hal) (your patch on gdm) but hal and not even dbus is started via upstart...hopefully you or someone is working on that ;)
<squirrelpimp> slangasek: now it startet including X, which presents an error message from libgconf2-4/gconf-sanity-check-2 and tells me, theres an issue with the configuration server
<slangasek> \sh: sounds to me like you need to upgrade hal and dbus
<pitti> tseliot: do you know why -vmmouse now wants to go back to universe?
<slangasek> squirrelpimp: are all your filesystems mounted?
<pitti> tseliot: in the past it was a dependency of -input-all
<squirrelpimp> yes... i think it might be a wrong mode in /tmp
<pitti> tseliot: is it obsolete now, or was it a merge error?
<squirrelpimp> i set that to 1777 to be sure and try again
<\sh> slangasek: apt-get update ; apt-get dist-upgrade should be enough, right? it came after the last dist-upgrade...
<\sh> slangasek: this morning I have to mention
<slangasek> \sh: both hal and dbus are shipping upstart jobs in the current versions
<tseliot> pitti: I don't think it's obsolete and I have yet to merge it with debian's version
<\sh> slangasek: I had to manually start hal ; start dbus ; start network-manager ; start gdm
<pitti> tseliot: merge error in -input-all, I mean
<squirrelpimp> ok, i have gdm login
<\sh> slangasek: dbus 1.2.16-0ubuntu3 (the latest upload of dbus e.g.) is on the system
<tseliot> pitti: oh, it could be. Can you file a bug report about that and assign it to me, please?
<pitti> tseliot: will do; but I wasn't sure whether it was a bug, or deliberate
<tseliot> tjaalton: do you know anything about this ^^ ?
<\sh> slangasek: so I checked the last uploads with scotts updates from yesterday, everything has the correct version on the system..so I'm confused now ;)
<slangasek> \sh: then perhaps I misunderstood what you were saying, because the jobs are certainly there in the packages
<squirrelpimp> i get "rc main process" stopped/continued lots of times during reboot
<squirrelpimp> is that expected?
<pitti> tseliot: done, bug 430532
<ubottu> Launchpad bug 430532 in xorg "should depend on -vmmouse?" [Undecided,New] https://launchpad.net/bugs/430532
<tseliot> pitti: thanks
<pitti> tseliot: I'll test it by installing -vmmouse into the live system once today's images land
<pitti> tseliot: i. e. whether it still actually works
<tseliot> pitti: ok, let me know
<\sh> slangasek: right...but they are not started .. so after reboot (kernel update) I'm on the console...and "start gdm" doesn't work...and after investigating why it's not started, I realized that hal and dbus are not started, too
<tjaalton> tseliot: it's fixed in git, and according to the changelog entry it should be uploaded already (on 3rd of August)
<squirrelpimp> slangasek: it seems, that if i put /dev/vg0/home in fstab, it won't work
<squirrelpimp> but if i replace it with /dev/mapper/vg0-home it will
<tjaalton> tseliot: but looks like it wasn't
<slangasek> squirrelpimp: ah; possibly because one is the kernel's "true" name for the device, and one is an alias
<squirrelpimp> might be
<slangasek> \sh: which version of mountall do you have installed?
<squirrelpimp> but it would be nice if either worked
<slangasek> squirrelpimp: yes - but knowing why is the first step :)
<slangasek> squirrelpimp: can you file a bug on lvm2 about this, and drop the bug number here?
<squirrelpimp> sure
<squirrelpimp> suspend to disk doesn't work
<\sh> slangasek: 0.1.4
<slangasek> \sh: and that's the version you had when you booted, too?
<\sh> slangasek: yes
<slangasek> ok
 * slangasek doesn't have that version here yet; 0.1.3 looks like it DTRT, but I'll keep looking
<\sh> slangasek: thx :)
<squirrelpimp> bug number is 430542
<squirrelpimp> slangasek: should i worry about the "could not read '...z60_hdparm.rules" from udev?
<slangasek> squirrelpimp: probably indicates a dangling symlink for some reason, and probably not a big deal
<slangasek> warrants a bug report on whatever left the symlink behind
<squirrelpimp> dpkg can't find any package the symlink belongs to
<TheMuso> If someone would kindly let linux-rt's binary packages through binary new, then I can upload the meta, and disks can be built once all this other stuff is sorted.
<slangasek> TheMuso: grabbing; go ahead with your meta upload
<TheMuso> slangasek: Thanks.
<tjaalton> pitti: the vmmouse fix was in git, but never uploaded. Ok to upload now or wait after a6?
<pitti> tjaalton: better wait, I think
<tjaalton> pitti: sure thing
<soren> Is Karmic still knackered? Will I spend the rest of the day regretting it if I "apt-get dist-upgrade"?
 * ogra wonders if there is any documentation what to do with the new upstart stuff in all the scripts that use chroots to build stuff and call invoke-rc.d and friends
<ogra> i.e. all our virtual things, my ltsp builders and my armel build scripts
<ogra> soren, did you get any instructions for the transition ?
<soren> ogra: Nope.
<slangasek> soren: karmic is settling; I don't know whether this means you'll regret it
 * soren has a reputation of being a bit of a masochist, so probably not.
<pitti> hey, from time to time we just _need_ to be taught how booting really works
<pitti> how better to find out than having to fix a completely screwed system :)
<soren> Exactly!
<ttx> no pain, no gain.
<ttx> (I used to run Gentoo)
<al-maisan_> so how does one fix the "Mount point '/dev/(pts|shm)' does not exist. Skipping mount" problem?
<cjwatson> slangasek: ah, good, I was just about to poke at util-linux after reading mail ...
<soren> ttx: Heheh :)
<slangasek> cjwatson: yah, sorry it took me so many mails to notice the problem :)
<cjwatson> yeah, I ignored most of them until timestamps were such that I could no longer put them down to the known bustedness
<dholbach> al-maisan_: did a dist-upgrade and reboot help with that?
<dholbach> al-maisan_: I booted with init=/bin/bash and ran   sudo dhclient &   to get me on the net, then dist-upgraded
<al-maisan_> dholbach: thanks, will try dist-upgrade, I have done a "sudo apt-get upgrade" so far..
<al-maisan_> dholbach: cool, the machine boots to the linux console login now :)
<dholbach> al-maisan_: all the best with completely fixing it!
<al-maisan_> :)
 * soren crosses fingers and goes for a reboot
<al-maisan_> hmm .. now when attempting "restart gdm" I get: "Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory"
<cjwatson> I'm told that's a problem with having done a partial upgrade ...
<al-maisan_> ah
<cjwatson> any out of date packages?
<\sh> cjwatson: no it's not
<cjwatson> \sh: well, slangasek said it was and I normally believe him - do you have evidence to the contrary?
<cjwatson> (or details)
<\sh> cjwatson: as discussed with slangasek I checked that everything is in place...no updates are missing...and it doesn't work as expected
<dholbach> \sh: after a complete upgrade I had two working machines again
<slangasek> well, I wouldn't have expected that particular error from a partial upgrade
<slangasek> I would've expected upstart to refuse to start gdm at all?
<cjwatson> ok, then I don't know; however of course it is possible that not everyone has the same cause for the same symptom
<\sh> dholbach: I dist-upgraded this morning and it didn't work..I just saw that slangasek uploaded new hal and new gdm
<slangasek> \sh: all those new uploads do is enforce a versioned dependency
<slangasek> they won't work any different than a system that was already up-to-date
<sebner> \sh: I was able to boot (after a fsck/mountall issue -reboot) but with old mountall/upstart from yesterday evening after the builds were working again
<\sh> I realized that problem when I "dpkg-reconfigure kdm" and selected kdm as default xdm ... after that, no mouse, no keyboard (both usb) were working...(btw...dpkg-reconfigure gdm doesn't work anymore)
<\sh> after manually "start hal ; start dbus ; start network-manager ; start gdm) it was working again
 * al-maisan_ sees a "init: dbus pre-start process (nnnn) terminated with status 1" message scrolling by while booting the machine in question..
<sebner> slangasek: should it boot already faster btw?
<al-maisan_> \sh: that manual start command sequence did the trick, thanks!
<slangasek> sebner: that's not my department :)
<dholbach> james_w is reviewing patches and packages in #ubuntu-reviews
<al-maisan_> oops, not quite, gdm comes up, but the touchpad and the keyboard are dead..
<sebner> slangasek: kk, we should be happy if it boots in general ^^
<pitti> al-maisan_: that would be missing hal then
<pitti> al-maisan_: at startup, X reads the input devices from hal, so hal must be running before X starts
<al-maisan_> pitti: OK.
<pitti> I haven't checked how the upstartification ensures this dependency (or whether it does at all)
<al-maisan_> pitti: I did "start hal" manually so it should have been running.
<pitti> al-maisan_: and afterwards started gdm?
<pitti> it should have worked then indeed
<al-maisan_> pitti: yes.
<slangasek> pitti: gdm "start on [...] started hal"
<pitti> al-maisan_: can you check "lshal" for info.capabilities "input.keys" and "input.mouse"?
<sebner> pitti: I'm wondering why we are fiddling with hal. So not soo deprecated yet?
<slangasek> TheMuso: I'm not tracking linux-rt further at the moment; when you want me to roll an ISO, shout
<StevenK> sebner: Not quite yet
<\sh> slangasek: hal needs started dbus but dbus wasn't started and dbus wasn't started
<StevenK> sebner: https://wiki.ubuntu.com/Halsectomy
<sebner> heh, k
<slangasek> \sh: not sure what you're responding to; I was simply addressing pitti's dependency question
<sebner> StevenK: ah, only GDM remaining, the rest are just applications :)
<cjwatson> \sh: if dbus isn't getting started, presumably that's the thing to debug?
<\sh> slangasek: s/and dbus wasn't started/and eventually we see something strange happening with dbus?/
<pitti> sebner: most apps switched over, but not X yet
<ogra> pitti, btw do we keep hal in universe once you are done ? so scripts and tools using it donw need to be ported
<\sh> cjwatson: that's what I wanted to say ;)
<ogra> *don't
<pitti> ogra: oh, of course, as long as there are still rdepends
<sebner> pitti: we can keep breaking the archive with switching to wayland if you are feeling bored :D
<pitti> ogra: but I hope we can throw it out of the default install in LL at least for Ubuntu (when X gets ported)
<pitti> ogra: and I heard that they are porting solid as well, so perhaps Kubuntu can drop it soon, too
<ogra> thats fine, i'm just to lazy to port usb-imagewriter :P
<pitti> sebner: heh
<lesshaste> hi.. I have a firefox problem where it freezes when uploading files... The strace at http://pastebin.com/f118d9b2e seems to actually imply it's an X server problem as firefox is waiting for something from the server which never arrives
<lesshaste> any tips on how to report this usefully?
<StevenK> sebner: And X.org input detection. Which is somewhat important
<StevenK> But only if you care about mouse movement and typing. And who needs those?
<lesshaste> the important part starts at line 1770
<ogra> StevenK, speech input FTW ?
<StevenK> ogra: Absolutely.
<StevenK> ogra: Then IRC gets filled with "um", "er" and "ar" a lot
<sebner> StevenK: cards ftw! or you accept my suggestion moving to wayland *hrhr*
<ogra> StevenK, and my neighbors will be annoyed :)
<al-maisan_> pitti: I do see various lshal info.capabilities entries that lists input.keyboard, input.keys and input.mouse
 * al-maisan_ tries starting gdm again
<pitti> al-maisan_: ok; can you check /var/log/Xorg.0.log for input device errors?
<pitti> $ grep hal /var/log/Xorg.0.log
<pitti> I get ~ 10 lines, like
<pitti> (II) config/hal: Adding input device AT Translated Set 2 keyboard
<pitti> (II) config/hal: Adding input device Logitech USB-PS/2 Optical Mouse
<Laney> soren: did you come back?
<al-maisan_> pitti: it works now .. for whatever reason .. so after booting to the console I did: start dbus; start hal; start gdm
<TheMuso> slangasek: Just role them when things are ready to be roled, i.e when preparation of disks for everything starts. I just wanted to get that kernel in.
<pitti> al-maisan_: I guess "started hal" is not enough; hal needs a second or two to detect everything
<pitti> al-maisan_: I guess "start hal; start gdm" fails, but "start hal; sleep 2; start gdm" works?
<soren> Laney: Yes. What's up?
<Laney> soren: Just checking - I dist-upgraded and didn't come back...
<YokoZar> pitti: is it possible hal could get held up for a bit and break when 2 seconds aren't enough?
<soren> Laney: but.. you're... here..?
<Laney> laptop
<pitti> YokoZar: I think the correct solution would be for hal to emit an upstart signal when it's done detecting
<pitti> Keybuk: ^
<YokoZar> pitti: Yeah that was my thought as well
<pitti> and then the rest (like gdm) can depend on that/
<StevenK> start on hal-ready (or something), right?
<pitti> Keybuk: is there an example how C code would send an upstart signal that gdm etc. could depend on?
<YokoZar> And if hal fails catastrophically and never releases the signal bootup probably should be blocked...
<pitti> I guess it's just a d-bus call
<slangasek> TheMuso: my point is I'm /already/ rolling other images, while the linux-rt kernel is (AFAIK) not ready in the archive yet
<slangasek> hmm. wasn't really /looking/ to reboot just then, but didn't go too badly all things considered
<slangasek> but dbus is definitely a problem here as well
<ion> keybuk: What do you mean by not caring about what udev thinks? What would we do differently?
<al-maisan_> pitti: sorry, was in a phone conversation, yes, there was a pause between "start hal" and "start gdm" since I was doing the lshal checks and queries.
<ion> ogra: Dear aunt, let's set so double the killer delete select all.
<al-maisan_> pitti re. the /var/log/Xorg.0.log input device errors: I get these as well.
<pitti> al-maisan_: errors?
<pitti> tjaalton: oh, in fact current live systems do have a working "vmmouse" like behaviour; so perhaps -vmmouse is indeed obsolete?
<pitti> tjaalton: oops, ignore me; that was my workaround with "-usb -usbdevice tablet"
<tjaalton> pitti: evdev works for the most part, but it doesn't feel "integrated" like with vmmouse, AIUI
<al-maisan_> pitti: http://pastebin.com/m16b6a3de
<pitti> tjaalton: yes, it works with clicking/releasing the lock
<slangasek> does upstart log things anywhere/
<cdE|Woozy> sometimes kms is failing on intel with the latest updates. it seems that drm is loading before agpgart-intel was loaded: http://pastebin.ubuntu.com/271986/
<slangasek> tjaalton: what's the best way to force modes for a VGA device that's not passing EDID?
<pitti> al-maisan_: hm, if it doesn't work with that, it's out of my knowledge, I'm afraid
<al-maisan_> pitti: sorry for not being clear enough .. everything works fine after issuing the manual start command sequence from the console. Thank you very much for helping me out!
<pitti> al-maisan_: ok, you're welcome
<slangasek> al-maisan, \sh: bug #430611
<ubottu> Launchpad bug 430611 in dbus "dbus fails to start on clean boot using upstart job" [Undecided,New] https://launchpad.net/bugs/430611
<al-maisan> slangasek: thanks!
<cjwatson> definitely a messy startup, but it does at least work for me ...
<\sh> slangasek: bingo :)
<cjwatson> people having dbus start problems: do you by any chance have /var on a separate filesystem?
<cjwatson> just a hunch, could be wrong
<\sh> cjwatson: nope
<slangasek> cjwatson: yes
<cjwatson> drat
<slangasek> oh, wait
<slangasek> no
<\sh> slangasek: do you have also some strange udev messages in /var/log/syslog like udevd[3227]: NAME="%k" is superfluous and breaks kernel supplied names, please remove it from /lib/udev/rules.d/40-ppc.rules:3
<cjwatson> I was wondering about the pre-start script
<slangasek> I do have cryptsetup
<cjwatson> \sh: everybody has those, but they're fairly harmless
<cjwatson> for the moment anyway
<\sh> cjwatson: ok...I never saw them before...so I'm curious :)
<cjwatson> it's a new warning in the new upstream release of udev that hasn't been handled in all the rules yet
<cjwatson> mentioned in the changelog, even ...
<slangasek> speaking of warnings, upstart-job and I are going to be having words
<cjwatson> the whine if you use invoke-rc.d?
<slangasek> yes
<cjwatson> \sh: what does 'dbus-uuidgen --ensure; echo $?' say, run as root?
<ior3k> do these dbus problems happen only on boot time? Or everytime?
<slangasek> and the improper emulation of init script "start" - it can obviously do its own darn status check to make the invocation a no-op
<slangasek> ior3k: what other time is there?
<\sh> cjwatson: 0
<cjwatson> oh well
<slangasek> ior3k: it's a problem with dbus not starting - boot time is about it :)
<ior3k> slangasek: I mean, dbus may not start on boot, but start manually afterwards
<al-maisan> cjwatson: I do have /var on a separate partition
<slangasek> ior3k: no, it is possible to start it by hand
<\sh> cjwatson: I have to revert my answer to "/var on a separate partition" the correct answer is "yes" and actually it wasn't mounted
<ior3k> slangasek: is it possible to rig the dbus init script with strace?
<ior3k> slangasek: would that help debugging?
<slangasek> ior3k: I don't know if it would; since upstart does service supervising, running it under strace changes the parameters
<slangasek> (not my first choice for debugging something in early boot, but someone can try it if no other fixes present themselves...)
<cjwatson> I wonder if mountall needs to emit a special event to say that /var/run has been mounted
<cjwatson> or if it would be ok to have dbus 'start on local-filesystems' rather than virtual-filesystems
<slangasek> where are those signals defined?
<cjwatson> as in documentation, or as in code?
<slangasek> documentation
<cjwatson> they're emitted by C code in mountall ...
<cjwatson> slangasek: *hollow laugh*
<squirrelpimp> the mute-button on the thinkpad stopped to work after the last round of updates
<squirrelpimp> there are lots of bugreport related to the mute button, but it worked as expected before the updates so i'm note sure against which packge to file the bug
<slangasek> I wonder whether this is connected to my inability to rebuild mountall due to testsuite failures
<slangasek> oh, wait
<slangasek> I need to suppress dh_auto_test :P
<squirrelpimp> never mind, i found a workaround
<cjwatson> slangasek: that's always reassuring
<tjaalton> slangasek: https://wiki.ubuntu.com/X/Config/Resolution has some optional ways to force the resolution
<cjwatson> /var/run *should* be considered virtual, though
<cjwatson> oh, /var/lib/dbus/machine-id
<cjwatson> slangasek: try 'start on local-filesystems' in the dbus job?
<slangasek> cjwatson: in my case that's on the rootfs, though; and dbus-uuidgen appears to only open it for reading
<slangasek> cjwatson: OTOH, I do have */usr* on a separate partition
<slangasek> so yeah, I'll test
<slangasek> (testing with local-filesystems; if that fixes it, is that the right signal to use?  What if /usr is on NFS?)
<cjwatson> it's not obvious is it
<cjwatson> really, we ought to make dbus work when only virtual filesystems are available
<cjwatson> especially with upstart depending on it
<cjwatson> or quasi-depending anyway
<slangasek> cjwatson: hah - well, that makes a difference, at least...
<slangasek> cjwatson: I did another test boot w/o changing first, and I get "dbus died w/ 127, respawn"
<slangasek> cjwatson: then I changed it to local-filesystems... and I get no attempt to start dbus at all
<slangasek> because mountall never emits the signal, AFAICS
<cjwatson> wuh
<cjwatson>         if ((! local_triggered) && (num_local_mounted == num_local)) {
<cjwatson>                 nih_info ("local finished");
<cjwatson>                 emit_event ("local-filesystems");
<slangasek> does it track noauto filesystems sanely?
<slangasek> also: bwuh, what decided to rewrite my fstab yesterday and put UUIDs in place of my already-unique lvm names
<cjwatson> it's supposed to, see cleanup
<pitti> meh, /etc/init/gdm.conf doesn't check for "text" any more
<cjwatson> I wonder about remount handling though
<cjwatson> maybe arrange for mountall to run with --debug?
<slangasek> where does it debug to?
<slangasek> pitti: "text"?
<cjwatson> syslog, if daemonised
<slangasek> al-maisan: would you be able to help with testing this further?
<slangasek> 4am here, brain not worky
<al-maisan> slangasek: yes, sure.
 * al-maisan fetches the other laptop from the living room
<slangasek> I can probably do one more test here, but black BIOS screen is making me sleepy
<al-maisan> slangasek: what package do I need to upgrade in order to perform the test?
<davmor2> slangasek: sleep they'll be a re-spin
<cjwatson> al-maisan: up-to-date everything, edit /etc/init/mountall.conf to add --debug to mountall's command-line parameters, reboot, look in syslog
<al-maisan> cjwatson: thanks
<cjwatson> Keybuk: so, for converting the ubiquity init script to upstart - how do I arrange for gdm to *not* start until ubiquity has completed?
<cjwatson> Keybuk: also, how do I say "start once service foo has started, but if service foo is not present on the system then don't worry about it"?
 * cjwatson wonders how the current set of upstart jobs handle the case where a package is removed but not purged
<slangasek> cjwatson: aha - ldd /bin/dbus-daemon | grep /usr
<al-maisan> cjwatson: here's the syslog excerpt: http://pastebin.com/m72c830db
<cjwatson> slangasek: ah - ok, I can deal with that
<slangasek> and the reason for not emitting the signal here is that I have a filesystem referenced as /dev/VG/LV syntax instead of /dev/mapper/VG-LV, which isn't getting handled
<cjwatson> hmm, nothing from mountall in that syslog
<cjwatson> (phone)
<slangasek> I expect the signal will be emitted for people not having that particular problem
<slangasek> ok, sleeping now
<slangasek> 'night
<al-maisan> slangasek: good night.
<al-maisan> cjwatson: I did add '--debug' after 'exec mountall' in /etc/init/mountall.conf
<al-maisan> I think there was some extra output but it scrolled by too fast on the console .. sorry
<al-maisan> Shift-PageUp does not work
<cjwatson> Keybuk,lamont: udev successfully built on powerpc now
<Keybuk> oh, neat
<lamont> \o/
<ogra> Keybuk, is there any documentation how to transition stuff that uses chroots and VMs and invokes initscripts or calls invoke-rc.d to the new model ?
<ogra> (i have various tools and scripts that will need chnages i guess ... i.e. ltsp, rootstock etc)
<kagou> hello
<ogra> and i guess our vitual builder tools might need to see some changes too
<Keybuk> upstart doesn't work with chroots
<ogra> but in vm's i guess
<Keybuk> this is one main reason I haven't changed anything that you _can_ run in a chroot
<ogra> i.e. in rootstock i fire up a VM after a first stage bootstrap to call the second stage and install whaever the user selected... in this vm i only fire up the bare minimum of initscripts to just make the vm work enough for the task ...
<ogra> is there a way to have something like a "minimal profile" upstart could use in that case
<ogra> stgraber, ^^^ the above will massively affect ltsp
<doko> hmm, boot is somewhat broken: init: sreadahead main process () terminated with status 1, and system hangs
<ogra> doko, you didnt upgrade today, did you ?
<directhex> doko, /topic
<doko> ogra: I did
<ogra> ouch
<pitti> doko: does it really hang forever? mine just powers down display, and gdm eventually appears after a second
<doko> pitti: now hangs for 5min
<pitti> ok, so that's not that then
<pitti> erm, s/after a second/after a minute/, of course
<lamont> cjwatson/Keybuk: does karmic need/want the change for debian bug 546834?  is it even an issue for karmic+1?
<ubottu> Debian bug 546834 in debootstrap "debootstrap fails when invoked from lh_build" [Grave,Open] http://bugs.debian.org/546834
<doko> messages before that are: "Begin: Running /scripts/init-bottom ..." and "Done."
<Keybuk> lamont: shouldn't think so, we don't use insserv
<lamont> yay
<Keybuk> doko: try with --debug
<doko> Keybuk: as kernel option?
<dpm> dut
<Keybuk> doko: yes
<lamont> Keybuk: and I pulled your branch and pushed my tree.  how much / which of -1ubuntu2 do I need to pull over to debian?
<Keybuk> lamont: which was -1ubuntu2 ?
<Keybuk> I wouldn't pull any of the upstart stuff for now
<Keybuk> you may want the versionsort() patch though
<lamont> ok.  there was also a "newer glibc" prototype change
<lamont> ah.
<lamont> yeah that
<sebner> Keybuk: can the boot considered faster now after all the bunch of updates?
<Keybuk> but then that didn't even look like it was used at all
<lamont> and does that work with older glibc too?  (as in sid?)
<Keybuk> sebner: it seems to depend
<Keybuk> sebner: for me, X comes up 7s faster
<Keybuk> but for other people, X doesn't come up at all ;)
<Keybuk> and on some HDD-based machines, it's exactly the same speed
<Keybuk> *but*, and here's the important thing, if this model does work
<Keybuk> it puts us in a better place for karmic+1
<Keybuk> because this was the "hard change"
<sebner> Keybuk: kk, here it seems to be same speed
<Keybuk> sebner: do you have before/after bootcharts ?
<sebner> Keybuk: sure but the bootchart from this morning might not be useful since I didn't get all of the updates. I installed some others after the builds worked again (mountall manually from LP), this even booted up ^^
<Keybuk> I mean of your boot before any of the updates
<doko> Keybuk: anything special to look for?
<sebner> Keybuk: sure, sec
<Keybuk> doko: can you take a picture and send it me ? :)
<Keybuk> doko: otherwise the last virtual 4/5 line is useful
<doko> Keybuk: ok
<ion> keybuk: What do you mean by not caring about what udev thinks? What would we do differently?
<sebner> Keybuk: the updates started yesterday right?
<Keybuk> ion: mountall checks that ID_FS_USAGE=filesystem
<Keybuk> ion: so if there's multiple meta-data in the block device, it ignores it
<Keybuk> ion: for "simple" block devices, that's not really necessary
<stgraber> ogra: yeah, I'll need to do some real testing quite soon
<mterry> In MainInclusionReportTemplate, there's the sentence "Who is the package bug contact in Ubuntu? (Needs one if its a nontrivial package which does not fully maintain itself through Debian)".  Can we scratch the parenthetical?  Seems like we always want a bug contact
<stgraber> ogra: as soon as my laptop starts working again ;)
<cjwatson> mterry: the parenthesis is there for a reason, and should be left in
<ogra> stgraber, i guess we have to drop all the rc.d script mangling
<sebner> Keybuk: http://img147.imageshack.us/i/ubuntukarmic200909151.png/  , the day before this log it booted with 39 sec's though. A clean jaunty install boots in 18 secs though. Using karmic since the beginning
<mterry> cjwatson, that's what I was asking for.  I just couldn't think of a situation where we'd want bug reports being filed that never get looked at
<ogra> stgraber, and i dont know what ltsp-client-setup and ltsp-client-core initscripts have to look like in the new worldorder, but i guess Keybuk can help with them
<Keybuk> sebner: err is this chart the "before" or "after" ?
<ion> keybuk: Wouldnât that mean writing additional special-case code? Now we have a single code path that works for everything. Isnât that better?
<cjwatson> mterry: we'd always *like* a bug contact, but it's not mandatory for main inclusion if the package is trivial and maintained well in Debian
<Keybuk> ogra: just leave them as they are?
<sebner> Keybuk: should be before
<Keybuk> ion: no, just a change to the "if" statement in the udev watcher
<ogra> Keybuk, if they work :)
<Keybuk> sebner: ok, that looks like a before
<sebner> heh
 * ion looks at the code
<sebner> Keybuk: do you also want the "half-upgraded" bootchart from today?
<mterry> cjwatson, k..
<Keybuk> sebner: if you like
<ion> So, if the device name is [hs]d[a-z][1-9], skip the get_property_value stuff?
<cjwatson> Keybuk: oh, speaking of which, shouldn't you subscribe to bug mail for mountall? :)
<Keybuk> ion: just skip the usage check
<Keybuk> cjwatson: yes
<cjwatson> mterry: basically, it's a bug if nobody's subscribed, but not all bugs are critical
<sebner> Keybuk: http://img11.imageshack.us/i/ubuntukarmic200909161.png/
<Keybuk> sebner: ok, and the full upgrade chart?
<mterry> cjwatson, yar.  I've just been influenced by jorge's exhortations to fill those gaps  :)
<sebner> Keybuk: haven't rebootet yet
<Keybuk> sebner: coward
<sebner> Keybuk: :P
<ion> keybuk: I might be missing something, but the usage check doesnât look very expensive.
<ion> Just a couple of strcmps
<Keybuk> ion: it's not the expense
<Keybuk> ion: it's the problem when someone has "/dev/sda1 /boot ext3 defaults 0 2"
<Keybuk> but blkid can't tell what filesystem is in /boot
<Keybuk> "multiple results returned" kinda thing
<Keybuk> mountall won't mount it
<Keybuk> even though it doesn't *really* need to check ID_FS_USAGE, because /dev/sda1 doesn't have "change" events
<ion> Ah, ok
<sebner> Keybuk: I'll reboot and if it breaks I'll hunt you :P
<Keybuk> (we check that because mdX and dmX *do* change, and need to be repeatedly checked until they contain a valid filesystem)
<Keybuk> sebner: take a ticket, join the queue ;)
<ion> I see
<sebner> Keybuk: does that mean that it'll surely break? :P
<ion> How about when UUID or LABEL is used and they mean sda1?
<Keybuk> sebner: WFM :)
<pitti> Keybuk: is it normal/expected that at shutdown I see a series of "rc init SIGSTOP", "sreadahead SIGSTOP", "rc init SIGCONT", "sreadahead SIGCONT"?
<Keybuk> ion: then obviously for those we check usage ;)
<Keybuk> pitti: yeah
<pitti> ok
<Keybuk> pitti: sendsigs has been doing that weird shit for a while
<sebner> Keybuk: no uplash, loads of udev warnings, but takes longer but it booted up :P
<Laney> is the archive stable yet?
 * Laney is wondering what the best way to recover is
<sebner> Laney: rockstable :D
<Laney> in terms of uploads/publishing
<sebner> Laney: the builds are back to normal too afaik
<sebner> Keybuk: http://img406.imageshack.us/i/ubuntukarmic200909162.png/
<Laney> mainly I want to get my system back up Â¬_Â¬
<Laney> chroot + dist-upgrade?
<Keybuk> sebner: wait a minute for sreadhead to go away (status sreadahead)
<Keybuk> should say stop/waiting
<Keybuk> then reboot again
<sebner> Laney: yeah
<sebner> Keybuk: rebooting
<ogra> Keybuk, fyi, armel imx51 (babbage) still boots fine :)
<ogra> i see a udev message on boot though, but i think that was mentioned here before
<ogra> ("symlink" in a udev rule)
<Keybuk> right
<Keybuk> we're testing udev GIT HEAD
<Keybuk> kay and I will do a release next week when we're in Portland
<ogra> well, as long as it works i dont care
<ogra> i'm just sad i cant hide the messages behind a splash atm :P
<cjwatson> Keybuk: what's the best way to ask users to get debug information out of mountall? edit /etc/init/mountall.conf and add --debug?
<Keybuk> cjwatson: yes
<sebner> Keybuk: http://img193.imageshack.us/i/ubuntukarmic200909163.png/
<Keybuk> sebner: odd, you have a dead sreadahead as well
<sebner> Keybuk: that means?
<Keybuk> don't know yet
<sebner> Keybuk: as my system boots this doesn't mean it's purely bad. :P
<doko-netbook> Keybuk, http://people.canonical.com/~doko/tmp/IMG_0892.JPG
<ion> 403
<cjwatson> Keybuk: any reason mountall doesn't just do nih_log_set_logger more or less up top if it's going to daemonise? it'd make debugging rather easier ...
<Keybuk> cjwatson: wouldn't make any difference, surely?
<cjwatson> it'd arrange for all the stuff from new_mount, cleanup, etc. to go to syslog
<cjwatson> which is before daemonisation
<ion> I wonder if rsyslog could be easily patched so that it could be started before a writable anything, and it would buffer stuff until it can dump them to syslog et al?
<ion> Similarly to logsave from e2fsprogs
<kagou> with 20090916 daily-live amd64, I install system, but at reboot -> screnn go black and system freeze :( To wich package I report the bug ? Or should I wait for tommorrow iso ?
<kagou> bug came clearly from new boot system
<Keybuk> cjwatson: except syslog isn't running ;)
<cjwatson> Keybuk: oh, heh
<Keybuk> cjwatson: which is why you normally send all that to stderr before you daemonise ;)
<cjwatson> fair enough
<Keybuk> ion: that's the plan for Upstart itself
<Keybuk> just buffer stdout/stderr of processes
<ion> Perhaps a command to dump the rsyslog buffer to stdout, so you could less(1) the so-far logged stuff even before it has been able to save them.
<Keybuk> then, if they fail, toss the log somewhere useful
<Keybuk> kinda like cron does
<ogra> Keybuk, oh ... http://www.mirror.co.uk/news/technology/2009/08/28/sharp-netwalker-the-future-of-netbooks-115875-21631914/ ... "Sharp reckon that the Ubuntu OS should be able to boot in under 3 seconds"
<ion> Alright
<Keybuk> apache failed, *and here's what it said*
<ogra> Keybuk, and you still test with a dell mini, tsk
<Keybuk> ogra: only if you use a different display engine than X
<ogra> i think its X on framebuffer
<ogra> like the babbage
<Keybuk> yeah, never going to be 3s then ;)
 * Keybuk will dance on X's grave when we get a proper display engine
<ogra> but their marketing said so, it *must* be true :P
<cjwatson> and the Mirror, no less a well-regarded publication filled with superb journalistic standards
<sebner> Keybuk: wayland!
<ogra> heh
<Keybuk> sebner: we played with wayland a while back
<Keybuk> doko: still 403
<sebner> Keybuk: really, when? too earler stage I suppose?
<Keybuk> sebner: you can get Dell Mini to boot in 3s with that
<sebner> O_o
<sebner> want have!
<Keybuk> I can make an Ubuntu Appliance boot in 1s
<Keybuk> it's just not very interesting
<ion> But you can ping localhost!
<Keybuk> (a device with a hardwired kernel, and a framebuffer, that launches a single framebuffer application)
<Keybuk> but that's all you need for a tomtom or something
<ogra> which you dont boot anyway
<ogra> only once or if power runs out
<ogra> the rest of the time you only suspend
<ScottK> TomTom takes longer than that to start.  Maybe they need lessons.
<ogra> start or resume ?
<sebner> ScottK: ahh! pssst or Keybuk gets bought by TomTom!
<doko> Keybuk: fixed
<ScottK> ogra: Start.
<ogra> my gps takes about three minutes to boot (its wince based though) but is instant on/off for suspend/resume
<ScottK> suspend/resume is ~2 or 3 seconds.
<Keybuk> ogra: of course you boot them
<loic-m> mvo_: how does one gets an app translated description + screenshot in so they get shown in software-store?
<ogra> once
<Keybuk> why would you suspend a satnav?
<mvo_> loic-m: screenshot> not at all at this point
<ScottK> Keybuk: I assume the on/off button does suspend/resume.  It certainly isn't shutdown/start.
<Keybuk> doko: that's quite odd
<loic-m> mvo_: you mean this point in Karmic dev cycle, or they're not handled by s-s?
<ogra> Keybuk, mine survives a week if its suspended ... and in car it's attached to the cigarette lighter and recharges ... why would i shut it down ?
<mvo_> loic-m: translation> via ddtp and the app-install-data template
<ScottK> doko: Is there any reason not to make celementtree go away now?
<mvo_> loic-m: screenshots can not be localized in the karmic cycle
<Keybuk> doko: that's very odd
<doko> ScottK: go ahead!
<ScottK> OK.  I can work on that.
<Keybuk> doko: it looks like udev isn't running
<Keybuk> doko: could you add an /etc/init/shell.conf with something like "start on startup" "console owner" "exec /bin/bash" and boot with that
<Keybuk> that'll give you a shell to do some debugging with
<loic-m> mvo_: sorry, for the screenshot I wasn't thinking about localised one, but about including one for app where it's missing
<mvo_> loic-m: oh, sorry. I misunderstood. that can be done via screenshots.debian.net
<mvo_> loic-m: before the final release we need to move that to scrrenshots.ubuntu.com though
<mvo_> (but that may be just a re-direct)
<loic-m> mvo_: and if the app isn't in Debian?
<mvo_> loic-m: that is not possible right now, I hope to get this resolved in time
<mvo_> loic-m: but currently we rely on the debian service here, also christop haas expressed willingness to help us
<loic-m> mvo_: for ddtp, that means translating through launchpad, doesn't it? No way to just include it in the package? And does it work for packages in universe?
<mvo_> loic-m: for ddtp there is no way to include it in the package itself. it does work for universe, if it does not, let me know, then there is a bug in the code somewhere. but it does for the cases I looked at
<loic-m> mvo_: Ok. It's just that going through launchpad means you need to hope the locale team ever validates it, which can never happen, and is a shame when you're also upstream translator
<doko> Keybuk: is this config file picked up automatically?
<mvo_> loic-m: oh, hm :( that is bad. there is a way by going via ddtp.debian.net
<mvo_> loic-m: but that requires review as well, not sure how quickly tha thappens
<ogra> doko, upstart reads the stuff in /etc/init
<doko> ahh, it is
<mvo_> loic-m: is there anything in LP that we can do to make it smoother?
<doko> Keybuk: yes, hal is not running
<Keybuk> doko: yes
<Keybuk> doko: hal should not be running yet
<loic-m> mvo_: not sure what you can do. Best would be a way to get this from upstream package, or untill it's possible to grab the email of upstream translator and let him translate ;)
<Keybuk> doko: could you join #ubuntu-boot, it's too noisy in here
<mvo_> loic-m: I proposed a new design for this to translations.launchpad.net so that the package descriptio nwould be put alongside the regular translation as a additional pot file. this way the same permission would apply as for the upstream translation. but unfrotunately it did not get implemented (yet?)
<loic-m> mvo_: didn't know that. Can't find the link, do you have it by any chance?
<mvo_> loic-m: https://blueprints.launchpad.net/rosetta/+spec/native-package-descriptions-support
<loic-m> mvo_: thanks a lot, I'll follow it. Best would be a freedesktop thing so upstreams just include a general description in the list of files gettext/whatever proccesses.
<cjwatson> WTF, +filebug redirects to help.ubuntu.com?
<cjwatson> damnit, there are some cases where ubuntu-bug is no use at all
<cjwatson> stupid stupid stupid
<james_w> +filebug?no-redirect
<cjwatson> thanks
 * cjwatson smart-bookmarks since obviously the UI has decided that helpfulness is for other people
<pitti> cjwatson: hm, where? I still used +filebug this noon on edge
<cjwatson> on edge just now
<cjwatson> https://edge.launchpad.net/ubuntu/+source/mountall/+filebug
<Laney> there was a mail about it to u-d-d but I thought it was just for "Ubuntu"
<ogra> lol
<ogra> Keybuk missed to remove usplash on usplash_down
<AnAnt> I don't understand Keybuk's dh_installinit changes (that was mentioned in last foundations report)
<nixternal> any idea on what I have to do in order to get my machines with encrypted drives up and running?
<al-maisan> nixternal: that's fairly vague question :)
<nixternal> not if you are running karmic it isn't
<al-maisan> nixternal: OK, so.
 * ogra humps Keybuk's leg
<ogra> Keybuk, i have never seen a babbage board boot that fast !
<ogra> Keybuk, though dbus crashed on first boot
<robbiew> lol
<ogra> it works wonderful on second
<robbiew> ogra: does bootchart work on babbage boards?
<robbiew> would be cool to see it
<kirkland> Keybuk: the avahi-daemon upstart job isn't starting the daemon on the alpha6 server
<ogra> its running since 10min
<ogra> generating the image is very slow
<robbiew> ah, right
<kirkland> Keybuk: this is causing the UEC node installs to not detect the cloud-controller on the network
<kirkland> Keybuk: how do i go about debugging this?
<kirkland> Keybuk: or is it a known issue?
<kirkland> Keybuk: actually, i can't get avahi-daemon to start at all, even manually
<kirkland> Keybuk: the upstart job throws a PID back at me
<kirkland> Keybuk: but it's gone by the time i look at ps
<kirkland> Keybuk: and there's no daemon running
<ogra> robbiew, Keybuk http://people.canonical.com/~ogra/babbage2-karmic-20090916-2.png (down from 90sec)
<Keybuk> ogra: you have the strange exe
<Keybuk> ogra: if you reboot it again, do you get down to 38s?
<ogra> no, i got from 54 to 45 already
<ogra> and as i said, very first boot after install crashed dbus
<ogra> and i dont have the right keymap atm
<ogra> Keybuk, GEEZ ! http://people.canonical.com/~ogra/babbage2-karmic-20090916-3.png
<ogra> you are right, it gets faster with every boot
<Keybuk> ogra: you *still* have that strange exe though ;)
 * Keybuk has no idea what that is
<Keybuk> don't suppose you have the .tgz from that latest bootchart
<ogra> i have all three :)
<Keybuk> could you mail me the latest one
<ogra> sure
<ogra> Keybuk, on its way
<kirkland> Keybuk: hmm, i see a new avahi upload since the last iso spin; i'm upgrading to that now
<cagonto> online boxing game http://www.kobox.org/kobox-fande-Nourine.html
<Keybuk> that looks like a link to my INBOX
<kirkland> Keybuk: hmm, that seems to have fixed that problem
<cjwatson> \sh: can you upgrade to current libexpat1 and dbus and see if that fixes things for you?
<kirkland> cjwatson: i'm installing a UEC node...  it's trying to fetch the node-preseed file by ipv6 address;  is that expected?
<cjwatson> al-maisan: ^-
<cjwatson> kirkland: I don't know
<kirkland> cjwatson: okay, thanks.
<cjwatson> kirkland: in my last test the cloud controller was only listening on IPv6; I adapted some things to cope, but didn't investigate why
<kirkland> cjwatson: hmm, my -cc is definitely listening on ipv4
<mterry> Keybuk, so I lied, rsyslog should handle HUPs, but I don't think the current /etc/init.d/rsyslog handles reloads.  It handles restarts...
<kees> Keybuk: apparmor needs to start much sooner (it's starting after avahi, for example)
<al-maisan> cjwatson: will do.
<Keybuk> kees: we need to work out apparmor
<kees> Keybuk: same for urandom, looks like it's started after network services that might be using the seed
<Keybuk> shall we look at apparmor next week?
<Keybuk> we can work it out in person then
<kees> Keybuk: yes please.  :)
<Keybuk> I think I have something in mind that's quite elegant, but want to make sure it works for you
<pitti> ogasawara: bug 193970 is back (seems this breaks again with each and every release); given its size, should I rather open a new bug or reopen this one?
<ubottu> Launchpad bug 193970 in linux "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Medium,Fix released] https://launchpad.net/bugs/193970
<al-maisan> cjwatson: yep, my machine boots perfectly now!
<ogasawara> pitti: lets open a new one to minimize the noise
<pitti> ogasawara: ok
<pitti> ogasawara: what should I do to put it back on the radar? is "regression-potential" enough?
<pitti> ogasawara: I guess the old patch still applies, but keeps getting dropped or so..
<kees> Keybuk: whatcha thinkin'?
<ogasawara> pitti: yup tag it "regression-potential" and also let me know the bug # and I'll get it on our list
<Keybuk> kees: I'm assuming that you have two groups of apparmor profiles
<Keybuk> profiles for particular services
<Keybuk> and generic profiles
<kees> kind of
<Keybuk> for the generic, we need something that loads them like the init scripts
<Keybuk> but for service profiles, we could so something clever
<Keybuk>   start on starting
<Keybuk>   exec [ -f /etc/apparmor.d/init/$JOB ] && load_ze_profile
<Keybuk> that way, if you dropped anything in that directory that had the same name as a service in /etc/init
<Keybuk> it would be automatically loaded *before* that service
<Keybuk> if you added an /etc/apparmor.d/init/sreadahead, then it's automatically used, etc.
<Keybuk> maybe it's not how things work
<Keybuk> but it's a nice idea if it is
<kees> instead of an "init" subdirectory, why not just look for the daemon name?
<Keybuk> that would work too
<superm1> pitti, re bug 193970, are you using the dell-laptop kernel module?
<ubottu> Launchpad bug 193970 in linux "iwl3945 | iwl4965: Wireless can't be activated after disabling kill switch" [Medium,Fix released] https://launchpad.net/bugs/193970
<Keybuk> though all you have with "starting" is the $JOB name (filename under /etc/init without the dir or .conf)
<pitti> superm1: apparenlty
<kees> i.e. sreadahead is /sbin/sreadahead, so  exec [ -f /etc/apparmor.d/sbin.sreadahead ] && load_ze_profile
<kees> Keybuk: hrm
<kees> Keybuk: I see your point, and an init script could contain all kinds of things to confine
<superm1> pitti, mjg59 needs to write a patch that inserts an input filter to intercept a keypress of XF86WLAN in dell-laptop kernel module to be able to update dell-laptop's rfkill status
 * kees ponders
<superm1> (he hasn't yet)
<pitti> superm1: hm, how did that work before?
<superm1> pitti, dell-laptop was introduced in karmicish kernels
<superm1> it's not worked perfectly since introduced because of this deficiency
<Keybuk> kees: right
<superm1> any other problems with <karmic were different
<ScottK> Lovely.
<cjwatson> al-maisan: excellent
<kees> pitti: any thoughts on bug 422392 ?  This will be needed for security update handling too.
<ubottu> Launchpad bug 422392 in devicekit-disks "devicekit-disks (and devicekit-power) need to be stopped when new package is installed" [Medium,Confirmed] https://launchpad.net/bugs/422392
<pitti> superm1: ah, thanks; I added that info to the bug report
<pitti> ogasawara: it's bug 430809 now, but seems it's not just reapplying the old patch then :-(
<ubottu> Launchpad bug 430809 in linux "[Dell Latitude D430, iwl3945] Wireless can't be activated after disabling kill switch" [Undecided,New] https://launchpad.net/bugs/430809
<pitti> kees: looking
<superm1> pitti, mjg59 said two or three days ago when i pinged him that it's "On his list", but he said that two weeks ago when i pinged him too :(
<pitti> kees: I agree; incidentally, I already did that some days ago in dk-power :)
<nixternal> Keybuk: need any testing help with the latest changes and encrypted drives? they seem to be the only issue I am facing now with the new upstart stuff
<Keybuk> nixternal: cryptsetup needs to be ported to use udev rather than an init script
<nixternal> groovy, so you are all good then
<kees> pitti: oh good!
<pitti> kees: if that's really the cause for bug 403192, you deserve a big big hug :)
<ubottu> Launchpad bug 403192 in devicekit-disks "update-notifier crashed with SIGSEGV in gdu_pool_get_devices()" [High,Confirmed] https://launchpad.net/bugs/403192
<kees> pitti: well, it's absolutely the cause of it continuing to crash even after it was fixed.  :)
<pitti> kees: I keep forgetting that some people never reboot ;)
<kees> (where "absolutely" is defined by "totally went away after I restarted dk-disks)
<kees> pitti: heh
<kees> speaking of never rebooting, I'm now going to reboot with my shiny new keybuk-ified boot process...
<ccheney> ogra: ping
<doko> Keybuk: start udev does start, then I get hundreds of messages "UNEXPECTED INCONSISTENCY, Superblock last mount time is in the future". after that I can't enter anything, did the fsck, started udev, and gdm did come up
<ccheney> ogra: i wonder if the new version of boost could possibly be causing the problem with arm on karmic
<ccheney> ogra: boost in jaunty is 1.35 but is 1.38 in karmic, perhaps using 1.35 might help with a karmic build?
<ccheney> ogra: unfortunately 1.35 is not in the archive for karmic but is still in jaunty so maybe could be tested by pulling it from there, if you are doing a manual build
<kees> hmpf, my resolv.conf was empty.
<ScottK> ccheney: We switched to 1.38 right after UDS, so I doubt it's causing anything new.
<mathiaz> cr3: hey - planning another upload of checkbox before alpha6?
<ccheney> ScottK: i don't know how long OOo has been busted on arm though
<kees> Keybuk: so, usplash didn't work, and xsplash didn't work.  how do I fix/debug ?
 * ScottK nods.
<ccheney> ScottK: its not used all that much so unless the mobile team does regular testing it might still be that
<ccheney> ScottK: and afaik the only dist that uses/tests arm much is us
<ccheney> ScottK: debian has an arm port but i don't know if anyone actually uses OOo on it
<\sh> kees: I read your blog article about removal of sun-java6 ;) one question: does openjdk have already the security manager of sun-java{5,6} (used e.g by tomcat{5,6})?
<kees> \sh: dunno -- I think so.
<ScottK> ccheney: Also we got some new patches ~recently.
<kees> \sh: I don't know how to test it, but I imagine it would stand out if it was missing
<\sh> kees: afaik it doesn't because of some strange licensing issues of sun...I could be wrong, but that's why most people use sun-java6 and tomcat6 app server
<ion> Removal of sun-java6, huh? A certain major (...ly sucking) Finnish bank seems to require sun-java6 for their web bank interface, openjdk doesnât seem to work there.
<ccheney> ScottK: new patches to boost?
<kees> ion: no worries, I suspect sun-java6 will (unfortunately) be staying
<cjwatson> Keybuk: would you mind if I turned usplash on for live CDs?
<\sh> kees: easy testing: vi /etc/default/tomcat6 -> TOMCAT6_SECURITY=yes, if openjdk has this feature, tomcat6 will start, if not it will break horribly and won't start up properly;)
<cjwatson> Keybuk: or do you actively prefer it off at the moment?
<ScottK> ccheney: It's a month ago, but a lot more recent than when we switched to it (in May): https://launchpad.net/ubuntu/karmic/+source/boost1.38/1.38.0-6ubuntu3
<ccheney> ScottK: ok
<ccheney> ScottK: thanks for the pointers, hopefully that will be what caused the problem
<kees> \sh: yes, tomcat6 loads with TOMCAT6_SECURITY=yes and openjdk-6
<slangasek> cjwatson: fwiw, I tried to turn usplash back on for cryptsetup, and it didn't take; I was going to investigate in a little bit
<cjwatson> slangasek: ok, I'll do other more productive things then
<jdstrand> kees: iirc, and I am no expert on this, but I thought all the security manager stuff was resolved when they released openjdk. ie, that and a few other things were blockers on it being open and functional
<jdstrand> certainly by the time we started using it...
<kees> jdstrand: yeah, that's what I thought too, so \sh's test just confirms that.
<sivang> hi all
<sivang> I want to get a dell notebook, it uses intel gma 950 - will it work with future version of ubuntu other then the one preloaded by dell ?
<sivang> is it an open source driver ?
<sivang> sorry for the noise, question been answered in #ubuntu
<Keybuk> cjwatson: I think it can go on for live cds
<Keybuk> cjwatson: assuming you've tested mountall and it doesn't hang on them ;)
<nixternal> note to those with encrypted drives: once you get to the shell using the shell.conf you can do '/etc/init.d/cryptdisks start' to get where you need to go :)
<nixternal> if that hasn't been mentioned yet of course
<nixternal> Keybuk: could I add 'exec /etc/init.d/cryptdisks start' or such to my shell.conf file to automatically continue on instead of having to do it manually?
<Keybuk> nixternal: I'm thinking that a short-term solution would be to simply start "cryptdisks" on stopped udevtrigger
<Keybuk> it wouldn't fix bugs where you had encrypted disks that took longer than a udevsettle to appear
<Keybuk> or encrypted lookback files on NFS
<Keybuk> but they never worked before anyway
<Keybuk> (whereas unencrypted versions of the above, which didn't work before, now *do* work)
 * nixternal needs to read up on upstart
<nixternal> I have to say, good work dude under this pressure :)  almost there, and a bit faster too
<Keybuk> the "bit" seems to vary wildly
<Keybuk> it's 7s faster on the reference hardware
<nixternal> hehe, true
<Keybuk> something ridiculous like 45s faster on ogra's ARM board
<nixternal> it is quite a bit faster, noticeably on my netbook, but I never ran bootchart on it previously
<Keybuk> but exactly the same speed on my Dell laptop
<ScottK> nixternal: Luckily you've got the reference system.
 * ScottK recently hit reboot (also on the 10v) and looked over to see how it was going and was suprised to the the login dialogue staring at me)
<nixternal> ya, same here
<nixternal> I keep rebooting just to see it go fast :)
<robbiew> :)
<nixternal> robbiew: hey, I heard my buddy Yosi's kid and yours go to the same school down there in Austin
<nixternal> guess your license plate caught his attention :)
<jdstrand> Keybuk: hi. I feel like I am missing somthing very obvious. is there a wiki page on the proper way to convert from sysv initscript to upstart?
<ScottK> it would be handy if an archive admin with shell access could look at 364630 and sync libchamplain and pyclutter.  They are tied up in a bit of a transitional mess in Universe.
<Keybuk> jdstrand: no, no wiki page
<ScottK> jdstrand: You have to crawl into Keybuk's head to find out.
<cjwatson> jdstrand: 'man 5 init' might help
<nixternal> hehe...
<Keybuk> also man 7 {start,stop}{ing,ed}
<jdstrand> cjwatson, Keybuk: cool, thanks :)
<robbiew> nixternal: ;)
<Keybuk> jdstrand: files in packaging are named debian/<package>.upstart
<Keybuk> and installed by dh_installinit
<jdstrand> excellent, thanks
<cjwatson> ScottK: will do when I can get mass-sync.py to stop hating me
<ScottK> cjwatson: Thanks.
<kees> pitti: in one you used killall, in the other you used pidof + kill.  any reason?
<pitti> kees: for some reason yet unknown to me, killall /usr/lib/devicekit-disks/devkit-disks-daemon fails for me half of the time
<jdstrand> Keybuk: is 'started on net-device-up lo' a valid way to start something after the loopback device is brought up?
<kees> oh, ew
<pitti> kees: killall devkit-disks-daemon works, but that's too imprecise for my taste
<pitti> kees: I'll change dk-p to use the same
<kees> pitti: yeah
<Keybuk> jdstrand: it should work
<jdstrand> Keybuk: really, I just want to start something before networking is started. I looked at networking.conf and network-interfaces.conf and it wasn't immediately apparent how I would want to do it...
<jdstrand> Keybuk: if that'll work, I'll give it a go then
<ccheney> is linux smart enough to not schedule on a ht virtual core if there are idle real cores?
<Keybuk> what do you want to start before networking?
<jdstrand> Keybuk: the firewall
<Keybuk> why not just:
 * ccheney is trying to decide whether to buy a i5 750 or i7 860, hopefully will help build OOo much faster
<Keybuk>   start on starting network-interface or starting networking ?
<Keybuk> but put the stuff to bring the firewall up in pre-start and down in post-stop
<Keybuk> so that "firewall" is up when the rules are loaded
<Keybuk> otherwise it'll get run every time an interface comes up
<jdstrand> Keybuk: I was thinking about that, but thought network-interface might make it more than I want it to. and wasn't sure that networking was enough
<Keybuk> depends
<Keybuk> network-interface is each ordinary interface
<Keybuk> networking is there because I'm a coward
<Keybuk> I don't think we *need* networking anymore
<Keybuk> ifup -a should be a no-op
<Keybuk> as either the interface was brought up by udev
<Keybuk> or the underlying device doesn't exist, so can't be brought up anyway
<jdstrand> Keybuk: actually, it wouldn't be horribly bad if the start ran slightly more often than desired for corner cases, the 'start' I would use is smart enough to not do anything if the firewall is already started
<jdstrand> I'll try 'start on starting network-interface or starting networking' then
<Keybuk> it would be bad
<Keybuk> it's expensive
<davmor2> ccheney: foolish mortal it doesn't speed anything up honest ;)
<Keybuk> having lo, eth0 and eth1 is not a corner-case, it's the common case :p
<jdstrand> Keybuk: that was why I initially thought I wanted to do this after 'lo' came up only
<jdstrand> Keybuk: is IFACE available to me?
<ccheney> davmor2: heh
<cjwatson> ScottK: done - there's a messy bug in mass-sync.py, I just hacked around it for the moment since I'm out of time
<ScottK> cjwatson: Thank you.
<soren> Keybuk: We don't need the networking job? Do we have new ways to deal with bridges, bonded interfaces, and other "virtual" interfaces?
<cjwatson> kirkland: is Etienne's comment in bug 430820 about setting eth0 to manual correct?
<ubottu> Launchpad bug 430820 in eucalyptus "eucalyptus node install results in broken /etc/network/interfaces" [High,Triaged] https://launchpad.net/bugs/430820
<cjwatson> it feels surprising to me
<Keybuk> soren: they still have entries in /sys/class/net
<kirkland> cjwatson: i didn't have to do that
<soren> Keybuk: I do believe the logic we used to have is horrible. bonded interfaces should be configured when the last of the slave interfaces is configured. Bridges could be created immediately and the related interfaces could get added when they turn up..
<kirkland> cjwatson: my routing table looks okay
<soren> Keybuk: Yes, when they get configured?
<kirkland> cjwatson: and seems to work, moreover
<Keybuk> soren: right, I think you're following me though
<kirkland> cjwatson: well, work meaning my nc get's a dhcp address
<Keybuk> we should do them on the tail of other interfaces, not in one big drop
<soren> Keybuk: Pray tell :)
<soren> Keybuk: Oh, yes, indeed.
<Keybuk> if you bond eth0 and eth1, then you should do that when you have eth0 and eth1
<cjwatson> kirkland: I've asked Etienne to file a separate bug for that, then
<soren> Keybuk: I'm just not sure why you think we're there?
<soren> Keybuk: Precisely.
<kirkland> soren: cjwatson: i have a fix for eucalyptus-cc init script
<kirkland> cjwatson: did you do the netstat check for the cloud being up?
<cjwatson> I wrote it, yes
<Keybuk> soren: I think we have everything we need to do that
<cjwatson> it's a hack of epic proportions
<Keybuk> I'm just not going to change that too :p
<kirkland> cjwatson: http://paste.ubuntu.com/272265/
<kirkland> cjwatson: can you take a quick look at the init script portion of that patch
<soren> Keybuk: We have the tools, but not the actual scripts... Right? Or do you have something up your sleeve that I don't know about? :)
<kirkland> cjwatson: i don't think your counter was working
<Keybuk> soren: right, exactly
<soren> Keybuk: Ok.
<soren> Keybuk: I would loooove to get that fixed for Karmic+1.
<soren> Keybuk: It's been bugging me for ages.
<kirkland> cjwatson: also, eucalyptus upstream asked for some logic to make sure that a cloud-controller is actually expected on this system
<cjwatson> kirkland: oh, that's just because I didn't check it
<kirkland> cjwatson: hence the -x cehck
<soren> Keybuk: I just didn't realise you'd be doing the whole networking thing from upstart, but it makes perfect sense.
<cjwatson> kirkland: instead of the if, how about '&& [ "$i" != 0 ]'? :-)
<cjwatson> kirkland: upstream weren't reading very closely, then ;-)
<cjwatson>         if [ ! -e /usr/share/eucalyptus/eucalyptus-cloud-@EUCA_VERSION@.jar ]; then
<cjwatson>                 return # no cloud here
<cjwatson> kirkland: further up in the same function
<cjwatson>         fi
<soren> Keybuk: That will also make iscsi a much happier place. Ooh, I can't wait. :)
<kirkland> cjwatson: ah, i missed that too
<cjwatson> kirkland: I think: http://paste.ubuntu.com/272279/
<kirkland> cjwatson: that looks good by me
<kirkland> cjwatson: let me test it here
<cjwatson> committed, as I think that has to be an improvement
<cjwatson> and I have to run :)
<cjwatson> should we try to get a new version of eucalyptus into alpha 6?
<cjwatson> if so it'll need to be very very soon
<kirkland> cjwatson: i think so
<kirkland> soren: are you planning to roll a new eucalyptus for alpha6?
<kirkland> soren: if so, see cjwatson's comment about "very soon" ^
<soren> kirkland: I /could/.
<Laney> Anyone want to help debug my unbootable system? http://orangesquash.org.uk/~laney/noboot.jpg :)
<Laney> did dist-upgrade already
<kirkland> cjwatson: actually, the network bridging isn't quite right yet ...  i'm debugging
<cjwatson> kirkland: ok, if you could fix it when you figure it out then I'd appreciate it - I have to run now
<ion> laney: First of all, did you boot without the quiet parameter?
<kirkland> cjwatson: sure thing
<Laney> ion: sure did
<kirkland> cjwatson: i think we're just missing an auto br0
<Keybuk> Laney: looks like you're using tux on ice or something?
<Laney> I have no idea what that is
<Laney> my root partition is on mdadm
<ion> laney: ls -l /dev/disk/by-uuid, see what /dev entry the UUID printed on the âmounting ... failedâ line points to, run mount /dev/THAT /root. Any output other than â...failed: Device or resource busyâ? Run dmesg. Anything interesting?
<Keybuk> ion: it's probably busy because the kernel things it's resuming maybe ?
<Keybuk> oh, no, different UUID
<Keybuk> ignore me
<cjwatson> kirkland: makes sense
<cjwatson> kirkland: that was in the documentation I was working from, so just a slip on my part
<kirkland> cjwatson: okay, i can fix it
<kirkland> cjwatson: goes in that udeb postinst?
<kirkland> cjwatson: if not, just give me a pointer
<Laney> So it seems to be trying to boot from /dev/sda1 instead of /dev/md0p1
<soren> kirkland: http://bazaar.launchpad.net/~ubuntu-core-dev/eucalyptus/ubuntu/revision/552 you can just create them like that? Really?
<Laney> I see "Starting manual resume from disk" in dmesg, too
<Laney> ion: ^
<Keybuk> Laney: can you run "blkid" from there
<cjwatson> kirkland: not the postinst, debian/eucalyptus-udeb.finish-install, setup_bridge_device
<Laney> it did bring up the array just fine
<Keybuk> and get a photo of the output
<Laney> Keybuk: oh, sure
<soren> kirkland: Well... You should probably fix up the permissions, but I mean... They will work as block devices?
<Laney> md0p1 and sda1 have the same UUID
<kirkland> soren: dude, you asked me to add changelog entries, no?\
<Laney> and then there's sda5 and md0p5 which are also the same (swap)
<kirkland> soren: oh!  you mean create loop devices :-)
<soren> I... did..?
<Keybuk> Laney: yeah
<cjwatson> soren: no reason they shouldn't - and yes, should be mknod -m660
<Laney> one second
<Keybuk> now if you look in /dev/disk/by-uuid where do they point?
<soren> and chgrp disk.
<kirkland> soren: i thought you were griping at me about creating an unreleased eucalyptus changelog :-)
<cjwatson> yes
<soren> kirkland: Nono, dude, I do that all the time :)
<kirkland> soren: yeah, kernel guys said our kernel is configured with loop=0, which means that 8 will be created by default, more can be created in userspace
<cjwatson> kirkland: oh, I think you need to do $(($LOOP_SUG - 1) not $((LOOP_SUG - 1) - there have been shell bugs about the latter
<kirkland> soren: otherwise, if it's >=0, then the limit is fixed, can only be overridden with kernel boot options
<cjwatson> dash at least used to fail to handle the latter as specified by POSIX
<soren> cjwatson: Well... the loop driver in the kernel allocates a bunch of structures for the 8 loop devices it starts out with. I didn't notice any code to automatically allocate more, but I didn't look that closely.
<Laney> Keybuk: http://orangesquash.org.uk/~laney/noboot2.jpg ... looks right?
<kirkland> cjwatson: thanks, i just saw your $(($i-1)) and had to go test your way to believe you :-)
<cjwatson> soren: I'm fairly sure from past memories that you can just create them
<kirkland> cjwatson: and then second-guessed my way
<soren> Oh...
<cjwatson> kirkland: yeah, that habit has a reasson behind it :)
<cjwatson> -s
<kirkland> soren: i created them here, worked like a champ
<soren> kirkland: Right, I may have only looked at the !=0 code path.
<Keybuk> Laney: in that it's exactly wrong, yes
<kirkland> soren: though cjwatson is right about the perms
<Laney> hah
<kirkland> cjwatson: i'll fix those two things now
<cjwatson> well, soren pointed them out first
<jdstrand> Keybuk: can you peek at http://paste.ubuntu.com/272290/ and let me know if I am going down the right path? this is my first upstart script
<soren> kirkland: And ownership.
<Laney> bug or user error?
<soren> kirkland: (group should be disk)
<Keybuk> jdstrand: don't think you want "6" in the stop on
<kirkland> soren: btw, should we go ahead and define CLOUD_PORT=8773 in eucalyptus.conf?
<soren> kirkland: I really have no opinion on that subject.
<kirkland> soren: as that's used in a couple of places now in the init scripts, though perhaps not yet universally supported
<jdstrand> Keybuk: no. that was intentional. it should not be brought down on restart
<cjwatson> coo, didn't know that upstart scripts were automatically set -e. nice.
<Keybuk> jdstrand: but brought down on halt and entering single user mode?
<soren> kirkland: If that fixes something for you, sure.
<kirkland> soren: k
<cjwatson> Keybuk: BTW the documentation isn't entirely clear on whether -e is used for {pre,post}-{start,stop} script as well as plain script
<jdstrand> Keybuk: well, single-user yes, halt no. I should add 0
<Keybuk> cjwatson: oh, it is ;)
<Keybuk> jdstrand: ok
<Keybuk> jdstrand: you're also missing "end script" after each of the script blocks
<Keybuk> jdstrand: and style says the /lib/ufw/... line should be preceeded by exec
<Keybuk> jdstrand: also, what's with the [ "$IFACE" = "lo" ] bit?
<Keybuk> jdstrand: if you only want to do this on loopback, just do "start on net-device-up IFACE=lo"
<cjwatson> Keybuk: I can read it either way, I think :)
<Keybuk> jdstrand: and that should be "start on" not "started on"
<Keybuk> jdstrand: oh, and style: description "Uncomplicated firewall"
<jdstrand> Keybuk: was not aware of net-device-up IFACE=lo syntax. will adjust
<jdstrand> Keybuk: ufw-init is a shell script, does that matter wrt style and exec?
<ion> keybuk: Interesting. I ran blkid on a jaunty system. I have ext2 on md127 on sd{a,b}1. I also have lvm on md126 on sd{a,b}3. blkid printed the identical UUID="foo" TYPE="ext2" for each of sda1, sdb1 and md127. It printed UUID="bar", TYPE="mdraid" for sd{a,b}3 and UUID="baz", TYPE="lvm2pv" for m126.
<Keybuk> jdstrand: it means that the pid stays the same
<Keybuk> jdstrand: saves you a fork()
<Keybuk> (and ptrace overhead)
<jdstrand> Keybuk: ok, will change and test. thanks for the feedback!
<Keybuk> jdstrand: though the comment looks good
<Keybuk> jdstrand: nothing to review in that
<Keybuk> (having just realised he said something about every single other line)
<jdstrand> heheh
<ion> keybuk: Is it just good luck that /dev/disk/by-uuid/33a915c6-874d-4d17-8de5-02afb786480e points to /dev/md127 here and not /dev/sda1 or /dev/sdb1? :-)
<Keybuk> cjwatson: everything is -e because not using -e kills kittens
<jdstrand> actually, I think the 'pre-start script' lines and the whitespace was ok...
 * Laney bounces
<Keybuk> jdstrand: yes, good whitespace!
<jdstrand> \o/
 * jdstrand strives for good whitespace over everything else
<soren> ion: md*127*?!? Seriously? Are md0-md126 all in use?
<kirkland> soren: okay, mknod fixes pushed
<kirkland> soren: using $LOOP_SUG as cjwatson suggested, chowning root:disk, and perm'd 660
<kirkland> soren: whoops, push failed, divergence
<soren> Where'd you push it?
<soren> ah.
<soren> Yeah, that's me :)
<kirkland> soren: uno momento
<soren> Sure.
<ion> soren: When creating the array, i experimented with some mdadm parameter for array name, hoping it would create device names like md-foo. Instead, it gave them numbers beginning from 127 and going down. I didnât feel like recreating the arrays just to get the numbers lower. :-P
<cjwatson> Keybuk: oh, I quite agree
<Laney> so who's bug is this? and can I get out of it?
<Keybuk> Laney: unsure
<Keybuk> it's either a blkid bug
<Keybuk> or a udev bug
<Laney> happy to help debug
<soren> Keybuk: Did you follow the conversation above about automatically created loop devices?
<Keybuk> soren: nope
<soren> Keybuk: Ok.
<soren> Keybuk: Short version: The kernel creates 8 of them on boot, but you can just mknod more of them, and the driver handles allocating the kernel structs and all that jazz.. Is there a way to make udev set the right permissions for them?
<kirkland> soren: okay, let me fix the network bridging issue ...
<soren> Keybuk: Right now we're mknod'ing them, followed by mknod and chmod, which obviously will not follow changes made in the udev rules.
<soren> Er... followed by chgrp and chmod. Not mknod again, obviously.
<Keybuk> soren: yeah, loop is broken
<soren> Keybuk: Heheh :)
<Keybuk> soren: it should be some kind of /dev/pts-a-like
<Keybuk> or /dev/loopctl
<Keybuk> so you ask for a new one, a kobject appears, and then udev can create the node
<soren> Yeah.
<nixternal> don't call it /dev/nixternal, as it may disappear from time-to-time :p
<Keybuk> now devtmpfs has gone mainstream, people may actually care
<kirkland> soren: okay, pushed /etc/network/interfaces fix too
 * hunger had a really strange problem, making it impossible to boot jaunty today.
 * Keybuk tries to isolate the electrical/plastic burning smell in his office
<ion> keybuk: blkid output with some structure added for clarity: http://pastebin.ca/1568672
<hunger> Somehow I ended up with a partition that the system considers to be LUKS encrypted even though it is not. Yesterday that was no problem, after installing the updates boot broke this morning due to this.
<hunger> So if somebody else is seeing boot problems after yesterdays round of updates, it might be worth your while to check your partitions for LUKS encryption:-)
<soren> kirkland: How do you update the changelog?
<kirkland> soren: dch -e
<pochu> pitti: hey, I've reported Debian #546967, in case you are interested
<ubottu> Debian bug 546967 in wnpp "RFP: media-player-info -- media player identification files" [Wishlist,Open] http://bugs.debian.org/546967
<soren> kirkland: Ah, that explains.
<kirkland> soren: as opposed to ...?
<kirkland> soren: you're looking at the timestamp/signature that gets updated?
<Keybuk> ion: can you join #udev and debug with kzak/kay
<soren> kirkland: If you just use "dch 'whatever you want in the changelog'", dch will handle breaking lines and all that stuff.
<kirkland> soren: ah
<soren> kirkland: Yes, the timestamp thing caught my attention :)
<soren> kirkland: dch called like I just said will not touch the timestamp.
<kirkland> soren: okay, i'll use that when touching your packages :-)
<soren> kirkland: Ta :)
<soren> So, are we all happy with this revision?
<kirkland> soren: did you clear the mknod hack with Keybuk ?
<kirkland> soren: what was the outcome of that?
<soren> kirkland: I think the conclusion was that loop is broken.
<slangasek> mknod?? <gibber, gibber>
<kirkland> soren: okay, then i'm fine with it, several bugs fixed, better than before :-)
<kirkland> soren: i pushed rev 557
<Keybuk> kirkland, soren: what was the hack
<kirkland> soren: for the record
<soren> slangasek: It turns out to be a well documented feature of the loop driver :)
 * Keybuk has put out the fire
<e-jat_> anyone know how to solve this bug 428365
<ubottu> Launchpad bug 428365 in ubuntu "Karmic Koala Alpha 5. Desktop does not start, freezes the boot screen" [Undecided,New] https://launchpad.net/bugs/428365
<soren> Keybuk: We were hoping you'd provide the hack.
<ion> keybuk: What was it? :-)
<Keybuk> ion: the US four-gang
<Keybuk> I think it's given up
<Keybuk> it had little flames and everything
<soren> slangasek: If you need more loop devices, you just mknod them, and the driver does some magic. We need more loop devices, so we mknod them.
<soren> Keybuk: That's /usually/ a sign of giving up.
<ion> keybuk: Parse error
<slangasek> soren: I'm putting my fingers in my ears and wandering back over to the alpha 6 zone
<Keybuk> uh
<Keybuk> fire started again
<Keybuk> brb
<soren> slangasek: See you there..
<Keybuk> and put out again
 * Keybuk has unplugged the gang this time
<Keybuk> (and put it outside, away from the expensive computers and expensive humans)
<nixternal> haha, you are working so hard you are starting fires..that is just scary :)
<kirkland> soren: actually, i missed a bug number in the changelog
<kirkland> soren: if you want to add 430820
<soren> kirkland: Naughty, naughty.
<soren> kirkland: Can you do it yourself?
<kirkland> soren: doing...
<Keybuk> nixternal: you know you're having a bad day, when ...
<mathiaz> kirkland: could you also add bug 425926?
<ubottu> Launchpad bug 425926 in eucalyptus "Eucalyptus 'Store' tab requires appliance store proxy package " [Medium,Triaged] https://launchpad.net/bugs/425926
<nixternal> hehe
<Keybuk> unfortunately I now have a Michael McIntyre sketch going through my head
<mathiaz> kirkland: to my changelog entry
<kirkland> soren: pushed 558
<Keybuk> Whoah-oh, my sex^Wnetbook is on fire!
<kirkland> mathiaz: sure
<mathiaz> kirkland: I've discovered the bug after I had pushed/merged my branch
<soren> kirkland: ta.
<kirkland>   [ Mathias Gug ]
<kirkland>   * Recommend python-image-store-proxy for eucalyptus-cloud. The Image Store
<kirkland>     feature won't work without it, LP: #425926
<nixternal> the netbook, the netbook, the netbook is on fire, we don't need no water let the lil bastard burn!
<kirkland> mathiaz: soren: done, pushed
<soren> kirkland: I'll do a test build and upload if it looks decent.
<kirkland> soren: thanks, let me know if you want some more testing too
<nurmi> hi all; I was hoping that we might have a quick discussion regarding the Eucalyptus init scripts
<soren> cjwatson: Did you leave?
<kirkland> nurmi: sure, shoot
<kirkland> mathiaz: connectivity issues?
<slangasek> soren: he did
<soren> Darn it.
<mathiaz> kirkland: well - my X server crashed - but I was using byobu to run irssi
<nurmi> kirkland: i've been trying out the latest package, and found one issue regarding the ordering of installation/init script starting
<nurmi> bug here: 430841
<soren> bug 430841
<ubottu> Launchpad bug 430841 in eucalyptus "after package install of eucalyptus-cloud, walrus, sc, only cloud service is loaded" [Undecided,New] https://launchpad.net/bugs/430841
<mathiaz> kirkland: however I'm using a the notitication command to send highlights to my desktop, which uses dbus
<slytherin> what all information is needed when filing a bug against pulseaudio?
<mathiaz> kirkland: and the dbus session went away when X crashed and I restarted my gnome session - reconnecting to the existing screen session failed to pick up the dbus session
<Treenaks> slytherin, doesn't "ubuntu-bug pulseaudio" supply everything now?
<nurmi> soren: ah, cool :).  I put in a few possible solutions that in the report, but wanted to chat about whether you have other ideas/concerns
<kirkland> mathiaz: byobu/irssi should have kept you connected, no?
<mathiaz> kirkland: probably the same issue as the ssh-agent socket when you login/logout in  machine and reconnect to an existing machine
<slytherin> Treenaks: I haven't tried
<mathiaz> kirkland: yes - it kept me connected - but it was using the old dbus session
 * Treenaks wonders why his scroll lock led has started blinking 
<kirkland> mathiaz: hrm, sounds similar to the ssh-agent issue
<mathiaz> kirkland: so highlights would not get sent to my desktop - instead I have an error message printed in my irssi window
<mathiaz> kirkland: which is very annoying
<soren> Hmm...
<soren> nurmi: I wonder if upstart would be helpful here at all.
<soren> nurmi: Or just make matters even more complicated.
<nurmi> soren: i'm not familiar with upstart, what is the basic idea?
<kirkland> nurmi: event-based service startup
<nurmi> nurmi: oh, right, spaced on the name.
 * nurmi talks to himself
<nurmi> soren: can the event be 'file is in place'?
<soren> I'm not sure, to be honest. This is all very, very new to me as well.
<soren> nurmi: Keybuk knows.
<ion> nurmi: File notification based events are in TODO, but not with very high priority.
<nurmi> ion: i see, what type of events are currently supported?
<kirkland> nurmi: soren: Keybuk has spoken to me before about inotify-driven upstart; i don't think we have that in karmic, though
 * kirkland could be wrong, however
<Keybuk> no, not yet
<Keybuk> it's on the TODO
<ion> Just a handful of events sent by Upstart itself (âstartupâ, âcontrol-alt-deleteâ etc.), the starting/started/stopping/stopped events for jobs and anything emitted by system scripts. And perhaps something else i forget.
<soren> nurmi: This is only a problem at package install time, though, right?
<nurmi> soren: correct
<nurmi> ion: i see, thanks; i'm also reading about upstart now, very cool :)
<nurmi> soren: what do you think about the idea of installing the service files as '.disabled' by default?
<ttx> soren: any progress on alpha6 image generation ?
<nurmi> soren: this would ensure that when init scripts 'start' the first time, the service will be loaded
<soren> nurmi: Where are these service files located?
<soren> ttx: The UEC images?
<ttx> soren: yes
<soren> ttx: http://uec-images.ubuntu.com/karmic/20090916
<soren> ttx: With MD5SUMS, manifests and everything.
<nurmi> soren: /usr/share/eucalyptus/
<ttx> soren: they don't show up on the test tracker
<soren> nurmi: Ungh... Modifying anything in there is not kosher.
<soren> ttx: Ah.
<soren> smoser: Can you take care of that?
<nurmi> soren: there may be another option, although I havn't tested it much
<soren> nurmi: Pray tell :)
<nurmi> soren: each of the eucalyptus-cloud/walrus/sc init scripts ultimately ends up calling '/usr/sbin/eucalyptus-cloud'
<nurmi> soren: that program is the bootloader for any webservice that exists in /usr/share/eucalyptus
<smoser> can i take care of what ?
<soren> smoser: Make the UEC images turn up in the test tracker.
<nurmi> soren: the command itself takes disable arguments, for example: --disable-cloud, --disable-walrus, --disable-sc
<smoser> um.. i can try. do we think its reasonable to believe that these could turn into alpha-6 ?
<soren> smoser: We will only know by testing them :)
<nurmi> soren: so that, even if the service file exists, one can 'disable' it using these options
<ttx> smoser: unless we test them, we'll never know
<smoser> thats not true
<soren> brb
<smoser> we can no that they will not be alpha-6 if we know of major issues in the packages they contain
<smoser> thats what i was asking, if there were any known issues as of an hour ago or so in the archive that would prevent it
<ttx> smoser: even in that case, it's good to know if there weren't any other issue, which the tests would unearth
<slangasek> smoser: none in the general case
<ttx> smoser: respins should be triggered by test failures on the tracker anyway
<smoser> how do i add these things ?
<smoser> to the tracker ?
<ttx> so it's always good to do it :)
<ttx> smoser: if I knew, I wouldn't ask.
<smoser> slangasek, ?
<slangasek> smoser: you tell me or stgraber what you have available for testing that you want on the tracker
<smoser> slangasek, http://uec-images.ubuntu.com/karmic/20090916/
<ttx> smoser: was this image bundled/uploaded to EC2 ?
<smoser> and, slangasek i'm in the process of what ttx is asking
<slangasek> ack
<slangasek> whoo manifests
<ttx> and MD5SUMS :)
<slangasek> are you hand-generating this md5sums file?
<smoser> so i'll bother you with the ami's later today
<smoser> slangasek, md5 is part of the tools now
<slangasek> ttx, smoser: there are scripts to do md5sums generation and sign them; we should use those (but blocked on an RT to let our users share files)
<slytherin> Treenaks: ubuntu-bug helped a lot. :-)
<slangasek> smoser: please don't reinvent the wheel here, we should reuse the cdimage toolkit we already have
<smoser> but i like inventing wheels
<slangasek> (yes, md5sum is a very small wheel - but sign-cdimage is less of one)
<ttx> smoser: square ones ?
<smoser> no, but seriously,  i didn't know. i agree, i'll use whatever is available
<slangasek> smoser: hmm, let me bounce you the relevant emails then; I thought you'd been cc:ed
<smoser> slangasek, point me at it and we'll do that for beta
<slangasek> smoser: /home/vmbuilder/cdimage
<slangasek> <handwave>
<slangasek> email to follow :)
<slangasek> smoser: you were cc:ed on the mail; Message-ID: <20090916005543.GB8869@dario.dodds.net>
<smoser> ok. i'll dig.
<Laney> Keybuk: please let me know if you isolate a fix... wouldn't mind a bootable system again
<slangasek> if you need me to resend, let me know
<Keybuk> Laney: I wouldn't expect me to isolate your fix until at least next week
<Keybuk> it's unrelated to the init transition
<Laney> ok
<Keybuk> you could temporarily work around it by booting with root=/dev/md0p1
 * Laney nods
<soren> nurmi: Why not just have one init script?
<kirkland> cjwatson: actually, etienneg is correct, in practice about the "manual" thing
<jjardon> hello, I have a problem with devhelp: $ devhelp
<jjardon> devhelp: error while loading shared libraries: /usr/lib/libgstbase-0.10.so.0: file too short
<jjardon> is this bug already filled?
<wasabi_> Weird question. Has something odd changed in Karmic that might effect speed and reliability of network connections?
<jjardon> (karmic here)
<wasabi_> Specifically, I can now only scp files at around 4k a sec, and all CIFS file transfers fail. Oddly enough, they fail when done by a Windows VM running on karmic.
<wasabi_> It's like TCP is just falling over in some way.
<slytherin> jjardon: not reproducible here
<wasabi_> Wireshark shows lots of TCP out of order stuff, and lost segments.
<wasabi_> This is between my machine, and any other machine on the same LAN. =/
 * soren cries about not being able to rip cd's.. :(
 * soren reboots
<cr3> in a package, how can I create manpage aliases so that foo-gtk, foo-cli, foo-qt, etc. open the foo manpage?
<soren> Do we know when xsplash is supposed to start looking right? I.e. not like a horizontal bar that jitters up and down a bit, but something that looks like it
<slytherin> cr3: symply install symlinks
<soren> s spinning horizontally.
<nurmi> soren: we can have one init script, but i'm not clear on how one would be able to control the services independently
<soren> nurmi: Well, it doesn
<soren> t do that now anyway.
<soren> At least not when stopping things.
<nurmi> soren: ?  currently, you can stop/start any of the three services using the init scripts
<cr3> slytherin: I thought I could simply tell dh_installman to update the mandb with aliases
<nurmi> soren: granted, it does restart the process, but when the process comes back after, say, a 'walrus stop', then the walrus service is no longer running
<soren> Hmm..
<soren> Oh, right, I see what you mean.
<nurmi> soren: i was thinking that we could maintain a small state file in /var/run/eucalyptus (next to the pid files) that records which services are disabled (i.e. a 'stop' has been called)
<soren> When would I want to stop them individually?
<soren> Or start them individually?
<nurmi> soren: then, the init script can read that file and decide which services should not be running, and use the '--disable-<service>' flags to 'eucalyptus-cloud'
<soren> nurmi: Are you still there? :)
<nurmi> soren: we are going under the assumption that, for each unique 'package' or 'service', there is a way to control it independently
<soren> nurmi: Yes. And why is that?
<nurmi> soren: honestly, other than perception, the only reason I can think to start/stop them independently is if something goes wrong
<soren> nurmi: That sounds reasonable.
<nurmi> soren: or, if you decide that you want to bring down one sc/cluster for maintain while keeping the other services up
<soren> nurmi: I'm just not sure having that option available in this way is important enough to warrant the other issues we're seeing.
<nurmi> soren: i see, the alternative you're suggesting is one init script for all three packages?
<ulaas> hi! how do i add my windows boot to grub2?
<soren> nurmi: Yes. I haven't thought about this a whole lot, but doing it that way sure would have saved me a few surprises :)
<nurmi> soren: i think as long as one can still install the services indepently (i.e., install walrus/sc/cloud alone on their own machines), then a single init script would be fine
<soren> nurmi: And then perhaps a separate mechanism to disable a particular service.
<soren> nurmi: Perhaps an explicit "/etc/init.d/eucalyptus-java-stuff disable sc" or something.
<nurmi> soren: nod; do you forsee confusion around having an init script that is not named the same way as the package/service itself?
<nurmi> soren: i.e., if one installs 'eucalyptus-walrus', and the init script is called 'eucalyptus-java-stuff', is that an issue?
<soren> nurmi: A little bit. It depends on the new name, I suppose.
<soren> nurmi: Hm...
<soren> nurmi: It's a shame cjwatson isn't here. He seemed to have thought about this a bit.
<stgraber> Keybuk: hey, I'm currently working on fixing ltsp following the upstart changes. When booting, I don't have dbus and hal running, but they work fine after I manually start them, what should be done to have them start automatically ?
<stgraber> ogra: ^ that's the only issue I saw with yesterday changes (so far)
<nurmi> soren: we can defer for now and re-fire the conversation when cjwatson is around, if you like; i'm happy to chat anytime :)
<soren> nurmi: Even during European business hours? :)
<nurmi> soren: if thats what it takes!
<Keybuk> stgraber: why don't they start automatically?
<nurmi> soren: init scripts make great 4am conversation :)
<soren> nurmi: Well, right before our call tomorrow would probably be a good time, actually.
<nurmi> soren: is 'right after' off the table? I have a meeting the hour before tomorrow
<nurmi> soren: ah, thats getting late in EU
<soren> Probably not. I can't really make appointments on cjwatson's behalf, though :)
<nurmi> soren: lets see how it goes tomorrow, i'll try to be around as far before and after the call as I can
<soren> Cool.
<c_korn> can someone give a comment about bug 428657 ? only a small bug.
<ubottu> Launchpad bug 428657 in quilt "Quilt tries to write into series also if it is a directory" [Undecided,New] https://launchpad.net/bugs/428657
<stgraber> Keybuk: dbus used to started by S12dbus, now it's not there anymore and I'm just wondering what should be done so it gets started at boot time :)
<stgraber> (I haven't had a chance to look at how upstart works in much details yet)
<Keybuk> stgraber: check /etc/init/dbus.conf
<stgraber> Keybuk: hmm, what exactly is that "local-filesystems" ? our filesystem is mounted from the initrd in LTSP so that may be the issue ...
<Keybuk> stgraber: filesystems that are not remote
<ulaas> any ideas abou grub2 windows boot?
<stgraber> Keybuk: how can I manually check that condition ?
<Keybuk> stgraber: mountall --debug will tell you
<Laney> hmm
<Laney> /etc/udev/rules.d/z60_hdparm.rules is a dangling symlink and a message about that file (z60) is the last thing that is printed before my boot (appears to?) hang
<nixternal> Keybuk: sorry to bug ya, but do you have any doco somewhere re: upstart? I am messing around with a kdm setup now
<Keybuk> what would you like to know?
<nixternal> cherry picking from /etc/init/ is how I have started piecing a file together
<Keybuk> man 8 init is a reasonable place to start
<Keybuk> that'll lead you to man 5 init, man 7 {start,stop}{ed,ing} etc.
<Keybuk> I'll happily review anything you come up with ;)
<Keybuk> if you're doing kdm, it'd be neat if you could include the extra events I added to gdm as well
<nixternal> cool...i will probably pass something in front of you over the next couple of days...i will let you rest and catch up with everything else first :)
<Keybuk> immediately after xsplash is started I do:
<nixternal> don't need any more fires going on there from overworking :)
<Keybuk>   initctl -q emit login-session-start DISPLAY_MANAGER=gdm
<Keybuk> and after login/auto-login
<Keybuk>   initctl -q emit desktop-session-start DISPLAY_MANAGER=gdm
<nixternal> hrmm, I will look at that...i didn't see it in the gdm.upstart file in the package
<Keybuk> it's in /etc/gdm/Init/Default and /etc/gdm/PreSession/Default
<nixternal> groovy, thanks for that!
<stgraber> Keybuk: running mountall basically skips everything as already mounted and doesn't trigger dbus
<Keybuk> yes yes
<Keybuk> it's the log I want ;)
<Keybuk> --debug outputs lots of opinions about what mountall thinks
<stgraber> http://pastebin.com/f200368f
<Laney> boot hangs even with init=/bin/sh
<cjwatson> soren: back now
<soren> cjwatson: Ooh!
<soren> nurmi: ^
<seb128> hum
<seb128> kees, do you have any details about all the changes you are doing on crash bugs?
<seb128> kees, you just sent quite some emails in my bugsbox which I don't really know what to do about ;-)
<Keybuk> stgraber: nothing looks wrong here
<Keybuk> stgraber: what was your problem, again?
<jdstrand> Keybuk: fyi, what was needed was 'start on net-device-added INTERFACE=lo'. 'started' doesn't work
<Keybuk> jdstrand: yeah I said that ;)
<stgraber> Keybuk: dbus doesn't start on LTSP, so hal doesn't start and I end up with a X without mouse+keyboard
<Keybuk> right, but does mountall finish?
<cjwatson> soren: back now
<cjwatson> cr3: <hat maintainer="man-db">the correct way to get aliases into the manual page database is using symlinks</hat>
<stgraber> Keybuk: ah, mountall should return at some point ?
<Keybuk> stgraber: it usually does
<kees> seb128: hi! sure, in karmic I added some segv analysis fields to apport reports, so I'm now going back through old bugs adding them, since they can help narrow down the cause of crashes.
<Keybuk> if mountall is sitting there, and nothing starts, then that's a bigger problem than "no dbus"
<cr3> cjwatson: thanks, I created a foo-gtk.links under my debian directory after looking at a few other sample packges
<jdstrand> Keybuk: I'm having trouble having upstart reflect the true status of ufw. eg, if it is disabled, it still shows that it is 'running'. I'd like to tell upstart it isn't running
<seb128> kees, I fail to see anything useful in what you added so far to those bugs, do you have any example of what we can do with those lines?
<Keybuk> jdstrand: if it's disabled, exit 1
<jdstrand> Keybuk: right, but it exits with error then
<Keybuk> alternatively
<Keybuk> if it's disabled
<Keybuk>   stop
<Keybuk>   exit 0
<jdstrand> I don't think it is an error condition to have ufw disabled
<kees> seb128: yeah, I can search for "SegvReason: exec" and look for crashes that resulted from misdirected execution flows, which is almost always a security bug.
<Keybuk> but I would say exiting with an error is correct
<Keybuk> start ufw
<Keybuk> *should* exit with an error
<Keybuk> because what the sysadmin asked for did not happen
<kees> seb128: also, it gives a sense for if it was a NULL deref, or a more complex issue.
<kees> seb128: which should allow for easier triage.
<seb128> kees, do you have a wikipage or something explaining what errors should be considered as real issues?
<cr3> cjwatson: I then thought to myself that perhaps setup.py should handle manpages, ie the upstream project, rather than just the debian packaging. however, it seems that handling manpages is a distro thing rather than an upstream thing
<Keybuk> this is Upstart, not sysvinit ;)
<seb128> kees, or security issues
<kees> seb128: no, it's not really real vs unreal, it's just a helpful heuristic to add when triaging crashes.
<seb128> kees, ie "not located in a known VMA region (needed readable region)!" doesn't speak to me
<seb128> kees, any wtf for those? ;-)
<stgraber> Keybuk: strace shows it stuck on a select
<seb128> or dictionnary or something
<Keybuk> stgraber: so mountall *isn't* finishing?
<kees> seb128: I can write up a wiki page with some details
<stgraber> Keybuk: no
<seb128> kees, that would be nice, thanks
<Keybuk> stgraber: you could've mentioned that bit *first* :p
<kees> seb128: where would you think such a page would be most discoverable?
<seb128> kees, just being curious but what "vma" is?
<jdstrand> Keybuk: maybe I am having a hard time leaving sysv, but if we are in a boot situation, the admin didn't say 'start', the boot process did. should I care that it exits 1 in that case?
<kees> Virtual Memory Address.
<Keybuk> jdstrand: no, you need not care
<stgraber> Keybuk: well, I didn't know that thing was supposed to return ;)
<Keybuk> (Upstart won't care either) :p
<jdstrand> Keybuk: I wasn't sure if the errors were captured somewhere which might cause later confusion
<kees> seb128: it's a virtual memory address, which can be compared against the allocated VMAs for a process (the ProcMaps.txt file)
<cjwatson> cr3: it's usually/often an upstream thing, but that doesn't necessarily mean that setup.py is smart enough to deal with them
 * Keybuk is of the very strong opinion that "start service" in Upstart should never exit 0 if service is not running
<Keybuk> even if the service is somehow disabled
<cjwatson> cr3: setup.py not being the be-all and end-all of upstreams :)
<jdstrand> Keybuk: if no one will see the error on boot, then I agree that do 'start ufw' should error out if it is disabled
<Keybuk> jdstrand: I think you're worrying about too many things
<seb128> kees, where? hum, the wiki documentation about apport or how to deal with crash bugs maybe?
<Keybuk> jdstrand: for example, Upstart will have its own first-class way of disabling jobs later
<cjwatson> cr3: there is, technically, support for just putting extra comma-space-separated names before the \- in the NAME section of the manual page - but if you use that without providing symlinks, I'll hunt you down :)
<Keybuk> jdstrand: that will disable them from auto-starting, while still allowing sysadmin to do "start job" if they want and actually start it
<cr3> cjwatson: thanks for the explanation, I've been using setup.py so much more than autotools lately that I started to believe it was the end-all indeed :)
<jdstrand> Keybuk: quite probably. I tend to fret and be paranoid when I am looking at something for the first time :)
<seb128> kees, just adding some lines about what informations there could be useful to bug triagers to spot security issues or useful trick you can use from that to track a bug in an easier way would be nice
<seb128> kees, thanks!
<Keybuk> jdstrand: I think it's abnormal for an Upstart job to have an /etc/default for example
<Keybuk> jdstrand: not in the least because those things can go in the upstart conf itself
<Keybuk> once we have an Upstart policy, it may even be a bug to have one
<stgraber> Keybuk: would the content of /proc/mounts help you have an idea of what's wrong ?
<Keybuk> stgraber: no, but /proc/self/mountinfo might
<kees> seb128: okay, cool.  I will add it here: https://wiki.ubuntu.com/Apport
<jdstrand> Keybuk: I was thinking about the /etc/default example too, since my issue here is essentially the same
<seb128> kees, thanks!
<jdstrand> Keybuk: but, for now, you have eased my mind and my upstart file much easier
<stgraber> Keybuk: http://pastebin.com/m3cc2caa0
<jdstrand> Keybuk: thanks for the hand holding
<Keybuk> jdstrand: that's ok ;)  I'm still making this up as I go along
<Keybuk> but Upstart does work in ways that are "surprising" to people used to sysvinit
<Keybuk> because Upstart works in ways that *I* think are right :p
<cjwatson> /etc/default> well, that was true of init scripts as well - the reason /etc/default was split out was because it relieved sysadmins of the necessity to understand the init script while merging
<jdstrand> haha
<Keybuk> cjwatson: right - and upstart jobs are supposed to be very simple to read and change - so the rationale goes away
<cjwatson> that *may* be less of an issue with upstart jobs, because they're simpler, but OTOH they're perhaps less familiar, so I don't know that it's a given
<jdstrand> Keybuk: sure-- fwiw, I see the power, I just don't have a firm feel for it yet
<cjwatson> sysadmins are almost certainly more used to writing shell scripts than upstart jobs
<cjwatson> I'm not entirely sure I disagree with you, I just haven't yet decided if I agree :)
<Keybuk> cjwatson: plus I'm going on a bit of a "only include configuration options if we test them" crusade
<Keybuk> for example
<Keybuk> RAMRUN=yes
<Keybuk> that is an inappropriately named config option in /etc/default/rcS
<Keybuk> it should be named
<Keybuk> DO_I_WANT_THIS_TO_BOOT=yes
<Keybuk> because all you're going to get by setting that to "no" is a non-working system
<cjwatson> I think /etc/default/rcS is perhaps somewhat exceptional :)
<Keybuk> and thus, it's ignored now
<Keybuk> cjwatson: I think the same holds true for most things in /etc/default
<cjwatson> /etc/default/console-setup
<cjwatson> comes to mind :)
<Keybuk> cjwatson: should probably be something more like /etc/console-setup
<Keybuk> it's not the "defaults" for an init script, after all
<cjwatson> true
<Keybuk> it's a first class config file
<cjwatson> I've often had to change syslog options, and appreciated the default file for that when it was introduced
<Keybuk> stgraber: I wonder whether mountall is expecting that it has to mount /rofs fw ;)
<Keybuk> err, rw
<Keybuk> cjwatson: it shouldn't be hard to edit the upstart job though
<Keybuk> with the bonus that you get far better merge context if the options change
<cjwatson> yeah, it's not editing it that's hard, it's that it's tedious to merge, and interrupts upgrades more often
<Keybuk> you'd have to merge the default file if they changed too
<cjwatson> the init script, and probably even the upstart job, change significantly more often than the default file, IME
<cjwatson> obviously I don't have relevant E of upstart jobs as time goes on yet
<Keybuk> and then there's the cost of all the default files
<Keybuk> opening them for every job that uses them, and reading them
<Keybuk> and if you edit the default file, should Upstart notice that, and take some action?
<Keybuk> (as it does with the actual conf file)
<Keybuk> and there's the simple fact that I think that things should be configured in one place, not spread out across the filesystem :p
<cjwatson> I'm not saying they're universally good - I'm just not convinced that they're universally bad
<cjwatson> anyway, late dinner :)
<Keybuk> stgraber: the mountall --debug output you had was somewhat annoyingly corrupted
<Keybuk> stgraber: could you try without the 2>&1 and see what you get
<stgraber> Keybuk: http://pastebin.com/m7b3d6ebe
<ion> It wouldnât be tedious to merge at all, if dpkg handled conffile updates sanely. :-P
<Keybuk> #
<Keybuk> #
<Keybuk> spawn: mount /rofs [1568]
<Keybuk> #
<Keybuk> mountall: mount /rofs [1568] terminated with status 1
<Keybuk> hah
<ion> Most of the merges would happen automatically and very few would require manual help.
<Keybuk> #
<Keybuk> #
<Keybuk> spawn: mount -f -a -t squashfs /dev/nbd0 /rofs
<Keybuk> #
<Keybuk> mount: according to mtab, /dev/nbd0 is already mounted on /rofs
<Keybuk> that's weird
<Keybuk> oh, no
<Keybuk> that's ok
<Keybuk> stgraber: don't suppose you have a shell right now?
<Keybuk> actually, don't worry
<Keybuk> it's pretty clear what's going on ;)
<Keybuk> #
<Keybuk> mounted: virtual 14/14 swap 0/0 remote 0/0 local 0/1
<Keybuk> #
<Keybuk> mounted: fhs 12/12
<Keybuk> that's quite funny
<Keybuk> it thinks / is a virtual filesystem (like proc)
<Keybuk> not a local filesystem
<Keybuk> and is not going to declare local filesystems done until it can mount /rofs rw
<Keybuk> (which won't ever happen)
<stgraber> Keybuk: don't you have a similar issue with the livecd ?
<Keybuk> stgraber: that's what I'm wondering, don't know why that works
<stgraber> Keybuk: the way LTSP and the LiveCD mounts / should be very similar
<Keybuk> stgraber: can you also do blkid -p /dev/nbd0 for me
<stgraber> :~# blkid /dev/nbd0
<stgraber> /dev/nbd0: TYPE="squashfs"
<Keybuk> oh, well, that's descriptive ;)
<Keybuk> udevinfo -q all -n nbd0 | grep ID_FS
<stgraber> root@
<stgraber> :~# udevadm info -q all -n nbd0 | grep ID_FS
<stgraber> root@
<stgraber> :~#
<stgraber> so basically, nothing ;)
<stgraber> http://pastebin.com/m695fde7d
<Keybuk> ok that makes sense
<Keybuk> at least it's SUBSYSTEM=block ;)
<Keybuk> ok
<Keybuk> I already have a fix for this
<Keybuk> I just need to invert it
<stgraber> Keybuk: cool
<xcdfgkjhgcv> ikonia: WTF was that for?
<ikonia> xcdfgkjhgcv: that is not for discussion in here
<soren> nurmi: Not around?
<TheMuso> Hrm, by the topic, can I assume things are still not sorted?
<Laney> my third try at upgrading just resulted in a third different failure ;)
<slangasek> TheMuso: things are 99% sorted, with the major exceptions being liveCDs and people using cryptsetup on disks other than /
<Laney> Have people experienced "no gdm"?
<TheMuso> ah ok
<slangasek> Laney: commonly so
<Laney> that bodes well for there being a fix ;)
<slangasek> Laney: what version of dbus do you have installed?
<cjwatson> and libexpat1
 * Laney returns to said machine
<slangasek> cjwatson: should only matter in practice if /usr is on NFS :)
<slangasek> (otherwise the dbus change is necessary and sufficient)
<Laney> slangasek: 1.2.16-0ubuntu4
<cjwatson> true
<slangasek> Laney: ok, then you have the version that fixed the first bug, and have found another bug revealed by that fix
<Laney> ):
<Laney> :) even
<slangasek> Laney: edit /etc/init/mountall.conf; add 'bash' before the mountall command; run mountall --debug 2>&1 > /dev/mountall.log from the shell; submit that log in a bug against the mountall package
<slangasek> Laney: (and subscribe me, so I can try to help triage while Keybuk is snorkeling in bugs)
<Laney> sure
<Laney> slangasek: "bash" before script or in the script block?
<slangasek> Laney: in the script block
<Laney> alright
<Laney> do you really mean /dev/mountall.log?
<cjwatson> yes, /dev is writable
<cjwatson> when running mountall, most other places aren't
<Laney> ok
<Laney> will have to fish it out of there, no networking either
<slangasek> Laney: you can get gdm up by hand by running 'start dbus && start hal && start network-manager && start gdm'
<slangasek> Laney: but we'd like the mountall log first, to know why it's not working automatically :)
<Laney> mountall is still grinding away
<Laney> should it take a while?
<slangasek> Laney: oh, I would expect it to hang indefinitely; background it and grab the log
<slangasek> Laney: btw, do you use LVM?
<Laney> aha
<Laney> slangasek: no, got an mdadm partition though
<slangasek> kees: I think bug #431042 needs another pair of eyeballs; there've been 4 of these reports now, all of them recent and all of them involving something holding the debconf db open when trying to configure libpam-modules
<ubottu> Launchpad bug 431042 in pam "dpkg error code 1" [Undecided,New] https://launchpad.net/bugs/431042
<Laney> slangasek: (which didn't get mounted)
<kees> slangasek: reading...
<slangasek> Laney: ok - please add that to the bug, that's the exact insight we need :)
<Laney> This exposing bugs lark is fun
<cjwatson> slangasek: 431042> mm, I saw that briefly and thought "isn't debconf just the messenger?"
<cjwatson> or at least some other dup of it
<slangasek> cjwatson: yes, I thought that for the first three instances that were filed against pam
<slangasek> there's some sort of deeper issue here, but I don't know what
<TheMuso> Is booting onto an LV a problem as well? If so, I'll hold off upgrading today as well. :)
<bodhi_zazen> still working on fixing upstart from yesterday ?
#ubuntu-devel 2009-09-17
<slangasek> TheMuso: no, only mounting LVs if you're using non-canonical names for them in /etc/fstab
<TheMuso> oh ok
<LaserJock> hmm, so software-store is going to replace gai for Karmic?
 * Laney stabs launchpad
<Laney> what's the query string? no-redirect or so
<Laney> got it
<kees> slangasek: but where are these coming from?  that's not our kernel: ubuntu 2.6.30.5-ep0
<slangasek> kees: oh, huh
<cjwatson> the most recent bug says easypeasy
<cjwatson> which is an eee variant of ubuntu
<slangasek> kees: is that consistent with the others also?
<cjwatson> I don't know whether that's the case for all of them
 * kees goes to find the others
<slangasek> kees: I've probably closed them as invalid
<kees> 426914?
<slangasek> kees: that's one, yes
<kees> I'm baffled how debconf could be running and apt didn't scream about locks first.
<Laney> slangasek: 431064
<cjwatson> kees: sudo debconf-communicate?
<cjwatson> (or similar)
<kees> cjwatson: yeah, that would certainly do it...
<cjwatson> kees: I dunno, maybe some bonkers wrapper or a package management frontend that starts debconf outside apt but doesn't pass through the fds etc. or ...
<kees> cjwatson: yeah.  though 426914 doesn't show any signs of weird-3rd-party-ness
<slangasek> kees: well, pam-auth-update can be run standalone
<kees> pitti: is the retracer still doing source traces?  seems missing from 427714, for example.
 * lamont notes that his daughter is DJ for the next 2 hours at www.klikradio.org.  </blatant plug>
<TheMuso> What sort of music/
<lamont> high school radio
<lamont> webcast only
<lamont> she's 11th grade
 * lamont afk for a while,sadly
<virtuald> q
<e-jat> can this bug 398214 assign to some one?
<ubottu> Launchpad bug 398214 in ubuntu "Karmic Koala stopps dead after /scripts/init-bottom" [Undecided,New] https://launchpad.net/bugs/398214
<Hobbsee> e-jat: that's probably a part of the boot stuff changing (ie, /topic), and should already be known.  That may well be a dupe
<Hobbsee> er, or not, looking at the report date
<slangasek> mathiaz: ubuntu-server candidates published (finally)
<mathiaz> slangasek: awesome - my dinner will have to wait *for* *ever* now
<slangasek> mathiaz: dinner first, testing after? :)
<mathiaz> slangasek: well - 1. sync, 2. start automated installs then eat, drink, party 42. do testing
<slangasek> kees: bug #431042> oh awesome, he's running update-manager and ubiquity at the same time
<ubottu> Launchpad bug 431042 in pam "dpkg error code 1" [Undecided,Incomplete] https://launchpad.net/bugs/431042
<slangasek> mathiaz: if that's what works for you :)
 * ccheney should have a fast i7 860 system by later next week, to build OOo on :-)
<Hobbsee> ccheney: ah yes.  is OO.o supposed to work on karmic?
<Hobbsee> hm, writer works now.
<ScottK> Has KDE4 integration too.
<Hobbsee> oh, it's just presentatoin that seems to be broken with opening files
<ScottK> I'll try that when I get my netbook back from middle daughter later tonight (she's doing homework)
<Hobbsee> 90+% cpu when opening a pptx, or a ppt file, it appears
<ccheney> Hobbsee: under kubuntu?
<Hobbsee> ccheney: unr
<ccheney> oh no idea about unr :-\
<Hobbsee> ccheney: i haven't run kubuntu in ages
<Hobbsee> ccheney: well, it shouldn't be much different?
<ccheney> kubuntu has some issues with new kde4 integration but roman is planning on having that fixed by end of week
<Hobbsee> i don't have a standard ubuntu karmic machine to test on, atm
<ccheney> hmm it might just be a function of the netbook being really slow
<ccheney> i noticed that even starting OOo takes ~ 4x as long on a netbook
<Hobbsee> i'd wondered that
<Hobbsee> but i don't see the same problem with opening a word doc, for eg
<ccheney> hmm if you want to you can file a bug report and attach the slow files
<Hobbsee> mmm, i might do that
<LaserJock> slangasek: what does Edubuntu need to do to get an Alpha 6, if possible?
<slangasek> LaserJock: I'll schedule a rebuild of the edubuntu DVD this evening; will someone be available to test that it works?
<LaserJock> slangasek: I believe so, I've got 2-3 people who've been testing recently
<slangasek> ok
<slangasek> there's a backlog of image builds, so it'll be at least 2-3 h before there's anything to test
<LaserJock> slangasek: we got over-sized because I added all the edu apps to the livefs
<LaserJock> slangasek: I'm committing a seed update now that should get us back down
<slangasek> ok, great
<kees> slangasek: hah, cool
<ccheney> hmm i hope p55 works with karmic, heh forgot to even check
<ScottK> ccheney: Is it known that OOo 3.1 doesn't know something is a .doc file unless it actually ends in .doc?
<LaserJock> slangasek: was there a specific decision/reason why software-store replaced g-a-i so soon (i.e. for karmic)?
<nixternal> oi oi, kdm init -> upstart v1 complete and working \o/
<nixternal> now to clean it up, make it pretty, and add some of the Keybuk love that he snuck into GDM for some extra splash lovin!
<ccheney> ScottK: wouldn't be surprised
 * ScottK 's daughter about had a heart attack tonight when she reopened her homework and OOo showed an empty file.
<nixternal> I love when that happens!
<ccheney> heh
<nixternal> ScottK: quit being lazy and teach her LaTeX already
<ScottK> She needs .doc for interoperability with school.
<ccheney> ScottK: there is a bug wrt kde4 integration not appending extensions properly (if that is what she saw)
<ScottK> ccheney: OK, but when I manually added the extension, writer opened it fine.
<nixternal> ScottK: .txt files then :p
<ccheney> ScottK: yea
<ScottK> I thought depending on file extensions was the Windows way ...
<ccheney> i seriously doubt OOo tries to do anything fancy to detect what kind of file you are trying to have it open
<nixternal> ahh, ya I noticed that same problem...glad you said 'added the extension' :)  now I can open up my buddies resume
<ccheney> ScottK: its Sun we are talking about... not a regular floss application ;-)
<ScottK> Well, I suppose.
<ccheney> but even gnome claims a 0 byte .doc file is a msword file
<ccheney> so i doubt that shared-mime-info does much better
<ccheney> files have to sufficient magic to not get confused for other things
 * ccheney isn't sure if doc files have it, but many file types don't
<TheMuso> We need resource forks in the Fs. :)
<ccheney> yep
<ion> Resource forks or not, we need to get everything to ignore the filename when determining the file type. :-) The filename only exists for humans. For all the computer cares about, files could be looked up by their inode or equivalent ID just fine.
<TheMuso> slangasek: according to the report for the latest studio candidate, ubuntustudio-desktop is uninstallable, which during the install, shows up as tango-icon-theme being uninstallable.
<ccheney> ion: yea that works in theory... until you get a file whose type can't be _easily_ determined from the contents
 * TheMuso digs to see what the problem is.
<TheMuso> Oh and the previous candidate was prefectly ok.
<ion> ccheney: Then call is aplication/octet-stream and blame the format. ;-)
<ion> it
<ion> Alternatively, determine it the hard way and cache the result. :-)
<ccheney> if you end up trying to be too smart you end up not printing on tuesdays :)
<astronut> so the 9.04 NBR installer somehow ate both my windows and recovery partitions
<astronut> neither will boot correctly
<TheMuso> Ok cannot reproduce uninstallability with chroot using archive.ubuntu.com, looks like it was transient.
<rgreening> ever since last update, my usb thumb drives are not autodetected anymore. Any ideas?
<ScottK> rgreening: Autodetected here on a fresh install.
<rgreening> hmm... strange indeed.
<slangasek> TheMuso: should I respin and see if the installability problem is fixed?
<slangasek> ScottK: kubuntu alternate also posted, finally
<slangasek> I believe we're just waiting now for DVDs and ARMs
<ScottK> slangasek: OK. It's getting late here.  I'll be able to get through several KNE tests, but that's it for tonight.
 * slangasek nods
<ScottK> Hopefully Riddell will be awake soon and start cranking through stuff.
 * spstarr_desk gasps at topic.. now someone tells me
<spstarr_desk> I cant boot my fsckin laptop now :)
 * spstarr_desk thinks something broke bad
<ScottK> Actually I think things are mostly back to good.
<TheMuso> slangasek: please
<spstarr_desk> The dreaded "Waiting for root file system" problem
<ScottK> spstarr_desk: If you look in today's backscroll, you'll find discussion on how to work through it.
<spstarr_desk> i dont have it..
<spstarr_desk> is this logged
<ScottK> spstarr_desk: irclogs.ubuntu.com
<spstarr_desk> looking now
<slangasek> TheMuso: spinning
<spstarr_desk> ScottK: this channel's log?
<ScottK> It's in htere.
<ScottK> htere/there
<spstarr_desk> oh udev crap
<spstarr_desk>  <maxb> Something weird is happening with karmic for me - supposedly clean shutdowns don't seem to be unmounting my root partition cleanly, and ext3 journal recovery happens on boot <-- yep
 * spstarr_desk begins from here
<spstarr_desk> oh its the blkid i need now in fstab?
<spstarr_desk> why was this changed *now* ??
<spstarr_desk> this is a horrible time to break thnigs
<spstarr_desk> ugh i have to go wired to fix this wifi + single user == death
<ScottK> It was supposed to land a couple of days ago.  I think better now than after Alpha 6 and before the Beta.
<spstarr_desk> the workaround isn't working for me
<spstarr_desk> it drops me to a busybox shell
<spstarr_desk> not bash
<spstarr_desk> idea #2, boot rescue CD mount /boot inside / inside a /fakeroot
<spstarr_desk> chroot; get network and dist-upgrade...
<spstarr_desk> and mount /proc
<slangasek> TheMuso: uninstallables fixed
<TheMuso> slangasek: So I see, thanks.
<spstarr_desk> now let's apt dist-upgrade
<spstarr_desk> is it mountall thats just broken?
<ScottK> Depends on exactly when you upgraded.
<ScottK> That was the last bit to get sorted.
<spstarr_desk> that's the last thing i see.. i upgraded a few hours ago
<ScottK> Probably that's it then.
 * spstarr_desk laughs, bad timing indeed!
 * spstarr_desk is glad the *buntu cds respect 'single' mode 
<spstarr_desk> drops me to a root prompt
<spstarr_desk> yay
<spstarr_desk> thanks :)
 * spstarr_desk goes back to wifi 
<spstarr> ScottK: is there a PPA for kernel? or nightly builds?
<spstarr> i want to test the radeon 3D support on karmic but the kernel is too old
<ScottK> There is, but I don't know where.
 * ScottK is off to bed.
<mathiaz> slangasek: allright - -server amd64/i386 tests completed and successful
<slangasek> mathiaz: yay!
<mathiaz> slangasek: 15/17 for amd64 and 14/17 for i386
 * slangasek nods
<spstarr> http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/ ?
<dholbach> #canonical-2009-09-17-07h16
<mneptok> dholbach: fail.
<dholbach> mneptok?
<mneptok> dholbach: was that paste meant to be meaningful?
 * mneptok is confuzzled.
<dholbach> which paste?
<dholbach> oops
<dholbach> no
<dholbach> good morning
<dholbach> lalala :)
<mneptok> moin :)
<Treenaks> dholbach, good morning :)
<dholbach> ouch ouch ouch
<dholbach> errr.... more coffee!
<mneptok> don't worry, i make mistakes, too.
<dholbach> mneptok: probably less than I do ;-)
<mneptok>  /m sabdfl yes, i think Daniel is sexy, too. but i never asked if he likes you. ask him to dinner and a movie at UDS.
<mneptok> oops.
 * Treenaks is still wondering about the blinking-while-typing Scroll Lock led
<slangasek>  /lickban mneptok
<mneptok> slangasek: give me a few hours in New Mexico heat and i make my own gravy.
<jussi01> o.O strange things int this channel (mind, mneptok is here...)
 * mneptok bursts into flame
<slangasek> kirkland, ttx: does bug #430820 need to be documented in the errata for a6?
<ubottu> Launchpad bug 430820 in eucalyptus "eucalyptus node install results in broken /etc/network/interfaces" [High,Fix committed] https://launchpad.net/bugs/430820
<kirkland> slangasek: i think it should
<kirkland> slangasek: network will be broken on -nc install first boots
<slangasek> kirkland: is there a straightforward workaround?  (If the bridge isn't configured right, how do you access the node to reconfigure it, via a virtual console?)
<slangasek> or is the node the physical cluster node?
<kirkland> slangasek: yes; login to tty1, edit /etc/network/interfaces
<slangasek> ok
<kirkland> slangasek: the specific line of sed is in that bug
 * slangasek nods
<ttx> slangasek: I would also mention bug 430758. I'll do some more testing this morning to confirm problem/workaround
<ubottu> Launchpad bug 430758 in eucalyptus "Cloud installer / Cluster install hangs at reboot after install" [High,Triaged] https://launchpad.net/bugs/430758
<kirkland> ttx: welcome back
<ttx> I'll doublecheck that logging in by ssh/tty2 and rebooting somehow works around it.
<kirkland> ttx: i didn't get that problem
<kirkland> ttx: note that there have been another set of iso's since you went to sleep
<ttx> that's why I meant by doublechecking :)
 * ttx rsyncs
<ttx> nurmi: ping
<teknico> superm1, hi, we've been exchanging emails right now
<pitti> Good morning
<pitti> pochu: oh, nice; yes, will do
<slytherin> Can someone please give back empathy on powerpc?
<soren> slytherin: Done.
<pitti> pochu: bug updated, uploading now
<pitti> kees: no, currently disabled because of xulrunner wreaking havoc
<pochu> pitti: \o/ thanks!
<pitti> pochu: do you need this in sid, or is experimental ok for now?
<pochu> pitti: exp is ok until libgudev is in sid
<pochu> pitti: I can poke you when that happens
<pochu> or if it can go to unstable directly, why not upload there?
<pitti> pochu: well, just in case the new rb doesn't make it into squeeze, I rather not have it in a stable release
<pitti> pochu: but once it's through NEW, I can upload it to sid with a snap of a finger, so just poke me
<pochu> ok, that's fine then :)
<pitti> pochu: also, feel free to add yourself to Uploaders: and just do it
<pitti> pochu: meh, Debian's udev missing .pc file
<ttx> kirkland: confirming bug 430758 is avoided by one recent fix from Colin in the initscript.
<ubottu> Launchpad bug 430758 in eucalyptus "Cloud installer / Cluster install hangs at reboot after install" [High,Fix released] https://launchpad.net/bugs/430758
<pochu> pitti: does it? it has /usr/lib/pkgconfig/libudev.pc, isn't that enough?
<pitti> pochu: that's for the library
<pitti> pochu: we need /usr/share/pkgconfig/udev.pc
<pitti> pochu: I'll hack around it
<slytherin> are there going to be mass give back for ia64? There are many FTBFS because of chroot problems.
<pochu> pitti: oh
<soren> ttx: Oh, cool.
<ttx> soren: it is still not displaying the eucalyptus initscripts messages, but that's more cosmetic
<ttx> I'll file a separate bug for that.
<Dyllan> Hi all. I have a script that uses zenith to provide the user with an easy to use interface other than the command line. But now I would like to transform it into a fully functional program for ubuntu/gnome, what devel tools are default/recommended for ubuntu, eg. glade etc?
<evand1> the buildds install recommends by default, so a hard dependency on something recommended by a dependency is not required, right?
<dholbach> evand: afaik they don't install recommends
<slytherin> evand: buildd don't install recommends.
<slytherin> Dyllan: AFAIK, glade is deprecated.
<Dyllan> slytherin, what would you recommend then?
<evand> dholbach: slytherin: ah, thanks!  I was completely unaware of that.
<slytherin> Dyllan: I haven't done much UI programming from scratch in gnome. the replacement for glade is something called gtkbuilder. But I never used it.
<Dyllan> slytherin, hmm ok. So can i write the program in any language then use gtkbuilder to design the front-end, is that the idea?
<spstarr> the topic can be changed  to karmic boots again ;-)
<bdrung_> do i need a FFe for bug #430658?
<ubottu> Launchpad bug 430658 in lintian "Please merge lintian 2.2.15 (main) from Debian unstable (main)." [Wishlist,New] https://launchpad.net/bugs/430658
<pitti> evand: hm, I think usb-creator now works without root privs, but its .desktop file still seems to run it through gksu?
<evand> pitti: whoops
<evand> fixing now
<pitti> evand: while you are at it, could you please fix this: /tmp/usb-creator.log
<pitti> evand: static file name in world-writable directory -> security vuln
<pitti> I can also report it as a bug, if you prefer
<evand> indeed, I'll move it to a more sane location
<evand> please do
<pitti> evand: need a bug about dropping gksu as well, or are just just doing it in bzr?
<evand> hrm, actually the desktop file in trunk just launches usb-creator-gtk.  Is this launching through gksu bug via bzr trunk or the package in the archive?
<pitti> evand: bug 431266
<ubottu> Bug 431266 on http://launchpad.net/bugs/431266 is private
<pitti> evand: hm, that's right, weird; I started it from the menu and it asked me for password (gksu)
<evand> are you sure it was gksu and not the pk authentication agent (though I'm not sure why that would come up either)
<pitti> evand: yes
<evand> very odd then
<pitti> hm, who knows
<pitti> ignore this for now, please
<evand> okay
<sebner> pitti: yeah it seems I can continue working on the main bug report! Bus 001 Device 007: ID 152d:2329 JMicron Technology Corp. / JMicron USA Technology Corp.
<sebner>   I'll do the necessary debugging now :)
<dholbach> sistpoty|work, slangasek, geser: thanks guys! announced your session!
<sistpoty|work> dholbach: thanks (but slangasek won't be around for this session though)
<dholbach> sistpoty|work: oh ok
<sistpoty|work> geser: would you like to help out again this Friday?
<geser> dholbach: good to let me know that I volunteered for that session too :)
<dholbach> sorry
<geser> sistpoty|work: yes
<dholbach> I misread that email
<dholbach> excusez-moi
<sistpoty|work> thanks a lot geser :)
<dholbach> geser: sometimes you need to help people to find their luck :)
<geser> dholbach: no problem, I planned to be round for the session anyway
<dholbach> sistpoty|work: updated :)
<sistpoty|work> dholbach: excellent, thanks!
 * sebner is sooo happy. This is going to be an awesome session :D
<tkamppeter> pitti, CUPS does not start automatically on boot any more. Does it need to get converted to Upstart?
<al-maisan> Hmm .. upon reporting bugs against pulseaudio one is prompted to try the packages from the ubuntu-audio-dev PPA .. once installed though ubuntu-bug declines to co-operate: ".. This is not a genuine Ubuntu package .."
<lool> haha
<lool> That's a good trick; I'll do that for more packages
<lool> al-maisan: You want to ping davidchen and/or TheMuso about it I guess
<al-maisan> lool :)
<pitti> sebner: right, seems that will cover your case as well then
<pitti> tkamppeter: no, it should still work
<pitti> ugh, that was hard to recover from; with the latest cryptsetup and today's updates, my machine is completely busted
<sebner> pitti: did you see my comment (with the debug information?), anyways. would you mind leading a helping hand in blacklisting that stuff?
<pitti> it hangs forever on "starting sad crypto disks..."
<pitti> (I don't have any)
<pitti> and purging cryptsetup causes it not to boot at all any more
<pitti> kirkland: hey
<pitti> kirkland: seb128 just pointed out a change which will fix the ecryptfs/gdm problem: gnome bug 565151
<ubottu> Gnome bug 565151 in general "Thrashing autofs home directory mounts" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=565151
<pitti> evand1: hm, trying to boot an usb-creator usb stick with current karmic on my machine fails; it just gives me tons of "init line 1: /dev/sr0 not found" lines and then throws me into the initramfs prompt
<pitti> it works on my wife's machine
<sebner> pitti: I also wouldn't mind if you upload the blacklist-version the next days (what you'll do, as stated in the bug report)
<pitti> can it be that it needs a longer timeout or something? did you hear this before?
<evand1> pitti: does /casper.log have anything of note?
<pitti> sebner: the bug report has the instructions how to blacklist; you need the ATTRS line with the GOTO, and the LABEL="...."
<pitti> evand1: is that accessible from the initramfs prompt?
<evand1> yes
<evand1> cat /casper.log
<pitti> ok
<pitti> I need to reinstall this machine anyway, booting is completely busted
<sebner> pitti: ah, just saw it. thx
<pitti> I'm writing a CD now, but before I run that, I'll try the usb stick again
<tkamppeter> pitti, thanks, then it seems that it is an upstart bug that all non-converted services (cups, mysql, sshd) did not start for me on boot.
<pitti> tkamppeter: right, seems so; init.d scripts need to work, for at least the next decade
<ogra> decade ? OMG !
<pitti> ogra: well, there's tons of third-party and proprietary software out there
<pitti> and even converting our own entire universe will last a while
<ogra> pfft, just ignore them ...
<ogra> :)
 * ogra hides from the wrath of MOTU
* cjwatson changed the topic of #ubuntu-devel to: karmic is getting happier, but is still feeling a bit hung-over, so be gentle | Archive: frozen for alpha-6, FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<highvoltage> :)
<ogra> more Alka-Seltzer for karmic !!
<ior3k> have you guys considered creating something like debian unstable for people who like to keep living on the (very bleeding) edge?
<joaopinto> ior3k, that's called karmic right now :)
<ogra> ior3k, we call it karmic
<ior3k> right, that's not what I mean
<ior3k> I mean a permanent name
<ior3k> so we don't have to change sources.list
<ogra> is it really that hard to adjust your sources.list twice a year ?
<ior3k> no, it isn't hard at all, I'm just asking
<ior3k> if there is some kind of rationale behind it
<ogra> yes, our unstable is a snapshot of debians
<ior3k> ah, so you keep an unmodified unstable branch that is exactly like debian's, then 'fork' it over to form the next distro's branch?
<ogra> which goes hand in hand for about half a release cycle and then gets into stabilization ... due to that stabilization phase our "unstable" diverges frome debians and requires a new snapshot at the beginning of the next release cacle
<Laney> we fork the stable branch at release and then merge debian into that
<ogra> *cycle
<ior3k> got it, thanks
<cjwatson> ior3k: we don't have developer bandwidth to maintain a separate unstable as *well* as karmic; we did think about it early on, but decided against it
<cjwatson> (indeed I was a proponent of a separate unstable, but was convinced otherwise)
<ior3k> cjwatson: makes sense, I guess everyone is mostly busy working on the *current* future stable version
<ior3k> cjwatson: thanks for the clarification
<amitk> gah! dist-upgrade seems to have broken compiz. No window manager for me :-/
<ogra> there is that ancient metacity thingie ;)
<amitk> right click doesn't work on the desktop and there is not gnome-panel
<amitk> *no
<ogra> doesnt actually sound like a windowmanager issue
<lamont> Error: Descriptions do not match: <-- where in debbuild's world to those errors come from, I wonder?
<evand1> are we expected to stick things (specifically, log files) in .cache these days?
<evand1> or is it okay to hate the XDG base directory specification
<slytherin> evand1: You shouldn't use .cache name hard coded
<evand1> slytherin: indeed, I was just doing that for brevity
<MacSlow> seb128, what valgrind command-line did you use to obtain the log you attached here https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/430722
<ubottu> Launchpad bug 430722 in notify-osd "current version has invalid read errors under valgrind" [Undecided,New]
<seb128> MacSlow, G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck --leak-check=full --num-callers=38 /usr/lib/notify-osd/notify-osd
<seb128> MacSlow, why?
<MacSlow> seb128, just wondering
<seb128> MacSlow, you don't get the issue?
<MacSlow> seb128, I added a possible fix and now try to reproduce it
<seb128> ok
<seb128> MacSlow, want me to try the fix?
<MacSlow> seb128, would be cool... one sec
<MacSlow> seb128, http://paste.ubuntu.com/272784
<MacSlow> seb128, if that fixes it, it would mean the purging of old bubbles is messed up
<MacSlow> which would need further investigation
<pitti_reinst> evand1: hm, now that you told me about /casper.log, the usb stick booted; I love race conditions :)
<evand1> haha, hooray
<pitti_reinst> I tried it three times before..
<evand1> I thought upstart was going to fix all boot race conditions, and give us ponies ;)
<evand1> if you do manage to reproduce it at some point, a bug report with the casper log attached would be greatly appreciated
<ogra> ponie races probably :)
<ogra> *pony
<evand1> haha
<pitti_reinst> evand1: yes, should be easy to reproduce, I'll just try it a couple of more times
<pitti_reinst> evand1: how does the USB stick booting work, is it "faked" to become /dev/sr0?
<pitti_reinst> evand1: since it seems to loop over getting /dev/sr0
 * lamont finds his answer: mergechanges
<ScottK> lamont: I listened to your daughter on the radio last night.  Would you please fix the IA64 chroots?
<ScottK> :-)
<lamont> ScottK: the debian ones?
<ScottK> No, our buildds
<lamont> so totally frustrated at those damn things
<lamont> oh ours?  what's b0rked?
<ScottK> (or did you do that already today)
<lamont> (build log somewhere?  or just any and all?)
<ScottK> chrootwait.
<ScottK> Any/All
<lamont> ah, ok
<cjwatson> ScottK: the necessary fix is to port dbus to ia64
<lamont> taking kids to school in about 2 seconds, will look at that once I'm back online
<ScottK> ouch
<cjwatson> it's not something that can be fixed on the buildd side before that
<cjwatson> look a couple of revisions back in dbus and you'll see the failure - missing clock_getres and clock_gettime IIRC
<ScottK> OK, that'll probably have to wait until after lamont takes his kids to school.
<lamont> oh. that.  nowI remember
<lamont> where are those funcs defined on other architectures
<evand1> pitti: lp:casper in scripts/casper, see find_livefs
<Keybuk> ok, that's five minutes ... and nobody's pounced on me
 * ogra pounces on Keybuk 
<ogra> just for fun
 * Keybuk rolls around on the floor with ogra
<ogra> cuddly :)
<ion> aaww
<Keybuk> :-)
<cjwatson> Keybuk: now, the question is, is that because there are no problems or is it the onset of despair? ;-)
<Keybuk> cjwatson: that was exactly what I was thinking
<Keybuk> but then I figured that either is a win
<Keybuk> now, onto the critical bugs
<Keybuk> *why* has compiz lost all my key bindings *again* :-(
<pitti> yay, finally; a working machine again
<pitti> Keybuk: would you mind if I re-add the check for "text" to /etc/init/gdm.conf? It's quite useful for broken drivers and debugging
<ogra> pitti, oh, please do !
 * ogra didnt know that was gone
<pitti> how could I not, now? :-)
<rgreening> any ideas on how I can debug why usb autodetection is broken? It worked in alpha5 but updating yesterday broke it.
<ogra> i often make use of it
<Keybuk> pitti: check for text?
<pitti> Keybuk: yes, in /proc/cmdline, like the old init script
<ogra> Keybuk, gdm didnt start with text on cmdline
<pitti> rgreening: usb drives?
<ogra> its very helpful if you want to debug stuff
<Keybuk> oh, I missed that
<Keybuk> sure
<Keybuk> you might want to add single in too ;)
<Keybuk> and all the -s and S synonyms of that
<pitti> rgreening: ubuntu-bug, and select "storage devices"
<rgreening> pitti: yeah. dmesg shows them.. but they do not autodetect for me to automount
<rgreening> pitti: ok.
<pitti> yay, apport symtoms :)
<pitti> Keybuk: "-s and S synonyms"?
<ion> pitti: See /etc/init/rc-sysinit.conf, everything that leads to DEFAULT_RUNLEVEL=S
<pitti> aah
<pitti> thanks
<Keybuk> ion: I still need to find out whether there's a better way of doing that
<Keybuk> I have a vague memory that the kernel actually passes all kernel command-lines to init
<Keybuk> (it must do, because adding --debug works :p)
<ion> :-)
<Keybuk> so it must pass the -b, -s, etc. to init too
<Keybuk> then I wonder whether it passes things that don't begin with -
<Keybuk> so maybe init gets "single" in argv[1]
<Keybuk> even "quiet", "splash", etc.
<Keybuk> so I could put those into the startup event in some meaningful way
<Keybuk> start on startup SINGLE=no
<Keybuk> or something
<darkham> please, tell me more about UserInterfaceFreeze
<darkham> of 10-09
<pitti> darkham: see https://wiki.ubuntu.com/UserInterfaceFreeze
<Keybuk> darkham: it's the point in our release cycle that, after which, changes to the user interface need to be approved
<darkham> yes, but nothing more about features?
<Keybuk> darkham: Feature Freeze happens before UI Freeze (a couple of weeks ago)
<darkham> what's was decided?
<cjwatson> Keybuk: init/main.c:unknown_bootoption
<Keybuk> darkham: what do you mean?
<Keybuk> cjwatson: hmm?
<darkham> features inside the featurefreeze
<Keybuk> darkham: is there a specific question you want an answer for?
<darkham> yes, i would have an answer about
<Keybuk> cjwatson: where are you looking?
<cjwatson> Keybuk: in the kernel
<Keybuk> cjwatson: ah, right; yes that's what I mean
<cjwatson> as I read it, it passes unknown foo=bar in init's environment, and unknown foo in init's argv
<Keybuk> *nods*
<Keybuk> that was my understanding too
<rgreening> pitti: ubuntu-bug is taking an awfully long time to collect info... been running since you told me to try it... I suspect its not working
<pitti> rgreening: did it ask you questions?
<rgreening> pitti: first time I tried it, I selected the storage option, and it complained about missing package or PID.
<pitti> uh
<pitti> rgreening: I never actually tried it on Kubuntu
<rgreening> pitti: second time I passed "storage devices" as text on cmdline.. and now its collecting forewver.
<pitti> it assumes devicekit-disks and everything
<pitti> not hal
<rgreening> pitti:  have that
<pitti> rgreening: ubuntu or kubuntu?
<rgreening> kubuntu with devicekitdisks
<Keybuk> cjwatson: nice to have that confirmed from kernel code though, saves me looking
<Keybuk> is a matter of figuring out how to pass them to jobs as well
<Keybuk> e.g. how does "-b" gets passed
<pitti> rgreening: does top say whether there's a busy process?
<cjwatson> yeah, seems like it makes sense to define more spellable names
<rgreening> pitti: 5% cpu... doesn't appear hung
<rgreening> loadavg if fine
<rgreening> is
<rgreening> strange
<ion> keybuk: http://heh.fi/tmp/init-args (i diverted /sbin/init and created a /sbin/init that prints $* and /proc/cmdline and execs the diverted init)
<Keybuk> cjwatson: the idea for upstart 1.0 is that words there get converted to jobs
<Keybuk> so if you had "single" on the command-line, you'd have a "single" job/state active
<Keybuk> then you could do:
<Keybuk>   while single
<Keybuk> &
<Keybuk>   while not single
<ion> keybuk: Some parameters seem to get passed as init args, some donât. Dunno what determines that.
<rgreening> pitti: I suspect nixternal has a bug in the code wrt text on cmdline enclosed in quotes :)
<slytherin> Does anyone know where can I find Daniel Chen?
<Keybuk> ion: ones the kernel knows don't
 * rgreening tries again anothe rway
<Keybuk> ion: "ro" and "quiet" are for the kernel, likewise root
<Keybuk> ion: can you dump "env" as well and try a few things like foo=bar
<ion> Ok
<ion> keybuk: Indeed, those do get added to the environment.
<Keybuk> but not the root= and stuff?
<rgreening> nixternal: apport-kde does not allow you to enter bug details without specifying a packge.
<rgreening> nixternal: apport-gtk does...
<rgreening> pitti: ^ so trying again with gtk version installed :)
<ion> keybuk: http://heh.fi/tmp/init-args
<ion> keybuk: The ROOT env variable might come from initramfs.
<Keybuk> yes, I think that gets a bit leaked
<Keybuk> the initramfs tends to export its environment randomly
<Keybuk> cf. MODPROBE_OPTIONS
<Keybuk> and break= ;)
<ion> Yeah
<Keybuk> it's arguable that the initramfs shouldn't use "export" at all
<Keybuk> since it sources everything
<pitti> Keybuk: can/should upstart scripts use log_warning_msg and similar LSB functions?
<pitti> or just echo? or nothign at all?
<Keybuk> no
<Keybuk> they shouldn't
<Keybuk> imo upstart scripts should freely output warnings, errors, etc.
<Keybuk> and not use things like 2>/dev/null
<Keybuk> so in karmic+1, those logs will be available and contain useful information
<pitti> so just echo "Not starting GNOME Display Manager (gdm); found 'text' in kernel commandline." is okay?
<pitti> to stdout
<Keybuk> pitti: tbh, i tend to just make it fail :)
<Keybuk> the text won't go anywhere
<Keybuk> so it's not worth making it descriptive just yet
<Keybuk> but sure, that's fine
<pitti> you don't see it on the VT?
<pitti> ok
<Keybuk> no
<Keybuk> that's a TODO
<Keybuk> what I actually want is for things to be a bit more like, well, cron actually
<Keybuk> if you do "# start gdm" yourself
<Keybuk> you should see the output on your VT
<Keybuk> but if gdm starts, you shouldn't get random dumpings across your VT
<Keybuk> just if it fails, you see the output as part of the "gdm failed" notification
<Keybuk> but if gdm is automatically started
<Keybuk> the failure log should go somewhere useful
<Keybuk> maybe /var/log
<Keybuk> maybe sent via e-mail
<Keybuk> etc.
<rgreening> pitti: bug 431878
<ubottu> Launchpad bug 431878 in kde4libs "USB Drive Fails to be Autodetected for Mounting in KDE" [Undecided,New] https://launchpad.net/bugs/431878
<rgreening> pitti: I suspect udev rules clutter.. just do not know 1) for certain and 2) how to debug
<pitti> Keybuk: so I think "if egrep -wqs 'text|single|s|S|-s'; then exit 0; fi" should do
<Keybuk> pitti: oh, I'd just do
<pitti> those are the combinations I found in /etc/init/rc-sysinit.conf
<Keybuk>   egrep -wqs 'text|single|s|S|-s' /proc/cmdline
<Keybuk> ;)
<Keybuk> though iirc, you'll get slapped with a "root=something-s always enters single user mode" bug ;)
<cjwatson> mm, you need for x in $(cat /proc/cmdline); do ...; done really
<Keybuk> indeed
<cjwatson> (or </proc/cmdline if that actually works)
<pitti> Keybuk: no, -w only matches whole words ast it seems
<Keybuk> pitti: it doesn't
<cjwatson> pitti: - is a word boundary though
<pitti> $ echo "root-something" | grep -wqs -- '-s'
<pitti> -> code 1
<Keybuk> grep's "whole word" is done on a boundary
<cjwatson> pitti: now try root-s
<pitti> $ echo "root-s" | grep -wqs -- '-s' || echo no
<pitti> no
<cjwatson> oh, hmm
<cjwatson> but:
<cjwatson> $ echo "root-s" | grep -wqs -- 's'; echo $?
<cjwatson> 0
<pitti> magic
<Keybuk> right just "s" not "-s"
<pitti> so I really want a WORD not a word (in Perlspeak)
<Keybuk> pitti: just copy the logic from rc-sysinit.conf
<ion> case " $(cat /proc/cmdline) " in *' -s '*|*' single '*|...) :-P (Or just for arg in $(cat /proc/cmdline)...)
<pitti> Keybuk: *nod*
<pitti> Keybuk: while I'm at it, I kill the gdm-cdd.conf stuff; it doesn't work any more
<Keybuk> pitti: I'm tending strongly towards killing off untested options and configs
<Keybuk> (as part of the sysvinit -> upstart migration)
<Keybuk> on the basis that if we let someone change something, we should continually test both settings
<Keybuk> and that upstart jobs are supposed to be a billion percent more readable than init scripts
<Keybuk> plus some config options are silly
<pitti> Keybuk: I take that as an "ok" for removing gdm-cdd.conf? :-)
<Keybuk> pitti: yup!
<Keybuk> TMPFS_SIZE ?!  ... which tmpfs? and why not just put it in /etc/fstab where it's supposed to go
<pitti> ogra: it's back in bzr, will upload after alpha freeze
<ogra> cool
<Keybuk> pitti: bug #431176 btw (for changelog)
<ubottu> Launchpad bug 431176 in gdm "karmic: gdm should not start in single user (recovery) mode" [Low,Triaged] https://launchpad.net/bugs/431176
<pitti> ah, nice
<hyperair> what's the difference between /etc/init and /etc/event.d?
<ogra> hyperair, one upstream release of upstart
<pitti> hyperair: the former exists :)
<ogra> well, depends where you look :)
<pitti> event.d is the deprecated name of older upstarts
<hyperair> ogra: meaning /etc/event.d can be effectively purged now?
<ogra> the latter exists too :)
<ogra> just not in recent versions
<ogra> hyperair, yes
<hyperair> i see
<Madkiss> hi all
<pitti> Keybuk: btw, "sad" crypto drives and "weak" partitions? :-)
 * pitti can imagine the mood under which Scott produced all that
<Madkiss> with todays updates, my system hangs after "starting sad crypto disks"
<Madkiss> what's wrong with it?
<pitti> happened to me as well
<Keybuk> yeah cryptsetup is fucked
<pitti> bug 430496
<Keybuk> it probably needs rewriting using udev properly
<ubottu> Launchpad bug 430496 in mountall "cryptsetup devices not mounted on boot" [High,Invalid] https://launchpad.net/bugs/430496
<Laney> al-maisan: I think you mistakenly credited me with the php-suhosin sync somehow
<pitti> well, it might not exactly be that particular bug
<pitti> but it's a placeholder for "fix it"
<hyperair> hmm can upstart handle pm-utils hooks?
<hyperair> like start on resume or something
<hyperair> =D
<kirkland> Keybuk: hey, i'm looking at https://bugs.edge.launchpad.net/ubuntu/+source/sysvinit/+bug/427277
<Keybuk> hyperair: eventually
<ubottu> Launchpad bug 427277 in sysvinit ""service start" complains about using the init script and recommends using "service"" [Low,Triaged]
<kirkland> Keybuk: happy to fix that
<hyperair> Keybuk: that's nice
 * hyperair needs to get round to switching my phc init script to an upstart job
<Keybuk> kirkland: I guess the right way would be that if /etc/init/$ARG.conf exists, use "start", "stop", etc. rather than invoke-rc.d
<kirkland> Keybuk: how would service tell if its being called in an upstart job
<pitti> unfortunately I can't reproduce the hang on "sad crypto drives" in a VM
<kirkland> Keybuk: ah, cool
<kirkland> Keybuk: so the "fix" is really *not* to use invoke-rc.d
<Keybuk> kirkland: you still need to use invoke-rc.d if it's an init script ;)
<kirkland> Keybuk: of course.  i meant "conditions permitting"
<al-maisan> Laney: you ack'ed it
<Keybuk> right
<yuriy> pitti: hi. what should i do to get the patch for bug 405378 into karmic as fast as possible? debdiff or commit to bzr? if the latter, what branch?  this bug is kind of critical now that +filebug doesn't work anymore, so i'd like to get this fix in and can work on a more complete fix later
<ubottu> Launchpad bug 405378 in apport "[karmic] in KDE apport does not open the browser to report a bug" [High,In progress] https://launchpad.net/bugs/405378
<Laney> al-maisan: bug 429531 ?
<ubottu> Launchpad bug 429531 in php-suhosin "Please sync php-suhoshin from debian unstable." [High,Fix released] https://launchpad.net/bugs/429531
<kirkland> Keybuk: what is the total set of actions you provide?  (start, stop, status) ?
<al-maisan> Laney: there was another bug, let me dig out the number..
<Laney> al-maisan: anyway if I only acked it then the requester should have had it
<al-maisan> Laney: bug #424789
<ubottu> Launchpad bug 424789 in php5 "PHP random segfaults on session_start();" [Undecided,In progress] https://launchpad.net/bugs/424789
<Laney> if I actually requested the sync then ...
<al-maisan> Laney: hmm .. "Replace LPUID with the Launchpad username of the sync requester, or the acknowledger if the requester is not an active developer"
<pitti> yuriy: I don't particularly mind, what's easiest for you; I'll commit it to bzr right away and upload right after the freeze
<Laney> I don't see myself on that bug
<pitti> yuriy: I don't think it's ubuntu specific, so I'll commit it to trunk (lp:apport) and cherrypick to the ubuntu branch
<james_w> Laney: I think you set it confirmed
<pitti> yuriy: thanks a lot for figuring this out; what was it?
<yuriy> pitti: ok, thanks!
<al-maisan> Laney: yep (Iain Lane  on 2009-09-14)
<Laney> Oh that was just status fiddling
<simon-o_> al-maisan: Did you sync awesome, bug 427767
<ubottu> Launchpad bug 427767 in awesome "Sync awesome 3.3.2-1 (universe) from Debian squeeze (main)" [Wishlist,Fix released] https://launchpad.net/bugs/427767
<Laney> not a big deal really anyway
<al-maisan> Laney: great, thanks!
<al-maisan> simon-o: yes.
<yuriy> pitti: a couple different things. simple bug where it's just canceling when the complete/reduced report radios aren't visible (the patch fixes this). hanging is a problem with how the app is excecuted/exited to work around bug 403361. need to figure out that one and come up with a more complete fix.
<ubottu> Launchpad bug 403361 in python-qt4 "apport-kde crashed with SIGSEGV in QWidgetPrivate::deleteExtra()" [High,Triaged] https://launchpad.net/bugs/403361
<simon-o_> al-maisan: You synced 3.3.4-1 and not 3.3.2-1. Was this on purpose?
<al-maisan> simon-o_: no .. let me have a look.
<simon-o> al-maisan: 3.3.4-1 is missing libxcb-event1-dev (>= 0.3.6)
<simon-o> https://edge.launchpad.net/ubuntu/+source/awesome/3.3.4-1
<Laney> too late now, you need to either fix 3.3.4 or do a sourceful upload of 3.3.2
<al-maisan> simon-o: I see. Sorry, I did not pay attention there.
<pitti> or a newer version of xcb-util
<pitti> if that just fixes bugs, it's okay
<Laney> yeah that's covered by "fix" :)
<simon-o_> Laney, pitti, al-maisan: It fixes some bugs: http://lists.freedesktop.org/archives/xcb/2009-August/004994.html
<simon-o> I'll request a sync
<pitti> looks fine
<al-maisan> yep
<al-maisan> simon-o: thanks!
<Laney> cool beans
<pitti> just note the freeze for main packages (so perhaps don't sync it right now)
<pitti> al-maisan: ^
<al-maisan> pitti: because of the pending A6?
<pitti> right; just in case it breaks stuff
<al-maisan> pitti: noted.
<al-maisan> hmm .. there seems no way to sync a specific version .. or is there?
<cjwatson> it's possible if you can get hold of the package, but ask yourself whether it's a good idea
<cjwatson> you have to mess around by hand with dpkg-scansources to do it
<al-maisan> cjwatson: I see.
<Laney> There's no -t testing or so?
<james_w> yes, you can sync from testing
<james_w> but a version that isn't in unstable or testing or ... is harder
<Laney> ah, well in this case it was a squeeze sync
<Madkiss> since today's updates, my ubuntu netboot client with karmic won't boot anymore
<Madkiss> this is a total regressino compared to yesterday :(
<hyperair> how does upstart stop tasks? kill them?
<simon-o> I requested the sync in bug 431914
<ubottu> Launchpad bug 431914 in xcb-util "Sync xcb-util 0.3.6-1 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/431914
<al-maisan> simon-o: thanks again.
<simon-o> al-maisan: your welcome, thanks for syncing :)
<al-maisan> simon-o: :)
<Madkiss> the last thing i see is "b43-phy: UNSUPPORTED PHY FOUND" or some such
<Madkiss> and after that
<Madkiss> it will just not do anything.
<Madkiss> could that have something to do with the upstart-update that apparently happened last night?
<Laney> more than likely
<slytherin> Madkiss: Does it really not do anything? How long did you wait?
<Pici> 22
<kees> goood morning
<kees> pitti: ah, okay, dang.  can xulrunner be perhaps blacklisted or something?  I find the source traces very helpful.
<pitti> kees: yes, certainly; I just quickly disabled it back then, and then forgot about it, since nobody complained
<kees> pitti: heh, okay.
<Madkiss> slytherin: ten minutes. after downgradingh upstart, it gets faster, but it does not mount /dev/pts and some such
<slytherin> Madkiss: hmm, then surely it is some problem with upgrades. Are you sure the mirror you are using has all the upgrades available?
<Madkiss> slytherin: yes
<ttx> nurmi: mail sent, happy testing
<Madkiss> it tells me that mountpoints /dev/pts and /dev/shm do not exist
<Madkiss> invoke-rc.d: unknown initscript, /etc/init.d/udev not found.
<Madkiss> wtf.
<cjwatson> it's an upstart job now
<kirkland> Keybuk: pitti: http://paste.ubuntu.com/272918/
<cjwatson> 'start udev'
<kirkland> Keybuk: i think that should do it; working here on my end
<kirkland> Keybuk: pitti: would you guys apply that patch to your /usr/sbin/service and make sure it works as expected?
<Madkiss> cjwatson: this  whole upstart-thing is utterly broken.
<pitti> kirkland: exec env -i LANG="$LANG" PATH="$PATH" TERM="$TERM"
<Madkiss> cjwatson: it left my system behind in a completely unusable state; i am not sure if this is supposed to happen round about one month before final release.
<cjwatson> Madkiss: we're two days into a transition to a new init system. I'm sure all your code works first time. ;-)
<pitti> kirkland: out of interest, what does that do? looks like a no-op to me?
<Madkiss> cjwatson: err. where was that announced?
<cjwatson> Madkiss: do please file bugs about breakage
<sebner> Madkiss: still alpha status though :P
<Keybuk> Madkiss: we're actually six weeks before release, which is quite a bit longer than "one month"
<Madkiss> cjwatson: "Hangs at boot. Does not do anything. Produces no output. Lets me not boot with init=/bin/sh"
<Keybuk> six weeks is a *quarter* of our release cycle
<pitti> Madkiss: are you on intel?
<Madkiss> amd64-.
<kirkland> pitti: which part?  the exec?  or the env sanitizing?
<pitti> Madkiss: I mean graphics
<Madkiss> no. nvidia.
<pitti> kirkland: env with TERM="$TERM" etc.
<Keybuk> Madkiss: you're saying that if you put init=/bin/bash on your kernel command-line, your system doesn't even boot to a shell?
<Madkiss> Keybuk: so you've had three quarters of time for breaking everything whatsoever.
<Madkiss> Keybuk: yes.
<Keybuk> Madkiss: then you don't have an Upstart problem
<pitti> kirkland: "sanitizing"? by setting variables to themselves?
<Madkiss> well, after downgrading upstart, i at least get to *somewhere*
 * Madkiss feels snipered
<kirkland> pitti: we inherited that from the original Red Hat service script
<kirkland> pitti: let me investigate
 * ogra wonders what could break that init=/bin/bash doesnt work anymore
<pitti> kirkland: it looks like a weird NOP to me
<Keybuk> Madkiss: what happens when you do use init=/bin/bash
<kirkland> pitti: oh, it's the -i
<pitti> aah
<kirkland> pitti: env -i, --ignore-environment
<ion> madkiss: You installed karmic. As long as itâs in development, you can feel lucky if it ever boots. :-P
<Madkiss> Keybuk: Right nothing after the br0-phy-message I posted earlier.
<pitti> kirkland: gotcha
<kirkland> pitti: so it clears all env variables, except those
<Madkiss> ion: it did so for almost two weeks.
<cjwatson> certainly, if you use init=/bin/bash, upstart is *not called*
<cjwatson> that's the point of init=
<kirkland> pitti: perhaps that not desired in upstart .... Keybuk ?
<Madkiss> ion: I would expect breakage to *reduce* the closer we get to point of release, instead, it's increasing.
<Keybuk> kirkland: doesn't make much difference, I don't think
<Keybuk> kirkland: "start" itself doesn't do anything, Upstart will run the service itself in an already safe environment
<Keybuk> (this is one of the big decision choices)
<ion> madkiss: Itâs still a development release.
<kirkland> Keybuk: okay, then i'll drop that bit from the upstart call
<pitti> kirkland: tried with "sudo service cups" (init.d) and "sudo service hal" (upstart), both work fine
<Madkiss> ion: I can not remember a point in time where Debian unstable was broken like this.
<Keybuk> Madkiss: I can remember lots of times
<pitti> kirkland: and /etc/init.d/hal stop rightfully complains
<pitti> kirkland: works for me
<Madkiss> whatsoever.
 * Keybuk thinks back to the libc5->libc6 transition
<Keybuk> and the shadow transition
<Madkiss> yeah, that was like 400 years ago.
<Keybuk> and the apt transition
<kirkland> +         exec ${ACTION} ${SERVICE} ${OPTIONS}
<kirkland> pitti: i changed the upstart call to that
<kirkland> pitti: i left the sysvinit one as is
<Madkiss> thing is, this need fixage.
<pitti> kirkland: oh, I wasn't saying that you should throw it out
<Keybuk> whenever you change any major component, you'd expect breakage
<Keybuk> at least for some people
<pitti> kirkland: I was just curious what it's supposed to do, since it looked like a noop to me; I missed the -i
<ion> madkiss: Sure. It will probably be fixed within the next six weeks. :-P
<kirkland> pitti: heh, well i don't think it's necessary if we're calling upstart; in the traditional case, i'll leave it
<pitti> kirkland: *nod*
<Madkiss> ion: given the attitude i'm confronted with, i am kinda left with a doubt about it :)
<kirkland> pitti: Keybuk: okay, i'll upload this as soon as the archive unfreezes
<pitti> kirkland: so, thumbs-up for me
<kirkland> speaking of ... has it unfroze?
<pitti> thank you
<kirkland> pitti: no problem, thanks for reporting
<Madkiss> do i need any special boot parameters for upstart?
<pitti> kirkland: realistically I don't think we'll re-roll, but not officially yet
<kirkland> pitti: right-o
<Keybuk> Madkiss: the only attitude is coming from you
<ion> madkiss: Itâs kind of funny you talk to us about attitude. :-)
<kirkland> pitti: i'll wait, i have a stack of uploads building now ;-)
<seb128> would be nice to lift the freeze soon
<seb128> I would like to sponsor os and dx changes before going for dinner
<Madkiss> Keybuk, ion: Listen, lads. Is anyone of you two into helping me debugging this thing?
<Keybuk> Madkiss: after everything you've said about my work, do you want me to help you?
<Madkiss> Keybuk: yes.
<Keybuk> really, you think I'm competent enough to help you?
<Keybuk> because what you were saying above really doesn't make me feel like you do
<Madkiss> If you claim that the situation I am in now was created by some bugs introduced by your changes, I have no reason to believe that there is anyone else who might rather be able to help me than you, eh?
<Madkiss> and furthermore, i am tempted to assume you want bugs in your stuff to be fixed, so here's one willing debian developer who might be able to help.
<Keybuk> well, you've just been ranting on how I should never have introduced my changes, and how other developers would have never broken things
<Madkiss> just tell me what to do. How do I make the boot process more verbose? Do I need some special switch?
<Keybuk> so how's that supposed to be make me feel like helping you?
<soren> kees: At some point you were interested in stuff that worked with sun-java-6, but not with openjdk. Are you still interested?
<Keybuk> I've already asked you a question, and suggested something to try
<Keybuk> that would be a good start
<Madkiss> I oversaw that, can you repeat the corresponding lines please?
<Keybuk> <Keybuk> Madkiss: what happens when you do use init=/bin/bash
<Madkiss> Keybuk: the last thing I see is "the last thing i see is "b43-phy: UNSUPPORTED PHY FOUND"
<Madkiss> Keybuk: and then nothing else happens.
<ion> Try with debug=yes init=/bin/bash
<Keybuk> ok, try taking "quiet" and "splash" off the kernel command line as well
<ion> Letâs see what the initramfs is doing.
<kees> soren: only if there's either a bug report for it, or direct code examples.  :)
<soren> kees: It's my homebanking thingie. I can file a bug, I gues.
<soren> guess, even.
<kees> soren: check your .xsession-errors for tracebacks, too.
<soren> kees: dead silent. I'll file a bug.
<Madkiss> well, erm.
<pitti> jdong, cody-somerville: in the light of the archive permissions reorg, are you fine with obsoleting ~motu-sru and getting added to ~ubuntu-sru ?
<pitti> jdong, cody-somerville: I'll care about the membership shuffling and updating the process page, but wanted to give you a heads-up
<jdong> pitti: sounds like a logical migration path; I'm good with that
<Madkiss> booting the box after having been on the grub shell leads to a lockup.
<Keybuk> it sounds a lot like you have a kernel problem
<Madkiss> *SIGH*
<slytherin> kees: There are many bugs open in launchpad about the stuff that doesn't work with openjdk, or simply crases openjdk.
<Madkiss> okay. last debug message I see is
<kees> slytherin: yup.  I'm trying to improve the quality of said reports.  instead of "it doesn't work", I'm trying to get "this code below, fails this way or that way..."
<Madkiss> "exec run-init /mnt/sbin/init"
<Madkiss> then a whole lot of "according to mtab blabla foobar is already mountred" messaged
<Keybuk> Madkiss: that's not trying with "/bin/bash" now, is it?
<Madkiss> no.
<Madkiss> wait a second.
<slytherin> kees: In any case at this point of time I don't think we should remove sun java6 from archives. We could target that for karmic +1 but I am not sure how good openjdk will be by that time.
<kees> slytherin: yup, I would tend to agree now
<slytherin> But sure openjdk is in far better shape now than it was in jaunty. It doesn't eat CPU when running javadoc on powerpc. :-)
<ogra> Keybuk, is sreadahead running nice'd ? it produces quite some load on the first few boots on armel
<Madkiss> the kernel reproducibly just hangs after having been on the grub shell
<Madkiss> jeez.
<slytherin> ogra: it does on i386 also. :-)
<Keybuk> ogra: it runs in more interesting priorities than nice is capable of
<ogra> slytherin, i'm lacking experience ... my world is full of arms in karmic :)
<Madkiss> hooray for this, i guess.
<Madkiss> Keybuk, ion, i am going to report back for duty tomorrow. I actually might slam a screwdriver into this computers display, I am tired as hell.
<Keybuk> Madkiss: np.
<Madkiss> oh, well
<Madkiss> hm.
<Madkiss> now I am on a bash at least.
<Madkiss> Keybuk: ^^
<Keybuk> what did you change to get there?
<Madkiss> i edited grub.cfg
<Madkiss> mount point /dev/pts does not exist.
<Keybuk> what says that?
<Madkiss> "mount -a"
<Madkiss> and indeed there is no /dev/pts
<Madkiss> and the reason for why it might hang during the normal boot process
<Madkiss> is that starting nfs-common just fails
<Madkiss> or rather
<Madkiss> does never come to an ende
<Madkiss> well. ttyl.
<dee> Hello.
<sebner> hihu dee :D
<dee> hi sebner. good you're here. :)
<dee> do you know what packages in brackets <...> mean if I do "apt-cache depends xutils-dev"?
<dee> And how are you btw.
<sebner> dee: I'm fine and you? Depends, Conflicts ,..?
<dee> Just test the command and you will see what I mean.
<dee> And yes. I'm fine too. Are you on Ubucon this year?
<sebner> dee: naaah, starting with university. You see the package it Conflicts/Replaces
<sebner> huhu jonbo
<sebner> *jono
<dpm> lool: lool: all UNR karmic translations have been imported into rosetta, and future import won't require manual interaction -> https://lists.ubuntu.com/archives/ubuntu-translators/2009-September/002750.html (sorry for the delay in coming back to you, I've just noticed i didn't CC you on that e-mail)
<sebner> jono: HAPPY BIRTHDAY!
<sebner> dee:   Replaces: <imake> means it replaces the package image
<jono> thanks sebner :)
<lool> dpm: cool thanks
<dee> sebner: I know the Meaning of replaces, but not for the brackets.
<ogra> Keybuk, mind to comment on bug 431963 (i suspect calling sreadahead from cmdline is a bit different than what actually happens during boot profiling)
<ubottu> Launchpad bug 431963 in linux "io/fs errors when launching gdm on imx51 with sata" [Undecided,New] https://launchpad.net/bugs/431963
<sebner> dee: ah, wondering now too. Maybe a special feature for Conflicts and Replaces. :P
<dee> jono: it's your birthday? so good luck for the future, nice evening (every day of course), have fun and rock on. :)
<dee> sebner: no, there are packages with Depends that have brackets.
<jono> thanks dee!
<Keybuk> ogra: not sure what you want me to comment on?
<Keybuk> ogra: his disk is clearly dying
<Keybuk> (or his SATA controller)
<ogra> difference between running sreadahead and the actual boot
<ogra> Keybuk, neither is, thats the prob
<ogra> its very likely the kernerl driver we got from freescale
<Keybuk> I disagree, he's getting I/O errors from particular sectors
<ogra> its reproducable by others with proven good HDs
<Keybuk> it could be the SATA driver, yes
<sebner> dee: then it may be a bug O_o
<Keybuk> sreadahead will cause more I/O in a shorter space of time than a normal boot
<Keybuk> is that what you mean?
<ogra> Keybuk, fun is, there is no SATA driver :)
<dee> sebner: no, ixel has the resolution. this are virtual packages.
<Keybuk> ogra: sure there is
<sebner> dee: ah good to know
<ogra> Keybuk, well, compared to me running sreadahead on a tty i guess there is a difference to what the bootprocess does
<Keybuk> ogra: no, not really
<ogra> Keybuk, nope, its a hardware bridge
<Keybuk> ogra: cat /etc/init/sreadahead.conf
<ogra> its SATA->USB
<Keybuk> ogra: you'll still have a driver for it
<ogra> and the kernel drives it with the special freescale ehci driver
<Keybuk> it's still a driver ;)
<ogra> sure i do, but its exposed as USB disk to the whole system
<ogra> by the HW
<ogra> fun is that its even exposed as /dev/sdb if no disk is attached
<nixternal> so what is the trick for today in order to get my encrypted /home working again? seems to have changed since yesterday
<nixternal> freezes at * Starting sad crypto disks...
<jpds> nixternal: bug #430496
<ubottu> Launchpad bug 430496 in mountall "cryptsetup devices not mounted on boot" [High,Invalid] https://launchpad.net/bugs/430496
<nixternal> jpds: ya, yesterday I was able to /etc/init.d/cryptdisks start
<nixternal> and all was good
<nixternal> today, I can do it, but as soon as I start KDM no keyboard/mouse
<nixternal> it doesn't kick off everything like it did yesterday
<nixternal> sure there is something else that needs to be started first
<pitti> @all: freeze is lifted, go ahead and upload; a6 isn't released yet officially, but we won't re-roll
* pitti changed the topic of #ubuntu-devel to: karmic is getting happier, but is still feeling a bit hung-over, so be gentle | Archive: FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<robbiew> heh
<dee> bye
<slangasek> ttx: does the errata entry for 430758 look accurate?
<slangasek> kirkland: please check the errata text for bug #430820
<ubottu> Launchpad bug 430820 in eucalyptus "eucalyptus node install results in broken /etc/network/interfaces" [High,Fix committed] https://launchpad.net/bugs/430820
<nixternal> Keybuk: anything I can do on the debug front to help out with anything? I have 2 busted machines waiting for some loving :)
<Keybuk> nixternal: I basically think I have to rewrite cryptsetup ;)
<nixternal> oooh now that sounds fun :)
<kirkland> slangasek: sure ...
<kirkland> slangasek: where is this errata text?
<nixternal> Keybuk: if i reformat/reinstall with latest release, and don't encrypt, I should be fine right?
<nixternal> I might r/r my lappy and leave my desktop broken for debugging purposes
<nixternal> i need something other than this netbook up and running right now, otherwise no work gets done :)
<Keybuk> nixternal: yeah
<siretart> nixternal: FYI, I've just updated my karmic vbox that uses root on crypted lvm and that VM still boots without any problems..
<Keybuk> the problems at the moment are cryptsetup and NFS
<Keybuk> cryptsetup because it really needs to decrypt devices when udev knows about them, not at an arbitrary point in the boot process
<nixternal> ya, I have /, /home, and swap encrypted...can't figure out how to work around it today
<Keybuk> (that'd give you big plus points anyway - plug in a USB stick a week after, and it can be still decrypted and mounted from fstab)
<Keybuk> NFS because I'm a dolt and didn't upload the portmap/rpc.*d upstart jobs
<Keybuk> on the cryptsetup front, if you do fancy finding out why my kludge doesn't work. I'd appreciate it
<jdstrand> slangasek: does bug #431804 require an FFe? it is fixing a bug by introducing a feature (upstart script)
<ubottu> Launchpad bug 431804 in ufw "ufw starts after some network daemons due to move to upstart in Ubuntu" [Low,Fix committed] https://launchpad.net/bugs/431804
<jdstrand> slangasek: hi btw
<Keybuk> I can't see why the /etc/init/cryptdisks-enable.conf thing doesn't work
<nixternal> Keybuk: I am looking at it now...the only thing i can see is "sad" as that is mentioned when the machine freezes
<siretart> Keybuk: I see some udev warnings (or errors, not sure) about udev rules during bootup. are you aware of them or are you interested in reports about them? the VM still boots fine, though.
<Keybuk> siretart: they are already reported
<Keybuk> and I'm aware of them ;P
<Keybuk> nixternal: silly question, what happens if you add "console owner" to the top of that job file somewhere
<siretart> ok
<nixternal> let me try
<pitti> siretart, Keybuk: btw, I checked udev trunk, it has the warnings fixed
<pitti> we just need to fix the NAME="%k" in the kvm rules
<pitti> (/lib/udev/rules.d/45-qemu-kvm.rules)
<nixternal> rebooting to try the new change...will let you know
<Keybuk> pitti: I know, I talked with kay about it yesterday
<Keybuk> the SYMLINK{unique} thing is an actual bug in udev ;)
<nixternal> Keybuk: whoa, that did it dude
<Keybuk> but that's fixed in git too
<Keybuk> nixternal: ...
<Keybuk> nixternal: !!!
<nixternal> console owner
<Keybuk> nixternal: maybe I should just not be allowed to use computers
<nixternal> lol
<nixternal> damnit, i owe you a big hug!
 * nixternal logs into KDE
<hyperair> Keybuk: what's wrong with cryptsetup?
<Keybuk> hyperair: broken by design
<hyperair> Keybuk: meaning?
<Keybuk> well
<Keybuk> everything else has changed so that the way it's designed is no longer the way other things work
<Keybuk> hyperair: it acts on block devices, and creates new block devices
<hyperair> right.
<hyperair> and what's wrong with that?
<hyperair> LVM does the same too
<Keybuk> it *should* be designed such that individual block devices are decrypted as a result of uevents
<Keybuk> ie. a udev rule calls out to cryptsetup to do its thing
<Keybuk> and cryptsetup creates new block devices
<Keybuk> which udev then picks up through the kernel again
<hyperair> then cryptsetup's initscript is screwed, isn't it?
<Keybuk> instead, it expects there to be a single point in the entire boot where "all block devices are visible, and should all be decrypted in one pass"
<Keybuk> exactly
<hyperair> well then patch it =p
<Keybuk> yeah that's what I said
<Keybuk> I'm convinced that I already did this a couple of years ago
<nixternal> Keybuk: what exactly does 'console owner' provide? I have an idea, just want to know if I am close
<Keybuk> at the same time that we moved lvm and mdadm to be called from udev
<Keybuk> nixternal: something more useful than /dev/null as stdin
<hyperair> well this kind of thing is not going to hit me in any case... my /dev/sda2 *needs* to exist before cryptsetup can decrypt it, and my root's sitting on it so it's done in initrd
<nixternal> Keybuk: oh, then I wasn't even close :)
<Keybuk> nixternal: what was your idea?
<Keybuk> hyperair: right
<rgreening> should hal return my unmounted usb drive with this command? hal-find-by-capability --capability storage
<hyperair> hal's deprecated isn't it?
<nixternal> oh jeesh, put me on the spot, now I will sound/look even more stupid than I already am...I figured it was something like superuser status...the whole owner thing is what got me
<Keybuk> ah
<hyperair> we're not supposed to not have hal and have to find some other way to dig devices out
<Keybuk> console output => connect stdin/out to /dev/console instead of /dev/null
<rgreening> hyperair: hmm... what's the correct command for karmic then? hyperair
<hyperair> which either doesn't exist or is all over the place so you can't find it anyway
<Keybuk> console owner => as output, but invoke secret magic rituals to make ^C work
<hyperair> rgreening: look at what i just said
<nixternal> gotcha....
 * nixternal jots that down to remember it
<rgreening> useless commentary
<rgreening> lol
<hyperair> but it's true!
<hyperair> well almost completely true anyway
<rgreening> can someone who has something useful to say? :) pitti :)
 * hyperair predicts that some years down the road, udev will be deprecated for the same reason hal was. and then we have to populate our /dev manually
<siretart> hyperair: that would be a step back
<rgreening> well, devkit-disks --enumerate doesn't show my /dev/sdc or /dev/sdc1
<kirkland> slangasek: yo?
<rgreening> so, what's below hal and devkit-disks (i.e. common)
<slangasek> kirkland: https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview
<hyperair> siretart: and hal disappearing without some new way of listing all types of hardware isn't a step back?
<slangasek> (usual place)
<hyperair> i mean come on, i'm still figuring out information from my hard disk using hal-device.
<slangasek> jdstrand: I think that's covered by the existing FFe for boot work; you might want to just drop a comment in that bug (and/or open a task)
<jdstrand> slangasek: cool, thanks
<hyperair> where in udev do i get my hard disk's serial number?
<siretart> hyperair: sysfs does still exist, no? writing some graphical voodoo should that hard...
<kirkland> slangasek: made two minor modifications to the command to be run; added 'sudo' and the networking service restart
<zyga> mvo: ping
<hyperair> siretart: yeah, so i'm going to have to spend some time figuring out exactly what all the cryptic names in sysfs mean
<hyperair> siretart: it's still a step back. sysfs isn't much better from when hal started imo.
<siretart> hyperair: try systool
<rgreening> hyperair: udevadm info --query=all --name=/dev/sda
<rgreening> switch /dev/sda for your drive
<rgreening> hyperair: ID_SERIAL is there
<slangasek> mr_pouit, NCommander: cody doesn't appear to be around today; either of you in a position to round up some more xubuntu testing for alpha 6?  we only have tests on 1 of 4 images, which is precisely enough to permit publishing 1 of 4 images with the milestone
<slangasek> superm1: mythbuntu doesn't show any test results since the OMGkittens respin; prospects of getting tests in some time today?
<hyperair> rgreening: point taken
<rgreening> now, if only I could get some help with debugging why my usb drives do not show up in hal nor devkit-disks, but the udev link is there.
<rgreening> :)
<NCommander> slangasek, I can probably do testing in a little bit, I need to try and force some food down
<Daviey> slangasek: yes, i think we can get some done today.
<nixternal> note to self: make sure you remove shell.conf after adding 'console owner' to cryptdisks-enable.conf :)
<NCommander> slangasek, and w.r.t. to last night, your right, I'm not sure why i was posting a kernel panic that bug; it was a separate issue.
<nixternal> NCommander: careful forcing that food down, you might choke :p
<nixternal> interesting...I have 3 intel machines, with damn near the same hardware....my netbook is perfect, my lappy I have to do the encrypted work around as with my desktop...my netbook and lappy have compisiting enabled and rocking, my desktop will not do compositing unless I add 'nomodeset' to grub
<Laney> this is *weird*
<Laney> looks like my fstab is being wiped out on boot
<sivang> nice :)
<sivang> leaving the system unusable ?
<Laney> naturally
<sivang> :)
<Laney> so I get kicked to this bash prompt, remount the drive rw and my changes in /etc don't stick
<Laney> but I can save stuff in /root which is on the same partition
<jono> I am trying to upgrade my karmic machine by booting from my USB stick, chrooting my local disk and doing the upgrade, but apt-get doesnt see the repos - any idea why?
<MsMaco> jono: can the chroot reach the net?
<jono> MsMaco, it seems not
<jono> any idea how I make it do that?
<MsMaco> jono: maybe make an aptoncd iso and loop mount it over a spot below your chroot'd ?
<MsMaco> chroot'd /?
<MsMaco> (too much that key)
<jono> hmmm
<jono> is there a way to get the chroot to the see the net?
<zyga> jono: mount proc?
<Daviey> jono: you need to bind proc ?
<jono> how do I do that?
<zyga> jono: and remember /etc/passwd
<Laney> mount -o bind /proc proc
<jono> still no net
<jono> also:
<jono> root@ubuntu:/# ifconfig
<jono> Warning: cannot open /proc/net/dev (No such file or directory). Limited output.
<zyga> jono: sdhh.. /etc/resolv
<zyga> jono you need to use mount -o bind from _outside_
<zyga> not from the chroot itself
<jono> ahhh
<Laney> I don't need to do that to be able to aptitude update from a chroot, fwiw
<Daviey> jono: where is the disk mounted?
<jono> buntu@ubuntu:~$ sudo mount -o bind /proc proc
<jono> mount: mount point proc does not exist
<chrisccoulson> i normally do "mount -t proc proc /mnt/chroot/proc" rather than bind mount
<jono> Daviey, /media/disk
<Daviey> sudo mount -t proc none /media/disk/proc
<zyga> jono: mount -o bind /proc /path/to/chroot/proc
<Laney> all works ;)
<jono> ok now ifconfig gives me output
<Daviey> \o/
<jono> but still no net in the chroot
<Daviey> jono: ping 74.125.127.100
<jono> Daviey, pings fine
<Daviey> jono: you need to sort out your resolv.conf
<Daviey> jono: cp contents of /etc/resolv.conf to inside chroot.
<Daviey> host to chroot.
<chrisccoulson> this is why i use schroot - you can make it dynamically copy files like that in to the chroot automatically
<jono> Daviey, so copy my host resolv.conf to the /etc/resolv.conf in the chroot?
<chrisccoulson> and also automatically mount all the important filesystems
<chrisccoulson> jono - yes
<Daviey> jono: yeah.
<Laney> this is so weird
<chrisccoulson> Laney - ?
<jono> yay!
<Laney> I made /etc/fstab and /etc/fstab.bak from a live cd
<jono> thanks folks
<Laney> then rebooted, and now they are both empty
<Laney> but the files are there
<jono> lets see if this fixes karmic now
<chrisccoulson> Laney - did you unmount the filesystem properly?
<Laney> yeah
<jono> erk
<chrisccoulson> that is wierd
<jono> root@ubuntu:/etc# apt-get update
<jono> Get:1 http://archive.ubuntu.com karmic Release.gpg [189B]
<jono> Ign http://archive.ubuntu.com karmic/main Translation-en_US
<jono> Ign http://ppa.launchpad.net karmic Release.gpg
<jono> 89% [Working]FATAL -> Could not set non-blocking flag Bad file descriptor
<jono> E: Method http has died unexpectedly!
<Laney> this happens when I do it from the rescue shell too
<Laney> i'll try again to be sure
<jono> any idea what that is?
<jono> Daviey, have you seen that before?
<chrisccoulson> jono - not sure. but did you mount /dev and /sys in your chroot too?
<chrisccoulson> (i'm not sure if that would cause your issue though)
<jono> reading http://michael-prokop.at/blog/2007/10/27/could-not-set-non-blocking-flag/ now
<Daviey> jono: no :)
<Daviey> sudo mount -o bind /dev /media/disk/dev
<jono> I think I have it fixed
<Daviey> win
<jono> I did a: sudo mount -o remount,dev /dev/sda1
<jono> managed to update the package list
<jono> now downloading updates
<jono> hopefully this won't bugger anything up
<Laney> spammed sync
<Laney> lets try again
<jono> hmmm it says Can not write log, openpty() failed (/dev/pts not mounted?)
<Daviey> jono: see the line above, you need to bind /dev to /media/disk/dev
<jono> just done that
<cjwatson> openpty message is harmless
<cjwatson> it just means dpkg's terminal output won't be logged properly
<jono> ok here we go :)
<Laney> Well fstab exists now but still get kicked to this dodgy shell
<cjwatson> I don't think bind-mounting /dev automatically binds mounts on subdirs too
<cjwatson> you need --rbind for that
 * hyperair takes note of rbind
<Laney> http://launchpadlibrarian.net/31955810/17092009299.jpg if anyone wants to poke
<Daviey> cjwatson: "all possible submounts", does that mean locations mounted are also bound?
<cjwatson> well, /dev/pts is a separate mount on a subdirectory of /dev, you see
<chrisccoulson> Laney - does your machine just boot to that without you doing anything?
<Laney> yes
<Laney> I thought it was because of the empty fstab, but apparently not
<nixternal> Laney: you added '/etc/init/shell.conf' I take it?
<chrisccoulson> hmmm, this might sound like a really silly question, but you're not booting with "init=/bin/bash" by any chance are you? it just looks like its starting a bash shell without trying to do anything else
<Laney> chrisccoulson: ... well I tried that once
<Laney> if grub saves it, then maybe
<nixternal> init=/bin/bash wouldn't give you @hostname and would give you @(none)
<nixternal> iirc
<Laney> and I'll feel like an idiot
<Laney> nixternal: I don't know what that is
<Laney> chrisccoulson: nah, no doing
<Laney> ...wait
<Laney> slangasek had me add "bash" to the mountall config last night
<nixternal> well there you go (I think) :)
<Laney> lets try
<skatteola> My boot dies (possibly unrelated for all I know) after I get a bunch of "mountall: <afewcharsofgarbage>: Read-only file system", "mountall: <afewcharsofpuregarbage>/sndstat: No such file or directory".. Where is it getting the broken paths?
<Daviey> "no job control in this shell", i normally see when someone has screwed their permissions/ownership of ~
<Laney> nope, the bash thing was it
<Laney> nixternal, chrisccoulson: Thanks for the inspiration :)
<skatteola> (actually it gets a bit further than that, mounting some fs's and then dies.)
<chrisccoulson> Laney - you're welcome
<nixternal> aww, I am inspiring \o/
<chrisccoulson> did it boot ok now?
<Laney> yeah
<nixternal> groovy :)
<chrisccoulson> Laney - you just need some more updates to break it again now;)
<Laney> this is only a bandaid system anyway - hit on a udev/util-linux bug yesterday which meant I couldn't have / on an mdadm array :)
<Laney> the fun of testing
<jono> back up and running
<jono> thanks folks :)
<jono> seb128, still have the issue with no window manager and panels
<chrisccoulson> hey jono - are they not running, or just running but frozen?
<nixternal> jono: kde is working fine...ahh the good ol' days, remember them birthday boy?
<nixternal> ;p
<jono> chrisccoulson, panels are running, but not showing - when I killall them they show
<jono> I have to run metacity --replace to get a window manager
<chrisccoulson> hmmm, i've not seen that issue before
<jono> interestingly, I clicked the button in the startup apps window to save current opened apps, one of which is tomboy which keeps loading but I don't see it in the list of startup apps anymore
<robbiew> jono: i had this after my first reboot (no panels)...but it was magically fixed in subsequent reboots
<Laney> what will happen to the UUID if I resize a partition?
<robbiew> has anyone with boothchart installed, noticed an 'sreadahead -t0' process running after the machine is up? on every reboot?
<cjwatson> Laney: ought to be preserved
<Laney> cool
<Laney> seems windows 7 still wants to be the first partition :(
<chrisccoulson> heh, i don't have the hassle of dual-boot any more:)
<Laney> I only dual for l4d and tf2
 * Laney donates to wine
<chrisccoulson> Laney - you're in to gaming are you?
<Laney> chrisccoulson: only casually - I'm really not very good :)
<chrisccoulson> i thought i would try gaming when i purchased my graphics card, but then i never bothered with it;)
<chrisccoulson> so its a bit wasted now
<Laney> CUDA!
<hyperair> frets on fire!
<hyperair> that runs on my intel =D
<pitti> pochu_: wow, that was fast: http://packages.qa.debian.org/m/media-player-info.html
<hyperair> huh what happened to debhelper?
<hyperair> http://launchpadlibrarian.net/31978323/buildlog_ubuntu-karmic-amd64.banshee_1.5.1%2Bgit20090916.r2.2d2d42f-0ubuntu1_FAILEDTOBUILD.txt.gz
<hyperair> it isn't supposed to add a debian/tmp to debian/<blah> paths is it?
<hyperair> dh_install, that is
<pitti> hyperair: it only does that in compat level 6 and above, I think
<hyperair> i've never had this with compat level 7
<pitti> sorry, from 7 on
<hyperair> for starters, i've been using this debian directory for several weeks now, and a cronjob preparing builds
<hyperair> or rather, alarm-clock-applet
<cjwatson> hyperair: man debhelper, look at the "Debhelper compatibility levels" section
<hyperair> cjwatson: i'm familiar with those.
<cjwatson> "dh_install, will fall back to looking for files in debian/tmp if it doesn't find them in the current directory (or wherever you tell it look using --sourcedir). This allows dh_install to interoperate with dh_auto_install, which installs to debian/tmp, without needing any special parameters."
<hyperair> cjwatson: but it's not supposed to prepend debian/tmp unless it can't find them in the current directory.
<cjwatson> is it possible that in this case perhaps it can't?
<hyperair> why wouldn't it be able to?
<cjwatson> maybe something failed to compile, but the build system didn't notice?
<hyperair> http://launchpadlibrarian.net/31974709/banshee_1.5.1%2Bgit20090915.r1.ba07145-0ubuntu1_1.5.1%2Bgit20090916.r2.2d2d42f-0ubuntu1.diff.gz <-- behold the existence of debian/Banshee.GStreamer.dll.config
<cjwatson> is that file really meant to be in debian/ ?
<cjwatson> oh
<hyperair> no wait
<cjwatson> err, no
<hyperair> lemme stare at it again
<cjwatson> I DON'T behold its existence
<cjwatson> I behold a patch that explicitly and specifically *removes* it
<cjwatson> @@ -1,3 +0,0 @@
 * hyperair groans
 * hyperair bangs head on wall
<Laney> haha
<hyperair> what went wrong with my script?
<hyperair> hmph. it's still in the git repository..
<jcole> we have hundreds of network printers.. and with ubuntu jaunty, i could go to add printer to see all the network printers and easily select the one i want... but with karmic, it *only* shows the model now and no longer the ip, so i have no idea which printer im selecting since the same model is all throughout the network... how do i show the ip like jaunty used to do so i can select the right printer?
<hyperair> ...aha. damn you, you stupid .gitignore
<jcole> ive browsed every option in the printer configuration gui and cant seem to find it out how to re-enable the ip... do i have to dtrop to a prompt and edit cups config files? or is there something hidden in gconf?
<tkamppeter> jcole, I did not change anything, seems to be a problem of the new CUPS 1.4.
<jcole> tkamppeter: ok, thanks for the update... i got it working by walking over to the printer, writing down its info, and manually adding it to the gui
<jcole> tkamppeter: if this doesnt get fixed, there is really no use of having a dropdown of scanned network printers if you are on a large network (since you cant determine which printer you are selecting)
<tkamppeter> jcole, I do not see any difference between Jaunty and Karmic, for me the printers in the list show without IP in both versions. If it is a non_HP printer, you should see the IP on the right when you click on the printer.\
<jcole> tkamppeter: i work for hp and they are *all* hp printers, lol
<jcole> tkamppeter: perhaps i need to install an hplip lib?
<tkamppeter> If it is an HP printer you have to click on "Connection", then choose AppSocket you see also the IP, but this is awkward.
<jcole> tkamppeter: jaunty used to show the ip
<tkamppeter> jcole, I have also only HP printers, as I get them from HP for testing.
<jcole> tkamppeter: i just look on my laptop which is jaunty, it shows the ip... want a screenshot?
<tkamppeter> jcole, does the web interface (localhost:631) or hp-setup show the IPs?
<jcole> tkamppeter: on which? my karmic or jaunty install?
<tkamppeter> On Karmic
<tkamppeter> jcole, by the way, are you working together with David Suffield or Shiyun Yie?
<rent0n> hello
<jcole> tkamppeter: im not sure where i go here to scan for network printers...
<rent0n> I've got one question: how do i understand wich verion of a specific package will be present in karmic?
<rent0n> *which version
<jcole> tkamppeter: heh, yes, david and shiyun both work for hp in vancouver, wa .. ive seen them in our internal linux irc rooms
<tkamppeter> jcole, the web interface also scans the network, you must go to "Administration", then click "Find new printers".
<jcole> rent0n: packages.ubuntu.com/packagename
<rent0n> I mean in jaunty the tint2 package is 0.6, so i expected to find 0.7 in karmic but if i look for tint2 on packages.ubuntu.com it says tint2 will be 0.6 in karmic
<tkamppeter> jcole, where are you located?
<rent0n> so i just wanted to know if this is a defintive choice
<jcole> tkamppeter: hp corporate in palo alto, ca
<jcole> tkamppeter: it says no printers found
<blueyed> Keybuk: I'm experiencing bug 432052 - how can I help debug this? are you working on (another) cryptsetup fix?
<ubottu> Launchpad bug 432052 in cryptsetup "Encrypted root not found (requires luksOpen / vgchange -a y in busybox)" [Undecided,New] https://launchpad.net/bugs/432052
<rent0n> or maybe it is possible that you will put the 0.7 version before releasing karmic
<Keybuk> busybox?  that's in the initramfs then?
<blueyed> yes
<Keybuk> nothing to do with me, then :p
<jcole> tkamppeter: localhost:631 looks different in jaunty... looks like the old school cups web in jaunty
<blueyed> Keybuk: ? cryptsetup fails to mount the root device?!
<Keybuk> blueyed: yes, but it's before init gets started
<Keybuk> so nothing I touched could break that
<tkamppeter> jcole: I get the same in Karmic, in Jaunty it works, and even shows IPs. but it does not automatically use the HPLIP backend.
<Keybuk> unless it was already broken in some way
<tkamppeter> Seems that in CUPS 1.4 they broke the web interface completely.
<jcole> tkamppeter: yep, same here, jaunty finds the printers in the web interface with the ips
<blueyed> Keybuk: uh.. it asked for a passphrase until yesterday.. I'd say until your cryptsetup upload. But good to know that init isn't started yet there. OTOH: you might have broken the initramfs then.. :P
<rent0n> uh?
<rent0n> someone can tell me how the thing works?
<Keybuk> blueyed: don't see how
<blueyed> Keybuk: it does not ask for a passphrase anymore.
<hyperair> how do you not have init started?
<debfx> blueyed: maybe it's fixed by https://edge.launchpad.net/ubuntu/+source/cryptsetup/2:1.0.6+20090405.svn49-1ubuntu4
<blueyed> Keybuk: lemme check.
<Keybuk> hyperair: he's still in the initramfs
<hyperair> Keybuk: isn't init started there?
<Keybuk> hyperair: no
<hyperair> Keybuk: i mean, isn't udev started there even?
<hyperair> =O
<tkamppeter> jcole, hp-setup in Karmic does not show IPs, as it uses DNS-SD for identifyinmg and distinguishing network printers.
<blueyed> debfx: maybe.. I do not have ubuntu4 here yet. Thanks!
<tkamppeter> jcole, in Jaunty is shows IPs.
<jcole> tkamppeter: yes, same here
<pochu_> pitti: it seems the new ftp assistants are doing their job ;)
<jcole> tkamppeter: im installing the hplip-gui to see if that has network scanning
<tkamppeter> jcole, you should report a bug on system-config-printer about displaying IPs.
<blueyed> will try that. b"r"b.
<smoser> slangasek, are you around ?
<rent0n> ok thank you in any case
<rent0n> maybe it's a too difficukt question
<jcole> rent0n: if you really need it, download it from packages.debian.org/tint2 and take your chances
<rent0n> jcole: i just wanted to know if there is a chance of getting an upgrade in tint2 package before karmic release of it's confirmed that the version will be 0.6
<rent0n> just to know
<blueyed> Keybuk: ubuntu4 fixed the keyphrase input. Unfortunately, it still fails. I'll upload screenshots. (Thanks, debfx)
<jcole> karmic got angry and was running slow... hopefully this reboot will make it happy
<stgraber> Keybuk: attached mountall --debug output
<Keybuk> to?
<stgraber> Keybuk: bug 431204
<ubottu> Launchpad bug 431204 in mountall "stuck waiting for mount points on LTSP setups" [High,Incomplete] https://launchpad.net/bugs/431204
<Keybuk> huh
<blueyed> Bug 432070 is my current state.. still not booting. I'll look into manually fscking in the chroot, but would like to have some feedback before trying the does-not-boot-back-to-LiveCD mambo.
<ubottu> Launchpad bug 432070 in mountall "UNEXPECTED INCONSISTENCY: fails to boot ("last mount time is in the future")" [Undecided,New] https://launchpad.net/bugs/432070
<slangasek> smoser: hi
<LaserJock> slangasek: how long do we have to confirm testing for Alpha6?
<slangasek> LaserJock: < 1.5h if it's going to be included in the announcement mail
<LaserJock> ok then
<LaserJock> slangasek: I've got a good review for i386 but haven't confirmed amd64 yet
<slangasek> < 1h13, actually
<jcole> tkamppeter: i downgraded cups to what is in jaunty-updates and it works perfectly :)
<jcole> tkamppeter: not sure if this is useful, but this is the cups.conf diff -> http://pastebin.ca/1570037
<Keybuk> stupid question of the week
<Keybuk> but how the hell do you file a bug?
<seb128> Keybuk, ubuntu-bug component
<cjwatson> +filebug?no-redirect if you don't want to use ubuntu-bug
<Keybuk> ugh
<cjwatson> it's an "experiment"
<Keybuk> can't they just check whether you're a bug contact and let you file bugs on your own damned packages?
<cjwatson> you'd think
<Laney> One of the proposals is to let bug-control members file bugs directly but redirect for others
 * Keybuk files a bug on malone
<Keybuk> Laney: if I'm a bug contact, I should be able to file bugs on my own packages for my own reasons
<Laney> of course, launchpad shouldn't get in the way
<robmur> Hi everyone
<robmur> When is alpha 6 due to be released?
<robbiew> about an hour
 * davmor2 giggles about an hour pff
<robbiew> :D
<robmur> Great, thanks.
<slangasek> davmor2: things not done in an hour may not get included, our website support goes home for the day then
<jcole> tkamppeter: what is interesting is line 29 and lines 87-116
<davmor2> slangasek: mostly done now last 2 tests on xub
<jcole> robmur: https://wiki.ubuntu.com/KarmicReleaseSchedule
<davmor2> slangasek: beside in an hour I want to be in bed :)
<slangasek> davmor2: then it's perfect timing! :)
<LaserJock> if anybody feels like some last minute testing the Edubuntu DVD needs testing on amd64
<tkamppeter> jcole: I have found the origing of the problem, it is not your config, simply run
<tkamppeter> /usr/lib/cups/backend/snmp
<tkamppeter> on Jaunty and on Karmic and compare the output.
<tkamppeter> Try the same with
 * Keybuk chuckles with delight
<tkamppeter> /usr/lib/cups/backend/dnssd
<Keybuk> that's made my day
<Keybuk> The 'status' command expects any of the following arguments:
<Keybuk> new, incomplete, invalid, wontfix, confirmed, triaged, inprogress, fixcommitted, fixreleased
<Keybuk> Failing command:
<Keybuk>     status udev
<Keybuk> bwahahaha
<ion> Hehe
<cjwatson> I'm pretty sure I remember warning that the "prefix commands with spaces" approach to e-mail commands would go wrong
<cjwatson> in about 2004
<cjwatson> or maybe 2005
<Keybuk> ;)
<tkamppeter> jcole: Both backends have put the IP into the human-readable output string (second string in quotes) in CUPS 1.3 (Jaunty) and not any more in CUPS 1.4 (Karmic). -> Regression.
<jcole> tkamppeter: ah, does this apply to all the backends?
<jcole> tkamppeter: s/does this/does this bug/
<jcole> $ ls /usr/lib/cups/backend/
<jcole> beh bluetooth cups-pdf dnssd hp hpfax http ipp lpd parallel scsi serial smb snmp socket usb
<jcole> $ apt-file search /usr/lib/cups/backend
<jcole> bluez-cups cups cups-dbg cups-pdf foomatic-filters hal-cups-utils hplip hplip-dbg hpoj mtink smbclient
<jcole> tkamppeter: thank you for looking into this for me
<jcole> tkamppeter: should i still submit the bug? or are you going to create a more detailed bug report
<superm1> slangasek, sure can ask the guys to try to get some in today.  we've been holding up with all the archive churn
<slangasek> superm1: sorry for the churn; we settled that all out yesterday evening, though, and the good candidates have been posted and waiting for testing
<superm1> ok
<slangasek> everything is ready to publish except mythbuntu, actually
<superm1> slangasek, i assume everyone else just went out without a usplash then?
<slangasek> superm1: yes
<pitti> sebner: still here?
<sebner> pitti: yep, but not for long
<slangasek> (and usplash seems kinda generally broken right now in my own testing, so I don't think you should sweat that)
<pitti> sebner: building a new libatasmart with the blacklisting now
<pitti> sebner: do you have amd64 or i386?
<sebner> pitti: i386
<pitti> sebner: uploaded a fix to karmic now
<pitti> sebner: I'd be grateful for testing feedback
<pitti> sebner: ok, then we need to wait for the buildds :)
<sebner> pitti: I happily test the fix but tomorrow if you don't mind
<sebner> pitti: it's also late in germany AFAIK :P
<pitti> sebner: oh, you aren't in .de?
<sebner> pitti: hmm, I know that you have loads of stuff to do and get to know many people but I told you pretty often that I'm from .at :P
<pitti> oh, you did? sorry
<pitti> well, timezone wise that doesn't matter
<sebner> pitti: np. yeah I know ;-P
<pitti> sebner: https://edge.launchpad.net/ubuntu/+source/libatasmart/0.14-1ubuntu1/+build/1247755 -> building now
<pitti> in a few minutes you can grab the .deb from there
<pitti> sebner: but nevermind, if you are about to go to bed, you can just as well dist-upgrade tomorrow morning :)
<sebner> pitti: heh, yeah. I'm really sorry. The first thing I'll do is a dist-upgrade (after getting up in the morning), what kind of feedback do you need then?
<pitti> sebner: just whether it works normally, with all local hacks removed
<pitti> you shouldn't get USB resets any more
<sebner> pitti: no difference between blacklisting and moving rule 95 aside :P
<pitti> sebner: right, but it's supposed to work in a default install without messing with the rules :)
<sebner> pitti: We'll see. gn8 for now!
<mneptok> g'nate?
<pitti> sebner: gute Nacht!
<slangasek> mneptok: no, g'nhuit
<cjwatson> hey, that nearly works in French
<cjwatson> do French people say bn8?
<slangasek> they say n8
<superm1> cjwatson, has the upstart ubiquity job actually been checked?  at least for mythbuntu, it's looking like at the end of ubiquity when pressing restart there is an endless loop of what looks like the gdm and ubiquity jobs fighting to spawn,stop and restart themselves over and over
<cjwatson> I checked that it worked on startup; I didn't get far enough to check it on restart, because it was obscenely late
<mneptok> slangasek: in sebner's case, i imagine "gute n'acht"
<cjwatson> the ubiquity job could check whether it's already run once, but that feels like a massive hack. I'm sure upstart has a better way to do that
<cjwatson> maybe it needs 'normal exit 1' or something?
<cjwatson> or 'normal exit 0 1', not quite sure from the docs
<cjwatson> Keybuk: ^- any thoughts?
<superm1> cjwatson, http://imagebin.org/64289 trying to pause virtualbox inbetween runs it looks like its not just ubiquity constantly respawning, but gdm too
<cjwatson> superm1: gdm respawning would kick off ubiquity
<superm1> ah
<cjwatson> and we know gdm is set to respawn
<cjwatson> though switching to runlevel 0/6 should stop it
<tkamppeter> jcole, simply report the bug, I will add what is missing.
<jcole> tkamppeter: cool beans
* slangasek changed the topic of #ubuntu-devel to: Karmic Alpha-6 released, please help find boot bugs | Archive: FeatureFreeze, UIFreeze | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<robbiew> whoohoo!
<c_korn> is karmic in a happy state again ?
<robbiew-afk> happy as it will be for this release ;)
<c_korn> have those upstart bugs been fixed? I was not able to boot the last time. then I purged the virtual machine completely
 * mneptok takes the plunge and runs update && upgrade && dist-upgrade for the first time in a week
<Lure> mneptok: coward ;-)
 * Laney hopes it gets at least two bugs happier...
<Amaranth> as long as you don't have file systems on a network it should work great
<Amaranth> if you do I think the answer is "maybe"
<Amaranth> same with encrypted disks, from what I hear
<Laney> and booting from mdadm
<Amaranth> yeah, basically you better only have things ubiquity lets you setup during install
#ubuntu-devel 2009-09-18
<TheMuso> That was.... weird. After update, my clock decided to jump 14 hours into the future.
<Amaranth> TheMuso: UTC=no sucks
<Amaranth> we're treating the system clock as local time now
<TheMuso> heh
<Amaranth> it'll probably jump forward 14 hours every boot
<TheMuso> Is this for real, or is this a joke?
<Amaranth> real, a compiz developer had the same problem
<kirkland> jdstrand: around?
<Amaranth> one of his commits ended up 6 hours in the future because of it :P
<kirkland> jdstrand: i'm hitting a new error with libvirt/kvm, wondering if it's apparmor
<tag> Any chances of bumping evolution up to 0.26.3 for Karmic?
<TheMuso> Amaranth: ah ok
<jdstrand> kirkland: please paste 'dmesg|grep audit'
<Amaranth> TheMuso: edit /etc/default/rcS and change UTC to yes
<kirkland> jdstrand: http://paste.ubuntu.com/273155/
<jdstrand> kirkland: do you have auditd installed?
<kirkland> jdstrand:     if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
<kirkland> libvirtError: internal error unable to start guest: /usr/bin/kvm: invalid option -- '-domid'
<TheMuso> Amaranth: I would, but I have a Windows install on another disk in this box.
<Amaranth> ah
<kirkland> jdstrand: no
<Amaranth> in that case it looks like it may be fixed now so it won't jump ahead every boot
<jdstrand> kirkland: it isn't apparmor
<TheMuso> Amaranth: anyway, nothing an NTP update couldn't fix./
<kirkland> jdstrand: hrm, okay
<jdstrand> kirkland: you'd get very obvious deny messages in dmesg and kern.log
<Amaranth> /etc/init/hwclock-save.conf will pass --localtime
<kirkland> jdstrand: hmm, okay, thanks
<jdstrand> np
<Amaranth> TheMuso: ntp doesn't work on boot if you use wifi
<TheMuso> Amaranth: I don't.
<jdstrand> kirkland: fyi, the error seems pretty clear-- kvm doesn't like '-domid'
<jdstrand> s/fyi/fwiw/
<kirkland> jdstrand: this is a very recent regression
<jdstrand> kirkland: weird
<kirkland> jdstrand: "dom" sounded apparmor-ish :-)
<jdstrand> heh
<jdstrand> kirkland: I'm unfamiliar with the -domid option
<kirkland> jdstrand: me too
<TheMuso> crimsun: Shall I upload your latest changes you pushed to bzr?
<kees> slangasek: so, I believe this patch to be ok, but I wanted to run it past your PAM experience: bug 430205
<ubottu> Launchpad bug 430205 in gdm "gdm login context incorrect" [Low,In progress] https://launchpad.net/bugs/430205
<crimsun> TheMuso: not yet; if you can wait about 15 minutes, i'll say 'yay' or 'nay' again
<TheMuso> crimsun: Sure.
<crimsun> TheMuso: i.e., i need to verify things don't break horribly ;-)
<TheMuso> I am going to get some fixes from libcanberra anyway.
<kirkland> jdstrand: okay, it's my fault
<crimsun> TheMuso: ok
<qwebirc69935> hello, i'm working on a translation for a program with PoEdit. but the language i'm translating into is RTL so i wanted to test some lines before i continue. is there a way to do that?
<crimsun> TheMuso: good to go with current ~crimsun/pulseaudio/ubuntu
<qwebirc69935> hello, i'm working on a translation for a program with PoEdit. but the language i'm translating into is RTL so i wanted to test some lines before i continue. is there a way to do that?
<qwebirc69935> anybody? ":)
<qwebirc69935> well, does anyone know where to ask such a question?
<qwebirc69935> i mean on which channel
<bpun> anyone knows of a library for arbitrary nodal creation/deletion ? (textual labelling)
<spstarr> do we have nightly kernel builds anywhere?
<spstarr> want to try out the radeon r6xx stuff
<TheMuso> spstarr: You might be better asking in #ubuntu-kernel.
<slangasek> kees: well, for starters "module_unknown=ignore" isn't going to prevent this from causing log spam
<slangasek> kees: which we had previous experience with in hardy :P
<slangasek> kees: for another, if gdm needs a custom auth line, I think it's Doing It Wrong
<slangasek> (the session stuff matches what's used in login, so it's not unreasonable)
<kees> slangasek: okay, cool.  let's work out something Right for gdm next week.
<dholbach> good morning
<sivang> morning dholbach
<dholbach> hi sivang
<sivang> dholbach: how's it going ?
<dholbach> good good - how 'bout you?
<sivang> dholbach: my spirit is high :)
<sivang> dholbach: why are you up so early? :)
<dholbach> ?
<dholbach> it's 8:23
<dholbach> that's not early :)
<sivang> heheh
<sivang> seb128 is still asleep so...
<sivang> I realized the older I get, the less I need to sleep
<Madkiss> what could be a reason for nfs-common to not start at boot time?
<Madkiss> i.e. it starts and nothing else is ever goping to happen.
<Madkiss> which directory is responsible for creating /com?
<StevenK> Madkiss: /com?
<pitti> Good morning
<AnAnt> Hello, can /usr/share/images/xsplash/ be configured via update-alternatives to ease branding ?
<pitti> AnAnt: no, there should just be alternative derivative-xsplash-artwork packages which Conflicts:/Replaces:/Provides: xsplash-artwork
<pitti> that's why ubuntu-xsplash-artwork was split out now
<AnAnt> pitti: ah, that's cool ! thanks
<Madkiss> StevenK: yeah. "service udev start" fails because the thing can "not connect to its communication socket" in /com/ubuntu/whatsoever
<AnAnt> how about gdm ? is it possible to make theme for it ?
<ivoks> Madkiss: karmic problems? :)
<pitti> AnAnt: it just uses the default artwork, so replacing ubuntu-wallpapers should do
<AnAnt> ok
<AnAnt> thanks
<StevenK> Madkiss: It's com.ubuntu.Upstart?
<pitti> Madkiss: oh, that's not a file path, but an object path in the D-BUS namespace
<pitti> Madkiss: presumably d-bus isn't running, or the  upstart d-bus service crashes
<kk_jaunti> hello, I have a strange issue with ekiga on ubuntu 9.04.  My machine is running on dhcp and ekiga says that I must do all configurations manually.
<kk_jaunti> now I don't get any option in or out of ekiga which guides me exactly waht to do.
<TheMuso> pitti: The only problem with that approach for gdm theming is that it doesn't allow for a different wallpaper for gdm and the desktop session.
<TheMuso> Same with the GTK theme due to gconf keys used.
<ivoks> i'm bit out of desktop development, so pardon if question is stupid... the thing that splashes beetwen gdm and gnome desktop is xsplash? what triggers end of splashing? cause it's splashing too long here :)
<AnAnt> I think ubuntu-xsplash-artwork should be Arch: all not any
<AnAnt> pitti: if derivative-xsplash-artwork Conflicts/Replaces xsplash-artwork, will that cause ubuntu-xsplash-artwork to get removed ?
<pitti> AnAnt: yes
<pitti> AnAnt: arch all> correct, that was a mistake
<AnAnt> ok
<pitti> kenvandine: ^ can you please fix in next upload?
<davmor2> pitti: you got a working system again now?
<pitti> davmor2: yes, I do; now that I know what the reason for the powered off screen is, it's all good :)
<davmor2> Yay
<dholbach> mvo: do you think you can take a look at bug 187371?
<ubottu> Launchpad bug 187371 in apt "the progress of the downloaded data not consistent" [Wishlist,Confirmed] https://launchpad.net/bugs/187371
<davmor2> pitti: Also thanks for the info on the ati bug, I'm glad that got resolved mean for beta I'll have all my test boxes back Yay
<pitti> :-)
<pitti> tseliot: ^ can you please upload that mesa today?
<pitti> davmor2: I guess you just deleted the r600.so file?
<dholbach> asac: do you know what's happening with bug 392815, bug 365965?
<ubottu> Launchpad bug 392815 in thunderbird-locales "Ubuntu Thunderbird's Contact List crash in Romanian" [Undecided,Confirmed] https://launchpad.net/bugs/392815
<ubottu> Launchpad bug 365965 in ubufox "[MASTER] installing firefox pulls in ubufox and all gnome depends through apturl" [Medium,Fix released] https://launchpad.net/bugs/365965
<dholbach> zul: do you know what's going on with bug 378240?
<ubottu> Launchpad bug 378240 in xen-3.3 "Please merge xen-3.4 (3.4.0-2) from debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/378240
<davmor2> no just didn't use that machine to test A6 ubuntu.  Works fine for xubuntu and kubuntu no compiz
<dholbach> lool: do you know if bug 211252 is something the mobile team is looking into?
<ubottu> Launchpad bug 211252 in obex-data-server "Cannot receive files using bluetooth" [Low,Confirmed] https://launchpad.net/bugs/211252
<lool> dholbach: We're not looking into it
<dholbach> ArneGoetje: can we do something to get bug 63515, bug 407649, bug 290304 off the sponsoring list?
<ubottu> Launchpad bug 63515 in scim-pinyin "Typo in skim-scim-pinyin string" [Low,Confirmed] https://launchpad.net/bugs/63515
<ubottu> Launchpad bug 407649 in scim-anthy "Sync scim-anthy 1.2.7-1 (main) from Debian unstable (main)." [Undecided,New] https://launchpad.net/bugs/407649
<dholbach> lool: mh
<ubottu> Launchpad bug 290304 in skim "Skim has no KMenu icon" [Low,Triaged] https://launchpad.net/bugs/290304
<lool> There was often the expectation that mobile team was doing everything bluetooth but it hasn't been the case really; Tollef and Emmet might have built on that impression
<dholbach> there's just so much old stuff on http://people.canonical.com/~dholbach/sponsoring/ and I'd love to get it off there - if it's stuff that's not appropriate, lets mark those bugs wont-fix :/
<dholbach> cjwatson: hey Colin - how are you doing? I had a conversaton with james_w and he said that merge proposal notifications were decided to go to ubuntu-devel@, but couldn't tell me where that was announced/documented - do you know anything more?
<dholbach> cjwatson: I'm asking because of the moderation queue
<dholbach> where we have a bunch of merge proposal mails right now
<seb128> oh please don't spam the list with those
<dholbach> seb128: I have similar feelings :)
<Amaranth> amitk: Are you on one of the computers having problems with compiz right now?
<Amaranth> err, not actually here
<Amaranth> oh, but amitk_ is :)
<amitk_> Amaranth: we both are ;)
<dholbach> Amaranth: don't listen to him - he's schizophrenic :)
<Madkiss> pitti: i see.
<Amaranth> We understand what you mean ;)
<dholbach> ... nevermind :-)
<Madkiss> okay, so I need to find out why d-bus crashes
<Amaranth> amitk_: On your computer have have the latest compiz-wrapper, no diversions or extra configuration for /usr/bin/compiz, and you get that crash?
<amitk_> Amaranth: I did a plain-old update-manager upgrade
<Amaranth> amitk_: Please paste the last line of CM_DRY=yes compiz
<amitk_> And I don't have enough compiz foo to even know what diversion you're talking about
<cjwatson> dholbach: I forget the details but I don't want to argue about it. If people don't like them on ubuntu-devel, let's create an ubuntu-reviews list
<amitk_> Amaranth: Execute: /usr/bin/compiz.real --ignore-desktop-hints --replace --loose-binding  move resize place decoration animation ccp
<Amaranth> alright, that shouldn't be triggering this crash
<Amaranth> amitk_: Sounds like you have a different problem, the compiz bug you commented on can only occur when you have 'core' on that line
<dholbach> cjwatson: what do you think should go on there? all merges for Ubuntu? what about sponsoring - should that still on ubuntu-{main,universe}-sponsors (ubuntu-sponsors at some stage)?
<cjwatson> IMO: all merges (people can filter); perhaps sponsoring stuff should be cced to that list
<amitk_> Amaranth: but the bug title that apport creates is identical I think. In any case, I filed a separate bug the second time and then marked it duplicate of the existing one
<dholbach> cjwatson: I don't want to argue about it either, just trying to figure out what best to do and how to deal with the current stuff in the queue
<amitk_> Amaranth: so all the files are attached to the 'duplicate' bug if that helps
<dholbach> cjwatson: do we have a good way of routing merge proposals that way?
<Amaranth> amitk_: Can you make it public? launchpad is being picky
<cjwatson> dholbach: dummy LP user with a contact address set?
<amitk_> Amaranth: bug 432303 (don't know why LP marks it pvt by default, is there a config setting?)
<cjwatson> added to the relevant teams
<ubottu> Launchpad bug 432303 in compiz "compiz.real assert failure: compiz.real: ../../src/display.c:793: updatePlugins: Assertion `j == pListCount' failed. (dup-of: 429858)" [Undecided,New] https://launchpad.net/bugs/432303
<ubottu> Launchpad bug 429858 in compiz "compiz.real assert failure: compiz.real: ../../src/display.c:793: updatePlugins: Assertion `j == pListCount' failed." [Medium,Triaged] https://launchpad.net/bugs/429858
<Amaranth> amitk_: No, they're all private because they might have passwords or something in the core dump
<amitk_> Amaranth: aaah
<dholbach> cjwatson: hm.... ok - I can get in touch with IS about that list, if you like
<Amaranth> amitk_: Although I'm supposed to be able to access them anyway but sometimes launchpad doesn't let me
<cjwatson> dholbach: of course maybe it should be on lists.launchpad.net, I don't know what IS' current rules are
<cjwatson> but yeah, have a word with them?
<dholbach> I think everything Ubuntu-related is fine to be on lists.u.c
<Amaranth> amitk_: Odd, your .xsession-errors doesn't have any of the compiz-wrapper messages, the first line about compiz is the assert
<cjwatson> dholbach: yeah, I think the ultimate plan is to move them to LP, but some work needs to be done there first
<Madkiss> The exact error message I am getting is "Could not connect to Upstart: Failed to connect to /com/ubuntu/upstart: Connection refused"
<Madkiss> I started dbus manually with dbus-daemon --system
<Madkiss> yet the same effect
<dholbach> james_w is doing reviews in #ubuntu-reviews
<Amaranth> amitk_: what is the output from gconftool-2 -g /desktop/gnome/session/required_components/windowmanager
<gioele> what is the correct procedure to report a papercut bug? Should I just add it to the one hundred papercut project?
<Amaranth> gioele: If needs to be a bug with a straightforward solution that affects every user on their first day using ubuntu
<Amaranth> gioele: If you think your bugs fits you can file it against the package the bug is about and the papercuts project
<gioele> Amaranth: it has all the properties needed to be considered a papercut
<gioele> is onehunderdpapercut the only papercut project?
<Madkiss> i could really use a hand on this
<gioele> I think 100papercut is a "closed" project, I mean they have those 10 groups of bugs, do they accept more bugs?
<Madkiss> what is responsible for creating "/com/ubuntu/upstart"?
<Amaranth> Madkiss: err, upstart
<Amaranth> gioele: They might get fixed otherwise or perhaps added to a karmic+1 series of rounds
<Amaranth> gioele: Make sure the bug is filed against an ubuntu package too
<Madkiss> Amaranth: okay, and "exec init 2" does not work, because it tells me the very same thing
<Amaranth> Madkiss: Right, those are work via dbus
<Madkiss> Amaranth: dbus-daemon --system is running
<Madkiss> is that correct?
<Amaranth> should be
<Amaranth> Madkiss: What are you trying to do?
<Madkiss> I am trying to debug why my system just won't boot
<Madkiss> nfsroot stuff
<Amaranth> oh, out of my leage
<Amaranth> league*
<Amaranth> I guess look for Keybuk?
<ogra> Madkiss, https://bugs.launchpad.net/ubuntu/+source/mountall
<amitk_> Amaranth: gconftool returns 'compiz'
<Amaranth> weird
<Amaranth> amitk_: well, once we get that patch the bug should be fixed, if it isn't I guess I'll just put my head through the wall
<sebner> pitti: I already installed new upstream from LP. Works great (the devicename in /media is still strange though)
<pitti> sebner: cool, thanks! the devicename is another known issue
<amitk_> heh
<sebner> pitti: kk, "Schwere Geburt" ;) , tell me if I can help with that name stuff
<james_w> what package should I reassign a bug of "superblock has a time in the future" on every boot?
<james_w> no more details yet, but it's on totally the wrong package
<ojwb> james_w: that sounds familiar - I think it's been reported before and discussed here...
<james_w> well, I know there are several different instances of the bug, so I don't just want to tell them "known bug" and close it
<james_w> I'd rather reassign to a correct package where someone that understands this stuff better can deal with it
<james_w> I know it's not the package manager's fault for installing updates that triggered the bug though
<ojwb> ah, ok, dunno then
<Ng> james_w: I think keybuk looked into that for asac/seb128 and it may have been a kernel issue
<Keybuk> the kernel issue should be fixed
<Keybuk> there are installer issues open still
<asac> Keybuk: where are those fixes? in -11?
<Keybuk> asac: 10.34
<cjwatson> would the installer issue we've identified cover an occurrence of that bug on *every* boot?
<cjwatson> I'd have thought it would only really be boots within (installation, installation + hwclock offset)
<Keybuk> a bug on every boot sounds more like a configuration error to me
<Keybuk> ie. the user's hardware clock being plain wrong, and them force powering of
<Keybuk> if you subscribe me to the bugs, I'll happily work through them with the users next week
<cjwatson> or some other error like the kernel one that we haven't identified yet
<Keybuk> indeed
<Keybuk> the first thing is going to be to find out whether there's commonality
<Keybuk> e.g. are they all east or west of UTC
<Keybuk> that tends to give us an idea
<james_w> what were the basic commands
<Keybuk> (they should all be east, obv. but I've seen people west with this problem and that really narrows it down :p)
<Keybuk> james_w: "date"
<james_w> grep ^UTC /etc/something
<Keybuk> james_w: "grep UTC /etc/default/rcS"
<Keybuk> james_w: hwclock --debug --show
<james_w> thanks, I'll subscribe you and request that information
<james_w> thanks Keybuk
<Madkiss> Keybuk!!
<Keybuk> bbl, packing for KPDX
 * pitti fixes the /etc/udev/rules.d/z60_hdparm.rules goo from hdparm
 * ogra looks for anyone to hold his hand ... first reboot after post A6 dist-upgrade here ...
<ogra> i'm scared
<sebner> ogra: Coward! (TM Keybuk) :P
<ogra> LOL !
<ogra> ok, lets just go for it
<ogra> hmm
<ogra> pitti, didnt you add a fix for the fbcon prob already ?
 * ogra is without KMS
<ogra> and xsplash is a really flashy experience ... changes sizes several times goes on and off etc
<AnAnt> can't xsplash throbber position be configurable ?
<SteveA> teknico: I hear you are having some problems updating karmic
<teknico> SteveA, yes, my machine does not boot anymore
<teknico> after this morning's upgrade of karmic
<SteveA> is there a bug open that describes the problem?
<teknico> it stops right after cryptdisks-early, which says [ OK ]
<teknico> I looked at those for cryptsetup and did not find anything
<teknico> but I'm not sure if the problem is there, or with udev, or something else
<cjwatson> what is the exact message just before that
<teknico> using the 2.6.31-7 kernel instead of 2.6.31-10 does not change anything
<cjwatson> kernel is not relevant
<teknico> I tried purging cryptsetup and running "update-initramfs -u", but no change
<teknico> all after chrooting in the main boot, obviously
<cjwatson> that suggests that it's not actually cryptdisks-early, but the next thing in the boot sequence, then
<teknico> (right now I'm booted on another partition)
<cjwatson> add --debug as a boot parameter and you may get more information
<teknico> cjwatson, as a boot parameter to the kernel line in grub?
<cjwatson> yes
<soren> Just "debug", not "--debug".
<soren> Or did that change?
<cjwatson> not that I can get either to work with a live CD, but AFAIK debug is a kernel parameter but --debug is an upstart parameter
<teknico> back
<soren> cjwatson: Oh.
<soren> Brave, new world.
<teknico> soren, I did not see your comment in time
<teknico> however, adding --debug did indeed make the kernel spew a lot of messages :-)
<teknico> I don't see error messages or apparent problems before it stops, as far as the scrollback goes
<teknico> I took a picture of the last screenful, where can I upload it?
<teknico> cjwatson, ^^
<cjwatson> you have an account on people.canonical.com, or you could use imagebin.com or whatever it's called
<toabctl> hi
<toabctl> what is the alternative for /dev/log in karmic?
<toabctl> i use this with python
<cjwatson> import syslog
<toabctl> cjwatson: i use import logging
<toabctl> and then the syslog-handler
<cjwatson> although /dev/log hasn't gone away
<teknico> cjwatson, http://imagebin.org/64348
<toabctl> cjwatson, for me, it's not avaailable
<cjwatson> toabctl: I believe that's a bug; please report it (probably against udev)
<toabctl> cjwatson, ok
<cjwatson> hmm, maybe not udev
<cjwatson> toabctl: what does 'status rsyslog' say?
<toabctl> sudo status rsyslog
<toabctl> status: Unknown job: rsyslog
<cjwatson> toabctl: install the rsyslog package
<cjwatson> in that case, not a bug as far as I can see
<toabctl> cjwatson, ok. that was the problem. sorry, my mistake.
<cjwatson> teknico: do you have a shell on tty2? (alt-f2)
<teknico> cjwatson, on boot, before it stops? I don't think so
<cjwatson> can you check?
<teknico> cjwatson, yes, but I'd have to leave here to reboot again
<teknico> cjwatson, it's very early in the boot, I don't think it could already have got to a shell
<cjwatson> ok, it's quite possible it hasn't, but nevertheless the boot sequence is quite different now from what you're used to
<cjwatson> teknico: if it doesn't have a shell, then chroot into the system and write yourself an /etc/init/shell.conf (not /etc/init.d/) as follows:
<cjwatson> start on startup
<cjwatson> console owner
<cjwatson> exec /bin/bash
<cjwatson> teknico: then when it hangs you should be able to press enter and get a shell prompt
<cjwatson> teknico: is there any way you can get online from another computer?
<cjwatson> this is going to be very painful if you keep having to reboot to answer questions
 * ogra wonders why the .conf suffix suddenly got into fashion everywhere
<lool> To distinguish disabled files
<cjwatson> because if you don't use an extension you have to track stuff like .dpkg-new all over the place
<ogra> ah
<cjwatson> particularly relevant for things that use inotify
<lool> Right didn't think of that
<ogra> yup, i thought it was just "because" :) i see there is a proer reasoning behind it now
<ogra> *proper
<lool> I guess you cant exclude dpkg suffixes in inotify
<teknico> cjwatson, yes, I'll get another machine on
<cjwatson> no particular reason why it should be .conf of course
<cjwatson> lool: you can, but you have to keep playing catch-up with all sorts of things
<ogra> (i was actually wondering that since module-init-tools moved to the same)
<cjwatson> lool: and Scott points out that vi backup files have an even less helpful naming scheme
<lool> Ack
<pitti> ogra: fbcon> no, I just did the diagnosis; it's not quite clear yet how to fix it correctly
<ogra> ah, k
<pitti> ogra: but that doesn't break KMS, once X starts, it comes back
<ogra> my screen looks scary during boot
<pitti> ogra: or just add it to /etc/modules
<cjwatson> I think it creates a file with a hardcoded name just to find out if it can write to the directory, or something
<ogra> i got so used to 1920x1200 consoles
<teknico> smtg urgent came up, bbiab
<cjwatson> teknico_away: also, if you could tell us if there's anything special about your filesystem layout, we might be able to correlate that with known bugs
<cjwatson> teknico_away: a photo of normal startup (without --debug) might help too
<ScottK> cjwatson: re ubuntu-devel and merge proposals:  Filtering is fine for my desktop, but I also read mail on my phone and it simply doesn't have that ability.  At best I'd have to redirect the list to a mailbox that gets read a lot less often.
<ScottK> It seems rather counter to the rationale for having a split devel and devel-discuss.
<cjwatson> ScottK: I meant that, after moving them to ubuntu-reviews, if people wanted to subscribe to that list but only review certain packages then they could filter
<cjwatson> ScottK: I didn't mean to say that the solution to people having problems with reviews on ubuntu-devel was for them to filter
<ScottK> Ah.  Thanks for clarifying.
<cagonto> online boxing game http://www.kobox.org/kobox-fande-Nourine.html
<tseliot> ScottK: do you mind if I mark bug #397950 as a duplicate of bug #432384 ?
<ubottu> Launchpad bug 397950 in ubuntu-release-notes "Kubuntu U/I for enabling ctrl-alt-backspace has moved" [Undecided,New] https://launchpad.net/bugs/397950
<ubottu> Launchpad bug 432384 in ubuntu-release-notes "DontZap is now an option in XKB" [Undecided,New] https://launchpad.net/bugs/432384
<ScottK> tseliot: As long as the Kubuntu specific language gets into the note, I'm fine with that.
<tseliot> ScottK: yes, instructions for both Ubuntu and Kubuntu will be available in the release notes
<tripzero> what facility in the livecd creates/logs in the "ubuntu" user?
<ogra> a) casper b) gdm
<tripzero> ahh, okay
<tripzero> this system doesn't have gdm (or any *dm)
<tripzero> so casper must be doing both...
<teknico> cjwatson, back, sorry
<teknico> ok, I created the /etc/init/shell.conf file with the three lines you mentioned
<teknico> you asked about the partition layout, it's a bit involved
<teknico> there are four primary partitions, sda1 to sda4
<teknico> sda1 is the alternate boot/root that is working right because it's not up to date
<teknico> sda2 is the main boot/root that stops when booting
<teknico> sda3 is an encrypted partition that contains three LVM2 logical volumes
<teknico> sda4 is a non-encrypted partition that contains other three LVM2 logical volumes
<teknico> sda3, and the logical volumes in it, are not currently used
<cjwatson> first step: reinstall cryptsetup :-)
<teknico> (I moved stuff elsewhere a few weeks ago, because cryptsetup was not able to access that partition any
<teknico> anymore
<teknico> cjwatson, are you sure? I don't need it right now
<cjwatson> teknico: is anything in sda3 mentioned at all in /etc/fstab?
<teknico> cjwatson, no, and I commented sda3 out of /etc/crypttab
<cjwatson> ok, then you're probably all right without cryptsetup
<teknico> cjwatson, ok, I'll reboot then, do I again add the debug option to the kernel?
<cjwatson> another thing to do before rebooting: edit /etc/init/mountall.conf and put "--debug" at the end of the 'exec mountall' line
<teknico> (btw, I'm on another machine now, as you suggested)
<cjwatson> don't bother adding it to the kernel this time, it was a bit too verbose and I'm not skilled at interpreting it anyway
<teknico> oh, you also wanted a picture of the stopping, I'll get that to you before rebooting
<teknico> cjwatson, http://imagebin.org/64353
<teknico> rebooting
<teknico> cjwatson, ok, it stopped, but I got a prompt this time
<cjwatson> and it just hangs after the fsck?
<teknico> yes. it says "/dev/sda2 clean, [numbers]"
<teknico> and then "root: clean, [numbers]"
<teknico> and that's it
<teknico> if I press Enter, I get the prompt
<cjwatson> ok, 'initctl list'
<teknico> a screenful of lines, most ending with "stop/waiting", some with "start/running" and a process number
<cjwatson> could you pipe it through a pager and get photos
<cjwatson> the details are kind of relevant ;)
<teknico> ehm, "pipe through a pager"?
<teknico> I can take photos and post them online, but it'll take a while for each photo
<cjwatson> | less
<teknico> four of them are running
<cjwatson> which
<teknico> oh, I can see in the scrollback, didn't lose anything
<teknico> udev, upstart-udev-bridge, mountall, shell
<cjwatson> ok, could you reboot into whatever recovery mode you're using, chroot in, edit mountall.conf as I said earlier, and reboot again
<teknico> there are also four network interfaces running, without process numbers
<teknico> I dont' recall you talking about mountall.conf, can you say it again, please?
<cjwatson> 15:18 <cjwatson> another thing to do before rebooting: edit /etc/init/mountall.conf and put "--debug" at the end of the 'exec mountall' line
<teknico> apparently I can do that right from this prompt
<cjwatson> if the root filesystem is mounted read/write, yes
<teknico> done, rebooting
<evand> Anyone have an opinion on whether I should disallow running usb-creator on a device that just contains a vfat filesystem, rather than a partition table and vfat partition?  I don't pretend to know how every BIOS will react to a device without a partition table, but I imagine at least some of them will fail miserably.
<evand> Of course, it does work on this BIOS.
<pitti> evand: would it be possible to make the "format" button actually do something and turn it into a signle-partition vfat device?
<pitti> that button is always gray for me, no matter what I plug in :-( what is it supposed to do?
<teknico> cjwatson, what am I looking for?
<cjwatson> teknico: show me the output
<pitti> evand: right, I think this machine here doesn't like aprtitionless usb stick booting
<evand> pitti: devicekit bugs I have yet to resolve -- disabled for now...
<pitti> evand: ah, ok
<cjwatson> teknico: I don't know offhand what you're looking for, I'm debugging somebody else's code :)
<teknico> cjwatson, I'll make a picture of the last screenful
<cjwatson> I may need stuff from before that as well, but yes
<evand> pitti: indeed, and that's how it currently operates.  If you have a USB stick with just a vfat partition on it, usb-creator flags it with a warning icon, and says it needs to be formatted before it can be used.  I'm discussing the possibility for it not to put that error up, and happily write the image.
<pitti> evand: right, I understood that; I'm not sure actually, USB booting still seems to be too much of a gamble either way
<pitti> so if it works on some/many machines, I don't see why not to offer it
<evand> yeah, I think I might enable it and make sure the documentation clearly notes to try the format button if you cannot boot
<evand> cool, thanks for the input
 * sebner is responsible for >50% of the sync requests in ubuntu-archive and now jdstrand destroys everything :P
<teknico> cjwatson, last screenful: http://imagebin.org/64356
<teknico> cjwatson, second to last screenful: http://imagebin.org/64357
<dholbach> #ubuntu-classroom Session in 8 minutes: How to run an Ubuntu Jam session!
<teknico> mmm, it occurs to me that skype and a webcam would be faster than this...
<cjwatson> I don't do skype, sorry
<cjwatson> if you could get back as far as the first output beginning with parse_fstab:, that would be good
<ccheney> shtylman: ping, any estimate of when the kde patches will be done? i am thinking of doing an OOo upload today to be in time for karmic beta
<cjwatson> maybe even new_mount:;
<teknico> cjwatson, looking for them
<jdstrand> sebner: heh
<ScottK> tseliot: It might be nice to get XFCE instructions in there too for Xubuntu.
<sebner> jdstrand: you are pretty mean, you know that? :P
<jdstrand> sebner: can you look at bug #429404 and add a comment on what exactly needs to happen. your first comment is unclear to me
<ubottu> Launchpad bug 429404 in ubuntu "Sync libjgrapht0.6-java 0.6.0-8 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/429404
<teknico> cjwatson, did not find them, the scrollback buffer is not deep enough
<tseliot> ScottK: I agree, however XFCE's XKB ui doesn't allow users to enable zapping. I have put a link to the wiki so that Xubuntu users can find a different (non UI) way to enable zapping
<cjwatson> teknico: do you have working network to the point where you can use scp?
<sebner> jdstrand: it needs to be synced. then I'll file a RM request for the old source/binary package and change b-d for package cdk (which ftbfs because of that).
<cjwatson> teknico: if not, do you know how to bring it up by hand?
<ScottK> tseliot: Then I think pointing to that in the release note is appropriate.
<tseliot> ScottK: ok, good
<cjwatson> teknico: oh, wait, you said that you were able to write to the root filesystem after the hang, didn't you? OK, do as follows:
<teknico> yes
<cjwatson> teknico: 1) edit /etc/init/mountall.conf again and put '>/dev/mountall.conf 2>&1' at the end of the 'exec mountall' line (yes, I do mean /dev/ there)
<jdstrand> sebner: ok, the 'b-d' in your comment in the bug wasn't clear, but it is now
<sebner> jdstrand: I'm sorry then :)
<cjwatson> teknico: sorry, /dev/mountall.log not /dev/mountall.conf
<doko_> ubuntul-archive: zope.copy and zope.i18n seem to hang in source NEW for a while
<wubbbi> Hello :) how can I help on Developing ubuntu? I have not so much c++ experience ... so are there any tiny things I can do? I got a lot of freetime today :)
<cjwatson> teknico: 2) reboot 3) after the hang (give it a little while just to make sure), 'cp /dev/mountall.log /home/teknico/' (or wherever your home directory is)
<jdstrand> doko_: I'll get to them today
<doko_> ahh, cool!
<cjwatson> teknico: 4) reboot again into your alternate system with networking 5) get that mountall.log file to me
<teknico_> cjwatson, sorry, I got dropped off freenode
<teknico_> I did not see what you said after "do as follows:"
<cjwatson> teknico_: 1) edit /etc/init/mountall.conf again and put '>/dev/mountall.log 2>&1' at the end of the 'exec mountall' line (yes, I do mean /dev/ there)
<cjwatson> teknico_: 2) reboot 3) after the hang (give it a little while just to make sure), 'cp /dev/mountall.log /home/teknico/' (or wherever your home directory is)
<cjwatson> teknico_: 4) reboot again into your alternate system with networking 5) get that mountall.log file to me
<teknico_> cjwatson, got it
<sebner> jdstrand: would you mind letting libjgrapht0.6-java through NEW because of my comment ... :)
<teknico_> cjwatson, http://pastebin.com/d220fbb6d
<teknico_> (no need for the last reboot, networking up and running)
<teknico_> (manually set up, that is)
<teknico_> the log ends like that, even after forcing a sync with Shift-Alt-SysRq-E
<jdstrand> sebner: ok'
 * sebner hugs jdstrand :D
<jdstrand> doko_: do you have FFe bugs for zope.copy and zope.i18n?
<doko_> jdstrand: they are in the bug reports
<jdstrand> doko_: what are the bug reports? I can't seem to find them (they aren't in the changelogs)
<doko_> jdstrand: of course, these are debian packages
<jdstrand> doko_: I'm confused. can you give me the LP bug report stating that the FFe is approved for these packages?
<doko_> looking again ...
<sistpoty|work> jdstrand: we want zope in a consistent state, and I recall that we acknowledged that
<jdstrand> I'm cool with that, I just want to see what that state is
<doko_> https://bugs.edge.launchpad.net/ubuntu/+bug/429614
<ubottu> Launchpad bug 429614 in ubuntu "sync request (unstable -> universe)" [Undecided,Fix released]
<doko_> https://bugs.edge.launchpad.net/ubuntu/+bug/429940
<ubottu> Launchpad bug 429940 in ubuntu "zope.i18n FFe" [Undecided,Fix released]
<jdstrand> doko_: thanks!
<mvo> hm, report-a-bug is no longer working. I understand why, but it would be nice if certain people (like ubuntu developers) could still report bugs via the web interface
<ogra> mvo, i neraly only send bugs from a different machine ...
<ogra> makes the new scheme pretty awful for me
<cjwatson> teknico: not ignoring you, but in a meeting
<mvo> ogra: yeah, same here
<jdstrand> doko_: btw, I rejected the zope.i18n from a few days ago and am deNEWing 3.7.0-4
<cjwatson> teknico: will analyse in the background
<teknico> cjwatson, sure, sorry to bother you
<mvo> ogra: its also a bit anoying if i want to report a bug on software-store and my version is (naturally) more advanced than the one in the archive. apport will not let me, but I want to :)
<ogra> heh
 * mvo should take this as a sign that its friday evening
<mvo> or I need a "--but-i-really-want-to-report-this-bug-pretty-please" option
<cjwatson> teknico: no, it's ok
<cjwatson> teknico: pastebin.com has cut off your log, though
<cjwatson> teknico: could you please send it to paste.ubuntu.com instead?
<teknico> cjwatson, no, it has not, that's what I was saying before :-)
<cjwatson> mvo: +filebug?no-redirect is the magic decoder ring
<doko_> jdstrand: sounds fine
<cjwatson> teknico: oh, sorry, so you did
<teknico> cjwatson, anyway I'll use the canonical pastebin from now on
<ScottK> mvo: I think you'd like Bug 431121 then.
<ubottu> Launchpad bug 431121 in malone "Don't apply +filebug redirection to ubuntu-dev" [Undecided,New] https://launchpad.net/bugs/431121
 * mvo hugs cjwatson
<mvo> ScottK: many thanks for filing that
<ScottK> :-)
 * mvo wants to press the "affects me" button a number of times now ;)
<al-maisan> mvo: easy, write an "affects me" bot :)
<sebner> jdstrand: would you mind taking a look at bug #432557 ? The last time I'll add work on your shoulders :)
<ubottu> Launchpad bug 432557 in libjgrapht-java "Please remove libjgrapht-java from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/432557
<jdstrand> sebner: ok
<robbiew> evand: man...I really like the slideshow....just had to get that out there ;)
<evand> hooray
<evand> does this mean I get that jetski I always wanted during the next review cycle?
<evand> ;)
<robbiew> heh
<robbiew> sure...if you always wanted one manufactured by Mattell
<evand> hahaha
<cjwatson> teknico: this is just a hunch, but can you try editing /etc/fstab and transforming /dev/vg_data/lv_SOMETHING to /dev/mapper/vg_data-lv_SOMETHING throughout
<evand> going to pass that on to picklesworth, as he's been the driving force behind the slideshow
<teknico> cjwatson, trying
<smoser> is tmpfs memory management dynamic ?
<smoser> ie: mount -t tmpfs mytmp /tmp/mytmp
<smoser> dd if=/dev/zero of=/tmp/mytmp bs=1024 count=10240
<smoser> that will increase memory consumed
<smoser> but will
<smoser> rm /tmp/mytmp/myfile
<smoser> free it ? (typo above, 'of=/tmp/mytmp/myfile')
<teknico> cjwatson, it still blocks: mountall.l
<teknico> mountall.log did not get truncated this time
<cjwatson> teknico: ok, can I have the new log
<teknico> cjwatson, sure
<teknico> cjwatson, https://pastebin.canonical.com/22290/
<pitti> ScottK, kirkland: there's a libvirt in hardy-backports unapproved, without mentioning a bug; has this been discussed on IRC?
<elops> anyone know good tutorial/walkthrough for adding Raid to ubuntu?
<ScottK> pitti: Not that I recall.
<kirkland> pitti: yes, let me grab the bug
<ScottK> elops: Please ask in #ubuntu
<elops> noone answered me
 * ScottK does recall mentioning to kirkland about including the bug in the changelog last time ....
<elops> :(
<ScottK> elops: It's OT for this channel.
<kirkland> [Bug 404060] [NEW] backport libvirt to hardy and intrepid
<ubottu> Launchpad bug 404060 in intrepid-backports "backport libvirt to hardy and intrepid" [Wishlist,Fix released] https://launchpad.net/bugs/404060
<kirkland> ScottK: ack, you did...
<cjwatson> teknico: you didn't do quite what I said with fstab
<cjwatson> teknico: you used things like /dev/mapper/vg_data/lv_big
<teknico> cjwatson, oh, I didn't?
<cjwatson> teknico: it needs to be /dev/mapper/vg_data-lv_big
<cjwatson> in each of those three lines, change the last / to a -
<teknico> oh, you're right, sorry, doing it
<ScottK> pitti: I just sprinkled holy water on the bug for hardy.
<det> What is the default/recommended version of boost in Jaunty?
<det> (for build depends for a package)
<pitti> ScottK: cool! /me wipes it off and approves
<teknico> wow, those paths don't exist at all :-/
<cjwatson> teknico: which ones?
<teknico> cjwatson, the ones I wrote
<teknico> cjwatson, I think I could cry now
<teknico> it started up, and you are officially my hero B-D
<cjwatson> yay
<cjwatson> please file a bug on mountall, saying that /dev/VG/LV paths in /etc/fstab don't work while /dev/mapper/VG-LV paths do
<cjwatson> use 'ubuntu-bug mountall'
<cjwatson> teknico: you can revert the --debug and redirection stuff in /etc/init/mountall.conf now, of course
<teknico> cjwatson, will do, as soon as I manage to do that :-)
<teknico> that shell is interfering with the normal one on Ctrl-Alt-F1
<cjwatson> teknico: alt-f2, you should have a shell there now - remove /etc/init/mountall.conf from that
<ScottK> det: It was 1.35.
<cjwatson> teknico: no X?
<det> You sure it's not 1.37 for Jaunty and 1.35 for Intrepid ?
<teknico> cjwatson, yes, X and all, and you're right, Alt-F2 is not bewildered :-)
<ScottK> det: For Main, yes.
<det> Main ?
<ScottK> The Main Ubuntu archive (as opposed to Universe)
<det> ok, thanks
<ScottK> IIRC, the boost defaults package isn't in Jaunty
<det> I really hate how boost versioning works. I wish I was able to just depend on a boost verions >= XXX
<ScottK> Go make them provide a stable API.
<det> Ya, im not blaming Ubuntu/Debian
<ScottK> You  can now with libboost-dev from boost-defauults, but myself I think it's better to switch boost versions on purpose.
<det> boost-defaults is Karmic thing ?
<cjwatson> ScottK: hmm, actually, this dbus/ia64 thing might be easy; it's guarded by a configure-tested #define, so the question is merely why configure's checks aren't producing the right results
<ScottK> cjwatson: Good to hear.  We really can't release with dead buildds.
<ScottK> det: We got it from Debian and it first appeared in Karmic.
<cjwatson> wow, nobody uses the ia64 porting box much, its karmic chroot doesn't have debhelper installed
<det> Thanks
<cjwatson> ah, no, it does have debhelper, it's just old
<tseliot> pitti: does loading fbcon in the initrd do the trick for you (bug #431812)?
<ubottu> Launchpad bug 431812 in sysvinit "fbcon loading a mystery (screen powers off)" [High,Confirmed] https://launchpad.net/bugs/431812
<pitti> tseliot: it certainly will (it was done like that before)
<pitti> tseliot: I added it to /etc/modules for now
<tseliot> pitti: ah, ok
<pitti> evand: ah, so usb-creator-gtk _is_ still using gksu, it's just not done in the .desktop file but in the program itself; so I wasn't hallucinating :)
<pitti> evand: (just saw your FFE)
<evand> pitti: ...not in trunk.  Or were you using usb-creator from the archive?  I was under the impression that you were running it from a branch.
<pitti> evand: no, I'm just using the karmic version
<evand> ahhh
<evand> that would do it
<evand> apologies for the confusion
<evand> glad to hear there isn't another bug lurking there though
<bdrung> persia, TheMuso`: i want to join the ubuntu-universe-sponsors team
<cjwatson> ScottK: I win. It was a link order bug!
<elops>  anyone have a working link to that article (pdf?) about the cheap petabyte storage from capricorn?  the linuxdevices link is broken and I can't find it anywhere
<cjwatson> ~trout Keybuk for overselling the problem
<ScottK> cjwatson: Excellent news.
<lamont> bug 425122 sounds like a package manager issue, not a postfix issue
<ubottu> Launchpad bug 425122 in postfix "Configuration on installation should pop up in a dialog, rather than staying in terminal" [Undecided,New] https://launchpad.net/bugs/425122
<lamont> where should I reassign that, I wonder?
<lamont> ScottK: 37 bonus points if you give me a one line check (for a shell script) that will evaluate false when the token passed to it is not a valid FQDN
<lamont> and true when FQDN, of course
<lamont> there are about 67 bugs against postfix from people who think that all numeric names, and exclamation points belong in hostname
<lamont> s
<ScottK> I've been carefully avoiding those.
<cjwatson> lamont: I've set the ia64 buildds on manual. Could you give them (just them) chroots with sysv-rc and whatever else it was set on hold, as before?
<cjwatson> lamont: then I can try to gradually build my way up the stack
<lamont> oh awesome
<ScottK> lamont: I've got about 7 lines of Python that will do that.  Want it?
<ScottK>  ~ that
<cjwatson>  dpkg-genchanges -b >../dbus_1.2.16-0ubuntu5_ia64.changes
<lamont> cjwatson: done, butw
<lamont> btw, even
<lamont> ScottK: sure - I'll figure out how to make that fit in the ugly postinst
<ScottK> lamont: Something like http://pastebin.com/f18deaad4
<lamont> ok - I'll see how hard I  want to smash my head against it for -3
<MindVirus5> Could someone change the importance to Critical in bug 405227?
<ubottu> Launchpad bug 405227 in gdm "gdm fails to start if /var/log/gdm does not exist" [Medium,Triaged] https://launchpad.net/bugs/405227
<teknico> cjwatson, back to normal, and thanks again: https://bugs.edge.launchpad.net/ubuntu/+source/mountall/+bug/432613
<ubottu> Launchpad bug 432613 in mountall "mountall gets confused by LVM fstab entries not starting with /dev/mapper/" [Undecided,New]
<cjwatson> teknico: great, thanks for the bug report
<teknico> cjwatson, hopefully this lost day will be useful to someone else :-)
<MindVirus5> Nobody wants to/can change the bug importance?
<squirrelpimp> what's the difference between edge and www on launchpad?
<squirrelpimp> and wouldn't https://bugs.launchpad.net/ubuntu/karmic/+source/lvm2/+bug/430542 be the same thing reported by teknico?
<ubottu> Launchpad bug 430542 in lvm2 "lvm volumes fail to mount when specified as /dev/vg-name/volume" [Medium,Triaged]
<cjwatson> mm, yes, looks like it
<cjwatson> I didn't think to look on lvm2
<cjwatson> 430542 has more detail so should be the master bug
<squirrelpimp> hehe... i filed it, which makes me the master-filer
<squirrelpimp> :)
<squirrelpimp> but what's edge.launchpad.net?
<ScottK> squirrelpimp: edge is the Launchpad user interface that's about to be released.  www is the current production release.
<squirrelpimp> aah, google
<squirrelpimp> :)
<squirrelpimp> but the database is the same
<ScottK> Yes
<Q-FUNK> cody-somerville: hi!  I was wondering if you had time to look at bug #432316 and if you would have any idea of what causes this?
<ubottu> Launchpad bug 432316 in gdm-2.20 "gdm-2.20: module i810 not found" [Undecided,New] https://launchpad.net/bugs/432316
<cody-somerville> Q-FUNK, No idea. I imagine 2.20 will be removed from the archive shortly.
<Q-FUNK> cody-somerville: why would it get removed?
<Q-FUNK> cody-somerville: did 2.27's dependy on gnome-session disappear and/or did re-acquire the themeable graphical greeter?
<lamont> hrm... keybuk appears to have escaped
<lamont> keybuk: dbus still ftbfs, btw
<lamont> well, on ia64
<lamont> not that is change had anything to do with it
<chrisccoulson> Riddell - you there?
<chrisccoulson> hey Q-FUNK - i had a look at your mouse issue in gnome-settings-daemon today
<chrisccoulson> g-s-d only sets the button mapping when a new device is added or the gconf key changes
<chrisccoulson> so it could be something else in your session changing it, or a Xorg issue instead
<Q-FUNK> chrisccoulson: yes, I noticed. thanks for checking this out.  unfortunately, the change that was mentioned mentioned doesn't fix this.  to make this more complicated, it seems that firefox-3.5 choses to ignore the setting made by g-s-d, while gnome apps randomly switch back to right-handed mouse.
<smoser> slangasek, around ?
<chrisccoulson> Q-FUNK - hmmm, that's wierd. the FF issue could be a FF bug though. all g-s-d is doing is telling Xorg the button mapping for the device
<chrisccoulson> Q-FUNK - if you're bored, you could attach gdb to g-s-d and break on XSetDeviceButtonMapping, just to see if it gets called when it changes back to right-handed
<chrisccoulson> anyway, bbl
<robbiew> smoser
<robbiew> slangasek is on holiday
<smoser> thanks robbiew
<jarnos> What is the password to unlock screen on resume from suspend triggered before login?
<tormod> jarnos, is this in Karmic?
<jarnos> tormod, yes
<jarnos> Xubuntu karmic
<tormod> jarnos, there should not be one, so please file a bug with "ubuntu-bug xscreensaver"
<jarnos> tormod, how did you know it was xscreensaver? ubuntu-bug?
<tormod> jarnos, it is a command. And xubuntu uses xscreensaver AFAIK. let's discuss in #ubuntu+1
<mr_pouit> tormod: afaik, xubuntu still uses gnome-screensaver by default.
<superm1> according to apt-cache depends xubuntu-desktop, that is the case
<tormod> thanks, I am not up to date on it
<directhex> is karmic still unwell, or is it safe to consider an upgrade from jaunty now, relatively speaking?
<sebner> directhex: at least it should boot now. UPGRADE! :P
<chrisccoulson> directhex - you're still running jaunty?
<directhex> chrisccoulson, someone has to!
<directhex> chrisccoulson, i was more thinking for wifey's netbook actually
<chrisccoulson> heh, yeah. i was actually running jaunty up until last weekend, and was surprised that someone else still is too ;)
<chrisccoulson> i upgraded just before all the breakage
<chrisccoulson> i've had a really fun week:)
<directhex> i could upgrade my dell
<chrisccoulson> directhex - things seem to be mostly working now, although your mileage might vary depending on how strange your set-up is
<chrisccoulson> i'm not having any major issues now
<chrisccoulson> which is in contrast to a few nights ago;)
<directhex> hm. 1 month to release... i normally start upgrading round about now
<chrisccoulson> directhex - i normally do it a bit earlier. but i put it off because i wanted to do a clean install, and i'd been waiting for the specs from the foundations team to be implemented
<chrisccoulson> but in the end, i just couldn't wait
<directhex> where's my craptop gone
<cjwatson> excellent, upstart built on ia64
<cjwatson> we might just be able to get the world put back together there soon
<sistpoty> excellent!
<ion> http://op-for.com/mr%20burns.jpg
<mathiaz> james_w: hi! could you import the smart package in pkg branches?
<rowinggolfer_> tkamppeter, I am told you are the man to help me
<rowinggolfer_> I have apt-get update/upgraded my karmic alpha box.
<rowinggolfer_> got this.
<rowinggolfer_> Setting up cups-pdf (2.5.0-8) ...
<rowinggolfer_>  * Reloading Common Unix Printing System: cupsd                          [ OK ]
<rowinggolfer_> Password for root on localhost?
<rowinggolfer_> Password for root on localhost?
<rowinggolfer_> Password for root on localhost?
<rowinggolfer_> as you can see... I'm  hosed.
<tkamppeter> rowinggolfer_: This one is old, and fixed.
<rowinggolfer_> tkamppeter, excellent.
<rowinggolfer_> I need to ctrl-C?
<tkamppeter> rowinggolfer_: sudo apt-get update; sudo apt-get dist-upgrade   should fix it.
<tormod> just press Enter IIRC
<rowinggolfer_> tormod, thanks.
<rowinggolfer_> tkamppeter, thanks.
<tormod> what about showing a slideshow while Gnome is loading "While Ubuntu is booting, we invite you to explore... Only a few minutes now..."
<virtuald> Haha
<Turl> hi
<Turl> when I boot I get errors like this from udev
<Turl> NAME="%k" is superfluous and breaks kernel supplied names, please remove it from /lib/udev/rules.d/
<Turl> also some like unknown key 'SYMLINK{unique}' in /lib/udev/rules.d/50-udev-default.rules:3
<Turl> and also "can not read '/etc/udev/rules.d/z80_user.rules'"
<virtuald> It's being worked on
<Turl> ok virtuald, thanks :)
<virtuald> At least it's bootable now :)
<Turl> yeah, it was unbootable just for half a day :P
<Treenaks> Turl, do you have a blinking scroll lock led as well? (changes randomly while typing)
<Turl> Treenaks: what?
<virtuald> Ooh I want one of those!
<Treenaks> Turl, I'm running karmic, and my scroll lock led keeps blinking while I'm typing
<Treenaks> and I have no idea where to start debugging that
<Turl> I don't have an scroll lock light here, sorry
<virtuald> Blinkenlights
<Turl> (I'm on a laptop, it just has numlock and caps lock)
<Turl> anyone getting a black screen for some (quite a lot) seconds from grub to the little moving ubuntu thing?
<Riddelll> chrisccoulson: hi
<chrisccoulson> hi Riddelll
<chrisccoulson> i was going to ask if you had seen bug 432536, but I think Amaranth subscribed you to iy
<ubottu> Launchpad bug 432536 in libindicate-qt "incorrect binary package name" [High,Triaged] https://launchpad.net/bugs/432536
<directhex> oh dear. is karmic shutdown broken?
<chrisccoulson> directhex - in what way? i can shut down ok
<directhex> chrisccoulson, lots of console spew relating to init
<directhex> also, seems to take a VERY long time to do any kind of bootsplashing. gets there eventually though
<chrisccoulson> directhex - i cant remember if i saw that the last time i shut down
<chrisccoulson> logging out takes an eternity here though
<sistpoty> directhex: you shutdown? :P
<directhex> sistpoty, of course!
<directhex> init: rc main process (XXXX) stopped by STOP signal
<directhex> init: rc main process (XXXX) continued by CONT signal
<directhex> where XXXX is presumably a PID
<directhex> spews for about a screen, slowly, before doing what it should
<directhex> bug 419753 i think
<ubottu> Launchpad bug 419753 in linux "[karmic] system fails to shutdown cleanly (dup-of: 418509)" [Undecided,Confirmed] https://launchpad.net/bugs/419753
<ubottu> Launchpad bug 418509 in linux "[Karmic] Hangs during shutdown with kernel 2.6.31-7" [High,Fix released] https://launchpad.net/bugs/418509
<sladen> TheMuso`: the latency and silence padding of bell.ogg is frustrating, do you have the originals (they can be encoded to Vorbis as part of the package build process
#ubuntu-devel 2009-09-19
<shtylman> ccheney: I wish I knew...I have been trying many things to no avail... for some reason when using oxygen style..there is no text!
<irvingpop> Howdy
<irvingpop> I need help creating a PPA for a program that has never been packaged before for Debian/Ubuntu.   Is this the right place?
<ScottK> irvingpop: #launchpad is the place for PPAs.
<jpds> irvingpop: #ubuntu-motu can help you out.
<irvingpop> Thanks!
<ScottK> jpds: Unless it's intended to go into Ubuntu, I think it's OT for #ubuntu-motu.
<jpds> ScottK: I assumed he was trying to get it into Ubuntu.
<ScottK> Could be, I read it the other way.
<mauren> hi
<ccheney> shtylman: hmm weird :(
<ccheney> shtylman: were you able to get the other bugs fixed?
<shtylman> ccheney: I need to take a closer look at the other bugs, but I am pretty sure there are fixes for them...they seem like *normal* bugs compared to this one..
<shtylman> the extension bug is not a problem and I have a fix
<shtylman> the one where it goes up a directory might be related to this oxygen/no text bug
<shtylman> and the cut off widgets...well... I don't think there is an immediate solution for that one.. the integration provides feedback on how big to make the widget...but it is either being ignored or we arn't doing it right..
<shtylman> if I fix it for one style, it breaks for another...
<shtylman> basically...im hung up on this filepicker text bug really
<tripzero> doesn't look like consolekit is working without gdm in jaunty
<ScottK> shtylman: My 15 year old daughter will be very glad to hear about the missing extension fix.  Between that and the fact that OOo only knows a .doc is .doc due to the extention, she thought she'd lost he homework and was going to have to redo  it.
<shtylman> ScottK: haha... wow
<shtylman> thats like an inspirational story..
<ScottK> I added the .doc manually, opened it again and it was all there.  She was very relieved.
<shtylman> ccheney: I will send the patches for extension tomorrow evening...I don't know about the other stuff...it isn't going well
<ScottK> But, yeah.  That's a good one to get fixed.
<shtylman> ScottK: yea... im quite upset that oo doesn't add the extension itself
<shtylman> the checkbox is checked
<shtylman> so I would have assumed that it would..guess not
<Amaranth> *groan*
<Amaranth> I can't reproduce bug 429858 anymore
<ubottu> Launchpad bug 429858 in compiz "compiz.real assert failure: compiz.real: ../../src/display.c:793: updatePlugins: Assertion `j == pListCount' failed." [High,Incomplete] https://launchpad.net/bugs/429858
<Amaranth> err, wrong one
<Amaranth> bug 430981
<ubottu> Launchpad bug 430981 in compiz "keybindings not remembered on reboot" [High,Confirmed] https://launchpad.net/bugs/430981
<Amaranth> anyone here having that problem?
<ccheney> shtylman: ugh sorry i was in another window, reading scrollback now :)
<ccheney> shtylman: ok finished reading, thanks for the update
<ccheney> shtylman: if at least some of the bugs can be fixed in time for beta that will definitely help :)
<ccheney> shtylman: i can wait to do the upload until sunday night (UTC-0600) but not much further than that or people will call for my head ;-\
<ScottK> more than usual ...
<ScottK> ;-)
<Amaranth> What? OOo uploads are done on weekends to not kill every else's day?
<ccheney> Amaranth: well when i try to upload on monday's it seems arm people scream :-\
<ccheney> Amaranth: our arm buildd is really slow
<Amaranth> ccheney: hehe, you kill their whole week :P
<ccheney> Amaranth: well it only takes ~ 30 or so hours to build but still its not like the 1-2 hours it takes on my machine
<Amaranth> ccheney: Holy crap, what kind of machine do you have?
<ccheney> i think with my new machine i get next week it will take < 1 hr to build OOo
<Amaranth> A couple years ago on a top of the line machine it took over 6 hours
<ccheney> i currently have a c2d 2.8ghz and next week will have ~ core i7 4ghz
 * hyperair thinks that the buildds should use ccache
<Amaranth> Wow, OOo must have improved their build times
<Amaranth> That's getting into Firefox territory
<Amaranth> ccheney: Soon "it's compiling" won't work well as an excuse for reading slashdot ;)
<ccheney> Amaranth: a hyperthreaded 4 core 4ghz system is a little faster than a cellphone cpu ;-)
<Amaranth> Yeah, I'd say
<Amaranth> ccheney: Wait, does OOo use gold or something now?
<ccheney> no
<ccheney> if it did it would compile super fast aiui
<Amaranth> Yeah, gold would probably have it under an hour on your current system
<wgrant> Doesn't armel have $large_number buildds now?
<ccheney> it might still take over an hour with the new system due to dpkg-shlibdeps etc, will have to see how it does
<Amaranth> We need one of those dual core 2Ghz Cortex A9 things for a buildd :)
<ccheney> yea :)
<Amaranth> or several of them
<ScottK> wgrant: It does, but if you upload a 30 hour monster right before a milestone freeze it can complicate things.
<ccheney> need one of those in the next iphone too :)
<wgrant> ScottK: I suppose so.
<Amaranth> it'll still take forever but it'll be like compiling on a netbook instead of a cell phone
<ccheney> 30 hours then if it breaks bad things happen, heh
<Amaranth> distcc to the rescue ;)
<ion> amaranth: Btw, icecc > distcc ;-)
 * ccheney wonders how long it takes to start OOo on arm, it takes ~ 8-10s on atom
<Amaranth> well most of that is IO, isn't it?
<ccheney> maybe so, the system i have has a hd but its probably pretty slow
<Amaranth> ccheney: cold cache it takes that long on my laptop
<ion> It would be nice if icecc was fully decentralized, though.
<ccheney> it takes ~ 2s on mine but it might not be completely cold
<ccheney> my hd is definitely faster than a netbooks though
 * Amaranth really hopes we don't have to enable unredirect_fullscreen_windows in compiz again
<Amaranth> It fixes a bunch of bad bugs having it disabled
<ccheney> anyone know if radeon 4350 works good on karmic?
<ccheney> er with the open driver i mean
<ccheney> hmm looks like 2d should work but not 3d
<Amaranth> ccheney: Right, 3D is what caused the fun loop of splash screen on the alpha 6 cds
<cjwatson> ScottK: ia64 is properly alive again, and I've given back everything that failed with chroot problems.
<glick> excuse me, in jaunty is there a known issue with pulse or alsa not working correctly and picking up mics?
<glick> not picking up mics?
<glick> i dont know if i should file a bug report, or if im just stupid
<Amaranth> yay!
 * Amaranth has a failsafe GNOME session
<wgrant> cjwatson: Do you want to give back lots of stuff in your rebuild archive, or do you want to grant the usual teams privileges to do so?
<glick> im trying to figure out where or if i should file a bug report
<cjwatson> wgrant: as it happens I'm right in the middle of doing so at the moment
<glick> my microphone in alsa cant be unmutted, and when i switch my recording device to pulseaudio, none of the recording applications can use it
<wgrant> cjwatson: Great, thanks.
<glick> i dont know if that would be an ubuntu bug, alsa bug, or pulseaudio bug
<cjwatson> wgrant: unfortunately the API gives up in despair when trying to do anything with my rebuild archive so I'm having to do it through the web UI. Takes a whiel.
<cjwatson> while.
<glick> or even IF its a bug
<wgrant> cjwatson: Erm, really? What error does it give?
<Amaranth> glick: file a bug or try asking about it again on a weekday
<glick> ok Amaranth
<cjwatson> similarly, the web UI can't actually load the main page for the archive so I probably can't adjust privileges either
<wgrant> cjwatson: Privs are done through the API.
<cjwatson> >>> launchpad.people['cjwatson'].getPPAByName(name='test-rebuild-20090909')
<cjwatson> ...
<wgrant> Ah.
<cjwatson> lazr.restfulclient.errors.HTTPError: HTTP Error 400: Bad Request
<wgrant> It's not a PPA.
<wgrant> launchpad.load('https://api.edge.launchpad.net/beta/ubuntu/+archive/test-rebuild-20090909')
<cjwatson> aha, thanks
<wgrant> There might be another way to get it, but that's how I do it.
<cjwatson> https://edge.launchpad.net/ubuntu/+archive/test-rebuild-20090909 oopses
<wgrant> Er.
<wgrant> That worked for me three hours ago.
<cjwatson> it's been consistently failing for me for ages
<wgrant> Yes, but you are special.
<wgrant> It works for me.
<cjwatson> as the archive owner, you mean?
<wgrant> Right.
<cjwatson> thanks, that API call works
<wgrant> Great.
<wgrant> Then you can hopefully call newComponentUploader on it.
<cjwatson> on which team?
<wgrant> It might be valuable to give ubuntu-dev access to all components, since all that can be done in that archive is retry.
<cjwatson> breaks with HTTP 500. Life's too short and it's a Saturday. I'll try again in working hours
<cjwatson> >>> ubuntu_dev = launchpad.people['ubuntu-dev']
<cjwatson> >>> for component in ('main', 'restricted', 'universe', 'multiverse'):
<cjwatson> ...     rebuild.newComponentUploader(component_name=component, person=ubuntu_dev)
<cjwatson> lazr.restfulclient.errors.HTTPError: HTTP Error 500: Internal Server Error
<wgrant> cjwatson: Argh, OK. I'll try things locally and see what's wrong. Thanks for trying.
<wgrant> cjwatson: I can't reproduce that newComponentUploader OOPS or see how it's happening, unfortunately. Can you grab an OOPS code for that at some point?
<cjwatson> wgrant: did you move http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html somewhere else? it's 404 now
<wgrant> cjwatson: Add -karmic before the .html, sorry. I might symlink it.
<cjwatson> ok
<cjwatson> thanks
<wgrant> cjwatson: I've identified and filed the bug that causes an OOPS when you view the copy archive, but can't reproduce the API OOPS.
<cjwatson> it's just hanging on "Loading credentials..." for me now, so I can't dig into it more at the moment :(
<wgrant> Hmm.
<GobiTheGoblin> Hi there =) I asked this in kernel channel too, but that place is dead silent. So I came here. The question is this: If I have understood correctly this should be somewhat correct dir/file structure of 2.6.31 http://kernel.ubuntu.com/git-repos/ubuntu/linux-2.6/drivers/hid/ ?
<GobiTheGoblin> Still, when i install sources from repos, those files are not there
<directhex> yay for Evo. Inbox (-2 unread, 2209 total)
<wgrant> directhex: I had -35 unread at one point.
<Ademan> not sure if this is *really* the right place, but what's the relation between notify-osd and that notification applet? and how can i get my notifications to stay resident in that notification applet (like pidgin)
<wgrant> Ademan: The notification applet to which you refer is indicator-applet. It's an entirely separate system from notify-osd (which uses libnotify).
<Ademan> wgrant: ah thanks, is it similarly available over dbus?
<wgrant> Ademan: yes.
<Ademan> thanks wgrant, D-feet time hah
<wgrant> Ademan: There are libraries around. libindicate, and its Python binding python-indicate.
<Ademan> wgrant: thanks, but i'm trying to shoehorn some of this functionality into irssi, which means perl, which seems to mean raw-dbus :-/
<wgrant> Ademan: Aha.
<wgrant> Ademan: Excellent idea.
<Ademan> thanks wgrant i have the notify-osd part working already :-) although it doesn't too much at the moment
<Ademan> egh indicator-applet doesn't seem to implement any interfaces... wth?
<directhex> sigh, that was quick. my karmic won't boot on my laptop
<directhex> yup. bricked.
<directhex> um... why would recovery mode still try to launch X? was that always the case?
<Laney> i think thats a bug
<Laney> did it for me too
<directhex> oh for..........
<directhex> Laney, this will fill you with as much rage as me
<directhex> Laney, touch /forcefsck; reboot
<directhex> Laney, welcome to extended black screen land
<Laney> haha
<Laney> i think i'll give it a miss
<directhex> Laney, the modesetting happens before a slow, feedback-free, and frankly scary action - no hints as to what it's doing
<directhex> okay, someone needs to do something about that, i mean really really badly
<directhex> hm. is karmic meant to use grub2?
<sebner> directhex: sure
<Laney> did it come back?
<directhex> sebner, you sure? this is grub1 still
<directhex> Laney, oh, yeah. once fsck finishes, it boots fine.
<cjwatson> grub2> only on fresh installs, and even then there are a couple of corner cases that still need grub1
<cjwatson> if you want to upgrade to grub2, see http://wiki.ubuntu.com/Grub2
<directhex> Laney, try adding "nomodeset" to boot parameters to actually see why it spends 5+ minutes on a black screen
<Laney> rather you than me...
<Laney> I wrestled with this system most of the week, finally got it reasonably alright
<directhex> hm. well, grub2 seems to work. compiz has gone the way of the dodo though :(
<directhex> aha, got it to come back
<ScottK> cjwatson_: Thank you for taking on ia64 and getting it going again.
<tgpraveen> is it true that the boot speed improvements and all would be available only from karmic beta
<tgpraveen> ?
<directhex> nspluginwrapper in karmic doesn't accept click events Â¬_Â¬
<ScottK> tgpraveen: There are quite a number of parts of boot speed improvements.  A great deal of them landed last week and were in Alpha 6.  I don't think it will all be done for a bit yet.
<kirkland> superm1: ping
<dhillon-v10> hi all, I need some help with a nautilus crashing problem, I enabled apport but all I get on stacktrace is ()????
<c_korn> dhillon-v10: try to install nautilus-dbg
<c_korn> (or even better: gnome-dbg)
<dhillon-v10> <c_korn> alright I will do that, I had to do a fresh install about 3 times before because this problem won't go away
<c_korn> odd, I did not have any problems with nautilus
<c_korn> which steps should reproduce the crash ?
<dhillon-v10> <c_korn> another problem is that this happens at random I am not sure what causes the problem, do you want me to post the log file viewer results
<c_korn> just open a bug and attach it.
<dhillon-v10> <c_korn> I have done that several times before no response till now
<dhillon-v10> http://paste.ubuntu.com/274312/
<tgpraveen1> : http://ostatic.com/blog/ubuntu-version-9-10-code-named-lucid-lynx
<tgpraveen1> (12:10:25 AM) tgpraveen1: ubuntu 10.04 name
<zyga>  
<citrus212> hi there
<citrus212> i need help with grub bootloader
<citrus212> i'm trying to load xp back onto it
<ScottK> citrus212: Help is in #ubuntu+1 for Karmic and #ubuntu for other releases.
<superm1> kirkland, contentless pong
<MontelEdwards> Hi
<MontelEdwards> I was wondering if anyone could help me with a Boo script.
<MontelEdwards> I am new to it, and i need something like the subprocess.call function in python
#ubuntu-devel 2009-09-20
<evand> MontelEdwards: Please see the topic.  You'll find more help in a dedicated Mono channel: http://www.mono-project.com/IRC
<ia_> hello. according to https://wiki.ubuntu.com/DevelopmentCodeNames , the next 10.04 will be called "lucid lynx" - could anyone tell me, please, does this approved information, or just the most suitable suggestion?
<wgrant> ia_: It looks official.
<wgrant> ia_: I don't see any official announcements, but there are lots of plausible news stories...
<wgrant> Who knows.
<Laney> apparently he announced it at a conference
<ia_> wgrant: yes, i'm thinking so, but asking, because usually official message is sent in ubuntu-devel-announce list about codename for next release.
<kirkland> superm1: yeah, sorry, nevermind, I figured it out :-)
<superm1> kirkland, what was it re?
<kirkland> superm1: karmic mythtv
<superm1> ah
<kirkland> superm1: i upgraded a couple of frontends today, was disappointed to see the db bump
<kirkland> superm1: as my backend is hardy
<kirkland> superm1: but i got the jaunty packages working on karmic, and pinned them
<superm1> kirkland, well if you want to help get a 0.22 in order for hardy, would be appreciated..
<superm1> there was some complexities since qt4 wasn't in hardy
<kirkland> superm1: i wouldn't mind trying 0.22 on my hardy backend
<kirkland> superm1: my ping was actually about that
<kirkland> superm1: i was curious how stable it was
<superm1> kirkland, well it's quite stable for me, upstream is getting really close to a release with it
<superm1> they've been in bug fix mode for a month now
<kirkland> superm1: good to know; available in a ppa for hardy?
<superm1> kirkland, well our weekly builds only do intrepid, jaunty, karmic
<superm1> *daily builds
<kirkland> superm1: hrm, okay
<kirkland> superm1: well, i'm out of town for the next 8 days, so I won't be playing it it for another week or so
<kirkland> superm1: i was in panic mode, though, today
<superm1> if you want to help sort out the problems in packaging for hardy (w/o breaking intrepid/jaunty/karmic), be glad to add it to the daily builds
<superm1> it's the same packaging for all distro releases we do
<kirkland> superm1: as I upgraded my way into a broken myth setup, the day before leaving for a long trip...  kim was *not* happy :-)
<superm1> haha
<kirkland> superm1: her words were to me, "oh no, you have *got* to be kidding..."
<superm1> kirkland, if you bzr get lp:~mythbuntu/mythbuntu/mythbuntu-weekly-build, that's our daily build script, it has the bzr branches for all the related stuff that gets used in it
<superm1> so maybe while you're on the plane or something, if you've got a schroot/pbuilder and the packaging/branches checked out you can take a look at hardy stuff
<kirkland> superm1: cool, i'll grab it
<kirkland> superm1: are there bugs filed for the known build issues?
<kirkland> superm1: is it mostly sorting qt4 and mysql5.1 issues?
<superm1> kirkland, not currently.  i think it's just qt4 and maybe nvidia vdpau stuff
<superm1> because it worked for a long time on hardy, but when it broke, the executive decision was, eh, get to if if we got time to fix it :)
<kklimonda> chrisccoulson, are ACKs in bug 429483 enough for an update or do we also need one from translation team? i cant check it out right now.
<ubottu> Launchpad bug 429483 in transmission "Transmission 1.75, a bugfix release, is available" [Wishlist,Triaged] https://launchpad.net/bugs/429483
<unimatrix> hi, will there be PulseAudio 0.9.18 in Karmic?
<unimatrix> or maybe at least 0.9.17? it's got some great tsched fixes that many users desperately need
<tgpraveen> !info pulseaudio
<ubottu> pulseaudio (source: pulseaudio): PulseAudio sound server. In component main, is optional. Version 1:0.9.14-0ubuntu20.2 (jaunty), package size 402 kB, installed size 1780 kB
<tgpraveen> unimatrix: pulseaudio (source: pulseaudio): PulseAudio sound server. In component main, is optional. Version 1:0.9.17-0ubuntu2 (karmic), package size 619 kB, installed size 4192 kB
<tgpraveen> currently in karmic
<unimatrix> weird, i've got karmic and it says it's 0.9.16
<tgpraveen> plan is  to get backports from .18 if it dosnt make it
<unimatrix> ok that's great to hear
<highvoltage> unimatrix: nice nick!
<unimatrix> highvoltage, thanks :)
<vmn> hello
<jdong> "BAR 6: No parent found for ..."
<jdong> *snickers* cute message :)
<jdong> oof, radeonhd, SO close
<jdong> worked great till the livecd tried to start compiz
<alex-weeej> mostly every icon has vanished from gtkmenus
<alex-weeej> bug or feature?
<alex-weeej> (karmic)
<alex-weeej> and gtkbuttons
<sebner> alex-weeej: feature. GNOME changed that
<alex-weeej> ok
<fatal> hello... just rebooted my ubuntu karmic installation for the first time for a while... now I get a black screen about halfway into the boot process.... any suggestions on how to debug/fix it?
<fatal> I've tried adding Option "DontZap" "false" in my xorg.conf and trying c-a-bs, but without luck.... also booting with kernel option "single" didn't help.
<fatal> Only way I can access the system is if I do "init=/bin/bash" ....
<hyperair> fatal: remove quiet and see the messages
<fatal> hyperair: last message I see before the blackness is the ufw starting....
<jdong> has anyone else seen their scroll lock light randomly blink on and off?
<hyperair> hmm
<jdong> no it's not a kernel panic
<fatal> I tried adding an echo+sleep in /etc/init/gdm.conf, but didn't see that...
<hyperair> hmm how strange.
<hyperair> no wait. it needs something else to print messages to console i think
<jdong> well with upstart, does gdm have console output?
<hyperair> come to think of it, does upstart even have console output?
<jdong> it definitely did the last time I played
<jdong> add console output to gdm.conf?
<jdong> </probably botching this up>
<hyperair> no, that is correct
<hyperair> man 5 init says so
<hyperair> whether it works is a different case
<jdong> haha I don't feel daring enough today to play with upstart jobs ;-)
<hyperair> they're fun to play with
<hyperair> =p
<jdong> I won't deny that
<hyperair> i've already rolled some of my own
<jdong> yeah I had a semi upstart booting system back in Hardy
<hyperair> and initctl list is pretty awesome
 * hyperair uses upstart to auto-phc-ize his system
<hyperair> undervolting, that is
<jdong> neat
<hyperair> it's awesome stuff. i really wish mainline would accept the phc patch
<hyperair> it gives me an extra hour of battery life (i think), and stops my cpu from overheating during kernel compilations or any compilation of similar or greater length
<ion> hyperair: I wish phc supported my CPU.
<ion> Itâs nice that phc doesnât require patching your kernel anymore. You can install it cleanly with dkms.
<hyperair> ion: what cpu is it?
<hyperair> actually yes you still need to.
<ion> model name: AMD Turion(tm) X2 Ultra Dual-Core Mobile ZM-82
<hyperair> in ubuntu that is
<hyperair> acpi_cpufreq.ko no longer exists.
<virtuald> Phrozen crew?
<hyperair> it's built in
<ion> Huh? I installed phc successfully with dkms. It loads just fine, until it notices it doesnât support ZM-82 yet and bails.
<hyperair> eh?
<hyperair> really?
<hyperair> what's the name of the kernel module?
<ion> http://linux-phc.org/forum/viewtopic.php?f=13&t=2
<hyperair> ion: seems like dkms is only for the amd one
<hyperair> ion: i'm an intel user
<hyperair> hmm looks like powernow-k8 is also compiled into the kernel
<hyperair> are you sure this works with DKMS?
<fatal> sees the problem was that KMS is now busted in the recent kernel updates....
<hyperair> heh is it?
 * hyperair doesn't use the stock kernel
<ion> hyperair: The page says the intel one if âofftreeâ as well.
<hyperair> ion: it looks like it needs to replace an in-tree module with its own.
<hyperair> ion: using a modprobe conf
<hyperair> and the said modules are compiled into the kernel, rather than as modules
<hyperair> i think it's been like that since jaunty.
<ion> Ok
<hyperair> it would be nice if we could get the phc thing packaged as a dkms module
<hyperair> but we'd need to get the kernel-team to switch powernow-k8 and acpi-cpufreq to module rather than in-kernel first
<alex-weeej> php > require_once '/usr/share/xpres/lib/Zend/Loader/Autoloader.php';
<alex-weeej> BAM
<alex-weeej> vm explodes
<alex-weeej> need help debugging
<alex-weeej> u910 host, u804 guest
<alex-weeej> alex@xpres-two:/usr/share/xpres/lib$ cd Zend
<alex-weeej> alex@xpres-two:/usr/share/xpres/lib/Zend$ ls -al
<alex-weeej> crash!
<alex-weeej> well, exit(1)
<alkisg> I'm trying to make a pxelinux boot menu similar to the one found in the ubuntu desktop cd. I can't find any info on how to localize the menus, is the isolinux localization method upstream or is it ubuntu-specific?
<LaserJock> anybody know anything about SCIM?
<CarlFK> anyone know if there is a lib in a repo that contains  http://git.busybox.net/busybox/tree/libbb/find_mount_point.c
<tormod> CarlFK, I think it is included in the busybox in the initrd
<CarlFK> tormod: yeah, but I can't call that form my app, right?
<tormod> CarlFK, maybe if you install busybox, but I am not sure how smart that is
<tormod> I think I have seen find_mount_point coded in sh somewhere...
<ebroder> Has anybody ever tried to run the debian-installer under Xen?
<CarlFK> " No library is required; just pass the target directory into statvfs()."  doh.  (end of my quest for find_mount_point.c )
#ubuntu-devel 2010-09-20
<bdrung_> doko: btw, do you have any idea how to debug bug #629955?
<ubottu> Launchpad bug 629955 in audacity (Ubuntu) "audacity 1.3.12-5 FTBFS on maverick" [High,Confirmed] https://launchpad.net/bugs/629955
<bdrung_> doko: i tried to build with gcc-4.4 (suggested by ScottK), but it still fails
<doko> bdrung_: we still build with 4.4
<bdrung_> doko: hm, ok. then what else changed between lucid and maverick?
<persia> bdrung_, If nothing else, you might look at differences between the powerpc build environment and the others: it did get built on powerpc, and there's probably < 15 packages that differ in the installed build-deps.
<bdrung_> right
<TheMuso> Whats up with powerpc?
<persia> TheMuso, It builds packages a bit slower than i386, and it seems audacity happened to get built at the right time to be successful on powerpc, but failed everywhere else.
<TheMuso> ah
<TheMuso> Probably because its slower hardware perhaps?
<ogra_cmpc> then armel would never ftbfs ;)
<ogra_cmpc> doko, just noticed your ping upstairs, will test tomorrow (sorry, i didnt notice it earlier)
<persia> ogra, armel has special reasons to FTBFS, which make up for the lack of speed :)
<doko> bdrung_: can you test to build with https://edge.launchpad.net/~ubuntu-toolchain-r/+archive/ppa/+packages (gcc-4.4-fsf)? not sure if this package still installs cleanly
<ogra_cmpc> persia, heh
<doko> bdrung_: seems to build with g++-4.3, so please find out which of the autoconf tests is the one that doesn't do the thing it should do
<bdrung_> doko: AC_EGREP_HEADERS
<bdrung_> in the portmixer tree
<doko> bdrung_: well, extract a self-contained test case and attach it to the report?
<bdrung_> doko: the failing configure.ac part: http://paste.debian.net/90486/
<doko> bdrung_: sure, and now find out, why it succeeds with 4.3, and fails with 4.4 ...
<bdrung_> doko: it fails if i run "./configure" in lib-src/portmixer
<bdrung_> doko: probably there needs to be a parameter. let's compare them...
<doko> bdrung_: and does it succeed if you run CC=gcc-4.3 CXX=g++-4.3 ./configure ?
<ogra_cmpc> it likely does some tests
<ogra_cmpc> extract them and call them manually with different gcc's
<bdrung_> doko: no. it needs additional parameters.
<bdrung_> doko: i found one differing parameter: libjack
<bdrung_> doko: i make progress:  I was able to limit the error to one command in lib-src/portmixer/configure.ac: AC_EGREP_HEADER([PaMacCore_GetStreamInputDevice], [pa_mac_core.h], , [have_support=no])
<Chipzz> doko: there was some discussion earlier about the default alignment on AMD64; you're the toolchain person, right?
<Chipzz> doko: https://launchpad.net/bugs/24692
<ubottu> Launchpad bug 24692 in NVIDIA Drivers Ubuntu "Amd64 ubuntu build hogs memory due to libs built with excessive alignment requirement" [Undecided,Incomplete]
<bdrung_> doko: i have created a small testcase and attached it to bug #629955
<ubottu> Launchpad bug 629955 in audacity (Ubuntu) "audacity 1.3.12-5 FTBFS on maverick" [High,Triaged] https://launchpad.net/bugs/629955
<bdrung_> ScottK: just to let you know: ^
<persia> bdrung_, So, why does that work on powerpc?
<bdrung_> persia: dunno. look at the attached testcase. something triggers the bug in this small example
<bdrung_> persia: i am too tired to work further on it.
<persia> Heh.  I've started a powerpc build against current maverick: I might look at the test case if I run into time, and I'll update the bug.  I just generally find it odd when things work on one arch and not others.
<bdrung_> persia: can you run the testcase on current maverick on powerpc?
<persia> I can, and will if I run into time to dig through it (requesting a maverick test rebuild of audacity requires more CPU time, but is one line at the command prompt)
<lifeless> kees: around?
<kees> lifeless: nope :) email me :P
<lifeless> kees: its for your embargo bug
<lifeless> kees: can't really move on it atm ><
<TheMuso> c
<AnAnt> Hello, can someone ack: LP #640567
<ubottu> Launchpad bug 640567 in swt-gtk (Ubuntu) "Candidate revision 3.5.1+versionbump-5ubuntu1" [Undecided,New] https://launchpad.net/bugs/640567
<persia> AnAnt, You probably want a rationale for the release team review.
<AnAnt> persia: the bugs it closes ?
<persia> Yep.  I usually write a few sentences in a "Rationale: " section at the top of the bug description just to make it super-easy for approval teams.
<AnAnt> ok
<AnAnt> done
<pitti> Good morning
<AnAnt> Hello
<AnAnt> please ACK LP #640567
<ubottu> Launchpad bug 640567 in swt-gtk (Ubuntu) "FFe: Candidate revision 3.5.1+versionbump-5ubuntu1" [Undecided,New] https://launchpad.net/bugs/640567
<ogra> mvo, around ?
<mvo> ogra: yes
<ogra> mvo, so i tried to use apturl ... but it doesnt work :(
<ogra> i ship a .desktop file with Typer=Link and Exec=apt:package-name?channel=ti-omap4-ppa ....
<ogra> klicking on it doesnt bring up software-center
<ogra> *Type
<mvo> does it bring up anything?
<ogra> only the loading animation of the netbook-launcher-efl
<ogra> i dont see anything in the processlist
<ogra> (at least it doesnt bring up an error ... i should probably see that as positive :) )
<mvo> ogra: does gnome-open DTRT ?
<ogra> lets see
<mvo> ogra: I wonder if netbook launcher is just having issues with Type=Link
<ogra> it opens weblinks fine
<iulian> AnAnt: I accept cheques, direct bank transfers and postal orders.  Is that OK with you?
<AnAnt> iulian: as long as I am not paying, I don't mind
<ogra> mvo, yeah. gnome-open brings up software center telling me there isnt a package called package-name :)
<mvo> ogra: haha
<ogra> using the above url
<mvo> ogra: so do you have a package in that channel ?
<mvo> ogra: then s-c will be more happy :)
<ogra> yes, there shuld be one
 * ogra looks up the ppa 
<ogra> mvo, https://edge.launchpad.net/~tiomap-dev/+archive/release ....
<ogra> mvo, same error with the actual package name now
<iulian> AnAnt: Are the rdepends affected by those changes?
<mvo> ogra: oh, that is rather silly of s-c, could you please report a bug about it?
<cjwatson> slomo: nitpicking I suppose, but your gst-plugins-good0.10 upload makes the changelog improperly formatted, due to:
<cjwatson> -gst-plugins-good0.10 (0.10.25-2ubuntu1) maverick; urgency=low
<AnAnt> iulian: should not, because that's not a new upstream
<cjwatson> + gst-plugins-good0.10 (0.10.25-2ubuntu1) maverick; urgency=low
<ogra> mvo, what about the .desktop file ?
<ogra> should i just blindly call gnome-open and make it Type=Application ?
<mvo> ogra: I'm not sure why it does not DTRT, but you can use gnome-open
<ogra> k, i'll try that
<mvo> ogra: could you try it with gnome-panel? it smells like a potential issue with efl-launcher
<cjwatson> slomo: could I have an upload without that glitch?
<slomo> cjwatson: sure, thanks
<ogra> mvo, well, gnome-open with Application works fine, i can live with that
<mvo> ogra: ok
<cjwatson> mvo: this software-center upload doesn't actually seem to have any change relevant to bug 640906.  r1218 in bzr claims to fix it but is just a changelog change
<ubottu> Launchpad bug 640906 in update-manager (Ubuntu) "gksu invocation with incorrect .desktop file" [Undecided,New] https://launchpad.net/bugs/640906
<mvo> cjwatson: let me double check
<cjwatson> (the rest looks fine)
<slomo> cjwatson: new version without that space uploaded :)
<cjwatson> slomo: thank
<cjwatson> s
<ogra> mvo, ugh ... i should probably do my tests with a binary packagename, not with a source one :P
 * ogra tests again
<iulian> AnAnt: Please upload.  I will take another look at it when it's in the queue.
<AnAnt> iulian: swt-gtk is in main, and I am MOTU
<pitti> didrocks: you rock! http://qa.ubuntu.com/reports/bug-fixing/maverick-fixes-report.html
<AnAnt> pitti: I think he knows that already
<mvo> cjwatson: thanks for the review and sorry for that oversight, I will upload a new one with just that diff
<pitti> he does, but I just can't stop saying
<didrocks> pitti: oh great! :-)
<iulian> AnAnt: OK.
 * pitti hugs mvo as well for being such a close #2
<pitti> mvo: you can still beat him!
 * didrocks hugs pitti & mvo
<iulian> Group hug!
<mvo> woah! I had no idea
<didrocks> pitti: don't tell that, he will add bugs to USC for beating me :) (I'll add more in unity then :p)
<cjwatson> mvo: no problem, thanks
<persia> How is that calculated?  I'm sure I didn't fix anything in prboom, and I know I fixed a couple other things.
<cjwatson> wow, I'm well behind this cycle
 * mvo hugs didrocks
<cjwatson> pitti: note that #4 and #5 look like the same person, and added together exceed didrocks
 * mvo hugs pitti
<cjwatson> (not to burst his bubble or anything ;-) )
<cjwatson> that would be bhavi's vast pile of merges I imagine
<persia> Indeed.
<didrocks> cjwatson: don't make me cry :-)
<cjwatson> persia: I believe it's from Changed-By of uploads with Launchpad-Bugs-Fixed fields.  Maybe sponsorship?
<cjwatson> persia: https://bugs.launchpad.net/ubuntu/+source/prboom/+bug/375498/comments/24 certainly shows you
<ubottu> Launchpad bug 375498 in prboom (Ubuntu) "prboom exits with signal 8" [Medium,Fix released]
<persia> Hrm, possibly (or potentially pabs just insisting a one-character fix was correct)
<pitti> cjwatson: indeed, our king of sponsoring
<persia> Ah, faulty memory works too :)
<mvo> but careful, once seb128 sees that he is only #3 I'm sure he will go into some final frenzy to catch up ;)
<didrocks> mvo: he's on vacation until eow :)
<cjwatson> mvo: python-apt: does DebSize maybe need to use K rather than L?  I notice that it's unsigned long long
<cjwatson> mvo: I don't know whether this matters - if it doesn't, feel free to ignore me
<mvo> cjwatson: yeah, K is more correct, also in pratice it should not matter that much. I can fix and re-upload if you want (and go through to see that its correct at the other places
<cjwatson> mvo: if it doesn't matter in practice, I'll just accept this now - you can always tweak it later
<cjwatson> ogra: your jasper-initramfs upload has a typo
<cjwatson> +    cp /root/usr/share/jasper-initramfs/ppa/ti-omap4-ppa.desktop /root/usr/share/applications/ti-ppa.dektop
<cjwatson> ogra: should be .desktop at the end.  Rejecting, please upload with that fixed
<mvo> thanks cjwatson, I think it does not matter much currently, in this case it should just limit the DebSize (the size of the packages download)  to 2^63 when it could be 2^64
<bdrung_> persia: what was the result of your powerpc build of audacity?
<persia> Precisely the same failure.
<persia> So that it built was clearly a timing issue, which means that a review of the differences in versions of the installed build-dependencies might identify the culprit.
<persia> Unfortunately, I haven't found time to run your test case yet (although I hope to as soon as I finish this one more bit on the other thing).
<ogra> cjwatson, ugh, please reject i'll do a new upload
<ogra> ah, you did already :)
<ogra> mvo, where exactly does sw-center get the channel name from ? the filename or the ppa url ?
<mvo> ogra: what does it display currently?
 * persia thought it got it from the channel definition file
<ogra> it doesnt display anything, still the error, i want to know if i use the right one in the apt: url
<ogra> i have ti-omap4-ppa.list in /usr/share/app-install/channels/ and the url contains channel=ti-omap4-ppa
<ogra> the full url for installing a test package is: apt:titiler-memmgr-tests?channel=ti-omap4-ppa
<ogra> https://edge.launchpad.net/~tiomap-dev/+archive/release/+packages
<ogra> sw-center displays the package name with a capitalized T and tells me that package is not available in my current software sources
<doko> bdrung_: updated bug #629955. I think the test should always fail, and that were just lucky until now. however I don't see yet why the extra error line leads to a different test result
<ubottu> Launchpad bug 629955 in audacity (Ubuntu) "audacity 1.3.12-5 FTBFS on maverick" [High,Triaged] https://launchpad.net/bugs/629955
<bdrung_> doko: should it really fail? should AC_EGREP_HEADER check the existence or the usability?
<doko> bdrung_: how is this header ever used?
<bdrung_> doko: it's used in src/px_mac_coreaudio.c. a separate check checks if we want to build src/px_mac_coreaudio.c
<bdrung_> wrong answer
<doko> bdrung_: well, then the correct fix would be to only run this test, iff you build src/px_mac_coreaudio.c
<bdrung_> i am looking for the documentation
<persia> Another option would be to not fail the build for platforms that don't have coreaudio if the test fails.
<bdrung_> doko: very good idea
<bdrung_> doko, persia: thanks for you help. i will forward our results to upstream
<persia> bdrung_, Did you get it building?
<bdrung_> persia: no, but we know now the reason and how to fix it (doko's suggestion)
<bdrung_> just run AC_EGREP_HEADER on the files that we want to build
<persia> OK.  I usually try to go one step more (maybe in discussion with upstream, or other interested parties).  Obviously, it would be unfortunate to release in current state.
<persia> Do you still want me to run the test in a couple minutes?
<bdrung_> persia: no
<bdrung_> persia: i will do a quick workaround test
<persia> Sorry about that then.
<bdrung_> persia: commenting the failing test should work
<persia> That's my least favorite way to fix things, but yeah, since in this case we know in advance it should fail, and we don't care.
<jibel> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<jibel> bug 642518
<ubottu> Launchpad bug 642518 in fglrx-installer (Ubuntu Lucid) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,Triaged] https://launchpad.net/bugs/642518
<cjwatson> chatter I saw in IRC scrollback suggested that kees was already on top of that
<jibel> this was introduced by the security fix of last week
<cjwatson> 17:01 <kees> ebroder: okay, thanks. this is a bug in the kernel update and we'l get it fixed asap; sorry for the glitch!
<cjwatson> (yesterday)
<jibel> cjwatson, okay. There is no comment from kees on the bug report.
<cjwatson> yes, I saw that
<bdrung_> cjwatson: my workaround works. let's wait for the upstream fix.
<lucidfox> 'Having SABDFL simply state ?this is how it is? may have given people finality, but for me, it was the wrong kind of finality. It was the finality of someone saying ?I?ve listened to the hundreds of comments complaining about this change, and I?ve chosen to ignore you?.'
<sabdfl> lucidfox: which issue?
<directhex> i guess the popular "sent from Ubuntu" bug
<lucidfox> Uh oh, I summoned the mighty giant! *hides* :)
<lucidfox> not that one
<directhex> no? wow!
<lucidfox> the window placement issue - this was a comment in my blog
<lucidfox> er, window button placement
<lucidfox> I actually feel concerned that, since it's only configurable via a hidden gconf setting, people turn to applications like Ubuntu Tweak, with known security issues, to change it
<lucidfox> I think I'll make a separate blog post about the harm of hidden preferences
<sabdfl> i wonder how folks feel about the buttons placement now?
<sabdfl> lots of discussion before the release, very little after
<directhex> sabdfl, i haven't found the regedit value to make my windows 7 partition put the buttons on the correct side of the window :/
<sabdfl> directhex: i had to use windows the other day too. wow. backwards.
<kklimonda> sabdfl: its so last week, now we are complaining about the new Evolution signature ;)
<directhex> kklimonda, what happened to complaining about the wallpaper? BRING BACK ubuntu-calendar!
<didrocks> about the button placement: a lot of people hated it at the beginning in the French forum, but now, they are advocating for it when people wanting the change it back to the right. Funny :)
<directhex> didrocks, i am reminded of http://www.ubercharged.net/wp-content/uploads/2010/06/1258035395841.jpg
<persia> I suspect most folk don't care that much, but it's nearly impossible to collect useful data, as those who were unhappy have "fixed" it, those who appreciate the change are quietly happy, and those who don't care are characteristically silent.
<kklimonda> directhex: hmm.. the old, good wallpaper of the month..
<pitti> didrocks: all just a matter of being used to something..
<directhex> change is scary!
<didrocks> pitti: right, habits are hard to changeâ¦ even for people who already switched to Linux
 * wgrant got used to the button placement in about a day. Now Windows is painful :(
<pitti> mr_pouit: hm, it seems there is no real code for saving the default keyboard layout in XFCE right now? or am I missing something?
<pitti> mr_pouit: I added some ideas to http://bugzilla.xfce.org/show_bug.cgi?id=5270, but not sure what would be the most upstream-desirable variant
<ubottu> bugzilla.xfce.org bug 5270 in Plugins "Active keyboard layout no remembered" [Normal,New]
<pitti> mr_pouit: in other words, how well should xfce support gdm
<persia> Why do we do that at the DE level again, rather than in X directly?
<kklimonda> sabdfl: but there is still the issue of not communicating those changes more clearly beforehand. I can see why some members of the community feel left out. It would make a good uds session probably.
 * persia doesn't currently, but has previously often had disagreements between keyboard layouts in GNOME vs. other places (raw X, console, etc.)
<directhex> kklimonda, it's not a democracy though. so perhaps stuff needs to be better communicated - but i wouldn't necessarily pay attention to the peanut gallery
<vish> well i dont lucidfox was complaining about the change itself , but rather the way it was changed.. the change had no purpose and still doesnt have any purpose
<persia> There's heaps of folk who can upload the packages that were controversial: if even one of them felt strongly enough to force the discussion to consensus to wait or to change, it may have been done that way.  That none of them did indicates a consensus to accept the change within the set of developers who can adjust it (Ubuntu Desktop and Core in this case).
<persia> Since anyone at all is able to be part of that group, just by having done a bunch of work (training is often received along the way), it's hard for me to see how it's an us vs. them thing.
<kklimonda> directhex: wellthat's all I'm saying - to make community understand the process.
<directhex> persia, the people who shout loudly about this stuff, very often, aren't interested in getting involved - only in having their opinions voiced
<vish> directhex: ++
<persia> directhex, My point is that we need to be clear that we're looking for ways to have our collective decisions be broadcast to a wider audience, rather than finding ways to ensure that certain participants provide certain other participants with specific information.
<directhex> twitter!
<persia> I have reservations about some behaviours related to embargoes myself, but I'm not that sure how different an announced embargoed item is from something someone spent doing unannounced and didn't share for a similar period of time.
<persia> Anyway, someone explain to me why selection of keyboard layout isn't done in X directly, rather than in the DE :)
<directhex> legacy mess
<persia> What would it take to fix?  Are we close enough that a UDS session would be productive?
<cjwatson> wait a sec, I don't like the change but there's a big difference between that and overruling a decision which was apparently requested by my manager's manager
<cjwatson> persia: ^-
<persia> cjwatson, Quite possibly.  Note that I make no statements about the motivation of individuals to choose not to overrule a decision.  Some folks might not do it for professional reasons.  Some folks might not do it out of respect, etc.
<cjwatson> persia: what I mean is that you can't translate that into a "consensus to accept the change"
<persia> I do claim though that if anyone who could make the change *really* wanted to do so, we'd at least have a discussion before the TB.
<persia> Why not?  If you accept a change because of your employment, how is that different from you accepting a change for another reason, in terms of your acceptance of the change?
<persia> I don't claim you're happy about it, only that you accept it.
<cjwatson> I might well choose to voice my disagreement in other ways.  There are ways of not accepting a change that consist of something other than immediately uploading to revert it.
<cjwatson> And this one hasn't been around for long enough that you can infer anything much from there not having been a TB discussion about it yet.
<cjwatson> (speaking for myself not as a TB member etc.)
<mr_pouit> pitti: there's a dialog in xfce4-settings-manager, and the backend in xfce4-settings-helper to apply the settings. From a quick look, something is stored and apply, but I don't know how, nor if there's a way to set something by default (libxklavier doc is so badly written that it's useless)
<wgrant> Is it a TB matter?
<persia> I'm thinking of the button-placement issue as a better example.  The evolution change is too young to be usefully analysed.
<persia> wgrant, I'd think that in a case of dispute between developers, the TB would have a say.  Might be CC instead.
<mr_pouit> pitti: and btw, the bug you commented it is reported against mcs (the previous settings manager for < 4.6), which did not include any keyboard dialog
<mr_pouit> s/it//
<cjwatson> wgrant: or whatever
<persia> cjwatson, But, yes, there are other ways of expressing disagreement.  It may be that "consensus" isn't the right word.  My feeling is that enough of us developers were willing to accept a change for one reason or another, or that we would have collectively agreed not to make that change.
<cjwatson> persia: alternatively: in a structure where enough people feel bound by some kind of authority not to revert something, you can't infer anything useful from a consensus to accept a change
<cjwatson> so it might be true but is essentially a null statement
<Laney> yes, I can't say that I would feel socially able to revert such a change, even if I had the technical requirements to do so
<persia> Possibly.   I like to believe that most folk do stuff because they think it's right, rather than because they think they should, but I understand this may not be true.
<Laney> Anyway, I'm happy to escalate to the TB if people feel that this is appropriate to do so now, given where we are in the release schedule.
<persia> Laney, You'd really want to first organise both opinions in terms of solid arguments, etc. for presentation, so they can be rationally considered.  Otherwise, the meeting will just be noise, which wouldn't help, regardless of your initial position.  I'm not saying you should or shouldn't do this, just that if you choose to do it, please do it in a way that doesn't devolve to confusion.
<Laney> persia: Yes. I'm obviously not interested in creating more noise, just having a decision made either way.
<Laney> ...and of course guidance on how best to handle/flag up potentially controversial changes in future
<vish> when does the TB convene? or how to keep track of this?
<Laney> wiki
<persia> vish, Subscribe to the TB mailing list.  TB meetings are alternate Tuesdays at 14:00 (sometimes UTC, sometimes british time, changing only slightly out of step with the UK)
 * vish looks up the list
<vish> persia: thanks..
<pitti> mr_pouit: oh, oops
<pitti> mr_pouit: shoudl I reassign it or create a new one then?
<bdrung_> FYI, the sponsoring overview is not up-to-date due to a bug. I have fixed the bug and you can find a newer overview here (until the fix is merged): http://people.ubuntu.com/~bdrung/sponsoring/
<mr_pouit> pitti: mmh, actually, the assignment is probably wrong (xfce 4.6 was released on 2009-02-27, and the bug filed on 2009-04-20, so I think it's already against the new settings manager)
<doko> bdrung_: could you comment on bug #640567?
<ubottu> Launchpad bug 640567 in swt-gtk (Ubuntu) "FFe: Candidate revision 3.5.1+versionbump-5ubuntu1" [Wishlist,Confirmed] https://launchpad.net/bugs/640567
<bdrung_> doko: it looks good.
<bdrung_> doko: should i sponsor it?
<doko> bdrung_: well,needs an exception from the release team
<bdrung_> doko: Iulian approved it
<didrocks> doko: thanks for backporting the fix of fullscreen OOo + compiz
<doko> didrocks: does it work for you?
<didrocks> doko: not tested here (I have compiz 0.9 for testing), just saw from the changeog. Will try to downgrade and see if it fixes. Does it work for you? I powndered backporting this one as I saw in the upstream bug this wasn't fully working
<doko> didrocks: it works for me in oowriter, and I can see presentations in full screen mode.
<didrocks> doko: good news, we'll definitively give it a look before eow
<didrocks> doko: that worthes a SRU I think. A lot of people should be using OOo to give presentations on lucid
<doko> didrocks: waits on pitti's approval
<didrocks> doko: oh nice :)
<bdrung_> didrocks: that the panels are over the presentation?
<didrocks> bdrung_: right
<bdrung_> didrocks: nooo. it was a nice feature for me (using two monitors and presenter-console)
<bdrung_> :)
<didrocks> bdrung_: you can avoid updating or create a package which conflicts with latest version :p
<didrocks> like apt-get install ooo-give-me-broken-panel
<bdrung_> :)
<sladen> pitti: https://bugs.launchpad.net/bugs/625849  that CVE (bzip2) has been published now
<ubottu> 'Error: Could not parse data returned by Launchpad: HTTP Error 401: Unauthorized\nResponse headers:\n---\ncontent-length: 21\ncontent-type: text/plain\ndate: Mon, 20 Sep 2010 13:45:50 GMT\nserver: zope.server.http (HTTP)\nstatus: 401\nvary: Accept-Encoding\nvia: 1.1 wildcard.edge.launchpad.net\nx-powered-by: Zope (www.zope.org), Python (www.python.org)\n---\nResponse body:\n---\nBug 625849 is private\n---\n (https://launchpad.net/bugs/625849)'
<pitti> sladen: I can't access this
<pitti> sladen: you want the security team to make it public?
<pitti> kees, jdstrand ^
<jdstrand> pitti, sladen, kees: there is other discussion in that bug which should not be made public yet
<sladen> jdstrand: I don't know, it's private ;-)
<sladen> jdstrand: but the new version with the fix has now been published (on the bzip.org website)
<jdstrand> sladen: yes
<jdstrand> sladen: we have the patch in dapper-maverick for both bzip2 and clamav already
<jdstrand> (I'm working on publishing USNs as we speak)
<jdstrand> sladen: the point I was making is there is *other* discussion in that bug that is not public yet
<smb> jdstrand, kees, pitti I had been discussing the 64bit problems in fglrx after last security update with tseliot. As there might be more to do than just make EXPORT_SYMBOL_GPL a EXPORT_SYMBOL (the function declaration would also need to go somewhere fglrx could use it), I would hope that the problem could be worked-around in fglrx-installer by the code I posted to bug 642518
<ubottu> Launchpad bug 642518 in fglrx-installer (Ubuntu Lucid) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,Triaged] https://launchpad.net/bugs/642518
<ogra> mvo, bug 643571 for you
<ubottu> Launchpad bug 643571 in software-center (Ubuntu) "apturl from .desktop file to enable PPA does not work" [High,New] https://launchpad.net/bugs/643571
<tseliot> smb jdstrand, kees, pitti: right, I'm getting a 64bit Lucid image to test smb's patch so that hopefully I'll just have to update fglrx
<pitti> are we even legally allowed to do that? i. e. exporting a new symbol as GPL?
<smb> pitti, That might be a third issue
<mvo> thanks ogra
<smb> The work-around would not need to
<ogra> mvo, tell me if i do anything wrong
<pitti> smb: they dropped a GPL symbol in a security patcH?
<smb> pitti, They changed an inline into a wrapper that is a real function
<smb> pitti, which is only GPL exported but has the same name of the inline before
<ebroder> smb: I like your approach of checking kallsyms better than mine. I think the patch looks fine, for whatever that's worth
<smb> ebroder, Thanks. :)
<smb> ebroder, Oh, I see your approach. I must admit that I failed to read through the whole bug report after discussing on irc. In theory the grep might be done against the header as well. Maybe having the advantage to let it compile against a kernel that does not run
<ebroder> smb: Oh, hmm. Good point. If you use kallsyms it'll pick the wrong function when you're building against the new kernel while running the old one
<smb> Now that you say so... Err, tseliot maybe we should do a hybride of both patches
<tseliot> smb, ebroder: let me check ebroder's patch
<smb> tseliot, Apart from doing the check differently it seems there is one half of the checking missing in the wrapper function. ebroder, was this done on purpose?
<tkamppeter> pitti, hi
<ebroder> smb: There's similar code for detecting other things there already, so it seemed like a half-decent place to put it
<cjwatson> ogasawara: can bug 641618 be closed now?  the only bug in there that isn't in the kernel I just upgraded to is bug 630885
<ubottu> Launchpad bug 641618 in linux (Ubuntu Maverick) "Maverick Kernel Freeze Exception" [High,Confirmed] https://launchpad.net/bugs/641618
<ubottu> Launchpad bug 630885 in linux (Ubuntu) "Preinstalled Maverick netbook image has no display on omap3 EVM (no LCD)" [Undecided,In progress] https://launchpad.net/bugs/630885
<ogasawara> cjwatson: yep, I'll close it.
<cjwatson> thanks
<smb> ebroder, I was more referring to this check in the kernel compat_alloc_user_space: if (unlikely(((unsigned long) size) > (((compat_uptr_t)~0) >> 1)))
<ebroder> smb: Oh, hmm. That must have been a mistake on my part
<ebroder> So your patch to kcl_ioctl.c, and my patch to the make infrastructure? :)
<smb> Heh, yeah. sort of
<smb> Though I somehow dropped __user on the variable declaration...
<tseliot> ebroder, smb: ok, so this would mean that should combine your patches and check the availability of that function in linux/compat.h as ebroder suggested. Is this correct?
<smb> tseliot, Yes that would be the idea
<tseliot> ok
<corecode> hey
<corecode> i'm always having problems finding the right bzr branch for a package
<corecode> i'd like to bzr clone the lucid glibc version
<pitti> corecode: if apt-cache show (or showsrc) shows a Vcs-Bzr:, then that's the one
<pitti> corecode: otherwise, lp:ubuntu/srcpackagename
<corecode> no /lucid/ somewhere?
<corecode> ah, /lucid-updates/eglibc
<pitti> corecode: right, for the stable branches; without a release name, it's the current dev release (i. e. maverick right now)
<corecode> how do i know whether to use lucid-updates, lucid-security or plain lucid?
<pitti> corecode: whichever is most current
<corecode> strange, my libc does not contain frame pointers, but the rules don't specify -fno-frame-pointer
<pitti> corecode: you can check with "rmadison packagename", or "apt-cache policy"
<corecode> thanks
<corecode> ah, it is called omit-frame-pointer
<corecode> still not finding anything that would set that
<tseliot> ebroder, smb: something like this should work: http://pastebin.ubuntu.com/497086/
<smb> tseliot, On a quick glance over this looks good to me
<tkamppeter> pitti, can a correction of a versioned dpendency of ghostscript on gsfonts still get into Maverick, as freeze exception?
<ebroder> smb, tseliot: Same here
<tseliot> ebroder, smb: good. I'll test it in both Maverick and Lucid
<tseliot> ebroder, smb: thanks for your help
<ebroder> tseliot: No problem. Let me know if there's anything else I can do to help
<tseliot> ebroder, smb: even though $ARCH_COMPAT_ALLOC_USER_SPACE is set to 0 in lucid (according to make.sh.log), the patch still makes it use the arch_compat_ function. Any ideas?
<tseliot> ebroder, smb: oh, now I see why
<tseliot> because it's defined and we check it with ifdef
<tseliot> and it's always defined
<smb> tseliot, Oops, yes
<smb> Needs to be re-phrased to another #if construct or probably the code which sets it to 0 removed
<tseliot> ebroder, smb: so I should just do this in the makefile: ifeq ($(ARCH_COMPAT_ALLOC_USER_SPACE), 1),  EXTRA_CFLAGS += -DARCH_COMPAT_ALLOC_USER_SPACE, endif
<tseliot> or whatever other solution looks better
<smb> tseliot, This sound reasonable, just be careful with that section before having a backslash at the end, so the hunk needs to be seperated by an empty line
<tseliot> smb: right
<pitti> tkamppeter: sure, please just upload it
<fta> cjwatson, hi, do you have time for the libvpx sync request from last week?
<tkamppeter> pitti, OK.
<corecode> how would i run debuild with make -j?
<corecode> i have 24 cpus
<corecode> and it is only using 1 :)
<ebroder> tseliot: You could do #if ARCH_... instead of #ifdef, but your way sounds fine too
<corecode> oh, just -j
<ebroder> corecode: Setting DEB_BUILD_OPTIONS=parallel=n is the same as -j n, but it's up to the package in question to support that - not all do
<corecode> ah ok
<tseliot> ebroder, smb: the final version of the patch works fine in Lucid and Maverick. I'll request an SRU tomorrow.
<smb> tseliot, Ok, thanks for doing all the tests and integration work
<tseliot> smb: np
<cjwatson> fta: need to wait for the fix for bug 635591 to be rolled out
<ubottu> Launchpad bug 635591 in Soyuz "Regression: syncing packages with UTF-8 changelogs fails" [High,Fix committed] https://launchpad.net/bugs/635591
<fta> oh, ok
<tkamppeter> pitti, ghostscript_8.71.dfsg.2-0ubuntu7 uploaded.
<corecode> can i set CFLAGS_APPEND for dpkg-buildpackage in a config file?
<tkamppeter> pitti, fixed also a trivial typo in gsfonts: gsfonts_8.11+urwcyr1.0.7~pre44-4.2ubuntu1
<pitti> tkamppeter: thanks
<pitti> . o O { try to quickly speak this version number three times }
<corecode> should debuild -e CFLAGS_APPEND=-fno-omit-frame-pointer work?  because i don't see it appearing
<bdrung_> doko: bug #643107 is your issue. eclipse builds on armel in Debian.
<ubottu> Launchpad bug 643107 in openjdk-6 (Ubuntu) "Eclipse 3.5.2-6 FTBFS on armel" [Medium,Confirmed] https://launchpad.net/bugs/643107
<cjwatson> corecode: I think that should be DEB_CFLAGS_APPEND
<cjwatson> corecode: it might still be overridden by debian/rules or by a Makefile in the package
<corecode> but it says the package may not override it
<cjwatson> that is an aspiration rather than truth
<cjwatson> (not entirely sure where you're seeing "it" say that, either ...)
<corecode> dpkg-buildpackage
<cjwatson> don't see anything like that in the current dpkg-buildpackage(1) manual page
<corecode>        CFLAGS_APPEND
<corecode>               Optimization  options appended to the compiler flags, which must
<corecode>               not be overwritten by the  package  (mostly  used  to  for  test
<corecode>               builds). Default value: empty.
<cjwatson> it doesn't say that any more in maverick
<cjwatson> which might suggest that it was never right to start with :)
<corecode> oh duh
<corecode> so how do i tell it now to build with a frame pointer?
<cjwatson> corecode: the easiest way is always to modify debian/rules
<cjwatson> corecode: all this DEB_CFLAGS_APPEND etc. stuff is an attempt to make that unnecessary in the future, but it's early days
<cjwatson> corecode: and you don't sound like your goal is debugging weird stuff in dpkg-dev, but rather getting your job done.  thus, modify debian/rules.
<corecode> thanks
<SpamapS> lifeless: I think here is an appropriate place for the java discussion actually.
<SpamapS> lifeless: /win 23
<SpamapS> I keep doing that. :-P
<lifeless> hah :)
<SpamapS> lifeless: a side tangent to the java discussion is your recent mentioning of Cassandra w.r.t. Ubuntu One...
<SpamapS> I've been reading the Cassandra mailing lists for about 4 months now.. and I am beginning to think its one of the most misunderstood databases in existence.
<lifeless> heh
<lifeless> sorry, phone call, paying attention again in  abit
<SpamapS> np
<sladen> rickspencer3:
<smoser> ugh. i feel beaten.
<smoser> in gnu make:
<smoser> x := $(shell case 1 in 1): ;; 2) echo 2;; ; esac)
<smoser> i cant seem to escape the close parens from indicating the end of $(shell)
<smoser> any ideas ?
<soren> smoser: Would you feel more beat or less beat if you resorted to a couple of if, if/else, else things?
<smoser> http://pastebin.com/dnbeDQs6 is my pathetic attempt.
<smoser> it is nicer to me when i act like that, yes soren.
<ebroder> smoser: close_paren = )
<ebroder> $(shell case $var in 1${close_paren} [...])
<soren> *chuckle*
<ebroder> It's what cdbs does
<soren> smoser: Well, you /could/ used backticks, but I can't really bring myself to recommend it.
<soren> smoser: Because, you know, they're evil and all that.
<smoser> ebroder, nice.
<soren> smoser: I'm sure if yo uused ebroder's suggestion, both you and make would walk away feeling like you've won.
<ebroder> I don't know...I'm pretty sure that make is winning no matter how you solve the problem
<smoser> well, its crazy, but this works: http://pastebin.com/1V2npC0D
<lifeless> barry: hi
<lifeless> barry: your friend hasn't replied
<barry> lifeless: :/
<lifeless> barry: did my ''Python packaging, dependencies, upstream facilities'' mail make sense to you?
<lifeless> SpamapS: (off the phone)
 * barry re-reads ;)
<barry> lifeless: can i forward this to debian-python?
<lifeless> of course; I'm also sending it to Jos
<barry> lifeless: cool
<SpamapS> lifeless: so, upstream facilities.. does that mean maven/cpan/pypi/rubygems ?
<lifeless> SpamapS: whats your mail
<lifeless> I'll copy you :P
<SpamapS> lifeless: clint.byrum@canonical.com or clint@ubuntu.com
<lifeless> SpamapS: check your mail :P
<SpamapS> wom 3
<SpamapS> ugh must get new keyboard
<SpamapS> lifeless: indeed, I think the high level idea needs to be that the installed package versions need to become arrays instead of scalars..
<SpamapS> lifeless: Tho, I think the way many are handling this is with funny thigns like lxc/openvz .. where they just build a new lightweight machine w/ the versions they want installed.
<lifeless> SpamapS: ugh
<SpamapS> lifeless: if something can accurately state its dependencies, then we can certainly assemble them in a number of ways. dpkg wants to satisfy each requirement with *one* package... but maven, for instance, allows one to simply install multiple versions, and picks one for the current build.
<SpamapS> lifeless: so if launchpad can state its dependencies, a program could probably assemble them into a private python library to override whatever is in the system's library.
<ari-tczew> doko: why you use *ubuntu2  to *ubuntu3 change in SRU? it should be *ubuntu2.1
<kklimonda> ari-tczew: it doesn't have to be - it just has to be lower than the version from the next release
<ari-tczew> very interesting
<SpamapS> lifeless: I wonder if ensemble has something to help with this. :)
<lifeless> SpamapS: I think the basic packaging layer needs fixing
<lifeless> SpamapS: lxc stuff and vms are nice tech  but totally different layers to this
<lifeless> SpamapS: the same issue turns up if you have two different python apps that have mutual incompatabilities with package A
<lifeless> and as you say, maven handles this better (and so we should also package java properly too, not in the flattened manner we do - as we discussed the other day)
<SpamapS> lifeless: debhelper type build tools can actualy solve this IMO. We just have to become comfortable with packages that have versions in their names.. which we already do when forced.. right?
<SpamapS> I mean, you can tell dpkg that launchpad needs python-super-library (>= 1.9, << 2.0) .. if python-super-library is kept as a virtual package provided by all versions of python-super-library.. this works.. no?
<SpamapS> probably not actually now that I type it out
<SpamapS> Provides: default-mta, mail-transport-agent, postfix-tls
<SpamapS> ||/ Name                          Version                       Description
<SpamapS> un  default-mta                   <none>                        (no description available)
<lifeless> SpamapS: standard policy for C/C++/CLR packages is to have the soname in the name
<lifeless> SpamapS: I'm proposing the same thing
<lifeless> s/packages/library packages/
<SpamapS> Hmm, Ok.
<SpamapS> Is there an easy way to detect API changes in a python library?
<kklimonda> no
<SpamapS> So right now your only hope is update lib, and run your unit tests?
<lifeless> thats not entirely true
<lifeless> setuptools has declarative per-version module obtaining glue
<lifeless> which isn't upstream really; which is why I initially only wrote barry saying 'upstream this man'
<lifeless> detecting an API change really isn't all that important in the first iteration of improvements,
<lifeless> the big issue is being *able* to represent the thing in dpkg; being able to have casual 'import foo' still work sanely and allowing more complex setups to work properly.
<SpamapS> I'm just trying to get at what would stand in for soname in a python package
<lifeless> right now we can't represent 1.2 and 1.3, we can have casual import foo work, but more complex setups fail
<lifeless> SpamapS: upstream releases ;)
<lifeless> SpamapS: policy vs mechanism :)
<SpamapS> in the pylons framework, for instance, they simply have you running a shell with the python include path prepended.. and easy_install/etc. everything just dumps stuff in your project's lib
<lifeless> SpamapS: which is terrible.
<SpamapS> totally
<lifeless> bbiab
<SpamapS> thats the length at which they have gone to get around this
<corecode> % bzr branch lp:ubuntu/mdadm
<corecode> bzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: CannotHaveLinkedBranch: <Distribution \'Ubuntu\' (ubuntu)> cannot have linked branches.">')
<corecode> what am i doing wrong?
<jml> corecode, that's a known bug in Launchpad right now.
<corecode> oh
<corecode> so, how do i do it right?
<corecode> because my actual issue is:
<corecode> % sudo lvresize -l+100%PVS media/media
<corecode> zsh: segmentation fault  sudo lvresize -l+100%PVS media/media
<jml> corecode, well, actually, https://code.edge.launchpad.net/ubuntu/+source/mdadm says there aren't even any branches for the package on LP
<corecode> so how is that package maintained then?
<corecode> is it possible that it isn't in bzr?
<micahg> corecode: yes, some packages there are issues with importing
<corecode> oh, too bad
<micahg> corecode: Debian has mdadm in git
<corecode> also i want lvm
<corecode> no food = bad concentration
<corecode> :)
 * micahg wonders how we got so far behing
<micahg> *behind
<corecode> how behind
<micahg> testing at 3.1.4, maverick at 2.6.7.1
<SpamapS> mdadm is a mess
<SpamapS> look at the bugs
<corecode> uh
<micahg> SpamapS: I would think that to be expected with 7 kernel revisions and no updates
<corecode> i thought every release takes all testing
<micahg> corecode: no, not if there are Ubuntu changes, someone needs to do a merge
<corecode> oh wow
<SpamapS> merging didn't get much priority this cycle
 * SpamapS vows to do more merges for natty
<corecode> if there was an easy way for me to do the merge, i'd occasionally do a merge
<SpamapS> I wonder how long squeeze will be frozen? The longer its frozen, the bigger our delta gets.
<SpamapS> corecode: merging is pretty easy really
<SpamapS> unless its one of the things that we maintain as fundamentally different from debian..
<SpamapS> https://merges.ubuntu.com/main.html
<corecode> i know
<SpamapS> the stats at the bottom are interesting
<corecode> if there was one script i could run, and then i have to fix the collisions
<corecode> fine
<SpamapS> grab-merge in that dir pretty much does that
<corecode> great; now i know where lvm is segfaulting
<corecode> but i don't know how to fix it
 * ari-tczew encourages SpamapS and corecode to do some merges for natty development. :)
<amikrop> Hello, where can I find some packages in which the code is Python and are packaged using CDBS?
<amikrop> I mean, some Python apps packaged with CDBS.
<SpamapS> amikrop: debian python packaging has been dominated by debhelper from what I've seen
<achiang> is there a proper way to override a setting in /etc/modprobe.d/alsa-base.conf ? can i drop a file into that directory that overrides it somehow?
<achiang> [i have a brute force method that works, just wondering if there's a better way to do it]
<Keybuk> curious
<Keybuk> I wonder whether X is using the i915 or nvidia card
<achiang> shouldn't it say in Xorg.0.log?
<Keybuk> seems to only detect the nvidia one
<Keybuk> the Intel one doesn't even show up in lspci
<Keybuk> well, it's in the chip I guess
<amikrop> SpamapS: I thought CDBS was using (extending?) debhelper
<cjwatson> corecode: psurbhi has been working on the big mdadm merge, but it took a bit longer than expected and will be natty at this point
<cjwatson> smoser: re your make problem, there's a simpler way
<cjwatson> smoser: it doesn't seem to be widely known, but you're allowed to put an open parenthesis before the pattern as well as a close parenthesis after it
<cjwatson> smoser: so if you write (1) rather than 1), the parentheses are balanced and make will be happier with you
<cjwatson> smoser: there are one or two other situations where this trick is useful too, such as a case statement inside $()
<cjwatson> (as in shell command substitution, not make function invocation)
<cjwatson> heh, cdbs doesn't use this - I may not know more make than cdbs, but I'm betting I know more shell ;-)
<superm1> /j #ubuntu-docs
<superm1> oops
#ubuntu-devel 2010-09-21
<cjwatson> pitti: one of your changes to media-player-info looks wrong
<cjwatson> +ATTRS{idVendor}=="22b8" , ATTRS{idProduct}=="41d9|41db" , ENV{ID_MEDIA_PLAYER}="motorola-droid" ENV{UDISKS_PRESENTATION_ICON_NAME}="phone-motorola-droid"
<cjwatson> pitti: missing comma-separation there?
<cjwatson> pitti: actually, uh, there seems to be lots of this.  Is the udev documentation wrong about what it accepts?
<Keybuk_> huzzah!
<smoser> cjwatson, that rocks. thanks. i have never seen that syntax for case
<psusi> ev, just subscribed you to bug #644011 since I believe it was caused by your upload the other day
<ubottu> Launchpad bug 644011 in ubiquity (Ubuntu) "Installer hangs if installation of grub fails" [Undecided,New] https://launchpad.net/bugs/644011
<YokoZar> I can't figure out which package this bug should be against: https://bugs.launchpad.net/ubuntu/+source/gnome-screensaver/+bug/632827
<ubottu> Launchpad bug 632827 in gnome-screensaver (Ubuntu) "[Maverick] X Screensaver not disabled, shows every 15 minutes regardless of Gnome screensaver settings (even in Totem)" [Low,New]
<micahg> YokoZar: could xscreensaver be installed or is that too far-fetched
<YokoZar> micahg: if it is it was pulled in by default somehow
<YokoZar> micahg: and it's not installed
<micahg> ah, your bug :)
<smoser> if I upload bug 644074 (ec2-api-tools package in multiverse) does it stand a chance at getting approved ?
<ubottu> Launchpad bug 644074 in ec2-api-tools (Ubuntu) "upgrade ec2-api-tools to 1.3-57419 (api version 2010-08-31)" [Undecided,New] https://launchpad.net/bugs/644074
<persia> lifeless, SpamapS : You might want to catch mjj re: Java library versioning; I believe there's a plan to have a soname-like facility in Debian in the future.
<lifeless> persia: \o/
<persia> Might be a while, like Wheezy+1 or so, but if there's interest in doing that, probably better to work with folks already looking at it for a few months, rather than a parallel solution.
<Mixmax> cjwatson: Good morning! Do you wish to be apart of the massive growth of Open Source software and ill have to ask you to keep an open mind.
<Hobbsee> Mixmax: if you wish to troll, please go elsewhere
<Hobbsee> where elsewhere does not include any other ubuntu channels, incidently
<lifeless> Hobbsee: welcome back to peak condition
<Hobbsee> lifeless: cheers
<lifeless> Hobbsee: did you get your good news?
<lifeless> whatever it was?
<Hobbsee> i don't remember which particular bit it was :)
<lifeless> @facebook
<Hobbsee> oh
<Hobbsee> mostly
<Hobbsee> parts of it, anyway :)
<lifeless> \o/
<Mixmax> ... /msg ananke Hows your frying going cock smoker ?
<micahg> Hobbsee: ^^
<Mixmax> Hobbit.. act and be one
<Hobbsee> !staff
<ubottu> hey Christel, Dave2, Gary, KB1JWQ, Levia, Martinp23, Pricey, SportsChick, VorTechS, jayne, jenda, marienz, nalioth, niko, nhandler, rob, stew or tomaw, I could use a bit of your time :)
<micahg> Hobbsee: you're no longer IRC admin?
<Hobbsee> micahg: i was never a staffer
<micahg> Hobbsee: oh, my mistake :)
<Hobbsee> micahg: no problem
<Mixmax> micahg: If you had liked linux or open source at all yould have booted ananke.
<Mixmax> micahg: And not let them turn it into The dreaded Dalnet!
<micahg> Hobbsee: thanks
<vish> odd, did i miss something?  why was he/she picking on cj-watson  though?
<micahg> vish: trolling...
<Hobbsee> goodness only knows
<wgrant> There was a great battle last week.
<Hobbsee> i'll never understand why people think they're going to get what they want by telling people to go and die, or other similar things
<slomo> hi, can someone sync this from debian/experimental? https://bugs.launchpad.net/ubuntu/+source/totem-plugin-arte/+bug/639760
<ubottu> Launchpad bug 639760 in totem-plugin-arte (Ubuntu) "Sync totem-plugin-arte 0.9.1-1 (universe) from Debian experimental (main)" [Wishlist,Confirmed]
<pitti> cjwatson: no, that looks wrong; I'll check this, thanks!
<pitti> Good morning
<pitti> cjwatson: right, seems this already happened in previous versions as well; I didn't change the generator script in 9
<pitti> looks like all the rules with an icon name miss it
<cjwatson> slomo: totem-plugin-arte is blocked on the rollout of a Launchpad fix.  I'll sync it after that
<cjwatson> slomo: (bug 635591)
<ubottu> Launchpad bug 635591 in Soyuz "Regression: syncing packages with UTF-8 changelogs fails" [High,Fix released] https://launchpad.net/bugs/635591
<cjwatson> ah, here, that's Fix Released now
 * cjwatson will look
<wgrant> Watch out -- it may not be on cocoplum yet.
<wgrant> But worth a try.
<cjwatson> slomo: I think I misremembered what this was blocked on, so at any rate done
<cjwatson> wgrant: it is, I checked bzr log there first :)
<wgrant> cjwatson: Ah, good.
<apparle> hi guys I want to access the touchpad. how to do it?
<slomo> cjohnston: thanks
<slomo> cjwatson: ^---
<pitti> cjwatson: m-p-i fixed upstream (now with automatic syntax check), and uploaded version 10
<pitti> cjwatson: thanks a lot for spotting
<doko> Riddell: kdesdk failed to build. could you address bug #641356 with the next upload too?
<ubottu> Launchpad bug 641356 in kdesdk (Ubuntu Maverick) "kdesdk-scripts recommends components in universe" [High,Triaged] https://launchpad.net/bugs/641356
<Riddell> doko: mm, ok
<tkamppeter> pitti, hi
<cjwatson> tkamppeter: the changelog in your ghostscript upload doesn't match the control file
<cjwatson> +  * debian/control: Updated versioned dependency of ghostscript on gsfonts,
<cjwatson> +    we need at least gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2 now due to the
<cjwatson> +    dropping of defoma.
<cjwatson> gsfonts (>= 1:8.11+urwcyr1.0.7~pre44-4.1)
<cjwatson> but:
<cjwatson> tkamppeter: is the control file correct (in which case that's fine) or is the changelog correct (in which case please reupload with a fixed control file)/
<cjwatson> ?
<doko> ttx: are you involved with likewise-open? there are some patches/fixes pending (assigned to Gerald Carter). But for now I'd like to just do a no change upload to get it built on powerpc.
<doko> zul: ^^^
<persia> doko, Are you sure that will work?  It didn't build for me on ppc yesterday, and I've been digging through the configuration hoping the Mac/PPC stuff would migrate to Linux/PPC.
<doko> persia: currently building on davis,now for about 30min
<persia> doko, Well, if it works, go ahead :)
<tkamppeter> cjwatson, the correct version number is 1:8.11+urwcyr1.0.7~pre44-4.1. I will re-upload.
<persia> doko, Just FYI, my build took 57 minutes to fail.
<apachelogger> Keybuk: I have a Qt upstart library to the dbus interface ^^
<apachelogger> (well, almost)
<maxb> Does anyone know what's responsible for adding localhost6 to /etc/hosts on a maverick update?
<Keybuk> apachelogger: doesn't Qt make one from the xml automatically?
<apachelogger> Keybuk: yes, but the dynamic nesting requires some poking
<apachelogger> Keybuk: comes to about 700 sloc including a simple example app and build system and xml
<pitti> cjwatson, ev, all others I forgot: I recently installed a current Maverick snapshot, and I just wanted to say that the new installer simply looks and feels awesome. Kudos!
<ev> yay
<ev> thanks pitti
<ev> that balances nicely with Keybuk's "it ate my shiny new computer"
<Keybuk> no, the Lucid installer ate my shiny new computer
<Keybuk> the Maverick installer mostly worked
<Keybuk> though I did note that it complained that I didn't have a working Internet connection
<cjwatson> my unproven suspicion is that grub_options is being initialised too early in lucid, before partitioning
<Keybuk> while bcmwl-kernel-source was sitting on the CD and it could have done something about that itself
<Keybuk> oh, and mvo - how the buggery bugger is apt-cd supposed to work?
<cjwatson> and that if it had actually shown the device it was supposed to show, we could have avoided going down a hideously wrong path involving grub-efi
<cjwatson> (which in part was because Keybuk asked me for help during sofa time :P)
<ev> Keybuk: it does do something about it
<Keybuk> ev: it didn't :p
<ev> Keybuk: if you click the "give me nonfree happiness" and hit next, it solves that problem for you
<Keybuk> I didn't have that button that I remember
<ev> cjwatson: I'm really confused as to how putting something in the MBR could so massively break GPT for OSX
<ev> given that it's just there for backwards compatibility
<cjwatson> it wasn't putting something in the MBR
<cjwatson> we were playing with grub-efi because I forgot how macbooks are supposed to work
<cjwatson> and it looks like the EFI System Partition got trashed in some arcane way
<ev> ahh
<cjwatson> also something odd with the partition table which I didn't really have a chance to debug because Keybuk wiped and reinstalled :)
<ttx> doko: likewise-open is now mostly maintained upstream and sponsored by the desktop team
<doko> ttx: ok, thanks
<ttx> doko: though I can help if need be, obviously
<doko> ttx: no, looks like it needs porting for powerpc. the autoconf/automake failure I did see in the build log just did hide that
<doko> persia: ^^^
<persia> Yep.  There's some upstream config to make it work for OS X/ppc so I'm fairly sure that it can be ported easily.  I believe it to be just a matter of defining the architecture correctly, but haven't unwound the complex configuration yet.
<doko> persia: look at NCommander's arm patches as a guide ...
<persia> I don't think it's that bad, but yeah, I've looked at those.
<mvo> Keybuk: apt-cdrom > that should just work, it talks to udev nowdays and looks for cdroms/dvds. what was/is the issue with it
<mvo> ?
<Keybuk> it seemed to find the CD ok
<Keybuk> but when I tried apt-get install, it said file not found
<Keybuk> (and the path it gave was certainly on the CD)
<mvo> Keybuk: wehh, that is bad (obviously). did it output anything more, or just that? what do I have to do to reproduce, was that a fresh install?
<Keybuk> yeah just a fresh install, CD still in the drive
<Keybuk> was installing bcmwl-kernel-source
<Keybuk> I'm pretty sure I can still reproduce it
<mvo> Keybuk: it would be nice if you could give me the output of "apt-get install bcmwl-kernel-source -o debug::aptcdrom=true
<Keybuk> sure thing
<Keybuk> will grab that for you in a bit
<mvo> Keybuk: and -o Debug::Acquire::cdrom=true as well please
<Keybuk> *nods*
<popey> Keybuk: you have a mbp?
<Keybuk> popey: aye
<ttx> doko: right, I'm pretty sure upstream answer was that "it's not supported"'
<ttx> let me dig a reference for that
<pitti> cjwatson: I just did some udev bug fixes, and prepared a new pacakge with an upstream merge; tested locally, works fine
<popey> maverick installer scared me so i pulled the plug because it started doing stuff to the disk before I had an opportunity to tell it where to put grub :S
<pitti> cjwatson: I'd like to upload http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/maverick/udev/ubuntu/revision/2619, do you consider it okay, too?
<Keybuk> popey: it asks that in the partitioning phase
 * ogra notices that all his ubuntu problems vanished when he started to use that tegra2 based armel netbook from toshiba
<pitti> cjwatson: there are two important bug fixes, a new keymap, some documentation updates, a new automatic test, and a small new feature in scsi_id (exports a new property); I think the feature is harmless for us, but I'd still like to get a second pair on it
<popey> Keybuk: hmm it might do now, it didnt when I tried, so i did 10.04.1 -> 10.10 instead
<ttx> doko: https://bugs.launchpad.net/ubuntu/+source/likewise-open5/+bug/345332
<ubottu> Launchpad bug 345332 in likewise-open5 (Ubuntu) "Build system only supports i?86 and x86_64" [Undecided,Won't fix]
<popey> Keybuk: keyboard layout wrong for you?
<popey> Keybuk: bug 630203
<ubottu> Launchpad bug 630203 in kbd (Ubuntu) "Macintosh keyboard layout is wrong" [Undecided,Confirmed] https://launchpad.net/bugs/630203
<cjwatson> pitti: looks fine
<doko> ttx: well, meanwhile, ARM is supported ... NCommander, did the patches land upstream?
<pitti> cjwatson: ok, thanks; uploading
<persia> ttx, There's PPC support upstream: that bug is just kinda amusing.
<Keybuk> popey: haven't explored fully
<Keybuk> I know the touchpad is difficult
<Keybuk> to right click a menu and choose an option in it is kinda impossible
<popey> yeah
<popey> I resorted to using a mouse ;(
<ogra> doko, bug 517300 says it was forwarded ... not sure it was ever applied
<ubottu> Launchpad bug 517300 in likewise-open (Ubuntu Lucid) "[armel] likewise-open needs porting to ARM" [High,Fix released] https://launchpad.net/bugs/517300
<Keybuk> popey: they keyboard seems mostly right, what's wrong for you?
 * cjwatson punts popey's bug off to the right package
<cjwatson> /usr/share/X11/xkb/symbols/gb is the relevant file
 * popey reboots to find out
<popey> thanks cjwatson
<popey> Keybuk: pressing the "' & ~" key next to Z gives me "< & >" respectively
<Keybuk> oh
<Keybuk> I think I expected the ~ key to be next to 1
<Keybuk> and have been using it there just fine ;-)
<popey> well, yes, thats a nice place to put it, but wrong according to mr jobs
<ttx> persia: eh, I suspect they added it later, then, because that's the answer I got from Jerry Carter at that time.
<persia> ttx, Oh.  I thought it was earlier.  As far as I've been able to tell, the PPC support is only for old Mac OS X.
<persia> But yeah, I don't expect upsteam to support ppc/linux today :)
<ogra> mvo, lol !
<ogra> mvo, you could just have told me to drop the 4 from the channel name :)
<tkamppeter> cjwatson, the ghostscript with corrected debian/changelog is uploaded and in the queue now.
<mvo> ogra: well, its not the only fix needed :)
<mvo> ogra: and honestly its a bit silly from s-c to mandate that ;)
<ogra> indeed
<ogra> but would be an easy workaround on my side
<mvo> ogra: there is another problem in the code left that I just fixed
<mvo> ogra: so its a good and worthwhile report
<ogra> k :)
<ogra> thanks for the quick fix
<ogra> i'll add testing results to the bug
 * ogra goes to find lunch
<mvo> ogra: I think the currently .eula display is broken too, I check that out now, if you could move that to plain text that would make it easier
<mvo> ogra: after lunch :)
<ogra> mvo, no prob, will do
<ogra> its not a real eula anyway, no ?
<ogra> there wont be a yes/no question i guess
<ogra> (or accept/cancel or how you wanna call it)
<mvo> ogra: yeah, I think we should just name it "info" instead or ".description"
<mvo> ogra: nowdays with s-c there is no need for yes/no anymore, that is legacy from gnome-app-install
<ogra> yup
<ogra> well, there is
<ogra> for TI at least
<ogra> some packages ship third party stuff that requires eula accepting
<ogra> which TI has no control over
<mvo> ogra: aha, ok.
<mvo> ogra: so we keep it as eula and write "if you enable this source you accept the eula"?
<ogra> how does s-c handle debconf questions with eula like java stuff for example ?
<ogra> does anything pop up on a per package basis ?
<mvo> that should work just fine
<persia> Isn't that just the normal debconf frontend?
<ogra> or is it just ignored
<mvo> the gnome frontend will be used during install
<ogra> ah, perfect
<ogra> current TI packages steal preinst from java i belive
<persia> mvo, Always GNOME, or whichever is appropriate?
<ogra> so that should just work ... but i'll clearify if we cant just leave the s-c eula and drop debconf fiddling
<persia> That wouldn't be safe anyway, in case people use other means to enable a channel.
<mvo> persia: gnome iirc, not sure what is up with the qt one these days
<ogra> anyway, lunch
<LBo> Hi
<cjwatson> tkamppeter: thanks
<LBo> I'm not sure if I'm in the right channel but I have a question about the python bindings for libindicate
<LBo> Is it possible to start the server in one process and add messages to that server in another process?
<LBo> With the python binding
<Keybuk> my office has gotten so untidy, I'm starting to think that it would be better to just get a new office
<cjwatson> sounds familiar
<ogra_cmpc> Keybuk, come over to the arm team, our devices are smaller :)
<soren> Quotes page!
<persia> Not necessarily: I have x86 machines that are smaller than some of my arm machines
 * soren misses the Quotes page
<ogra_cmpc> soren, btw, i bought a new blinker :)
<ogra_cmpc> it had a car attached *g*
<Keybuk> ogra_cmpc: it's not devices, it's mostly notes
<ogra_cmpc> next europe uds you dont have to drive scared
<soren> Heheh :) Did you keep the car it came with or was it just a vessel for your new blinker?
<Keybuk> I appear to now be using laptops as bookmarks in notebooks
<ogra_cmpc> soren, didnt fit, so i kept the car too :) http://people.canonical.com/~ogra/car/0180175676001.jpg
<soren> ogra_cmpc: Nice :)
<zyga> where is this magic repo with all the -dbg packages?
 * zyga needs to hunt some crashes
<zyga> pitti, could you please point me to the debug symbol repository?
<persia> ddebs.ubuntu.com ?
<ogra_cmpc> zyga, the debigging wikipage should have it
<persia> Indeed
<ogra_cmpc> *debugging
<ogra_cmpc> i thik there is also a subdir needed
<ogra_cmpc> not only ddebs.ubuntu.com
<persia> Well, sure, but that's enough to analyse archive structure :p
 * zyga could not find any information about this apart from pitti's email from 2007
<persia> !stacktrace
<persia> !debug
<ubottu> For help debugging your program, please see https://wiki.ubuntu.com/DebuggingProcedures
<persia> https://wiki.ubuntu.com/DebuggingProgramCrash
<zyga> persia, thanks!
<persia> !crash
<ubottu> For help debugging your program, please see https://wiki.ubuntu.com/DebuggingProcedures
<persia> bah.  Something shuold point at the right URL :(  I suppose it's not hard to find from the landing page, but...
<zyga> persia, I found a bug in dbus menu and I need symbols to report a proper bug
<persia> zyga, You know about the retracers, right?  That if you're using Ubuntu packages, and you crash, apport will upload the coredump, and the retracers will do the symbol insertion for you?
<zyga> persia, this bug has several duplicates but for each report the retracer failed
<persia> Anyway, for future note, #ubuntu-bugs is great resource for information about debugging, filing good bugs, etc.
<zyga> persia, thanks :-)
<tseliot> pitti: do you know why I can't find linux-restricted-modules-envy-2.6.24 in Hardy?
<alourie> question: who would be the person to talk to about uds.ubuntu.com?
<pitti> zyga: right, what persia said (sorry, was out for lunch)
<zyga> pitti, thanks, I got it now
<pitti> tseliot: it's only in hardy-updates indeed
<pitti> linux-restricted-modules-envy-2.6.24 | 2.6.24.503-503.31 | hardy-updates/multiverse | source
<pitti> tseliot: I don't remember any more, did we introduce that post-release, or was that an abi bump or so?
<tseliot> pitti: that doesn't depend on the ABI as it uses DKMS. Maybe we introduced it post-release
<tseliot> it was some time ago...
<tseliot> pitti: I'm asking as I need to update it now because of LP: #642518
<tseliot> bug #642518
<ubottu> Launchpad bug 642518 in fglrx-installer (Ubuntu Karmic) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,In progress] https://launchpad.net/bugs/642518
<pitti> tseliot: is linux-restricted-modules-envy-2.6.24 the dkms version?
<tseliot> pitti: yep
 * tseliot has to update any fglrx package in hardy, jaunty, karmic and lucid :/
<pitti> ugh, good luck
<tseliot> thanks, I'll need it ;)
<tseliot> smb: BTW I'm working on a patch for Hardy which we'll have to apply to both linux-restricted-modules-envy-2.6.24 and linux-restricted-modules-2.6.24 (which the kernel team maintains)
<tseliot> apw: ^
<smb> tseliot, Ok got that ready already
<tseliot> smb: ah, even better. Will you share the patch?
<smb> tseliot, sure, I'll send you a mail
<cjwatson> you know that your problem has become complicated when you find yourself stracing automake
<tseliot> smb: thanks
<smb> tseliot, Had to modify it slightly as lrm does not make use of make.sh
<tseliot> smb: ah, I'll have to check lrm-envy as I don't remember whether it uses make.sh or not
<smb> tseliot, mail is away. Maybe it works for envy the same
<smb> Should actually not matter that way whether you come from make.sh or not
<tseliot> smb: I hope it does, as I don't really remember how lrm-envy works
<tseliot> yes, as long as you get that flag from somewhere
<smb> Understandable, its so long ago. Had to dig around in lrm as well
 * tseliot nods
<tseliot> smb: BTW have you built lrm with your patch
<tseliot> locally, that is
<smb> tseliot, yes
<tseliot> ok
<tseliot> ah, fix committed in Hardy
<smb> tseliot, test build failed with the change to make.sh. Thats how I noticed it is not used there
<smb> tseliot, Yes and uploaded to proposed now
<tseliot> smb: great
<smb> pitti, Btw, could you accept it?
<smb> pitti, l-r-m for hardy, that is. Its the fix for the fglrx compile failure after the last security upadte
<tseliot> smb: I guess we should request an SRU in the bug report anyway
<smb> true
<smb> tseliot, who? :)
<pitti> smb: looking; takes a bit longer since it was just uploaded (no debdiff yet)
<smb> pitti, Ok, np. It was really just done
<smb> pitti, Seems one of us ( tseliot  or me ) needs to add SRU info to the bug
<pitti> seems fine? tasks look alright
<tseliot> smb: I was planning on doing it as soon as all of my sources are ready. But if you want to do it first, please go ahead
<smb> tseliot, Ok, I'll update the bug and subscribe the sru team
<pitti> smb: hold on, I'm currently wiggling the bug
<pitti> u-sru gets autosubscribed
 * smb holds
<tseliot> smb: perfect, thanks
<pitti> it shoudl be clear, but of course we'll waive the 7 day period for this
<pitti> done
<smb> pitti, great thanks. Yeah it sort of is fixup. Though l-r-m in hardy is probably slightly less critical. It is not recompiled locally. So it would have broken next time we would try to upload it.
<smb> pitti, otoh the security relevant part would still be vulnerable if we do not recompile it...
<kees> assuming fglrx uses it unsafely, that is
<smb> kees, correct as fglrx in lrm was compiled before the securty update it still would use the old implementation
<smb> (as that was an inline)
 * kees nods
<smb> pitti, I assume yes, but done also meant you are done wiggling the bug?
<pitti> smb: right
<smb> ok, just wanted to be sure not to step on some body parts. ;)
<pitti> cjwatson, mdz, kees, Keybuk: TB meeting reminder (3 mins)
<pitti> sabdfl seems to be off today?
<kees> pitti: yup, there's another meeting in there atm
<kees> doko: so, how do I turn on all the CompilerFlags defaults for llvm?
<doko> kees: -O99? no, sorry, don't see what you want ...
<kees> doko: I mean -fstack-protector, -D_FORTIFY_SOURCE etc
<doko> kees: in the JIT, or in clang?
 * kees does not know llvm at all.
<kees> isn't it a C compiler?
<doko> you can use it as a C compiler too
<doko> so llvm-gcc-4.2 should be easy
<doko> clang you'll have to look at
<kees> ah-ha, but the things we use it for are the JIT, not the C compiler? if so, I'll ignore this some more
<doko> the JIT, have fun ...
<kees> heh
<doko> kees: but then, why don't you start modifying hotspot in openjdk first? ;P
<doko> ohh, and llvm-gcc-4.5 should already be done
<doko> if you did gcc-4.5
<kees> I'm not touching JITs yet :)
<maxb> It's quite late in the cycle, and there is still no sun-java6 in the maverick partner repository. Is anyone visual on getting that uploaded in time?
<ogra_ac> there is a maverick-partner already ?
<maxb> Doesn't a partner repository spring into existence at the creation of a new distroseries?
<ogra_ac> yes, like -security, but nobody uploads to them before release usually
<ogra_ac> not sure if partnaer is different in that regard, but i wouldnt expect so
<ogra_ac> since you need a stable release to compile the partner packages against
<ogra_ac> i wouldnt expect partners to be keen to rebuild for every changed dep during a dev cycle
<tseliot> pitti: can you approve the following source packages in -proposed, please? linux-restricted-modules-envy-2.6.24 (in hardy), fglrx-installer (in jaunty, karmic, lucid)
<ogra_ac> mvo, is there any change in update-notifiers behavior in maverick ?
<maxb> Hmm. Well, sun-java6 is a bit of an oddity, as it's actually synced from Debian non-free
<mvo> ogra_ac: no, why?
<ogra_ac> i havent seen it auto-popup since a while
<ogra_ac> even there are updates pending and i ran apt-get update
<ogra_ac> GrueMaster said he doesnt see it on hos x86 netbook either
<ogra_ac> *his
<mvo> ogra_ac: its magic (too much of it) - you can run "update-notifier --debug-update " to see why its not comming up
<ogra_ac> will do
<ogra_ac> mvo, so it looks like it reports the right amounts of packages etc but u-m never pops up
<mvo> ogra_ac: so the logic is that if you upgraded manually in between (apt-get, synaptic etc) it will reset the 7 day counter
<ScottK> ogra_ac: Remember it was decided that not telling you about updates is a good thing.
<ScottK> TheMuso: Ping (re your espeak upload in the queue)
<ogra_ac> ScottK yeah, but it used to pop up if i manually ran apt-get update
<ogra_ac> in lucid at least
<ogra_ac> but if it waits seven days .... well ... shrug
<pitti> tseliot: meeting-o-mania, will do ASAP
<pitti> tseliot: no -envy in https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1 ?
<tseliot> pitti: np ;)
<tseliot> pitti: that's in NEW
<tseliot> unfortunately
<pitti> ??
<tseliot> pitti: [ubuntu/hardy-proposed] linux-restricted-modules-envy-2.6.24 2.6.24.503-503.32 (New)
<tseliot> this is what the email that I received says
<tseliot> pitti: I guess it's perceived as an ABI bump (as in lrm) but there's no ABI here
<tseliot> as I use DKMS
<smb> I though all kernel modules also NEW before finally getting out...
<smb> I was surprised once but then thought I just may have forgotten that feature. Though it seemed strange as the abi had not changed... Maybe a new "feature"
<cjwatson> if you upload any package name, binary or source, which is not currently in the archive, then it will hit NEW
<cjwatson> this one is a little odd
<cjwatson> I suspect that uploads to -proposed don't magically inherit overrides from -updates
<cjwatson> because linux-restricted-modules-envy-2.6.24 is only in hardy-updates, not in hardy
<tseliot> ah
<tkamppeter> pitti, it is about bug 632094 and bug 618017. I have a possible fix. The self-extraction Python script for the PPD archives throughs Tracebacks when simply killing the process, like entering "/usr/lib/cups/driver/openprinting-ppds list | less" end then pressing "q" without scrolling down before. I have a simple fix for that, should I upload it for Maverick?
<ubottu> Launchpad bug 632094 in foomatic-db (Ubuntu) "openprinting-ppds crashed with IOError in main()" [Undecided,New] https://launchpad.net/bugs/632094
<ubottu> Launchpad bug 618017 in foomatic-db (Ubuntu) "openprinting-ppds crashed with IOError in ls()" [Undecided,Incomplete] https://launchpad.net/bugs/618017
<pitti> tseliot: hm, did yuo happen to upload fglrx-installer/karmic twice?
<pitti> tseliot: I just accepted it, but now it's in the queue qgain
<pitti> tseliot: ah, no, you have to reupload
<pitti> FAILED: fglrx-installer (The source fglrx-installer - 2:8.660-0ubuntu5 is already accepted in ubuntu/lucid and you cannot upload the same version within the same distribution
<pitti> tseliot: ^
<tseliot> pitti: I don't think so and I received only 1 email about it
<pitti> tseliot: I'll reject it; please let me know if you have a new upload; use ubuntu4.1?
<tseliot> pitti: oh, I see, I'll do it again in a second
<tseliot> pitti: is it only lucid or shall I do the same for karmic?
<pitti> tseliot: no, it's only karmic
<pitti> tseliot: jaunty and lucid went fine
<pitti> sorry, I already fired the "plz test" mail for karmic
<tseliot> pitti: I misread that message. Ok, I'll reupload karmic's source
<tseliot> pitti: done (it's 4.1 this time)
<tseliot> pitti: ok, it's waiting for approval now
<pitti> tseliot: accepted
<pitti> tseliot: thanks a lot!
<tseliot> pitti: thanks for approving all of those packages ;)
<pitti> np
<tkamppeter> pitti, if you are on approving packages now, can you approve my ghostscript (the newer one, I have fixed a copy'n'paste error in changelog)?
<pitti> will have a look later
<mathiaz> ttx: what's your take on bug 641001?
<ubottu> Launchpad bug 641001 in puppet (Ubuntu Maverick) "cacrl should be use instead of hostcrl when generating apache2 passenger configuration" [Medium,Triaged] https://launchpad.net/bugs/641001
<mathiaz> ttx: should it be included before release or maverick-updates is ok as a 0 day sRU?
<ScottK> mathiaz: My advice is that for things you would SRU, as long as they don't impact the kernel, would be to go ahead (speaking for myself, don't take that as release team approval)
<pitti> +1
<pitti> at least until the RC
<tkamppeter> pitti, can you have a look at bug 618017? It is a rather trivial patch to eliminate annoying Apport pop-ups caused by Python Tracebacks. Should we take it into Maverick?
<ubottu> Launchpad bug 618017 in splix (Ubuntu) "FFE: openprinting-ppds crashed with IOError in ls()" [High,Triaged] https://launchpad.net/bugs/618017
<pitti> simple crash fixes always sound fine
<pitti> tkamppeter: this is not an FFE, btw
<pitti> it's not a feature at all
<tkamppeter> pitti, How is it called then?
<pitti> a bug fix :)
<pitti> there's no particular procedure for those, just upload and wait for a release team member to review the upload/bug
<tkamppeter> FFE removed. pitti, should I prepare and upload the packages?
<pitti> tkamppeter: please do
<pitti> thanks for fixing!
<ttx> mathiaz: I'd say before release
<mathiaz> ttx: I've uploaded the package to maverick
<mathiaz> ttx: we'll see how it goes :)
<mathiaz> ttx: puppet is on the -server isos
<ttx> mathiaz: I'll track it
<mathiaz> ttx: that's why I wasn't sure if it could be uploaded
<ttx> oh, it always can.
<ScottK> TheMuso: unping.
 * nigelb hugs lucidfox :)
 * lucidfox hugs back
<lucidfox> That was a bit random, nigelb :)
<nigelb> lucidfox: More like a bit delayed :)
<nigelb> Thanks for posting the interview :)
<lucidfox> Ah!
<lucidfox> nigelb> I thought it was about my conversion to the evil Kult of the blue K
<nigelb> lucidfox: wait, where is that? scrollback?
<lucidfox> nigelb> Yes, and #kubuntu-devel
 * nigelb will look
<Keybuk> clearly the touchpad support needs some improvement :-/
<fagan> Keybuk: well this is the first relase
<fagan> *release
<Keybuk> first release of?
<fagan> the multitouch stuff
<Keybuk> I'm not using the multitouch stuff
<fagan> damn I really should read stuff right
<fagan> i read touchpad as multitouch
<fagan> :P
<Keybuk> having a few difficulties right-clicking and middle-clicking with the MBP touchpad
<fagan> Keybuk: isnt the MBP touchpad supposed to be getting better now
<Keybuk> yeah, it can right-click by clicking with two fingers
<Keybuk> but you can't, for example, right-click and then move the pointer
<Keybuk> which is kinda necessary to use context menus
<Keybuk> the other main problem seems to be that if you change fingers at all, it stops whatever you're doing
<Keybuk> so if you click and drag an icon, and add another finger because you ran out of touchpad, it drops the icon there and then
<fagan> thats not good
<Keybuk> but hey, just about everything else works
<Keybuk> even the keyboard backlight :p
<fagan> have you tried utouch with it yet
<fagan> ?
 * fagan got scrolling on all 4 fingers with his crappy old laptop touchpad 
<Keybuk> fagan: no, I probably should
<Keybuk> two-finger scrolling actually works on this with the bcm5974 driver
<fagan> Im not even going to bother with the pinch and the other stuff id say
<fagan> but the two three and four fingers work easy on my old computer
<fagan> which I found very strange
<SpamapS> lifeless: you do realize your "how do we package multiple versions of the same lib" question is causing my head to explode, right? ;)
<ion> Hasnât that been done for ages? E.g. libcurl3, libcurl4
<ion> Gtk 1.2, 2.0
<fagan> yeah ion is right
<fagan> there always was a lot of them
<fagan> so developers who dont port their app to the newer version can stay in the repo
<fagan> and in cases like python where we havent moved to 3 yet but we still have it in the repo so people can use it
<SpamapS> ion: compile time/link time checks are easy
<SpamapS> Try building an app on top of say, ruby on rails 2.x right now..
<SpamapS> then ubuntu ships rails 3.0
<SpamapS> and your app implodes
<SpamapS> Or maybe even just a minor release version where the developers inadvertently broke the API in a python module..
<SpamapS> Yes you should fix your app to work with the new API version.. but there's no link time check thats failing because you didn't.
<SpamapS> Its just some random runtime fatal error.
<SpamapS> Unless we find a way to get 100% code coverage unit tests to write themselves, its monumentally harder to test for API compatibility in scripting languages.
<lifeless> SpamapS: its the same answer as for c libraries
<lifeless> SpamapS: forget about perfection, just use the same rules that gems, eggs and jars themselves use.
<lifeless> SpamapS: solved problem
<SpamapS> lifeless: what rules do eggs use?
<SpamapS> I honestly don't know. ;)
<SpamapS> and that just solves the "existence on the system" problem right? you still have to munge your load path to get the ones you want. Don't you?
<lifeless> setuptools knows how to do it
<lifeless> .pth files
<lifeless> bbiab
<SpamapS> .pth appends
<SpamapS> I know that ruby has solved this quite well with rvm http://rvm.beginrescueend.com/
<ion> Yeah, a decent deployment system basically takes a snapshot of all the dependencies and pushes that along with an app release to production, assuming youâve tested the combination first.
<SpamapS> rubygems actually has it doable in code
<SpamapS> you can say    gem 'libFoo', '> 3.0'
<lifeless> SpamapS: 'Require'
<ScottK> Which works great until libFoo does something incompatible in 3.1 that got released yesterday.
<lifeless> from pkg_resources import require; require("foo==3.0.0")
<lifeless> ScottK: the newer-versions-break-stuff isn't limited to ABI changes in C libraries though
<lifeless> simple behaviour things can do it, so thats not unique to python
<lifeless> and the fix is the same: upload again with a capped version range
<SpamapS> lifeless: so analogous to the way rubygems is doing it.
<lifeless> SpamapS: yes
<SpamapS> lifeless: given that, it would actually be better to embrace rubygems/pypi/cpan than try to fold them into .deb wouldn't it?
<lifeless> SpamapS: that is why I said 'upstream' in my mail :)
<lifeless> SpamapS: but I think the deb wrapping has a lot of value:
<lifeless>  - we've tested combinations
<lifeless>  - no worries about MITM attacks and can use the apt toolchain to get what you need mirrored in advance etc
<SpamapS> lifeless: and licensing, and other things too...
<mathiaz> SpamapS: IMO we should embrace upstream tools
<SpamapS> mathiaz: agreed 100%
<mathiaz> SpamapS: and make sure they don't break apt/dpkg.
<mathiaz> SpamapS: IMO it's unreasonable to try to package everything in the world
<SpamapS> even a bad idea
<SpamapS> we're talking python, but I'd like to consider java for a moment
<SpamapS> mathiaz: so for Hadoop/cassandra, they need lots of libs from maven/ivy/etc...
<mathiaz> SpamapS: right
<SpamapS> mathiaz: but we'd like to make sure they are licensed correctly, working, etc.
<SpamapS> seems like the upstream tools aren't going to help us do that.
<mathiaz> SpamapS: and the versin of the libs are different for every one of them
<mathiaz> SpamapS: I think one of the first step is to decide whether we'd allow to have multiple version of the same library in the archive
<lifeless> I think we should embrace upstream tools - yes. But that can mean many things.
<lifeless> For me, I think we want to write thunks for them so that:
<lifeless>  - they can request dependencies (even at runtime) from the package manager.
<SpamapS> mathiaz: Yes, we should allow multiple versions. No we should not allow unlimited versions. ;)
<lifeless>  - we find a way such that we can represent enough of the magical complexity that they have, to work well.
<mathiaz> SpamapS: right - IIUC in the java world that would actually be the case
<SpamapS> lifeless: for scripting languages, its all runtime. ;)
<lifeless> I'm thinking the dbus service that installs packages, sort of thing.
<mathiaz> SpamapS: one version of a library per application
<lifeless> mathiaz: that would be too restrictive for some java stuff.
<lifeless> (sadly)
<SpamapS> lifeless: how do you authorize a runtime program for installing things though? that seems rather haphazard at first glance.
<mathiaz> lifeless: some application could have 2.0.1 and 2.1.2 of the same jar?
<lifeless> mathiaz: yes
<lifeless> SpamapS: theres an existing service for it
<lifeless> SpamapS: on the buildds we could just have it say 'true'
<lifeless> SpamapS: packagekit
<mathiaz> SpamapS: I'm not sure I get your use case?
<mathiaz> SpamapS: dependencies can be sorted at package build time?
<lifeless> mathiaz: OSGI
<mathiaz> SpamapS: or when an application is installed (via gem, maven, etc..)
<lifeless> mathiaz: you can't actually sensibly ask maven to predict all the deps in advance
<lifeless> mathiaz: because its got a complex minilanguage; better to make the callbacks /work/.
<mathiaz> lifeless: agreed
<lifeless> and if something is needed that isn't packaged, error, and then we package it etc.
 * mathiaz nods
<mathiaz> IMO we should provide a maven repo available from the buildd networks
<mathiaz> and populate the maven repo on a per need basis
<SpamapS> well with maven thats at least doable at build time
<SpamapS> I feel though that the same solutions for maven/java will not work for scripting languages
<mathiaz> well - populating the maven repo == packaging them correctly in apt
<lifeless> mathiaz: thats roughly what I'm saying
<SpamapS> tell the buildd to install on runtime need. Then run the unit tests. Without code coverage, we miss deps.
<lifeless> mathiaz: except inject a deb-backed maven repo implementation
<mathiaz> lifeless: right - and having a pseudo maven service that answers if the version of the dep is already packaged
<lifeless> mathiaz: so there isn't a 'regular' maven repo at all.
 * mathiaz nods
<lifeless> just a maven-repo that talks to apt; and apt can handle N versions of a library to handle things like (e.g.) hudson
<lifeless> or atlassian stuff, etc
<lifeless> etc
<lifeless> et
<lifeless> c
<SpamapS> lifeless: so rather than using the local mode that maven-debian-helper uses, you'd have a maven backend that helps resolve things?
<lifeless> SpamapS: right, maven-debian-helper is broken by design
<mathiaz> SpamapS: the backend could also help to create the build dependency
<mathiaz> SpamapS: what does maven-debian-helper actually do?
<SpamapS> well in this case.. really all we're talking about is building our own limited maven repository.. doesn't need to be special at all... we just have to apply our packaging policies to the bits in the maven repository
<SpamapS> and the same would work for pypi/gems/cpan/pear/etc.
<SpamapS> and be a lot easier than trying to .deb them all
<mathiaz> SpamapS: well - the output would always to be driven by .deb
<mathiaz> IIUC the problem is in building the dependencies - right?
<SpamapS> mathiaz: maven-debian-helper puts a java library in a local repository with a special version "debian" and then tries to muck with the spec file of other things to not require a specific version, but rather to require the version "debian"
<mathiaz> if the dependencies are all packaged, the correct depends can be generated?
<lifeless> SpamapS: I wasn't proposing a maven repo; rather a maven 'repo implementation'
<mathiaz> lifeless: that maven pseudo-repo would be used by buildd?
<SpamapS> mathiaz: No, I'm saying it would be far easier to simply approve/disapprove syncs into a maven repository than to try and make .debs for everything.
<mathiaz> lifeless: or ubuntu developers to figure out what needs to be packaged?
<SpamapS> I mean.. big picture thinking here..
<SpamapS> we already do this for *debian* -> *ubuntu* .. why not *maven* -> *ubuntu-maven* ?
<lifeless> mathiaz: uh, 'an adapter from the maven object api to apt'. Is what I'm proposing.
<SpamapS> the goal is to be able to repeat builds, sustain support, etc. right?
<mathiaz> SpamapS: yeah - the problem then is about ubuntu licensing policies
<lifeless> SpamapS: licence metadata perhaps?
<mathiaz> SpamapS: yeah - and maven repo is a binary repo IIUC
<SpamapS> I'd bet money on maven repositories being built in a way to be extensible.
<lifeless> SpamapS: I'd be happiest with a (source jar)->deb machine
<mathiaz> SpamapS: sources for every version are not necessarly available
<SpamapS> True, maven isn't a source repo, which kills that idea. ;)
<lifeless> SpamapS: I'll take your money; jars are extensible but at that point why not just reflect it straight int oapt.
<lifeless> SpamapS: maven is both binary and source.
<lifeless> foo-1.2-source.jar and foo-1.2.jar
<mathiaz> lifeless: are *all* sources available for each binary in the maven repo?
<SpamapS> Those sources are often very tricky to build again into the same binary
<mathiaz> lifeless: I thought binary jars could be uploaded to maven without their source
<SpamapS> http://mvnrepository.com/artifact/org.apache.hadoop/avro/1.3.3
<SpamapS> no source
<ScottK> lifeless: Of course not.  I guess my point is that providing a versioning capability is one thing, but developers still have to be willing to keep API/ABI compatibility or increment the version.  IME there's only a limited amount of discipline for that in the Python world and ~none in the Ruby/RoR world.
#ubuntu-devel 2010-09-22
<ScottK> Ultimately some kind of software engineering discipline is required.  Let's figure out how to have infinite variants of all libraries interact with each other is a recipe for insanity.
<SpamapS> ScottK: We all agree on that. We are trying to deal with exactly that lack of discipline by providing the ability to assemble multiple versions of Ubuntu/Debian packaged software for a single application's expectations.
<ScottK> SpamapS: I think that's the wrong solution.
<SpamapS> its pretty much the way the web is developed these days.
<SpamapS> sane or not
<lifeless> SpamapS: folk can choose to publish source or not
<ScottK> I think it's reasonable for developers to be able to layer cpan/pypy/maven/gems/etc on top of the distro, but I think can't make that part of the distro.
<lifeless> some upstreams are insane, and need to be helped to learn about open *SOURCE*
<SpamapS> You're saying if 99% of zope is good, but 1% of it breaks its API in the next release of Ubuntu, people who are relying on said API should ... not use zope?
<lifeless> ScottK: I think that we've segued.
<ScottK> OK.
<lifeless> ScottK: I'm not talking about mass important pypi
<lifeless> or maven.org
<SpamapS> I do see Scott's point though. That we're facilitating API madness.
 * ScottK was in transit for a while.
<lifeless> ScottK: I'm talking about removing the *technical limitation* that prevents coinstalling incompatible versions of a dependency shared by either (other packages) or (user installed software)
<ScottK> Yes.  Please don't do that.
<ScottK> lifeless: If packages are packaged for co-installation that's not a problem.  People just have to be convinced it's worth the trouble.  See the postgresql packaging for a excellent example of how to do it.
<lifeless> ScottK: right now for C/C++/CLR packages we support this by putting the soname in the library package, and making clients of the library depend on the libraryname-soname package, with some minimum version specified
<ScottK> (I know you know that)
<lifeless> ScottK: ack
<lifeless> ScottK: so the thing is that neither the java nor python packaging policies cater for this.
<ScottK> True, but we also normally only ship one version in a final release unless there are multiple source packages.
<lifeless> ScottK: *and* we need some sensible upstream support/blessing for making 'get the newest $soname-like thing' for the more dynamic (python and ruby specifically) languages.
<ScottK> lifeless: Actually what we're trying to do with separate binary packages for Python 3 is a form of this.
<lifeless> ScottK: cool; I have to admit I haven't looked really closely at that.
<lifeless> ScottK: did you see my use case on the debian-python list?
<ScottK> lifeless: I did, but I confess I only skimmed it.
<lifeless> ScottK: fair enough
<lifeless> very briefly, the scenario is to be able to have two versions of launchpad installed on a machine, (which commonly requires two different releases of (say) zope.publication)
<lifeless> this is orthogonal to whether launchpad itself would be a package.
<lifeless> ScottK: re: different source packages & binary packages - I would expect different source packages in this scenario
<lifeless> ScottK: all the discussion about maven and pypi glue for finding stuff is simply saying: if we can support a richer set of $language packages, then we can -more easily- do the following things:
<lifeless> (in no particular order)
<lifeless>  - have packages that build with easy_install and the like be fenced off from the internet and get their requirements from apt
<lifeless>  - when a user is using easy_install, have it preferentially find versions from apt
<lifeless> (for java s/easy_install/maven/, etc)
<lifeless> I'd personally still expect to be looking at a deb source package and putting license metadata into place - perhaps assisteded by some automation, but such automation is also orthogonal
<ScottK> In the world of cheap VMs isn't this a bit overenginieered?
<ScottK> lifeless: Why not just run a separate VM for each one and don't worry about conflicts?
<lifeless> ScottK: for a developer doing development, who has the same issues, vms are not at all that cheap.
<lifeless> ScottK: one could say the same thing about having libgettext4 and libgettext5 installed - just use a vm fo rthe programs that need the old/new thing.
<ScottK> OK.
<SpamapS> Basically, just allow debian packagers to produce binary packages that play in upstream packaging space.
<SpamapS> if pypi has a way to do version requirements, allow a .deb to satisfy that...
<ScottK> SpamapS: I agree with that.
<ScottK> Isn't that (at least sort of) what our patched easy_install does now?
<lifeless> ScottK: two key missing points:
<lifeless>  - packagekit integration to get extra requirements on the fly
<lifeless>  - packaging policy change to put the version number (or as many significant bits as we choose) in the package name.
<ScottK> packagekit is pretty broken with respect to Debian packages anyway.
<lifeless> sadly :(
<ScottK> In order for Kpackagekit to know if it needs extra packages, it actually has to attempt a simulated install and see the results (or something close to that)
<lifeless> so the idea though, of user space code being able to say "I need this library, please, now" is useful but not strictly needed.
<SpamapS> lifeless: or you could package your app, and the requirement would be resolved at install time.
<lifeless> SpamapS: that doesn't help with runtime determined dependencies
<lifeless> SpamapS: doesn't help *us* the *packagers*
<SpamapS> lifeless: ok, my brain's full.. will need to process this a bit to feel good about it. :)
<ScottK> SpamapS: I think run time dependency discovery is not a great idea.  Imagine a web page waiting for a new library to install before it can render.
<lifeless> ScottK: by runtime I'm primarily thinking about build chains that do runtime determination
<lifeless> ScottK: not after-packagin runtime dependencies
<ScottK> Ah.  OK.
<ScottK> That's a bit different.
<ScottK> POX has done some stuff kind around that idea in dh_python2/3.
<persia> Probably nice to split the problem space: have one thing that tries to determine what is missing.  Have an entirely different thing that tries to address this perceived lack.
<persia> The first is hugely useful for packagers.  The latter is potentially useful for someone.
<persia> If the output of the first is compatible to the input of the second, folk share.
<ScottK> Step 0 though is upstreams that are willing to maintain API/ABI compatbility or document when they change.
<lifeless> ScottK: I don't really see that as hugely important; we can do what we did with e.g. libcamel for upstreams that don't.
<lifeless> ScottK: its nice then they do, but we don'tneed it.
<persia> There's vast potential to improve the interface for upstreams to be able to do so easily.  Some languages don't even have a convention available to indicate a version.
<ScottK> Just use releases as API/ABI surrogates?
<lifeless> sure
<persia> That said, I've found it a rare upstream that isn't willing to track API/ABI, assuming they can be shown how to do so.
<ajmitch> as long as upstreams know how to
<ajmitch> instead of doing things like bumping SONAME for every upstream release, or the equivalent
<persia> Right, hence the importance of making better tools available, or *any* tools/convention for things like Java.
<lifeless> and we're back to changing the packaging policy to encode more data ;)
<ajmitch> yeah, we had this debate yesterday in #debian-cli :)
<ScottK> lifeless: I'd start with an upstream concept and see how to extend it.
<ScottK> For example, what do Python eggs not have that we need?
<ScottK> Or if they have it, how do we exploit it?
<lifeless> ScottK: thats where I started
<lifeless> ScottK: pkg_resources.require, which is a setuptools (not distutils) thing, supports versioning of dependencies
<lifeless> if we say (reasonably so) that you should use that if you need versioned depends, then the upstream angle is taken vare of
<ScottK> lifeless: I'd talk to POX about what he's already doing to automatically generate versioned depends in dh_python.
<ScottK> {2,3}
<lifeless> where does he hang ou?
<persia> And we can use that to populate autodependencies (${Python:Depends} in this case)
<lifeless> persia: sure, but that is orthogonal to the problem I want to solve
<ScottK> lifeless: #debian-python on OFTC is best, but #ubuntu-motu also often works.  He's in .pl, so likely sleeping.
<persia> lifeless, I'm thinking about "by runtime I'm primarily thinking about build chains that do runtime determination".  Why would the build-chain output not want to auto-generate package dependencies?  end-user-runtime differs.
<lifeless> persia: I think it would nice to do so.
<lifeless> persia: I'm saying that that is a separate benefit to being able to even *build* such things more easily.
<persia> You want build-time installation of build-deps?
<lifeless> persia: and to being able to *install* concurrent versions
<lifeless> persia: yes, its a key thing for both maven and easy_install chains; its not -mandatory- but we can save a lot of packager headache if we do it well
<persia> Concurrent installation isn't hard, if one packages it in a namespace-safe manner.  That said, having been involved with the pain that was maven, I'm convinced the idea of build-time install of build-deps is misguided at best, and potentially actively harmful.
<persia> We have a solution for maven.
<lifeless> persia: hah. no, we don't.
<persia> Have had it for > 1 year.
<lifeless> doesn't scale, doesn't handle enough cases.
<persia> doesn't scale how?
<persia> What cases doesn't it handle?
<persia> Show me bugs, or explain yourself :)
<lifeless> it doesn't handle the concurrent-deps case
<lifeless> OSGI apps for instance
<persia> Does if the package of the dep is concurrent-install safe.
<persia> That we choose not to do that much is a different thing :)
<ScottK> No policy changes are needed to do so, just will to do the work.
<lifeless> persia: they aren't orthogonal; the maven helper whose code I saw doesn't understand concurrent installs
<lifeless> ScottK: in which case it will be easy.
<ldunn> Hi, I'm looking at https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/644015, and in debian/rules, there's the following line: ifneq (,$(findstring test,$(DEB_BUILD_OPTIONS)))
<ldunn> . I'm guessing that's to disable testing?
<ubottu> Launchpad bug 644015 in bzr (Ubuntu) "bzr package build should run the test suite" [Undecided,New]
<ldunn> If so, changing 'ifneq' to 'ifeq' should enable it, right?
<lifeless> hey, I'm not trying to make this it a Big Thing. Last I checked though, bother the java and python policy specified *how* packages were named, and didn't provide an abi-or-equivalent field.
<persia> lifeless, It's been a while since I looked, but my memory was that concurrency was experessed by installing two different packages (versioned), which provided two different .pom files, which maven happily processed.
<persia> lifeless, Dunno much about python, but for Java, nthykier and mjj29 have been working on that for some time.
<persia> Won't hit policy until there's a healthy bundle of stuff in the archive, and very unlikely to go pre-squeeze-release because of the RC load that level of policy violation would create (RT would kill folk)
<lifeless> ok, java policy has been updated
<lifeless> Some package must also provide a symbolic link from... <- a bit fragile for upgrades, still.
<lifeless> however http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html is still no-allowance-for-concurrent
<ajmitch> with the cli policy, libraries are installed into a versioned directory & can be requested by version, because they contain the version information within them
<persia> lifeless, Java policy is still work-in-progress :)  For python policy, definitely talk to POX before trying to invent something.
<lifeless> persia: I hear you
<lifeless> persia: I sent mail to barry/spamaps/jos precisely because I don't have time to invent something... but I want to benefit from it ;)
<persia> Then they ought go talk to debian-python :)
<ScottK> Which is where barry started.
<persia> Excellent.  Why are we talking about it here then?  It's an interesting discussion, but I'm now confused.
<ScottK> Not sure, but that's only the Python bits of this anyway.
<lifeless> persia: because SpamapS told me his head was exploding.
<lifeless> persia: and then we started over 3 times as new people weighed in
 * persia gives SpamapS a exceedingly strong head restraint, for preservation of skull
<persia> lifeless, I didn't see that much repetition in the restarts, but maybe I didn't read closely enough.
<jiboumans> lifeless: fwiw, i understand what you want to achieve. there's a similar problem in perl (except require foo 2.3 works). this does seem like an issue for python/debian-python though that we might support, not one we can likely drive =/
<lifeless> jiboumans: oh hai :P
<ScottK> It's going to take someone that wants it enough to champion it.
 * jiboumans omnipresent
<lifeless> jiboumans: I'm looking in the long term
<jiboumans> lifeless: not being a python expert, is there a 'proper' python way to do it now if i were installing from source/github?
<lifeless> jiboumans: I'm happy to help organise etc, I don't think I can put in lots of time.
<lifeless> jiboumans: pkg_resources.require, part of the setuptools (now distribute) stack.
 * ScottK calls on the spirit of barry to cover all things Pythonic.
<persia> jiboumans, eggs are about as close as you'll find for that sort of thing, and the cheeseshop is a better example than github for use.
<lifeless> which is in equal parts reviled and adored all the Python worlds.
<jiboumans> persia: i... failed to parse that.. eggs? cheese?
<jiboumans> lifeless: what i'm getting at is that if there's a best practice, we can probably integrate and codify it
<jiboumans> or at least give it a shot
<persia> jiboumans, Uhhh : python things to help folk shop for code?  Ask someone who doesn't run and hide when confronted with pythong.
<lifeless> jiboumans: yes, thats what it is
<lifeless> jiboumans: the 'it all works easily stuff' is built on:
<lifeless>  - distribute (new shiny)
<lifeless>  - eggs
<lifeless> they have an ongoing discussion about metadata
<jiboumans> heh
<lifeless> but the critical bit is that in a app/library you say
<lifeless> require('foo==1.3.2')
<lifeless> import foo
<jiboumans> i've been through this with perl, i have a vague idea of the space :)
<lifeless> and you either get an error, or foo 1.3.2
<lifeless> require('foo>=1.3.2')
<lifeless> import foo
<lifeless> and you might get foo 1.4
<jiboumans> lifeless: right, so now we have to make sure you can install foo 1.3.2 and foo 1.3.3 at the same time and life is good
<lifeless> jiboumans: exactly
<lifeless> jiboumans: which requires two things:
<lifeless>  - disk layout
<lifeless>  - a symlink or something so that a trivial script that just does
<lifeless> 'import foo
<lifeless> '
<lifeless> will pickup the latest shiny.
<lifeless> (or most stable shiny, whatever - policy not mechanism)
<jiboumans> right.. alternatives can do that
<jiboumans> we'd want debian to adopt that though, or we'd carry a nasty delta
<lifeless> alternatives, a meta package (supplying the symlink and current 'best' dependency)
<persia> Rather, we'd want to inherit the solution from Debian, although some of us may participate in it's creation.
<lifeless> pysupport could put the link in place
<lifeless> it is, in principle, very simple
<jiboumans> SMOP ;)
<lifeless> hah, perl 6 you say?
<jiboumans> smop!
<persia> jiboumans, More than that, programming + working with all the people who need to use the feature to make sure they adopt it as the one-true-way.
<jiboumans> and mind you, there's a release of perl 6 ;)
<jiboumans> persia: *nods*
<jiboumans> intuitively it feels like debian is the place where this would happen though and we'd follow, even as you said we'd participate in the creation
<jiboumans> the 'we' there is not very likely my team though given our goals
<persia> Yep.  We tried the other way once (dh_iconcache) and it only made it harder to reach the correct final state.
<jiboumans> (the latter we, who'd create it ;)... damn it's getting late
<jiboumans> food calls &
<ldunn> Hmm. So, bzr tests are running, and the fails so far have been unicode encoding errors. Can these be safely ignored?
<persia> No.
<ldunn> â¦ok then.
<persia> Lots of folk use Ubuntu in places where non-unicode is unreadable confusing garbage.
<persia> Do they fail only on the buildds or also run locally?
<lifeless> possible a stable build-dep on testtools 0.9.6
<persia> I think the buildds default to C as a locale, which complicates things.
<lifeless> persia: we turn off relevant test sfor that case
<ldunn> Oh? Hm. I'm just running it in pbuilder at the moment. I'm new to this :)
<lifeless> persia: but yes, it could be related
<persia> lifeless, OK.  That's safe then.
<lifeless> ldunn: you might like to chat to maxb
 * persia hasn't ever seen unicode work right when LANG=C
<ldunn> alrighty
 * ldunn sits around, waits for tests to finish
 * ScottK is sitting around waiting for builds to start.
<bdrung_> ScottK: for what build?
<ScottK> bdrung_: PPA uploads of the new clamav release for Lucid, Karmic, Jaunty, Hardy, and Dapper.
<ldunn> ... bzr build failed. >:(
<mathiaz> persia: hi!
<mathiaz> persia: is there a standard way to find the current JAVA_HOME?
<persia> mathiaz, In what context?
<MarkDude> So is there a better more up to date source for info on app submission process then : https://wiki.ubuntu.com/PostReleaseApps/Process -- I need info for a session at Code Camp
<mathiaz> persia: https://issues.cloudera.org/browse/DISTRO-2
<mathiaz> persia: ^^ trying to support building with default-jdk *and* sun-java-jdk
<mathiaz> persia: depending on which one is installed
<mathiaz> persia: JAVA_HOME will be different IIUC
<persia> MarkDude, That's about as close as it gets.  Note that under current semantics that submits applications to something that isn't Ubuntu, but dependent on Ubuntu.
<mathiaz> persia: it seems that /usr/lib/jvm/default-java/ won't point to the sun-jdk if installed
<persia> Yes, JAVA_HOME would differ.  Why would you want to support building with sun-jdk?
<mathiaz> persia: because that's what upstream strongly recommends
<MarkDude> ok persia  - and the important thing for me to stress would be that; the process is *still fluid*. Also that the process is *open* and public - correct?
<persia> Right, looking at recent discussions, it seems we're trying to move away from any expectation or dependence on JAVA_HOME
<persia> MarkDude, Could you explain more about the topic and audience?  I may be able to provide more targeted advice.
<MarkDude> It will be primarily an MS crowd
<MarkDude> not all tho
<MarkDude> Silverlight, etc and Iphone
<MarkDude> But some Android devs also
<persia> Yeah, that's probably best for now.  There are other processes (also still fluid) that would be more appropriate for people working on primary system applications, but if you're talking to a bundle of folk who just want to have some little bit, they can use that.
<persia> Note that if their work is interesting, it might make sense to incorporate that as a system application, but that's a more complicated message than is easy to put across in a short time (plus, making it a system application creates an expectation of ongoing maintenance, etc.)
<MarkDude> Cool. ty. I might come back in a week or so to see if I could get some nice person to glance at my notes :)
<MarkDude> That would make sense- but I would use that info after - when talking to a specific person
<MarkDude> Thank you developers, you folks ROCK!
<persia> mathiaz, I've just reviewed the current draft of what will become Java policy, and it specifically fails to mention JAVA_HOME, as most stuff is packaged to not require this.
<persia> mathiaz, My recommendation for the upstream solution would be to check for the JAVA_HOME environment variable, and if not set, use the regular Ubuntu way to build stuff.  If set, use it.
<persia> mathiaz, For extra points, remind upstream of the upcoming EOL date for sun-java, and that even Oracle primarily extends openjdk these days.
<mathiaz> persia: yop - that's what I'm saying to upstream
<mathiaz> persia: it seems that they're running into issues when using openjdk
<mathiaz> persia: I'll look at the debian/rules again
<mathiaz> persia: thanks again for your input on JAVA_HOME
<persia> OpenJDK isn't bug free :)  That said, when issues are encountered, upstream is usually happy to get patches.
<persia> Sorry I didn't have more useful news.  JAVA_HOME was all the rage some time back.
<ldunn> Blugh. I'm lost with these tests
<spiv> ldunn: for the bzr package?
<ldunn> yeah
<spiv> Pastebin the failures?
<ldunn> Err. They're going way past my scrollback in gnome-terminal. Does pbuilder keep logs somewhere?
<spiv> I don't know, sorry.  (But I am a bzr dev, so I may be able to help with the bzr test failures)
<ldunn> Hm, well there were 16 failures, I think about 5 were related to unicode errors, and a few were broken pipes with the HTTP server
 * ldunn re-runs pbuilder and collects failures as they come
<ldunn> heh, I'm not going to be able to catch all of them
<ldunn> http://ubuntu.pastebin.com/tYxTJ9i8 spiv, that's more or less what's come up so far, up to ~2500/25000
<spiv> It's not possible to redirect the output with > or tee?
<ldunn> uh. Let me check
<ldunn> there we go.
<persia> pbuilder *does* make logs (although I don't use it, so don't know where).  Check the docs, and save yourself hassles.
<ldunn> bah, --logfile. :D
<ldunn> ... ok, so... that... didn't really seem to work.
<ldunn> Unless it doesn't store the log in the pwd
<ldunn> In which case... here's a few more failures http://ubuntu.pastebin.com/ZgxFLrBn
<ScottK> ldunn: You need to do --logfile [path to logfile from pwd including name]
<ScottK> i.e. --logfile log
<ldunn> That's what I have
<ldunn> sudo pbuilder build bzr_2.2.0-1ubuntu1.dsc --logfile pbuilder.log
<ScottK> Needs to go after build and before the .dsc
<ScottK> pbuilder doesn't look after the .dsc
<ldunn> ... oh!
<ldunn> *that's* more like it. Thanks :)
 * ldunn waits another half hour
<ScottK> You're welcome.
<hyperair> ldunn: you might like to try sbuild, it works much faster ;-)
<hyperair> especially those aufs + tmpfs builds
<ldunn> oh? I'll investigate
<hyperair> ;-)
<nigelb> james_w: ahoy there! You're doing package training on Thursday - just a reminder :)
<ldunn[laptop]> Ok! Finally. http://pastebin.com/kVa8N0Pa
<ldunn[laptop]> 5750 lines... o.o
<persia> ldunn, Yep, but only the test failures are interesting: most of the rest is just context.
<ldunn[laptop]> Yeah
<ldunn[laptop]> I figured I may as well paste it all in case there's some other info that might help
<persia> from the looks of it, the tests store test logs somewhere: is the dirty build environment still available?  There may be files of interest there.
<ldunn[laptop]> It seems like pbuilder removes the environment. "I: removing directory /var/cache/pbuilder/build//2021 and its subdirectories"
 * ldunn[laptop] pokes the manpage a bit more
<persia> There's some argument that preserves it (again, I have no idea which)
<persia> If there's no way to preserve it, that's a bug in pbuilder
<ldunn[laptop]> yeah
<persia> It's also worth inspecting the test source: lots of times it's possible to figure out the issue from the way the test fails and the test source.
<spiv> persia: bzr includes the log entries with the failures
<persia> spiv, Those little 4-5 line bits are the entirely of the test failure output?
<spiv> Yes, although some are much longer!
<spiv> See e.g. the log starting at line 4092
<persia> Tracebacks are interesting, but I have to admit, I really appreciate exception handlers that try to explain what went wrong for test failures.
<spiv> Yes, me too :)
<spiv> Some tests are much better than others at that...
<persia> It's always the case.  It's easy to mandate that folk write tests when committing code.  It's much harder to convince folk that their tests need to fail in a helpful manner without accusations of recursive TDD
<ldunn[laptop]> So, I guess some of these tests are failing because the pbuilder env isn't set up for unicode?
<persia> ldunn, To put that another way, perhaps the tests are making unwarranted assumptions about the environment in which they are run.
<spiv> Well, bzr's test suite is supposed to cope with LANG=C.
<ldunn[laptop]> hmmm.
<spiv> (By skipping tests, if necessary)
<ldunn[laptop]> It skipped 246 unicode-related tests, apparently
<persia> Mind you, skipping tests isn't usually the best way to get around stuff, as it might defeat the point of the tests running during the build :)
<ldunn[laptop]> This is true.
<persia> Another option would be to adjust build-depends, force LANG=${something-else}, and then run the tests.
<persia> Either way, looks like a bug in the test suite (the test should have been skipped if it depended on LANG != C )
<ldunn[laptop]> Hm. :/
<spiv> That said, at least the bzrlib.tests.blackbox.test_alias.TestAlias.test_unicode_alias failure is reproducible with LANG=C
<spiv> So it appears our test suite has some bugs here :/
<ldunn[laptop]> So, at the moment, the test suite probably shouldn't be enabled on this package?
 * spiv kicks off a local test run
<spiv> At the moment, yes :(
<spiv> Please attach that log to the relevant bug, if you haven't already.
<ldunn[laptop]> I haven't, I'll do that
<persia> ldunn, Based on the meeting last night, I believe the test suite is required to be enabled on that package.
<spiv> I'll see how easy it is to fix these failures, it's probably not hard.
<persia> new microrelease coming up ? :)
<spiv> If LANG=C is the only cause, a reasonable workaround may be to set it to something else (and cause more tests to run too, as an added benefit)
<persia> (might wait until the test suite passes in a buildd environment before placing the final tag)
<spiv> *nod*
<spiv> Hmm, I notice python-paramiko isn't installed in that environment... that's good, paramiko has a bug that causes a test failure ;)
<spiv> (I've submitted a patch to upstream and to the bug for the ubuntu package, but no response yet)
<persia> That's part of why we use the specialised environment: we can control what packages are installed there (save a certain minimal set, but anything that doesn't work with those is probably suspect anyway)
<spiv> Right.
<spiv> In an ideal world, perhaps the package build would manage to run the test suite twice: once with the minimal dependencies, and once with all the Recommends and Suggests as well.
<spiv> But I expect that would be pretty tricky to do.
<persia> spiv, Requires turning on (limited) network access mid-build, which then permits packages to significantly vary behaviour based on contents of internet sources, which permits a number of interesting avenues to enable running arbitrary code on arbitrary machines.  That said, a responsible upstream wanting to make sure their testsuite runs under adverse conditions can always add all sorts of random things to build-depends to test it.
<spiv> Well, we already have http://babune.ladeuil.net:24842/
<spiv> Which currently exercises our trunk on a variety of platforms
<ldunn[laptop]> I note it failed on maverick :P
<spiv> (In addition to merges to trunk and the stable branches having to go through PQM, which runs 'make check')
<persia> That's probably the right place to exercise it in a variety of environments on each platform then.
 * persia has a 5 line patch that passes "make check" and causes complete system failure for all users
<spiv> ldunn[laptop]: failed to fetch the code due to a config issue:
<spiv> http://babune.ladeuil.net:24842/job/selftest-maverick/lastFailedBuild/console
<ldunn[laptop]> oh. Alright, heh
<ldunn[laptop]> Ah, so I see.
<spiv> persia: Me too, how about we apply it to the packaging? ;)
<persia> Please no :)
<persia> I think that fails the intent of the request to run the test suite, even if it satisfies the letter.
<spiv> Right.
<pitti> Good morning
<Keybuk> Morrrrrning
<ldunn> moin
<pitti> hey Keybuk
<Keybuk> morning pitti
<Keybuk> Right, time to get the day started; it's Emacs time, baby, yeah!
<ldunn> M-x start-day
<pitti> emacs kills IRC clients!!
<pitti> that's why vim is better!!11!
<ldunn> :k irc
<ldunn> Or something.
<pitti> tkamppeter: I reject your "ignore every error" uploads; this is a way too big hammer (and a wrong one, too) to fix this crash
<pitti> tseliot: can you please upload fglrx-installer for maverick as well?
<tseliot> pitti: yes, now I can, however it was broken in maverick because it wasn't compatible with the new X (not only because of the security fix)
<pitti> tseliot: ah, right; we disabled it in jockey, didn't we?
<pitti> tseliot: so, not urgent then
<tseliot> pitti: yep, I'll revert that change when the driver is ready
<pitti> ara: nice work on qa.u.c.!
<ara> pitti, thanks :)
<apw> pitti, are we making work items db for natty yet ?
<pitti> apw: we don't
<apw> pitti, any idea when we're going to ?
<pitti> I guess I should finally move the stuff from ~pitti to ~platform :)
<ttx> hmm, looks like there is an issue with the recent apache2 security update
<ttx> Three reports of bug 644853
<ubottu> Launchpad bug 644853 in apache2 (Ubuntu) "apache2.2-common 2.2.14-5ubuntu8.2 failed to install/upgrade: Module reqtimeout does not exist!" [High,Confirmed] https://launchpad.net/bugs/644853
<ttx> !regression-alert ^^
<ttx> !regression-alert
<ubottu> cjwatson, jdong, pitti, slangasek, ScottK, mdz, kees, ttx, marjo, seb128: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<ttx> mdeslaur: ^
<ttx> hm, strange
<pitti> weird, did that change in the packaging?
<ttx> pitti: not in the security update... I suspect a more general upgrade issue introduced in a past update
<pitti> http://launchpadlibrarian.net/53953428/apache2_2.2.14-5ubuntu8.1_2.2.14-5ubuntu8.2.diff.gz looks really strange, though
<ttx> yes
 * ttx checks out branch
<ttx> beh, no lucid-updates branch
<soren> That debdiff is wrong. There were actual changes in the upload.
<soren> None that should cause this, though.
<soren> I found these two, though:
<soren> https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/576255
<ubottu> Launchpad bug 576255 in apache2 (Ubuntu) "can't install apache2.2-common (2.2.14-5ubuntu8)" [Low,Invalid]
<soren> https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/562370
<ubottu> Launchpad bug 562370 in apache2 (Ubuntu Lucid) "Upgrade from 2.2.14-5ubuntu6 to 2.2.14-5ubuntu7 results in syntax error, missing module" [Critical,Fix released]
<ttx> right, the 8 -> 8.2 debdiff is clean
<cjwatson> $ dpkg -c /home/lp_archive/ubuntu/pool/main/a/apache2/apache2.2-bin_2.2.14-5ubuntu8.2_i386.deb | grep reqtimeout
<cjwatson> -rw-r--r-- root/root     13704 2010-08-19 03:23 ./usr/lib/apache2/modules/mod_reqtimeout.so
<cjwatson> and that package was just configured ...
<soren> if dpkg --compare-versions "$2" lt 2.2.15-1~0;
<soren> looks really weird in a package with version 2.2.14-5ubuntu8.2
<soren> But maybe that's just me.
<soren> (from apache2.2-common.postinst)
<soren> Oh.
<ttx> soren: yes, maybe the error is triggered once you pass twice that piece of code.
<cjwatson> so the error specifically means that /etc/apache2/mods-available/reqtimeout.load doesn't exist
<soren> a2enmod decides whether a module exists based on whether a conffile exists.
<soren> ...so if the use deletes said conffile, the postinst goes boom.
<soren> Forever.
<cjwatson> quite so
<ttx> so those three users would just have played too much manually with their conffiles ?
<ttx> ah! ah!
<ttx> a2enmod is supposed to be run only once. And with that update, it runs twice.
<cjwatson> ttx: I still don't see how that could cause that error
<cjwatson> a2enmod doesn't remove the .load file
<ttx> cjwatson: wouldn't /etc/apache2/mods-available/reqtimeout.load move to mods-enabled or something ?
<cjwatson> symlink
<cjwatson> it's not moved, no.
<ttx> arh, too bad for my explanation
 * ttx should just set up a reproduction.
<cjwatson> a2enmod should be idempotent
<cjwatson> the added a2enmod in the postinst matches the pattern of a2enmod calls above
<soren> It's the exact same bug as this:
<soren> https://bugs.edge.launchpad.net/ubuntu/+source/apache2/+bug/576255
<ubottu> Launchpad bug 576255 in apache2 (Ubuntu) "can't install apache2.2-common (2.2.14-5ubuntu8)" [Low,Invalid]
<cjwatson> albeit ones for a fairly old version
<ttx> cjwatson: except that the above ones are much more restrictive in versioning.
<cjwatson> sure, but nevertheless
<soren> The user reporting it just failed to mention that he got the error on upgrade, so it was marked Invalid.
<soren> infinity probabaly assuming that the user just tried manually doing "a2enmod reqtimeout" and having removed the corresponding .load file had caused it himself.
<cjwatson> certainly seems like || true would be a sufficient fix
<soren> *nod*
<cjwatson> and that the version guard should be fixed for the backport to lucid
<soren> It's rather surprising this never happened before.
<soren> There's a bunch of a2enmod calls in that postinst.
<soren> There's probably a howto somewhere on the internetz telling people to delete that file.
<soren> *sigh*
<lifeless> soren: there's a howto for every bad idea ;P
<cjwatson> having the list of available modules effectively come from /etc isn't really a great design
<soren> lifeless: Some day we should clear out the internet and start over.
<ttx> soren: and appoint you as BMP reviewer, maybe
<soren> ttx: BMP?
<ttx> branch merge proposal
<soren> Oh.
<ttx> "Internet core committer"
<soren> Yeah, keeping the internet in bzr sounds like a good idea.
<soren> I can think of a few pages, I'd like to run "bzr blame" on.
<lifeless> lol
<ttx> soren: I see which precise one you mean.
<soren> ttx: I'm sure you do :)
 * soren shakes his fist in the Internet's general directoin
 * ttx discards the regression alert on the "Internet's fault" pile
<ttx> sorry for the noise chaps. Blame those 3 concurrent bug reports.
<tkamppeter> pitti, what about only ignoring IOError (this upstream has introduced a little later) for bug 618017?
<ubottu> Launchpad bug 618017 in splix (Ubuntu) "openprinting-ppds crashed with IOError in ls()" [High,Triaged] https://launchpad.net/bugs/618017
<pitti> tkamppeter: you can do that, but only at the actual print statement, not for the entire program
<pitti> if it fails to open an output file, it should fail properly
<tkamppeter> pitti, this program is rather simple. It only takes data which it contains by itself (the compressed PPDs are embedded in the program) and it does nothing else than putting the data out to stdout. It does not open any files.
<didrocks> ev: hey, before you release the next ubiquity version, if you can just look at my merge proposal (bump dep on libindicator for ABI change). Thanks!
<ev> didrocks: absolutely
<pitti> tkamppeter: well, but hiding each and every error in it will make debugging a pain; you won't even know that it's this program which is at fault then
<didrocks> ev: thanks a lot :) the new libindicator-dev will be available within the day
<pitti> didrocks: wow, ubiquity is using indicators now?
<ogra_ac> pitti, in the new minimal panel :)
<didrocks> pitti: yeah, in the "install only" mode
<tkamppeter> pitti, normally the program is called by CUPS and the output is piped into another program. The other program does not necessarily read all the output of the PPD archive and closes before the archive program finishes. This situation should not trigger Apport.
<didrocks> pitti: you have a top panel now
<ogra_ac> didrocks, pitti, or in oem-config mode
<ogra_ac> its really slick and small
<pitti> tkamppeter: ah, right; so the print should catch that IOError and cleanly exit the program then
<ogra_ac> we should use it everywhere !
<pitti> tkamppeter: this at least explains the pipe error
<didrocks> ogra_ac: yeah, it's great :)
<apparle> hello guys, is there any API on linux similar to page 73 of this http://www.aquaphoenix.com/hardware/ledlamp/reference/synaptics_touchpad_interfacing_guide.pdf
<apparle> or if you know a better channel to ask that, please forward me there
<tkamppeter> pitti, I can do one of two things:
<tkamppeter> pitti, 1. I use the upstream version of pyppd, as usually one should use programs as they come from upstream. It catches only KeyboardInterrupt and IOError but for the whole program.
<tkamppeter> pitti, 2. I can consider the upstream program as not acceptable (reporting a bug to upstream), letting only KeyboardInterrupt being caught for the whole program and IOError only for the two print statements for the list and for the PPDs.
<tkamppeter> pitti, WDYT?
<pitti> tkamppeter: hm, I think use 1. and report a bug to them to only catch the IOError on the print
<tkamppeter> pitti, OK. I will do so.
<cjwatson> didrocks: FYI the Build-Depends change needs to be done in d-i/update-control
<cjwatson> (in addition)
<cjwatson> actually I should just say that in the merge proposal, shouldn't I
<didrocks> cjwatson: really? I don't see them as rdepends of libindicator0
<didrocks> oh, the path
 * didrocks is tired, sorry :)
<didrocks> cjwatson: ok, fixing that ;)
<didrocks> cjwatson: merge reproposed, sorry for not seeing it
<pitti> cjwatson: btw, I processed unapproved this morning (and now again); light-themes, compiz, and telepathy require more input, but I can't self-approve my udev and p-common uploads
<tkamppeter> pitti, new version of foomatic-db uploaded. Please check and tell me whether it is OK, after that I will do the rest.
<tkamppeter> pitti, the pyppd there is now unpatched upstream. Functional change is only the "try: ... except: ...", all the noise in the debdiff is doc files and version number change.
<pitti> tkamppeter: perhaps you could replace "apport popup" with "crash on SIGPIPE"
<pitti> (but don't worry about that for foomatic-db)
<pitti> tkamppeter: looks fine to me, accepting
<ogra> mvo, sw-center change works (enables the PPA), but i get an "untrusted packages" error when trying to install from the PPA
<mvo> ogra: thanks, could you file a bug please?
<ogra> mvo, will do
<ogra> any specific logs you want ?
<hrw> hi
<mvo> ogra: no, I think I know what the problem is
<mvo> ogra: just the bug so that I can target it
<ogra> mvo, k
<ogra> filing as we speak :)
<mvo> thanks!
<ogra> mvo, bug 645120 for you
<ubottu> Launchpad bug 645120 in software-center (Ubuntu Maverick) "using an apturl source that also enables a PPA pops up an "Untrusted Packages" message when installing from the PPA" [High,New] https://launchpad.net/bugs/645120
<ogra> mvo, oh ... i didnt click past the error message yet, seems hitting the install button is a no-op
<ogra> is that a separate bug or related ?
<tkamppeter> pitti, hplip is uploaded.
<mvo> ogra: please add it to the bugreport (the info)
<ogra> ok
<ogra> done
<mvo> ev: I'm doing a fresh install now and selected "use entire disk" but in the confirmation screen I have only a ext4 now, no mention of a swap device. is that intentional (information most users will not care about). or did it for some reason not create a swap device?
 * mvo is trying to reproduce the apt-cdrom bug that keybuk mentioned yesterday
<Keybuk> yeah, sorry, I oddly haven't been able to reproduce now it's all installed
<Keybuk> what I originally did:
<ogra> reinstall !
<ogra> :)
<Keybuk> installed from CD-ROM, no network connection
<mvo> Keybuk: no worries, I wanted to see the new installer anyway (its shinny!)
<mvo> Keybuk: desktop install or alternate install?
<Keybuk> did apt-cdrom add, apt-get update (which complained obv. about no network) then apt-get install bcmwl-kernel-source
<Keybuk> desktop
<Keybuk> then apt complained that it couldn't find the files
<Keybuk> it gave the name of the CD exactly as it was
<Keybuk> and it gave the paths exactly as they were on CD
<Keybuk> CD was mounted at /media/apt
<Keybuk> ogra: it was rather too much of a fight to get things installed in the first place!
<ogra> Keybuk, yeah ...
 * ogra has no ubuntu probelms anymore since he bought an armel netbook :)
<mvo> Keybuk: so it was the desktop-install cd?
<Keybuk> it was
<mvo> thanks
 * mvo is doing the install now
<mvo> ev: its really shinny, kudos
<Keybuk> right, lunch - grab me later or tomorrow if you can't replicate and I'll try and help out
<mvo> Keybuk: bon appetite
<ogra> mvo, hmm ... now i'm trying to install oo.o here, seemingly using the metapackage (sw-center says: openoffice.org office suite  in the UI) but that only offers me an "update now" button, installing one of the components works though
<mvo> ogra: oh, i check
<ogra> mvo, seems i get the metapackage offered in "addon packages" in the writer screen
 * ogra wonders if thats just a wanted design i'm to dumb to understand
<mvo> ogra: that OOo is not there is a bug
<ogra> mvo, ah, k, i was doubting my skills to understand mpt's decisions :)
<mvo> you are not a target user ;)
<mpt> wait what?
<mvo> ogra: but seriously, this one is a bug
<mvo> ogra: I think a bug in the meta-data to be precise
<mvo> ogra: is that on i386?amd64?*cough* arm?
<ogra> mvo, *cough* arm indeed :)
<mpt> There shouldn't be an "Update Now" button anywhere afaik
<mvo> ogra: ohhhhh
<ogra> but writer installs just fine
<ogra> oo.o finished building yesterday
<ogra> so data should be available
<mvo> mpt: it appears if there is meta-data for a item but we have no package for it, it usually means that /var/lib/apt/lists is empty for some reason
<mvo> mpt: and a update fixes the issue
<mpt> ah, I see
<mvo> mpt: but apparently ogra has hit a bug on arm
<ogra> \o/
<ogra> another one :)
<mvo> ogra: what does apt-cache policy openoffice.org give you?
<ogra> lets see
<mvo> ogra: dude, if you find more bugs, you will have to rotate into QA!
<ogra> installed and candidate say (none), rest is empty
<ogra> mvo, nah, rotate more QA ppl to arm so i dont have to search them :)
<mvo> ogra: hm, why is this? is the package not availalbe for arm at all?
 * ogra cant ssh in currently and a writer install is running, i need to test OO.o for doko ... so i have to copy/brain/paste here
<mvo> ogra: at least LP says it is
<ogra> yes, it is
<mvo> but why does apt not know about it then :) ?
<ogra> no idea
<ogra> does the apturl stuff run an apt-get update if it enables them ?
<ogra> s/them/PPAs/
<ogra> though the package cache should be up to date, the image was rolled this morning ... (3h ago)
<bullgard4> What is an Â»unseeded packageÂ«? As in "ubuntu-release delegations for unseeded packages in universe/multiverse"
<micahg> bullgard4: usually packages without a Task
<bullgard4> micahg: Thank you.
<ev> mvo: thanks!  Very much appreciated.
<cjwatson> mvo: Keybuk's problem might have been an installer bug instead - just uploaded a backport of a change I made to Debian a couple of days ago to fix a similar problem
<mvo> ev: I just saw that a swap device is created so my earlier question is solved
<mvo> cjwatson: aha, ok. what branch should I look at to see the diff?
<cjwatson> mvo: lp:~ubuntu-core-dev/base-installer/ubuntu
<mvo> thanks
<mvo> cjwatson: that seems to be a bit confusing, I check why apt is requiring both
<mvo> (confusing on apts side)
<ogra> mvo, hmm, so even after apt-get update i dont see oo.o meta in apt-cache policy
<ogra> mvo, http://paste.ubuntu.com/498447/
 * ogra has ssh now
<mvo> ogra: I can't see it in the packages file for armel on ports
<ogra> weird
<ogra> publisher hiccup ?
<mvo> possible
<wgrant> Unlikely.
 * wgrant looks.
<cjwatson> ogra: you don't have universe enabled
<cjwatson> openoffice.org | 1:3.2.1-6ubuntu2 | maverick/universe | amd64, armel, i386, powerpc
<cjwatson> the metapackage has been in universe since lucid (I don't know why)
<cjwatson> if it needs to be re-promoted, somebody should seed it
<mvo> I can do that, I need to seed ubuntu-extras-keyring anyway
<ogra> cjwatson, oh, weird
<ogra> thanks !
<salty-horse> hey. I'd like to get this tiny bugfix in the cairo2 package -- should I just file a bug pointing to it? https://bugs.freedesktop.org/show_bug.cgi?id=30115
<ubottu> Freedesktop bug 30115 in general "cairo_device_type_t enum has a trailing comma" [Normal,Resolved: fixed]
<mvo> cjwatson: can I ask for a quick advice? should I seed it into desktop ? or rather platform? I think desktop is better as we probably leave it out on the server, but I don't have a strong opinion. as it only contains new stuff it should not harm much to have it as a recommends on ubuntu-standard
<ogra> cjwatson, mvo, hmm, shouldnt sw-center have told me that its in universe though ? (and offer to enable it)
<cjwatson> mvo: I think ubuntu.maverick/supported-desktop-extra, given that there's already oo.o stuff there
<mvo> ogra: it should have, that is a bug in the meta-data, I add a test for this
<ogra> ok
<ogra> thats what i thought
<mvo> cjwatson: I meant where to seed "ubuntu-extras-keyring" :)
<cjwatson> oh
<cjwatson> mvo: my gut feel would be platform.maverick/desktop-common
<mvo> cjwatson: yeah, that makes sense, thanks
<mvo> hm, it looks like openoffice.org depends on some other universe stuff (like openoffice.org-filter-mobiledev
<ogra> imho we dont need it seeded in main
<mvo> ogra: ok, I fix the meta-data
<ogra> (we dont use it on armel at all btw)
<ogra> (in the images)
<hrw> I have good news - armel cross compiler 4.5 landed in ubuntu (gcc-4.4 is on a way)
<tkamppeter> pitti, all new packages for bug 618017 uploaded.
<\sh> how can someone disable on lucid the write_net_rules script to overwrite self written /etc/udev/rules.d/70-persistent-net.rules file? during jaunty this behaviour was different somehow..
<ubottu> Launchpad bug 618017 in splix (Ubuntu) "openprinting-ppds crashed with IOError in ls()" [High,Fix committed] https://launchpad.net/bugs/618017
<\sh> oh damn....the format changed...halleluja
<ogra> ScottK, in case you have a bored minute i'd like to draw youre attention to bug 645200 :)
<ubottu> Launchpad bug 645200 in systemtap (Ubuntu) "please sync systemtap 1.3 from debian experimental" [Undecided,New] https://launchpad.net/bugs/645200
<LLStarks> kenvandine, i found a glaring ambiance/radiance bug not fixed by your new release.
<LLStarks> should i mark its bug for uife?
<kenvandine> LLStarks, file a bug for sure... i know very little about the theme :)
<kenvandine> but i can make sure someone looks at it asap
<LLStarks> https://bugs.launchpad.net/ubuntu/+source/light-themes/+bug/622284
<ubottu> Launchpad bug 622284 in light-themes (Ubuntu) "font blur on some buttons in beta theme" [Medium,Confirmed]
<LLStarks> oh wow
<LLStarks> mark already jumped on it
<LLStarks> i feel honored.
<ev> mvo: http://paste.ubuntu.com/498545/ - interested?
<jcastro> charlie-tca: https://wiki.ubuntu.com/UbuntuOpenWeek/Timetable can you pass that along to xubuntu folks? Sessions wanted!
<mvo> ev: yes, checking
<ev> that's roughly: fakeroot fakechroot -s debootstrap --variant=fakechroot maverick maverick; fakeroot fakechroot -s chroot maverick; apt-get -y install ubiquity ubiquity-frontend-gtk; apt-get -f install
<charlie-tca> Be happy to.Thanks for letting us know
<ev> I noticed you fixed a similar bug relatively recently, in ubuntu1, not sure if this is related though
<mvo> ev: so that is from debootstrap?
<ev> correct
<ev> well
<ev> sorry
<ev> the error is not from bootstrap
<ev> that succeeds after it retries a few times
<ev> the error is from chrooting into the presumably successfully created chroot and trying to install ubiquity
<ev> debootstrap returns 0
<\sh> oh I'm stucked now...I'm writing my own 70-persistent-net.rules file, and in jaunty write_net_rules never touched it when it was there..now on lucid, it always replaces my rules with its own...which is totally different behaviour, even chmod 444 of this file doesn't prevent udev to overwrite
<JanC> cjwatson: it seems like the btrfs patch you added to GParted causes it to crash - https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/609447
<ubottu> Launchpad bug 609447 in gparted (Ubuntu) "gpartedbin crashed with signal 5 in Glib::exception_handlers_invoke()" [Medium,Confirmed]
<cjwatson> psurbhi: ^- that was your btrfs patch for gparted - could you look at that, please?
<RoAkSoAx> cjwatson: you are the one who generates the cdimage .manifest-daily right :)?
<cjwatson> RoAkSoAx: scripts that I operate do it, yes
<cjwatson> (though I am but one of the operators these days)
<RoAkSoAx> cjwatson: Well I think there might be a mistake with this entry: " ubuntu maverick /kubuntu-mobile/daily-live/current/maverick-mobile-i386.iso 701138944"sionce it is pointing a kubuntu ISO instead of an ubuntu one :)
<slangasek> pitti: 618017> the packages seem to have been accepted, in spite of your nack in the bug log - did you and tkamppeter work this out off-line?
<pitti> slangasek: yes, I rejected the original ones, and he uploaded fixed versinos
<slangasek> pitti: oh; the changelogs still all refer to try: main() except: pass
<pitti> slangasek: really? where?
<pitti> hplip (3.10.6-1ubuntu10) maverick; urgency=low
<pitti>   * debian/local/pyppd/pyppd/: Updated to pyppd 0.4.9, to suppress runtime
<pitti>     error tracebacks by putting a "try: ... except ...: pass" construct around
<pitti>     the main function call. This avoids Apport pop-ups when the execution of the
<pitti>     self-extracting compressed PPD file archives gets stopped by the calling
<pitti>     process (LP: #618017).
<pitti> slangasek: those were the ones I've seen
<pitti> slangasek: I think there was one package which got accepted before, something with p*
<pitti> slangasek: but it got fixed again as well
<slangasek> pitti: "around the main function call" - looks to me like exactly what you were objecting to
<slangasek> anyway, if you're aware of it, I assume all is as it should be :)
<pitti> slangasek: right, but now only KeyboardInterrupt and IOError
<slangasek> ahh, ok
<pitti> slangasek: the latter is still not quite well, but I asked Till to file an upstream bug
<pitti> slangasek: and since the program is basically just one fancy print statement, I considered it "good enough"
<cjwatson> RoAkSoAx: thanks, fixed
<pitti> but I didn't want it to shadow things like ImportError, or wrong format strings, etc.
<pitti> tkamppeter: bug 645328> oops, sorry about that, and thanks for finding; I'll get it fixed first thing tomorrow
<ubottu> Launchpad bug 645328 in cups (Ubuntu Maverick) "use of dpkg-vendor requires dpkg-dev" [Undecided,New] https://launchpad.net/bugs/645328
<RoAkSoAx> cjwatson: thank you :)
<tkamppeter> pitti, thanks for passing through my uploads. Don't you have access to pass through ptouch-driver?
<pitti> tkamppeter: perhaps it wasn't in the queue yet when I processed it; but we'll get it in, don't worry
 * pitti -> dinner
<mvo> zul: I noticed that after a recent upgrade squid seems to be not always started anymore, is that a know issue? might be something with squid-deb-proxy, I have not investigated yet
<zul> mvo: ill take a look
<mvo> thanks, I can dig more into it tomorrow (almost dinner time for me :)
<mvo> ev: apt bug is fixed, thanks for reporting it
<ev> mvo: you rock!
<mvo> thanks :)
 * mvo will not say just how silly the bug was
<\sh> anyone have a short hint on how to enable debugging mode for udev? udev.conf: udev_log="debug" or something like this?
<cjwatson> yes, that.  or udevadm control --log-priority=debug
<cjwatson> run update-initramfs -u after editing the file if you want debug output in the initramfs too
<\sh> oh wow...if this is not a big bug
<\sh> ok...here it goes: /lib/udev/write_net_rules writes into /etc/udev/rules.d/70-persistent-net.rules, while debugging enabled, it reads this 70-persistent-net.rules file, but adds stuff into the very same file, because the main rules files which triggers write_net_rules is 75-persistent-net-generator.rules
<\sh> so 70 comes first, and 75 changes everything
<cjwatson> I thought it had to be that way.  the purpose of writing the net rules is to record the state of the mac->device mapping in this boot, to preserve it for future boots.  thus writing the net rules has to come last
<cjwatson> but I'm going out so can't debug this now
<\sh> cjwatson: if you want to have a nic named "eth0 " on a different device, you need to say that normally in 70-persistent-net.rules but somehow this is not wanted by /lib/udev/rules.d
<\sh> if the admin tells udev to "this is the action you need to do when finding this device with mac address X:Y:Z", the system shouldn't overwrite his wish
<\sh> s/his/his\/her/
<\sh> the second bug I would say is, that write_net_rules helper script can't be prevented to write the 70-persistent-net.rules file, even if admin says that this file is chmod 444
<Darxus> Why do the graphical package management tools use apt-get instead of aptitude?
<Darxus> They don't flag packages as installed as a dependancy, right?
<hallyn> how does debuild -S decide what files to keep?  iow, how does it decide whether to ignore .git/ ?
<ev> hallyn: the DEBUILD_DPKG_BUILDPACKAGE_OPTS environment variable lets you control that
<hallyn> ev: thanks!
<hallyn> (wonder if there is a way to get 'bzr dailydeb' to honor that)
<ev> ~/.devscripts most likely
<pitti> DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I"
<pitti> always a good thing to have
<doko> http://qa.ubuntuwire.com/ftbfs/ isn't updated anymore
<ScottK> doko: The admin for that is away right now, but I've pinged them.
<doko> ScottK: thanks
<\sh> cjwatson: ok, the workaround is to overwrite 75-persistent-net-generator.rules in /etc/udev/rules.d/ but this should not be the case, when the README tells something else
<\sh> and that doesn't work when you do it when you start the server up...*grmpf*
<achiang> does anyone know who calls sysv-style initscripts like "reboot" and "shutdown"? if i issue them as root from the cmdline, i think i'm directly calling the binaries in /sbin...
<jcastro> charlie-tca: I've got karl looking at the tomboy menu thing
<charlie-tca> Thank you
<charlie-tca> I hope we can get it fixed
<charlie-tca> It just seems not everyone can reproduce it.
<jcastro> I think we got it
<jcastro> charlie-tca: was there someone working on appindicator support for XFCE somewhere? I remember seeing something a while back.
<charlie-tca> I don't remember. I will have to go looking
<jcastro> ok if you run into anything lmk. (That being said the fallback is supposed to be working anyway)
<charlie-tca> I will do that. Thanks
<jcastro> if someone is interested but needs help I can get them help too
<mr_pouit> jcastro: not really. There's a panel plugin (xfce4-indicator-plugin), but nothing in xfce core.
<tkamppeter> pitti, I have reported the pyppd problem upstream now.
<hallyn> hggdh: my bug-control membership is about to expire, you're listed as someone to get in touch with - can you renew?
<hggdh> hallyn: doing it now
<hallyn> hggdh: thanks!
<hggdh> hallyn: what is your LP id?
<hggdh> hallyn: forget, got it. You are all set.
<mvo> ogra: the channel adding stuff should be fixed in trunk now (in software-center)
#ubuntu-devel 2010-09-23
<lamont> so I wonder, how do I get network-mangler to quit trashing /etc/hosts?
<nigelb> james_w: you remember the class? :)
<james_w> nigelb: yes, thanks for the reminder :-)
<james_w> nigelb: did anyone pick a topic for me yet? ;-)
<nigelb> james_w: nope, nothing came up :(
<james_w> I think it's been 6 months since I've done a "UDD intro + Q&A", so I can do that again
<nigelb> yay!
<ScottK> doko: http://qa.ubuntuwire.com/ftbfs/ should be back in business now.
<wgrant> In case anybody tries to fix it, the firefox FTBFS on powerpc is some unknown Soyuz breakage, so don't.
<ScottK> james_w: At UDS, I would be very interested in sitting down with some UDD type person to review how I deal with clamav packaging to find out if UDD can help be do it better/faster or if it presents any interesting use cases UDD might want to support.
<ldunn> Are all translations for a package stored in the po/ directory of the package, if it exists?
<mgunes> For bugs targeted to be fixed in the development branch in time for the final release, do we use milestones (e.g. ubuntu-10.10) or release nominations? The current practice has been to use milestones and reject the nominations, but https://wiki.ubuntu.com/RCBugTargetting (which might be outdated) states otherwise.
<ScottK> mgunes: No, that's not outdated AFAIK.
<ScottK> TheMuso: Would you please look at bug 621374 and bug 619809 and comment on if you think we should update the packages or not?
<ubottu> Launchpad bug 621374 in onboard (Ubuntu) "Feature freeze exception request for new minor release" [Undecided,New] https://launchpad.net/bugs/621374
<ubottu> Launchpad bug 619809 in virtkey (Ubuntu) "Feature freeze exception request for new minor release" [Undecided,New] https://launchpad.net/bugs/619809
<mgunes> ScottK, I recall quite a few RC bugs where nominations were rejected and a milestone was used instead; bug #605577 would be one recent example.
<ubottu> Launchpad bug 605577 in Ubuntu Translations "Help contents title bar shows cubes with numbers instead of a proper title" [High,Triaged] https://launchpad.net/bugs/605577
<ScottK> mgunes: The list that the release team reviews is those that are milestoned and targetted to the release.
<ScottK> That doesn't mean everyone is doing it right.
<mgunes> ScottK, there seem to be plenty of bugs tracked in Maverick:  https://bugs.launchpad.net/ubuntu/maverick/+bugs
<ScottK> mgunes: You asked a question.  I answered it.  If you were going to argue with the answer, why bother to ask?
<mgunes> ScottK, I wasn't arguing; I meant to confirm your observation that everyone might not be doing it right, since both milestones and nominations seem to be used.
<ScottK> mgunes: Oh.  OK.
<ScottK> Sorry about that then.
<mgunes> no worries.
<pitti> Good morning
<pitti> tkamppeter: cheers
<Hobbsee> !info ubuntu-restricted-extras-java
<ubottu> Package ubuntu-restricted-extras-java does not exist in lucid
<Hobbsee> then where on earth is it from?
<Hobbsee> oh, it's ruddy superOS
<Hobbsee> !superos
<Hobbsee> hmmm.  anyone here deal with that?
<Hobbsee> and for bonus points, they have no place to report bugs
<ScottK> Nice.
<Hobbsee> quite
<ScottK> You could possibly sick the trademark police on them.
<Hobbsee> they've already changed from super ubuntu to superos
<Hobbsee> mvo: can we instruct launchpad not to accept bugs following some pattern, and force the overwrite of that file?
<mvo> Hobbsee: uh, no idea. I think that is more something for #launchpad
<mvo> (sorry)
<Hobbsee> mvo: ah.  no problem
 * Hobbsee finds a contact address, so sticks the Long Pointy Stick on it
<ScottK> \o/
 * ajmitch hopes they've got good flame-resistant clothing
 * ScottK cheers the return of the stick.
<Hobbsee> haha
<Hobbsee> "we don't provide support for this software"...yeah, i couldn't have guessed
<ScottK> Hobbsee: But if they are still naming their packages ubuntu-foo, then maybe they are still vulnerable.
<Hobbsee> ScottK: good point.  I'm not sure
<Hobbsee> ScottK: to be honest, as long as I don't keep receiving bugs about their conflict, i'm happy
<Hobbsee> they can name packages however they like if they don't cause us bugs
<Hobbsee> if they cause themselves bugs, that's their own problem
<ScottK> Right and the odds of that would be better if the package weren't called ubuntu something
<Hobbsee> true
<ScottK> "How can it not be an Ubuntu bug, it's got Ubuntu right in the name?"
<Hobbsee> then i'll issue smackdown #2 to the reporter, and further dupe their bugs.  This is not really aproblem
<ogra> popey, ! you banned karl ?!?
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, what's on
<pitti> erm, still digging through the ridiculous stack of overnight email
<pitti> oh, and I uploaded a cups fix for the upstart migration
<pitti> how are you?
<tkamppeter> fine, I have seen your solution in the BZR yesterday.
<tkamppeter> pitti, I have seen in debian/rules of CUPS that there is also firewall (ufw) profile in CUPS. Does it take into account access to LPD-based network printers? See bug 645603.
<ubottu> Launchpad bug 645603 in cups (Ubuntu) "cups printer was properly installed and working under 10.04 LTS. Once I upgrade it to 10.10, it is no longer working." [Undecided,Invalid] https://launchpad.net/bugs/645603
<pitti> tkamppeter: isn't lpd on port 631 as well?
<tkamppeter> pitti, no, LPD is on port 515 and I do not know whether the printer uses additional ports to answer LPD requests.
<tkamppeter> pitti, CUPS uses also SNMP and DNS-SD for discovering printers (the former also to check status). I do not know which ports these protocols use. They should also not be blocked by the firewall.
<tkamppeter> wc -l x
<pitti> jdstrand: ^ the firewall (ufw) isn't active by default, or is it? i. e. will /etc/ufw/applications.d/cups preclude other ports (like from lpd) from being used?
<smb> pitti, Good morning. Could you accept re-uploads for Karmic (master, mvl-dove, ec2) and binNEW lrm Hardy?
<pitti> . o O { seems it really gets time to get back to platform }
<smb> pitti, There never seemed to be someone being able to fit your shoes. :)
<pitti> slangasek, cjwatson: could one of you please review my udev upload from Monday? I discussed it with Colin before, and I vouch that it's safe
<ogra> mvo, hey ... just tested your fix, works fine !
<mvo> ogra: nice, thanks!
<mvo> ogra: that means one final upload
<ogra> mvo, kleiner lacher als dankeschoen :) http://www.youtube.com/watch?v=ei7LP99FFb4&feature=channel
<ogra> mvo, i havent had the opportunity to test with a list of packages yet though (TI only has one test package in their PPA)
<ogra> though if it doesnt work i can ask them to create a metapackage or so
<mvo> ogra: that does make sense I think
<mvo> ogra: it should work :)
<pitti> smb: meh, kernel-overrides is broken; hardy NEWing will take a bit
<pitti> smb: karmic accepted, and hardy -envy
<pitti> fiddling with hardy lrm now
<popey> ogra: :)
<ogra> :(
<ogra> sniff
<ogra> my best coffebreak entertainment is gone
<pitti> smb: meh, and queue overriding is broken for me as well; I really need to get to something else right now, I'll have a look later (unless someone beats me to it)
<jibel> pitti, please don't publish bug 525807 to lucid. It was marked verification-done but it is not. Thanks.
<ubottu> Launchpad bug 525807 in openoffice.org (Ubuntu Lucid) "[upstream] [3.2.1] OOo Slide Show and Fullscreen modes - not full screen under compiz" [Medium,Fix committed] https://launchpad.net/bugs/525807
<pitti> jibel: can you please set it to "failed"?
<smb> pitti, Doh! Well I guess I'll have some more tea then. ;-)
<jibel> pitti, done.
<pitti> ah, seems queue override needs a full package name now
<pitti> argh pain argh
 * smb hands pitti a stress ball
<popey> ogra: lol
<pitti> smb: ok, lrm/hardy done
 * pitti raises his shields to full power and finally goes to do something he's supposed to
<tseliot> pitti: can you approve fglrx in maverick, please?
<smb> pitti, Thanks, and good luck
<tseliot> oops
<smb> shields down to 20% captain
<pitti> later :)
<ScottK> TheMuso: Thanks.  Approved.  I'd appreciate it if you'd keep an eye on getting them uploaded sooner rather than later.
<TheMuso> ScottK: sure
<lool> pitti: Mind if I bother you for a sync to maverick?  FFE and rationale in LP #645200l systemtap 1.3-1 from Debian experimental
<ubottu> Launchpad bug 645200 in systemtap (Ubuntu) "FFe: please sync systemtap 1.3-1 from experimental to maverick" [Undecided,Confirmed] https://launchpad.net/bugs/645200
<ScottK> didrocks: I think your approach of disabling all tests for libcairo-perl due to a few corner cases failing is probably overbroad, particularly this late in the release cycle.  Fortunately persia has worked out a more focused solution that only disables the tests currently failing.  I'm going to reject your pending upload.  Would you please have a look at what persia has prepared and consider sponsoring it if you think it's suitable?
 * persia is build-testing that, and will push a patch to the bug when it completes
<didrocks> ScottK: sure, I've done that after talking to slomo, and almost nothing is using libcairo-perl in any case, so if persia has a better solution, please go ahead and upload it :)
<ScottK> didrocks: I'm just about to be away for several hours, so I'd appreciate it if you would have a look after persia puts the debdiff in the bug.
<didrocks> ScottK: sure
<persia> didrocks, I can't, so I'll hope for your signature on it in a few minutes :)
<didrocks> persia: ok, I'll look at it :) just ping me!
<pitti> tseliot: done; can you please update jockey as well? and thanks a lot for getting this in!
<tseliot> pitti: sure, I'm also looking at another issue in jockey when updating initramfs (which maybe we should do for the current kernel instead of the newest kernel). What do you think? (this is in the handlers)
<pitti> tseliot: hm, why is it doing that for fglrx?
<pitti> tseliot: or do you mean for the wl blacklisting?
<tseliot> pitti: here's the use case. I boot into an older kernel and decide to install the driver for that kernel but then initramfs is updated only for the newest kernel
<persia> didrocks, bug #187823 has a more targeted patch
<ubottu> Launchpad bug 187823 in libcairo-perl (Ubuntu Hardy) "ftbfs (1 failed test) with current cairo version" [High,Confirmed] https://launchpad.net/bugs/187823
<tseliot> pitti: to blacklist the radeon KMS driver
<tseliot> pitti: the same applies to nvidia with nouveau
<pitti> tseliot: so you want to update all?
<pitti> tseliot: i. e. -k all?
<tseliot> pitti: maybe just the current kernel? Or the current kernel and the latest kernel
<pitti> tseliot: hm, I thought -u woudl already do the current kernel
<tseliot> pitti: which is what dkms does by default with my template
<pitti> tseliot: so, mirroring the dkms behavior makes sense to me
<tseliot> pitti: -u without further arguments should only update the latest kernel
<tseliot> pitti: ok
<tseliot> pitti: I'll let you know when the code is ready
<pitti> tseliot: cool, thanks!
<cjwatson> didrocks: is anyone from the desktop team looking at bug 642746?
<ubottu> Launchpad bug 642746 in libwnck (Ubuntu) "[Maverick] Workspace layout is 1x9 instead of 3x3" [Undecided,Confirmed] https://launchpad.net/bugs/642746
<cjwatson> I've seen a few reports of that, and I see the bug myself
<didrocks> cjwatson: not that I know of, but I wanted to work on it as I use metacity too :) Assigning to the team for now
<didrocks> it's a recent update, I didn't get that before
<didrocks> persia: didn't know about this SKIP testsuite (only familiar with python ones). Looks good and build fine. Sponsoring now, thanks!
<persia> didrocks, Neither did I until I saw the comments in the source file :)  Thanks.
<bdrung_> doko: can you have a look at bug #640732?
<ubottu> Launchpad bug 640732 in audacious (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init()" [High,Triaged] https://launchpad.net/bugs/640732
<jdstrand> pitti: hi! ufw is not enabled by default. /etc/ufw/applications.d/* are what are called 'application profiles'. They provide a means for someone to do something like 'sudo ufw allow CUPS' instead of having to specify the port and protocol
<jdstrand> pitti: they don't do anything unless the admin decides to use them. the cups application profile does not currently have an entry for lpd (515/tcp)
<pitti> tkamppeter: ^ so this shouldn't cause the lpd failure you mentioned
<jdstrand> pitti: as for snmp, there is no application profile. for dns-sd, if the firewall is enabled, multicast is allowed by default
<pitti> jdstrand: ok, thanks for the heads-up; so probably cups' profile should get the lpd port added to?
<jdstrand> pitti: possibly. ufw in Debian has some default application profiles that includes lpd already (/etc/ufw/applications.d/ufw-printserver) that we'll get in natty
<pitti> jdstrand: ah, nice
<jdstrand> pitti: I'm rethinking how we do those and will probably provide these default ones and remove the package-specific integration unless the packager wants to override the ufw defaults
<jdstrand> but I need to think about it some more
<doko> bdrung_: hmm, do you have such an example?
<doko> new .0 release in feature freeze ...
<bdrung_> doko: you can install audacious in maverick and follow the steps in comment #6. i haven't a stripped down version example for this bug.
<bdrung_> doko: new .0 release of what?
<didrocks> cjwatson: libwnck fix pushed
<doko> bdrung_: audacious, what else. is this amd64 only?
<doko> not reproducible on i386
<bdrung_> doko: 2.4.0-0ubuntu1 doesn't differ much from 2.4~rc2-0ubuntu1 which doesn't differ much from 2.4~beta2-0ubuntu1. 2.4~beta1-0ubuntu1 was uploaded before feature freeze.
<bdrung_> doko: i386 is probably affected too. some duplicates are filed against i386: https://bugs.launchpad.net/ubuntu/+source/audacious/+bug/633012
<ubottu> Launchpad bug 633012 in audacious (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init() (dup-of: 640732)" [Medium,New]
<ubottu> Launchpad bug 640732 in audacious (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init()" [High,Triaged]
<doko> bdrung_: is this amd64 only?
<bdrung_> doko: according to the bug reports: no
<doko> bdrung_: and can't reproduce on amd64 either
<doko> although that's a remote system
<cjwatson> didrocks: yay
<tkamppeter> pitti, jdstrand, is the UFW totally open (inactive), totally closed, or closed with some exceptions in a default installation?
<bdrung_> doko: i can reproduce it.
<bdrung_> doko: the question is what differs between our systems? i was even able to reproduce it in my VM
<bdrung_> doko: hiding won't help. ;)
<jdstrand> tkamppeter: the default installation is disabled (ie open)
<jdstrand> tkamppeter: s/open/inactive/
<jdstrand> tkamppeter: ie, it does nothing unless someone explicitly enables it
<tkamppeter> jdstrand, pitti, if enabling it all ports get closed if no exception is defined in one of the /etc/ufw/applications.d/* files?
<jdstrand> tkamppeter: /etc/ufw/applications.d/* are not exceptions and nothing is done with them automatically when enabling the firewall. think of /etc/ufw/applications.d/* as /etc/services on steroids: it is just a way for an admin to conveniently reference (groups of) ports and protocols by application name
<jdstrand> tkamppeter: eg, you do something like 'sudo ufw allow Samba' rather than specifying 137/udp, 138/udp, 139/udp and 445/udp
<jdstrand> meh
<jdstrand> 139/tcp and 445/tcp
<jdstrand> tkamppeter: see 'man ufw'
<jdstrand> APPLICATION INTEGRATION
<tseliot> pitti: one more thing that I've noticed is that if a package is already installed and we enable it, the icons of control panels don't show up in the menu unless we do what's suggested in bug 581838 . I'd like to take care of this problem too
<ubottu> Launchpad bug 581838 in gnome-menus (Ubuntu) " Manually created menu item in Gnome disappears from Gnome, Ubuntu 10.04 (64 bit).after reboot" [Low,Invalid] https://launchpad.net/bugs/581838
<tkamppeter> jdstrand, thanks.
<pitti> tseliot: because it puts a desktop file into /usr/share/applications which isn't shipped in a package?
<pitti> I've seen several incarnations of this report already; you either need to run the dpkg trigger, or (easier) just ship the .desktop file in the .deb
<persia> Please, please, select the latter of those options :)
<pitti> *violently agree*
<tseliot> pitti: I do both things
<tseliot> pitti: however, when we switch between alternatives (and the packages are already installed), even though we call dpkg-trigger from python, it doesn't work because that's supposed to be called by a package.
<doko> bdrung_: the list of segfault bugs in audacious is "impressing" ...
<pitti> tseliot:
<pitti> $ sudo dpkg-trigger --by-package fglrx-installer gmenucache
<pitti> $ sudo dpkg --configure -a
<pitti> tseliot: so you enable/disable the desktop file based on an alternative?
<tseliot> pitti: yes, so that we don't end up having ati's control panel when nvidia is in use
<pitti> tseliot: if the trigger causes too much grief, you could also use /usr/local/share/ perhaps?
<pitti> tseliot: but if you have the fglrx package isntalled, why wouldn't you show it?
<pitti> I mean, it's highly unusual to have fglrx installed on an nvidia system?
<tseliot> pitti: I can have an image that has both fglrx and nvidia installed and I can enable the right driver according to the hardware
<pitti> tseliot: ah, ok
<tseliot> pitti: let me check how I call dpkg-trigger in nvidia-common (in a library that jockey uses)
<tseliot> pitti: I do "dpkg-trigger --by-package=fakepackage gmenucache"
<pitti> tseliot: you need a --configure call as well
<persia> tseliot, Rather than adding/removing the .desktop file, consider hiding it.
<pitti> right, you could enable/disable NoDisplay=, too
<persia> NoDisplay is a really clean way to hide it :)
<tseliot> persia: we don't install .desktop files in that directory, only links to the actual desktop files. When you switch between alternatives, those links point to different desktop files
<tseliot> pitti: ah, so that's what I was missing
<persia> tseliot, Much of what was horridly confusing about an experience moving hard drives between machines a while back now becomes clear :)
<tseliot> pitti: and would it work if I did "dpkg --configure -a" after "dpkg-trigger --by-package=fakepackage gmenucache" despite the fact that fakepackage is a fake package?
<pitti> tseliot: works here
<tseliot> persia: that's just the tip of the iceberg. Welcome to my world :P
 * persia quickly withdraws to something that makes sense
<tseliot> pitti: good, so it'll be just a one line change in nvidia-common
<tseliot> hehe
<pitti> tseliot: "sudo dpkg-reconfigure python-gmenu" alternatively that should work as well
<pitti> not sure what is better
<pitti> but using the "gmenucache" trigger hides the implementation detail which package is responsible for it
<pitti> it's not unlikely to move to gnome-menus at some point
<tseliot> ok, thanks
 * tseliot -> lunch
<bdrung_> doko__: commented bug #640732. using g++ instead of gcc fixes the crash.
<ubottu> Launchpad bug 640732 in audacious (Ubuntu) "audacious2 crashed with SIGSEGV in std::ios_base::Init::~Init()" [High,Triaged] https://launchpad.net/bugs/640732
<doko__> bdrung_: I love plugins ...
<bdrung_> doko__: i will be afk for some hours - i need a new "perso" before it will be electronical and expensive.
<bdrung_> doko__: indicates that a bug in gcc or shouldn't gcc be used for linking?
<didrocks> ev: ping to remind about merge https://code.edge.launchpad.net/~didrocks/ubiquity/take-libindicator-abi-change. the installer mode will have no indicator in the bar otherwise
<ev> didrocks: indeed, already realized that I forgot to upload it with the last version.  I'll do another upload shortly.
<didrocks> ev: great, thanks :)
<tseliot> pitti: I have tested my changes to jockey but I don't know if bzr hosting is up now, so here's the patch (which in bzr is split into different commits): http://pastebin.ubuntu.com/499093/
<tseliot> let me know if I can upload the changes
<pitti> tseliot: https://code.edge.launchpad.net/~ubuntu-core-dev/jockey/ubuntu/ seems to work?
<pitti> tseliot: ah, -k <version> will _also_ update the current kernel?
<pitti> erm, also the latest kernel, I mean?
<tseliot> pitti: yes, they announced a downtime for code hosting at 14 UTC
<tseliot> pitti: "-u -k $YOUR_KERNEL" means update this specific kernel while "-u" by itself updates the latest
<pitti> tseliot: --help sounds like it would only update that particular versio then
<tseliot> which is why both commands are required
<pitti> ah, so they are cumulative
 * tseliot nods
<pitti> tseliot: looks fine, thanks
<pitti> tseliot: so it's one commit for reenabling fglrx, one for the initramfs, and one for dch -r/debcommit -r?
<ogra_ac> shouldnt that use triggers ?
<pitti> ogra_ac: can't -- it's just changing symlinks
<ogra_ac> ah
<tseliot> pitti: yes, commits 431-433
<pitti> tseliot: nothing new in ~ubuntu-core-dev/jockey/ubuntu
<tseliot> pitti: if you agree, I'll push my changes and then upload
<pitti> tseliot: please go ahead; thanks!
<tseliot> pitti: ok, pushed. Also, here's the debdiff for nvidia-common: http://pastebin.ubuntu.com/499148/
<tseliot> just 1 line
<tseliot> of code that is
<pitti> looks fine
<tseliot> pitti, superm1: I have one final change that I'd like to have in maverick. We spotted the problem in OEM when using chroots. It's a patch for DKMS which corrects the logic behind kernel selection (when building modules). I wrote the original code so I'm just correcting myself. Here's the (well tested) patch: http://pastebin.ubuntu.com/499094/
<tseliot> pitti: BTW I've just uploaded both jockey and nvidia-common
<jibel> tseliot, I've verified bug 642518 in hardy
<ubottu> Launchpad bug 642518 in fglrx-installer (Ubuntu Karmic) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,Fix committed] https://launchpad.net/bugs/642518
<jibel> tseliot, The module builds fine and is loaded correctly upon reboot, so that's great, but there is an error in the make.log see http://paste.ubuntu.com/499115/
<tseliot> jibel: let me have a look
<jibel> tseliot, I think that $srctree is not correctly set in the Makefile.
<tseliot> jibel: ah, so /usr/src/linux-headers-2.6.24-28-generic/include/config/compat.h exists, right?
<jibel> tseliot, let me check
<jibel> tseliot, yes it's there
<smb> tseliot, It might be that this is only printed on the first run
<smb> I think the makefile is called first normally, then srctree is not set, then it calls the kernel makefile and gets called from there and this time srctree would be defined
<tseliot> smb: ah, it could be. Shall we check $srctree in the code before doing grep?
<tseliot> or simply use grep -q so that the error doesn't show up
<smb> tseliot, That probably could be done (or encapsulate the grep and check into something like ifeq KERNELSRC). I guess i have the same (harmless) warning in lbm. But if people get confused and its easy to do, maybe that is a good idea
<smb> tseliot, Was that dkms package in hardy?
<tseliot> smb: yep
<smb> Ok, yeah. So more likely to get noticed
<nacho> hey guys
<nacho> not sure if you saw but even if we are not shipping a new version of gedit we do with gedit-plugins
<nacho> is there any reason to not include it  in maverick?
<tseliot> smb, jibel: I guess that simply passing "-q" to grep will remove that line from the log and it's a trivial change anyway
<smb> tseliot, If you used the line I sent you be aware that it relies on match text going to stdout. You may need to modify it a bit more
<tseliot> smb: yes, that's your patch. You're checking the exit status of grep, aren't you? "grep -q" will make it quiet
<smb> tseliot, No I was checking for empty or non-empty stdout output
<smb> So making the same quiet would be bad
<tseliot> smb: right, I've just re-read your patch
<smb> I probably should have paid more attention to the log output, but there is a bunch of that when doing lrm. So it just went under. And it worked.
<tseliot> smb: then something like this should work: ifneq ($(shell grep -q compat_alloc_user_space /usr/src/linux-headers-2.6.35-22-generic/include/linux/compat.h && echo "found"),)
<smb> tseliot, that looks reasonable as long as you have not hard coded the path.
<tseliot> smb: yes, I used that only to test things locally with the makefile
<tseliot> jibel: let me update the patch
<jibel> tseliot, the -q will only make the output quieter but since it's an error it goes to stderr
<jibel> tseliot, I mean you need to redirect stderr
<tseliot> "Quiet; do not write anything to standard output" i.e. I can't read the man page :P
<tseliot> jibel: -s should work though
<jibel> tseliot, why not run $(shell grep [...]) then test $$? ?
<jibel> tseliot, right -s should work. Let me update the Makefile
<cjwatson> if you test $$? outside the $(shell) then it will be in a different shell process, surely
<cjwatson> or at least may be
 * tseliot was trying to avoid $$?
<jibel> tseliot, it fails silently and the module builds. I'm now trying to build it with dkms
<tseliot> jibel: ah, good
<tseliot> cjwatson: do you know if there's a way to prevent lrm-envy from ending up in NEW? Something in the version that I use perhaps?
<tseliot> there's 2.6.24.503-503.32 in -proposed
<tseliot> hardy-proposed, that is
<cjwatson> tseliot: I doubt it
<cjwatson> tseliot: it'll be a soyuz bug
<tseliot> cjwatson: I suspected that but I had to try ;)
<jibel> tseliot, that's okay with dkms too.
<tseliot> jibel: ok, good. I'll upload a new version of lrm-envy with the updated patch
<tseliot> thanks for testing
<jibel> tseliot, you're welcome
<tseliot> uploaded
<era> can bug 165181 get a sponsor for its patch?
<ubottu> Launchpad bug 165181 in synaptic (Debian) "Order by "Supported" Column Slow" [Unknown,New] https://launchpad.net/bugs/165181
<tseliot> pitti: also, please approve lrm-envy in hardy-proposed when you're back
<tseliot> or whenever you have the time
<hallyn> james_w: hey, I'm trying to do a bzr dailydeb on a package that originally used 3.0 (quilt) format.  That appears broken in dailydeb.  Is there something I can trivially substitude?  I tried 1.0 (quilt) but got broken depend on Dpkg::Source::Package::V1::quilt
<james_w> hallyn: it's just "1.0" not "1.0 (quilt)"
<james_w> and it's not a trivial substitute as it doesn't have built in quilt support
<hallyn> james_w: anything else I can try?
<james_w> there's not a great answer right now unfortunately
<hallyn> ok, so i'll just manually apply the patches out of debian/rules pre-build
<hallyn> any estimates as to when 3.0 might work?
<james_w> that's the best I can offer right now
<james_w> no idea, I haven't heard of a good solution yet
<james_w> bug 614768
<ubottu> Launchpad bug 614768 in bzr-builder "Unable to build dpkg v3 (quilt) packages" [High,Triaged] https://launchpad.net/bugs/614768
<smoser> james_w, thanks for the 'changelogs.u.c' pointer. embarrisingly never had seen that before.
<hallyn> james_w: thanks
<james_w> smoser: np
<pitti> tseliot: oh, another one? I binNEWed it this morning
<tseliot> pitti: yes, jibel riported a problem with an annoying message coming from grep
<tseliot> pitti: the new upload is just a cosmetic change
<pitti> tseliot: ah, thanks; will look at it
<tseliot> pitti: great, thanks (together with jockey and nvidia-common) :)
<pitti> tseliot: done, thanks
<tseliot> pitti: thanks a lot
<ari-tczew> pitti: when do you plan review lucid-proposed for approval?
<pitti> I did way too much queue review today already..; no plan yet, just "soon" :0
<jcastro> bdrung_: f-spot is also affected by the submodule bug (since you're in there already)
<bdrung_> jcastro: submodule? bug number?
<jcastro> bug 402814
<ubottu> Launchpad bug 402814 in Launchpad Bazaar Integration "Importing revisions with submodules is not supported" [Wishlist,Triaged] https://launchpad.net/bugs/402814
<bdrung_> jcastro: ok. added
<bdrung_> 8 projects. i want an working import for vlc. currently i am using a workaround
<Keybuk> kees: have you been fiddling? :-)
<Keybuk> deathspank scott% iwconfig |& grep eth1
<Keybuk> eth1      IEEE 802.11  Access Point: Not-Associated
<Keybuk> deathspank scott% sudo iwconfig |& grep eth1
<Keybuk> eth1      IEEE 802.11abgn  ESSID:"attwifi"
<Neko_> Keybuk, hi, ogra just informed me upstart relies on 2.6.35, any description available of why that is?
<Keybuk> Neko_: I don't know why ogra informed you of that, no
<Keybuk> to be honest, I don't know why ogra does many of the things he does ;-)
<Neko_> so there should be no weird features in udev or upstart or anything else that basically relies on some fancy new sysfs or so feature of 2.6.35 over, say, 2.6.31, that hasn't got some workaround?
<Neko_> I'm hoping nobody bothered to clean it up since Karmic/Lucid
 * ScottK is pretty sure he didn't say that.
<Keybuk> Neko_: you didn't say udev
<Keybuk> you said Upstart
<Keybuk> udev certainly relies on whatever the *latest* kernel version was at the time that version of udev was released
<Keybuk> which is only natural, since udev is pretty much the kernel's userspace partner
<Neko_> how do udev releases map to kernel releases? :/
<Keybuk> take an Ubuntu release
<Neko_> I mean say, udev 117.. how do I know which kernel that would be happy with
<Keybuk> whatever version of udev is chipped with that release, needs whatever kernel was shipped with that release
<Neko_> is that an ubuntu udev thing or a www.kernel.org/udev thing?
<Keybuk> well, you won't find it on either
<Keybuk> but a good guide, first look at:
<Keybuk> https://launchpad.net/ubuntu/+source/udev
<Keybuk> 117 was shipped in Hardy, so look at:
<Keybuk> https://edge.launchpad.net/ubuntu/+source/linux
<Keybuk> err w/o the edge obviously
<Keybuk> Hardy had 2.6.24
<Keybuk> so figure that udev 117 needs kerenl 2.6.24
<Neko_> I somehow doubt 147~-6.1 is going to run on Maverick even if we try
<Keybuk> forwards compatibility tends to be much better than backwards
<Keybuk> usually you can update your kernel without updating your udev
<kees> Keybuk: with wifi? no... why?
<Keybuk> for the most part, it works, occasionally you may need to update rules if you care about a particular new subsystem of that new kernel
<Keybuk> kees: see the paste - it amused me - it's the kind of thing you'd like
<Keybuk> kees: you can only see what AP you're associated to if you're root ;-)
<Keybuk> Neko_: indeed, it's this slight focus on making sure that forwards compatibility works that means backwards compatibility doesn;t
<kees> Keybuk: oh, I missed the sudo. weird.
<kees> Keybuk: it's probably all the same query call that includes the key too
<Keybuk> I'd guess iwconfig is making a kind of "give me everything" query
<kees> Keybuk: s'okay, until current kernels, I could read the kernel memory that held that info directly. ;)
<Keybuk> kees: *grumpy*
<Keybuk> I want /dev/kmem back, damnit
<Keybuk> of course, in Ubuntu, you can just ask NM for the same info - which happily sends it over D-Bus ;-)
<kees> yup :)
<kees> nothing stops you from compiling and running a kernel with /dev/kmem. :)
<ogra_cmpc> Keybuk, i said that things like upstart and udev sometimes rely on kernel features, in some releases more in some less
<ogra_cmpc> Keybuk, and that if you roll an ubuntu image of maverick with your own kernel you should have a 2.6.35
<kees> pitti: what do you think of a 30 min default? I don't want gnome-keyring to remember forever as a default...
<Keybuk> ogra_cmpc: right, that's good advice
<Keybuk> if you roll your own images of any ubuntu version, only *update* software
<Keybuk> never downgrade
<Keybuk> kernel 2.6.36, 37, 38, ... should be fine too
<ogra_cmpc> Keybuk, especially if you try to revive an arch we dropped :)
<Keybuk> kees: yes, but you'd stop me uploading that to the archive as the default :p
<ogra_cmpc> and see weird bugs nobody can explain
<Keybuk> there are reasons it's a dropped arch :p
<ogra_cmpc> yes :)
<kees> Keybuk: indeed, since only you need kmem :)
<Keybuk> kees: no, everybody needs kmem!
<Keybuk> because otherwise there's no way to get the string arguments to functions out of the kernel while tracing ;-)
<Keybuk> the tracing infrastructure simply returns the address of the string, not the string :p
<Keybuk> (as you well know)
<kees> Keybuk: key part of your sentence "while tracing"
<kees> :)
<Keybuk> kees: tracing is for everybody
<Keybuk> automated performance optimisation, etc.
<Keybuk> hell, you could even do automated intrusion detection by having something trace the kernel looking for unusual call patterns :p
<kees> if something genuinely has general-purpose utility, a specific interface to the kernel needs to be built. /dev/kmem isn't really the right answer for that.
<Keybuk> ideally ftrace would just return strings :p
<Keybuk> but I suspect certain security people would object if all strings were returned by the kernel :p
<Keybuk> got to run -- bbiab
<stgraber> ogra_cmpc: ping
<SpamapS> is there a way to start using merge-upstream when you already have the upstream+debian in a branch? Every time I attempt this, it just goes horribly and deletes the debian dir. :(
<james_w> SpamapS: packaging is bad and must be deleted
<SpamapS> and punished? ;)
<james_w> I think Didier has seen that problem, but I can't remember the cause now
<james_w> SpamapS: what command are you running?
<SpamapS> bzr merge-upstrea --version x path/to/new/tarball
<SpamapS> m
<SpamapS> forgot the m
<james_w> ok
<james_w> and this is a packaging branch, or the upstream branch?
<james_w> did you set an upstream- tag by hand?
<SpamapS> This is my packaging branch
<SpamapS> I've tried that yes
<james_w> I think it must be thinking that the ./debian dir used to be in upstream but has now been removed
<SpamapS> I've also tried importing just the latest version, reverting the deleted debian dir, and then committing, tagging that (so its a single change that just has upstream in it)
<lifeless> kees: ping
<lifeless> kees: I want some security team cycles, and AFAICT its a last minute launchpadlib thing for Ubuntu 1 / Ubuntu SSO so it is sadly urgent.
<lifeless> kees: I've mailed you, but if you're not the best places person to comment... please do.
<lifeless> point me at someone else.
<james_w> SpamapS: that sounds reasonable to me
<james_w> did it not work?
<SpamapS> james_w: no, still deleted the debian dir
<james_w> SpamapS: you ran merge-upstream twice in that scenario?
<SpamapS> I'd be fine if I could say --ignore-packaging or something
<SpamapS> james_w: I reverted everything that merge-upstream did
<james_w> latest == version already in packaging branch, then you imported again for a new upstream release?
<SpamapS> basically what I did was create my own private packaging branch to package an upstream project ... after about 3 releases .. I wanted to use merge-upstream.. so I did merge-upstream, which deleted debian, so I reverted..
<SpamapS> I have this in a pushed branch btw
<james_w> ok, let me take a look
<SpamapS> https://code.launchpad.net/~clint-fewbar/clb/packaging
<SpamapS> http://bazaar.launchpad.net/~clint-fewbar/clb/packaging/revision/7
<SpamapS> so thats the first one where I tagged it upstream-something
<SpamapS> when I try to merge-upstream 0.4.1's tarball.. debian is still deleted
<james_w> SpamapS: ok, I think we can fix this for the future
<james_w> do the merge-upstream of 0.4.1, bzr revert ./debian, bzr commit -m "Merge 0.4.1 release", and then continue from there
<james_w> 0.4.2 should import fine on top of that
<kees> lifeless: okay, I'll read
<SpamapS> james_w: ah, ok. :)
<james_w> SpamapS: not sure what you did with 0.4, but upstream- tags shouldn't be set by you in normal use, only as a bootstrapping
<lifeless> kees: thanks
<james_w> it looks like you reverted a lot, then set the upstream- tag on the packaging, which tells bzr-builddeb that all of that is upstream, so it will continue to delete the debian dir
<SpamapS> james_w: ok, I'll refrain from trying to outsmart it. :)
<james_w> upstream- tags are set on the "pristine upstream" branch that is part of the history, and the diff between the latest one tagged with that and the tip what bzr-builddeb considers the packaging, and what it will conserve in the merge
<james_w> SpamapS: never try and outsmart dumb code ;-)
<lifeless> james_w: is that like arguing with fools?
<james_w> indeed
 * SpamapS certainly rushed in
<SpamapS> james_w: ok, so I deleted the upstream-0.4 tag..
<SpamapS> james_w: now trying to bootstrap.. getting
<SpamapS> bzr: ERROR: Unable to find the tag for the previous upstream version, 0.4, in the branch: upstream-0.4
<SpamapS> using --last-version=0.4
<james_w> SpamapS: ah, put the upstream-0.4 tag back if you are using --last-version=0.4, or use --last-version=0.3
<SpamapS> james_w: I have no upstream-xxx tags
<james_w> I thought I saw an upstream0.3 one
<SpamapS> So.. is the point that to bootstrap, one must manually tag the branch and then revert what it messes up?
<SpamapS> yeah there was an 0.3 but that was was screwed up too
 * SpamapS gives up, and just uses import+revert :-/
<james_w> SpamapS: exactly
<achiang> is there an appropriate channel to ask audio stack questions?
<kees> lifeless: ow ow my eyes. I will try to develop a coherent reply to this proposal.
<lifeless> kees: so I wasn't jumping at ghosts ?
<kees> lifeless: no, it needs a little more thought. frankly, the gnome-keyring philosophy is flawed, but yes, there is a good and mostly valid point about security theater. however, I think this proposal overcorrects too far. I'll write up my thoughts. I've asked the rest of the team to chime in too.
<lifeless> great, thanks.
<maco> hmm theres still something buggy about boot. i get it on both laptops that run maverick and i think i saw an ubuntu (not kubuntu) user say they hit it too... where after plymouth is done doing its thing, instead of going to the dm it just sits there displaying the getpwid(0) error (which afaict is harmless -- its there on good boots too, just hidden by gdm/kdm) on a black terminal and you cant change VTs to restart your dm...
<maco> i had it with lucid too though, so its not a new bug
<maco> just annoying to have ~ 1/4 of boots fail
<maco> any of you other developery types hitting that?
<ScottK> maco: IIRC there's an open bug about it.  I haven't been hit.
<maco> ScottK: any idea what package was deemed the cause so i can narrow down lp?
<ScottK> maco: I have a vague recollection is was filed against plymouth or kdebase-workspace, but I don't actually know.
<slangasek> yes, the getpwuid(0) is spurious and unrelated to the problem you're having; but I haven't seen this particular problem
<slangasek> the problems users have reported against plymouth are largely "plymouth never starts, and I get this error message"
<maco> mm i can try rebooting a few more time to hit it again, but i thought the splash was there before that message
<maco> (my systems all boot in < 10 seconds so i tend not to actually *see* bootup happening)
<maco> ok splash was *definitely* there
<maco> (wow 2 out of 3 boots today!)
<maco> (i mean, 2/3 were failures)
<maco> slangasek: is there a correspondence between what stage of boot it is and the dots, or are the dots not a true progress indicator?
<slangasek> I don't think that's straightforwardly reversible to tell you where you are in the boot, no
<achiang> last time i looked at plymouth code, the dots just animate on a timer, iirc. nothing to do with actual progress
<maco> aww
<kees> lifeless: replied
<lifeless> thanks
<lifeless> thanks kees, you were remarkably phlemgatic :)
<kees> lifeless: uhm, thanks? I have no idea what that really means in that context. :)
<lifeless> kees:  balanced
<lifeless> kees: unflappable
<kees> lifeless: yeah, managed to educate myself just now. figured "producing phlegm" wasn't what you meant. :)
<barry> ajmitch: hi!  good having you on the udd meeting yesterday.  as stakeholder for revu, you might want to subscribe to this wiki page (and subpages): https://wiki.ubuntu.com/DistributedDevelopment
<ajmitch> ok
<barry> ajmitch: and the mailing list (i will send out a summary of the meeting shortly)
<ajmitch> I've been on the mailing list for awhile :)
<barry> awesome!
#ubuntu-devel 2010-09-24
<lamont> it'd really be nice to be able to read the PDFs my bank sends me without booting windows.
<lamont> (write password, null read password)
 * lamont wonders which package to file that bug against
<Keybuk> evince
<Amaranth> Really? I thought it'd be poppler
<Keybuk> well, poppler perhaps
<Keybuk> I usually start at the top and let them worry about it ;-)
<Keybuk> though I think poppler is now libpdf or something
<ScottK> lamont: I think okular will handle those.
<achiang> lamont: send me your bank statements, i'll read them to you. ;)
<RAOF> evince in Maverick grew the ability to read my bank statements, which was nice :)
<lamont> ScottK: I'd prefer not to install the world of kde just to see it.. I'd rather libpdf got smart enough to open null-password files
<lamont> achiang: heh
<ScottK> lamont: It should be somewhat less than the whole world these days.  Isn't that still better than having to use Windows.
<ScottK> lamont: It's just kdelibs and the base runtime.  None of the workspace components needed.
<lamont> 9 upgraded, 64 newly installed, 0 to remove and 221 not upgraded.
<lamont> Need to get 56.0MB of archives.
<lamont> which tells me it's time for a dist-upgrade
<lamont> I'd be happy enough to just know which packages I need to downgrade to hardy-versions, since I think libpdf or whatever just didn't believe in passwords back then, or something like that
<lamont> Keybuk: so is libpdf the right place to file the bug?
<Keybuk> errr
<Keybuk> I really don't know
<Keybuk> I find that application authors are much more helpful if you misfile a bug on them, than library authors
<Keybuk> a bug filed on a library tends to stay there ;-)
<lamont> ah, good point
<lamont> though epdfview (libpoppler based) has the same issue.
<lamont> I'll toss it at evince
<dugger5688> I'm looking to create an indicator applet, anyone know a good tutorial?
<kklimonda> dugger5688: I don't think there is a good (or any) tutorial, you should just read source of applications that use it
<dugger5688> kklimonda: That's what I ended up doing, thanks.
<mgunes> dugger5688, these might be of help: https://wiki.ubuntu.com/MeetingLogs/devweek1001/AppsOnThePannel , https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Technical%20Resources
<persia> ajmitch, Hey.  Do you have a bit of time to talk about ARB/-extras and how this affects the support team?
<pwnguin> woa
<pwnguin> another dugger
<ajmitch> persia: alright
<persia> ajmitch, So, if I'm reading stuff correctly, if there is a bug, there is an expectation that the author will fix it, and arbitrary developers won't be able to upload changes.  Is that correct?
<ajmitch> at the moment I'm unclear on the permissions surrounding extras.u.c
<wgrant> It's the ~a-r-b PPA.
<persia> Right now !extras is an alias to !repos, which doesn't mention extras.u.c at all, and I think we'd do well to advise the support teams of what level of support we can offer, and how they can request it, etc.
<ajmitch> wgrant: right, I wasn't sure if that PPA was just a staging area or if extras was being exposed as another pocket
<wgrant> ajmitch: It's synced from the PPA and resigned.
<persia> pocket copy from the PPA to somewhere else or not isn't really important: mirror implementation detail :)
<wgrant> This makes the set of extremely dangerous Launchpad users quite a lot larger :(
<persia> How so?  Isn't the ~a-r-b PPA restricted to ~a-r-b members?  That's only four new people to trust.
<persia> (although they are subject to less peer-review than usual)
<ajmitch> persia: to be honest, I was expecting to have a little bit of time to discuss implementation specifics on the list before the process was announced :)
<wgrant> persia: ~a-r-b isn't just the ARB.
<wgrant> It has a few others as well.
 * persia digs at LP
<ajmitch> https://edge.launchpad.net/~app-review-board/+members
<persia> Right, so untrusted folk are tremolux, wendar, jono, and fagan, with special danger from tremolux, and jono, and expanded permissions for mvo.
<persia> Given that mvo basically controls how we install software anyway, I'm not sure that it's really expanded permission there.
<persia> So just tremolux, wendar, jono.
<persia> Anyway, that's a separate can of worms than the one I wanted to review today :)
<ajmitch> ideally it'd be owned by the TB
<ajmitch> right, the issue was of bugfixes
<ion> Couldnât there have just been an âextrasâ component alongside main, restricted, universe and multiverse, with a similar process to them (with -proposed and all) etc?
<persia> So if it is the ~a-r-b PPA, then I'm fairly confident that ~ubuntu-dev can't support it.
<persia> ion, No, for complicated reasons having to do with Release and Packages files.
<ajmitch> why I was wondering if it was a separate pocket was whether the packages will even show in launchpad to be able to file bugs against them
<persia> wgrant, Do you know if Malone will allow bugs to be filed?
 * freeflying 
<persia> ajmitch, Whilst we wait, I was thinking we might adjust !extras to be "extras.ubuntu.com contains new software made available after the formal release.  This software is unsupported by the Ubuntu team, but the original authors offer some support."
<persia> Does that wording seem acceptable to you?
<ajmitch> that seems reasonable
<persia> OK.  I'll request that change, and let the meme seep through the various channels by which the support team collect information :)
<persia> Err, rather "extras.ubuntu.com is an additional !repo that contains..."
<TheMuso> g/c
<ScottK> persia: It's not just unsupported.  It's not part of Ubuntu.
<persia> ScottK, You have better alternative text?
<kklimonda> repo's url is misleading :/
<wgrant> I don't understand why it's under ubuntu.com
 * ajmitch would love to stay & discuss that, but has a bus to catch in 5 minutes :P
<ScottK>  "extras.ubuntu.com is an external repository for new software made available after the Ubuntu release.  This repository is not part of the Ubuntu distribution and the software is completely unsupported by the Ubuntu team, but the original authors may offer some support."
<wgrant> persia: To LP it's just another PPA.
<wgrant> persia: It's not like partner.
<ScottK> persia: ^^^
<persia> wgrant, So no bugs.  Thanks.
<persia> ajmitch, Does ScottK's suggestion also work for you?
<ScottK> persia: But you can make a project with the same name that can get bugs.
<kklimonda> ScottK: Is "completely" really necessary?
<ScottK> persia: See ~kubuntu-ppa and /kubuntu-ppa for an example.
<ScottK> kklimonda: Yes.
<persia> ScottK, Right, but not using the recommended bug reporting mechanisms (e.g. ubuntu-bug, apport, etc.)
<wgrant> kklimonda: Universe is also unsupported.
<ScottK> persia: Of course not.  Those are recommended for Ubuntu and this is not part of Ubuntu.
<kklimonda> ScottK: I mean, are people going to get confused if we leave this word out.
<wgrant> kklimonda: So it needs to be made clear that extras are even less supported.
<persia> wgrant, For some value of "unsupported"
 * persia will be filing a blueprint about that any day now
<wgrant> persia: Yes, but it's billed as unsupported.
<persia> I know.  I just wish that it wasn't, or that what was billed as "supported" had a well-defined support group.
<ScottK> kklimonda: Here's what is said about Universe in sources.list: software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu team.
<ScottK> This is less supported than that.
<persia> Considerably.  Lots of folk support lots of parts of universe.
<kklimonda> ScottK: whoa, I haven't seen that :)
<persia> Some folk release flavours based on healthy chunks of universe.
<wgrant> Who decided it would go under extras.ubuntu.com?
<wgrant> That's asking for trouble.
<persia> wgrant, opaque
<ScottK> wgrant: Probably rickspencer3.
<wgrant> Yay.
<ScottK> wgrant: It's all been pointed out multiple times, but they are doing it anyway.
<wgrant> I know.
<wgrant> I just hoped that some new knowledge might have come to light.
<persia> All the more reason to ensure the support team understands: we can best avoid confusion by prepping the first line to give good answers.
<ScottK> I don't think there's much actual knowledge involved.
<wgrant> As well as giving an incorrect image, it also grants unvetted people access to my machine.
<wgrant> Previously it would need someone who had been interrogated by the DMB.
<persia> Only four of them, and in a way that can be avoided.
<wgrant> There are members on the ARB who are not ~ubuntu-dev.
<persia> Right.  jono, wendar, fagan, and tremolux
<dmb> i don't interrogate anyone :(
<persia> dmb, But we, on the DMB, do.  Capitalisation is important.
<ScottK> dmb: You are a dmd, but not the DMB.
<dmb> :)
<persia> ajmitch, So, can I use ScottK's version, or do you want me to proceed with mine?  (I like ScottK's better)
<kklimonda> ScottK: do you know whether there have been arguments for not doing it through -backports? Is it to make it easier for.. random developers to get their software into Ubuntu?
 * persia would also accept a nod from stgraber, mvo, or statik
<kklimonda> I just don't quite understand how does it help us to deliver good software..
<ScottK> kklimonda: It's all been discussed.  They've decided to do it the way they are doing it.  The community input is not particularly relevant.
<ScottK> kklimonda: It doesn't.
<ScottK> It lets Canonical make a marketing point about Ubuntu being great for app developers.  The technical reality doesn't seem to be particularly important.
<wgrant> ScottK: It's not been discussed.
<wgrant> Discussion was not allowed.
<wgrant> Or was ignored.
<ScottK> wgrant: No.  It was discussed at UDS-M.
 * persia didn't want to bring up all the potential things about extras.ubuntu.com: just to set some expectations for the support team
<kklimonda> I'm not fond of entire "opportunistic development" idea and now this..
<ScottK> It was "too hard".  Implementing a whole new pocket was easier.
<ScottK> kklimonda: I think opportunistic development is a great thing to support since a LOT of that kind of work goes on inside companies, but that doesn't translate at all into the arb stuff.
<persia> A lot of that work goes on outside companies too, resulting in nifty cool things.
<stgraber> persia: I'm fine with both yours and ScottK's versions. The "external" bit is going to be quite unclear for a lot of people I'm guessing as it's going to be on .ubuntu.com but I don't really have any better suggestion.
<stgraber> (sorry, took me a while to read the backlog)
<ScottK> stgraber: I'd like it better if it were on canonical.com (it would be clearer), but not much we can do about that.
<wgrant> Maybe we can get it fixed for Natty.
<kklimonda> ScottK: persia: but those cool things created outside of companies are often buggy or.. really simple. I haven't seen anything cool myself other than various scripts which are more of hacks -- in a good way -- then applications. Or maybe I'm just afraid that we'll create environment for tinkerers.. which isn't actually that bad.. but I feel like it misses the spot, especially when people blog
<kklimonda> about new indicators which are against guidelines created by Canonical designers. But then I may be prejudiced - "opportunistic" has a really negative meaning in Polish.
<ScottK> kklimonda: When it's good, it's about it being easy to solve a small local problem.  We should be in favor of that.
<ScottK> Converting that into applications that are suitable for general use is a lot of work.
<ScottK> Nominally it's an order of magnitude harder (See Fred Brooks, The Mythical Man-Month).
<ScottK> That's where the confusion is.
<jono> persia, I am not on the ARB, to be clear
<wgrant> jono: Hm, but you're in ~a-r-b...
<ScottK> jono: But you're on the LP team, so you have whatever accesses it has.
<stgraber> ScottK: well, canonical.com would feel weird too as it's not a canonical-only archive as partner is for example, but I'd certainly like to see that evolve into something more like the archive, where the ARB would act as archive admin (looking at the queue, accepting new packages, ...) and having the other ubuntu-dev be able to upload updates as usual. That'd also mean that bug could be reported as for any other packages (ideally, LP would m
<kklimonda> ScottK: every time I see this title I read it "The Mythical Man-Moth" ;)
<wgrant> stgraber: You got cut off.
<wgrant> stgraber: But that sounds like -backports.
<highvoltage> jono: ah, it says that you are on https://launchpad.net/~app-review-board/+members but I guess it's just because you're meant to administer it then?
<jono> highvoltage, yep
<ScottK> stgraber: Unfortunately many of the things one needs to know to be do archive admin work aren't in what they ask for for ARB members.
<jono> I just set up the team, that's all
<jono> I am not eligible to assess apps
<ScottK> jono: But the secuirty footprint is the same is if you were.
<wgrant> I don't too much care about the ARB making bad decisions.
<YokoZar> ScottK: I want to eliminate the spring package duplication  (spring-engine needs to be a dummy that installs spring).  Can I just upload a new spring package providing the dummy or do I need to first file a task to remove spring-engine?
<jono> ScottK, security footprint?
<stgraber> wgrant: "(ideally, LP would make it clear that it's on "extra" and not supported in any way)" I guess that's the missing part ;)
<ScottK> YokoZar: Go ahead and then file a bug asking for removal of the old source.
<wgrant> I care about the fact that compromise of their browser results in compromise of every Ubuntu machine on the planet.
<ScottK> jono: If someone gets your LP cookie, they can do the same stuff any arb member can do.
<jono> ScottK, is this something you are seriously worried about? I think I can maintain my security :-)
<wgrant> jono: I don't think anyone can. I have had LP admin cookies on multiple occasions.
<wgrant> People make mistakes.
<ScottK> jono: Security is about minimizing risk and removing it where it's not necessary.
<wgrant> The fewer people can make fatally large ones, the better.
<jono> ScottK, right, but what is the worst that could happen? they can post to the group - there is no upload access from the arb group
<wgrant> jono: Er...
<wgrant> jono: They own the PPA.
<wgrant> http://extras.ubuntu.com/ubuntu/dists/maverick/Release
<jono> erk, wise point :-)
<jono> lol
<wgrant> extras.ubuntu.com is that PPA, resigned.
<jono> what would you recommend I do to mitigate the security risk?
<jono> leave the team?
<wgrant> I don't know.
<ScottK> Turn over the team to the tech board, probably.
<wgrant> It needs to be discussed with people.
<jono> well I am happy to take appropriate steps
<wgrant> And not just rushed through without consulting anybody.
<wgrant> srsly.
<jono> ScottK, seems entirely reasonable
<jono> maybe I can hand it to the TB and they can discuss appropriate actions
<ScottK> If any of them get compromised, we're already screwed, so this doesn't make it worse.
<jono> ScottK, if you have a better suggestion I am happy to hear it
<highvoltage> jono: the whole ARB thing is a serious blow to the quality of ubuntu process, stgraber's suggestion makes a lot of sense
<ScottK> No, I think that's the best thing, but I'd discuss it with them first.
<jono> highvoltage, what was stgraber's suggestion?
<wgrant> highvoltage: Who needs input from the development community? Silly.
<jono> wow, it is frosty in here
<highvoltage> jono: scroll up a bit to the part about 23:37 < stgraber> ScottK: well, canonical.com would feel weird too as it's not a canonical-only archive as partner is for example, but I'd certainly like to see that evolve into something more
<jono> remember this process is experimental and we are going to discuss this at UDS
<jono> and if required adjust and refine where required
<persia> jono, If you don't want to be on the team, there's a way to be owner of the team, and not a member, but still admin.  I don't know the details of setting that up, but it's why I can't upload to most of main.
<jono> I was merely asked to put together the process, which I did
<highvoltage> jono: what is more frosty? good feeback from people who care? or canonical saying they're going to implement something really bad and they don't care what anyone has to say about it?
<persia> jono, This doesn't make the risk much lower, but a little bit.
<jono> persia, ahhh thanks for the input, I will investigate this
<jono> highvoltage, I was referring to the general tone in here, it just feels rather frosty
 * highvoltage hands jono a cup of hot chocolate
<jono> lol, thanks :-)
<persia> jono, Note that you still need to preserve your keys: I'm not core-dev, but my LP credentials are at least as useful to an attacker as any core-devs.  Yours will soon become considerable (getting your LP password means having root on millions of machines)
<ScottK> jono: The whole ARB thing does seem to have been implemented in a manner that was pretty impervious to community feedback.
<jono> I am not denying that things can be improved in the process, absolutely, and we should have a throrough assessment at UDS
<jono> ScottK, I disagree
<ScottK> I'm not suprised.
<jono> ScottK, I believe that community feedback has been accomodated, but the outcome is not what you would prefer
<persia> So, can we dispute specific technical issues?
<jono> ScottK, I am fully aware of your unhappiness and concern with the ARB
<wgrant> So we are opening up new holes on people's machines... before we do the assessement.
<ScottK> jono: I'm not the only one.
<wgrant> Awesomeness.
<persia> There's been some process issues, but I think we'd do better to fix it than to go over what happened badly so far.
<jono> ScottK, agreed, but there are also others who welcome the process
<jono> persia, I think UDS is the perfect venue to bring all concerns
<jono> persia, agreed
<persia> jono, I think it's important not to conflate people who want it to be clearer and easier to add apps post-release with people who like a specific process.
<ScottK> jono: Why?  Last UDS it wasn't so perfect.  Why will this one be different?
<jono> persia, agreed
<ScottK> jono: I agree with the goal, I just think this is a very poor way to achieve it.
<jono> ScottK, because we can try the process, assess it's success, and review it at UDS
<jono> ScottK, I know this, we have already discussed this
<jono> I am not wanting to deafen you, but I am not sure why we should have the conversation again
<ScottK> Absent appropriate technical underpinnings, the process can't succeed.
<jono> I think we are clear on each other's points
<ScottK> Certainly.
<jono> ScottK, I think your feedback and a solid review at UDS will be very valuable
<ScottK> We'll see.
<jono> and as I made clear in the discussions, my sole resonsibility was to put together an assessment board, I am not qualified to provide input on the technical implementation
<wgrant> Forcing feedback to occur after it's all already implemented seems a little odd.
<ScottK> I'm aware of that.
<jono> if you disagree with the governance, then that is up to me, but it sounds like your primary concern is the technical approach
<ScottK> jono: Don't get confused with me being upset about the structure as a whole and me blaming it all on you, I don't.  I know what you were trying to do.
<jono> personally I think the sandboxing approach you mentioned on the phone, ScottK, makes great sense
<ScottK> It's the only way.
<highvoltage> ScottK: jono doesn't seem to understand the problems (or doesn't want to)
<jono> ScottK, I know, and I respect your honestly and balance
<jono> highvoltage, what don't I understand?
<ScottK> highvoltage: I think it's mostly just not in the part of the initiative that's his problem.
<jono> ScottK, yeah, again, with the caveat that I am not the best qualified on the technical approach, I agree that a sandbox seems the best approach and safe
<ScottK> jono: My biggest problem with the process is that absent that appropriate technical basis, it's horribly premature.
<persia> jono, I think folks have issues with both, on three points: 1) that the technical critiques and alternate model discussed at UDS (and afterwards) did not appear to be considered, 2) That the body of approvers is not restricted to the already trusted ~ubuntu-dev, and 3) That the process development was relatively opaque, even to members of the new board.
<highvoltage> jono: 23:47 < jono> ScottK, I believe that community feedback has been accomodated, but the outcome is not what you would prefer
<highvoltage> jono: that sentence tells me that you haven't really been listening
<jono> persia, on the latter point, I was entirely guilty
<persia> jono, I don't claim this is the place and time to discuss it, but I think it's important to separate the concerns in order to avoid pointless arguments blocking real progress.
<jono> the process was developed in the open (wiki, with the TB etc), but I did a terrible job of involving ubuntu-devel
<jono> highvoltage, how does this infer that I have not been listening?
<jono> highvoltage, just because the eventuall decision was not in line with some opinion on ubuntu-devel does not mean I wasnt listening
<persia> jono, Always feel free to lean on me if you're unsure how to involve development folks in something.  I can't promise people will like it, but I can promise you'll get feedback and discussion.
<jono> highvoltage, also, as I have made clear, I am not involved in the technical implementation
<jono> highvoltage, and I apologized fully about not involving ubuntu-devel enough
<highvoltage> jono: because you think that it's just about prefered outcome. it's not, it's that people care about ubuntu and want to make it better, and this process isn't doing that
<jono> highvoltage, hence, I believe I did listen in the area of *my* responsibility, but you should not judge me based on the responsibility of the technical process
<highvoltage> jono: yay plausable deniability.
<jono> persia, I always respect and value your opinions and experience, thanks for the offer
<persia> highvoltage, Don't kill the messenger: jono didn't have choice about some large parts of this (as I interpret backscroll)
<jono> persia, again, I really could have done a better job with the process development
<highvoltage> persia: ok
<highvoltage> jono: sorry if I come across too hard
<jono> highvoltage, no worries, pal - I am sorry you are frustrated :-(
<persia> highvoltage, Not that I'm telling you not to raise the points, just not to pin it all on one person :)
<wgrant> Where are we to give feedback?
<jono> highvoltage, yeah, I think your points are better attributed to those who built the technical implementation
<wgrant> The ARB doesn't know why it happened like this.
<jono> wgrant, what kind of feedback? technical process?
<wgrant> jono: Technical issues, process issues...
<jono> wgrant, feel free to provide process issues to me
<jono> technical issues, Rick Spencer is probably a good person to talk to
<wgrant> Discussion on the ML was limited to being told that it was all set in stone.
<persia> jono, I suspect that those answers are likely some of the issue: I suspect people would like to hear "The CC" and "The TB".
<wgrant> Do the CC or TB have power any more?
<jono> wgrant, well, that is not 100% true, nothing was set in stone, but I agree that a largely completed draft was presented to ubuntu-devel as a whole, and I have said, that was a mistake on my part
<persia> Some, in some areas, depending.
<wgrant> As I see it, Platform will come along and push things, and the relevant governance body might wave them through.
<jono> wgrant, why do you assume that?
<jono> neither the CC or TB is pushed to approve anything
<jono> I can 100% guarentee this
<jono> and I would whole-heartedly push back if Canonical tried to force the hand of the CC or TB
<wgrant> It was apparently accepted without any discussion with people not directly related to its implementation.
<ScottK> jono: That's true, but they are busy people.  They evaluate what is put in front of them.  The analysis of alternatives given to the TB didn't even include using the existing backport pocket as an option that was consdiered.
<persia> jono, CC is fairly independent, but also fairly inactive, which is OK, but lots of stuff gets directed to you, rather than to CC, which complicates the picture.  No offense to you, but it weakens the perception of CC as point of contact and point of decision.
<jono> wgrant, the TB evaluated the process and made a series of suggestions which were merged in, they then approved the process based on the changes
<jono> wgrant, and I have already apologized for not including ubuntu-devel in the discussion, not sure what else you want me to do, I can't change history :-)
<persia> Most of TB is privy to data that may not be widely exposed, and under (mild) restrictions: they are unlikely to disagree with certain classes of initiative (many of which are good in the first place).
<jono> wgrant, I can assure you I will not make the same mistake again
<jono> ScottK, I agree, but I am not sure it is scalable to present alternatives with every proposal to the TB - I do though have faith that if the TB felt an approach had a better technical alternative, they would pick up on it
<wgrant> I am disappointed that we have a new, opaque, extremely security-sensitive process.
<persia> I firmly believe that the CC and TB are able to control the project if they choose to do so.  I'm not sure that such a choice has always been made in the past.  I'm not convinced that waiting for complaints is not a useful way for the boards to operate, as long as people are making complaints.
<wgrant> And we *cannot* fix it.
<jono> persia, well things often come to me, but if it affects the charter that the CC are responsible for, I send it to the CC
<jono> the CC never ask me to make decisions
<jono> but indeed many come to me before the CC, and then I move it to the CC if it needs their attention
<persia> jono, I know.  I see that.  Doesn't change the perceptions I hear from folks not as familiar with our governance structures as you and I :)
<jono> persia, maybe we need to improve that perception, what do you think we could do to improve it?
<ScottK> jono: The wiki page specifically described alternatives that were considered and didn't include the one that to many of us made the most sense.  That's really, in some sense, cooking the books.  I don't blame the tech board a bit.  They can't evaluate information they don't have.
<persia> jono, To be clear, I'm not critiquing you.  I think you are a valuable member of our community, an important leader, and do your job well.  That doesn't mean I don't think there are areas for improvement, here and there.
<jono> wgrant, i am sorry for your frustration, but we did discuss reviewing the process at UDS, and I think you should express your feedback strongly then
<wgrant> jono: ... after the process is implemented.
<jono> ScottK, the process I put together didnt outline alternatives
<persia> jono, I think that it makes sense to sit down and review all our governance structures, who reports to whom, how, what accountability groups have, what responsibilities groups have, etc.  And make sure it's all in one document somewhere, and point folks there.
<persia> jono, I'm hoping the track you lead at UDS will let us start on some of that.
<jono> persia, it might be good for us to draw a governance map of how everything fits together and socialize it as a whole
<jono> persia, good idea
<jono> sorry guys, but I need to run
<persia> Have a good night.
<wgrant> Night jono.
<jono> sorry for the frustration, I hope we can alleviate it soon - again, please feel free to provide feedback to me on the process
<jono> biab
<ScottK> jono: I know you're just the process guy, but until the technical elements are defined it's impossible to get the process right.
<persia> The converse is also true to some degree.  The two are best considered in concert.
<jono> ScottK, I am positive we can get the process right
<jono> ScottK, I think if you can recommend a strong proposal for a better alternative at UDS, that could be awesome
<jono> in my mind, if there is a clearly better technical implementation that does not require significant resources to implement, then it would be bonkers not to consider it
<persia> Did anyone ever document the backport-based process we reviewed at UDS last time?
<jono> ScottK, maybe you, wgrant and persia could put together a proposal ready for UDS?
 * persia would want to see Laney and stefanlsd involved as well, as they were part of the group that argued that process last time.
<persia> jono, Anyway, you have somewhere else to be (noted above).  Go.  Come back.
<jono> persia, totally
<wgrant> We could also unterminate the mailing list discussion, so we can get additional viewpoints...
<ScottK> jono: Unless rickspencer3 indicates he's open to do it a different way, I think it would be a waste of time.
<jono> I think having a prepared proposal could be awesome for the discussion
<jono> ScottK, I know rickspencer3 would be open to better technical solutions that meet the goal
<persia> And to follow-up on what initiated this discussion (and thanks to stgraber for the approval)
<persia> !extras
<ubottu> extras.ubuntu.com is an external !repo for new software made available after the Ubuntu release.  This repository is not part of the Ubuntu distribution and the software is completely unsupported by the Ubuntu team, but the original authors may offer some support.
<ScottK> jono: There precious little evidence of that in the actions to date.
<wgrant> persia: Looks reasonable.
<jono> ScottK, I think that is a bit harsh
<persia> Lets start from the assumption that things can be sorted, and approach our governance bodies if they can't.
<ScottK> jono: What changed based on the developer feedback to your call for arb members?
<jono> ScottK, rickspencer3 is very open and flexible to the best solution; I don't believe it is "his way or the highway"
<persia> Complaining at folks because of corporate affiliation doesn't help maintain our community.
<jono> persia, entirely agree
<ScottK> That may be, but so far the entire evolution has been remarkably insensitive to outside feedback.
<jono> ScottK, as persia says, if you feel there is corruption here, you should raise it with the CC/TB
<ScottK> jono: It's not corruption, it's just how Ubuntu works.
<jono> ScottK, no it isn't - no one has the right to force their will on people, but people do hav ethe right to be passionate
<jono> it sounds like you have a concern that rickspencer3 is forcing his will on people, and if you have evidence to suggest this, it would not be unreasonable to raise this with the CC/TB
<ScottK> jono: What's the community process for deciding what apps go in the default Ubunt install?
<jono> ScottK, what kind of apps?
<ScottK> There isn't one.  Canonical managers basically decide and that's what happens unless there is overwhelming community feedback to the contrary.
<nixternal> hey snookies!
<highvoltage> ScottK: you file a RFP! :D
<maco> so while there's people who know how things work awake and online and such.... if there's a blueprint from four years ago that was never implemented, is it valid to bring it up again for natty?
<jono> ScottK, right, but if you are arguing this is the Ubuntu way, why are you complaining if rickspencer3 pushes something through?
 * nixternal can't even read what the hell is gooin on in here
<ajmitch> nixternal: spirited discussions
<ScottK> jono: I didn't say I like it.
<jono> ScottK, then change it
<highvoltage> maco: yes. that's why blueprints are not deleted
<nixternal> ajmitch: i am quite drunk, do is o.....bah
<ScottK> But as nixternal pointed out on another channel, I've not drunk sufficiently tonight, so I'll see you all later.
 * ajmitch was just catching up on scrollback
<maco> ajmitch: i read the first 2/3 of it and gave up
<nixternal> i need to be hanging out with jono right now. white castle style!
<jono> ScottK, ok
<jono> nixternal, let's roll!
<ajmitch> nixternal: heh
<maco> nixternal: what, you want sliders?
<nixternal> hell now!
<nixternal> no!
<jono> anyway, I best leg it, I need to tidy the house in a sec
<nixternal> no sliders; i was out drinking and fighting witht he tea baggers tonight. much fun
<ajmitch> jono: I'd just wished we'd had a bit of time to discuss organisational issues before you announced the process, but that's past now
<jono> ajmitch, yeah, I apologized for that :-(
<nixternal> jono: fyi, we need to talk. have a conference coming up and would like you to be here. next april actually
 * ajmitch is still hoping to get some responses back from others on the arb list
<jono> nixternal, sweet, let's talk soon
<jono> right, I am off, laters all!
<nixternal> later
<maco> highvoltage: so how would you suggest i bring up this blueprint again? its one requesting a font manager in the default install, which says to me it goes in the default packages session, whenever teh heck that is at uds, but somehow need to make 2 blueprints fit one session or something....
<highvoltage> maco: I can't tell you how to best match your blueprints to sessions, but you can add it to the UDS by clicking on "Propose for sprint"
<maco> mmk
<persia> You probably want to review and clean up the spec to be accurate for natty.
<maco> the current spec wiki page for it is a bit funny in the use case section, because as akk pointed out, it looks like the one name that is used for 3 separate use cases is really someone with an inflated idea of their own skill level writing pseudononymousely
<persia> Lots of times use cases are things-the-author-wants-to-be-able-to-do
<persia> Way-back-when when the other Jane managed a nice spreadsheet for us to review, everyone would look at all the blueprints, and add their own use cases.  We just have too many now.
<highvoltage> persia: which may still be valid though
<persia> highvoltage, They almost certainly are valid, although perhaps in need of stylistic help.
 * highvoltage remembers other Jane's spreadsheet
<ajmitch> culling a few blueprints might be useful one day
<ajmitch> certain people want to remove blueprints altogether :)
<ScottK> maco: Why would we need a font manager when everyone will love the new Ubuntu font?
<persia> I'm in favour of either removing blueprints (and adding spec pages to certain bugs) or revamping with mpt's mockups of a total project management system.
<persia> ScottK, Because I can't use that font here.  Neither can at least half the population of the world.  Next LTS maybe.
<ajmitch> persia: either way, it's an area that sorely needs some love
<persia> ajmitch, Totally.
<ScottK> jono: re your severed fifth post: Maverick is 10.10, not 10.04.
<jono> ScottK, wow, I am an idiot, thanks for the note
<jono> fixing now
<ScottK> No problem.  Stuff happens.
<jono> :-)
<pitti> Good morning
<pitti> kees: I liked mdeslaur's suggestion to go back to what lucid had, so that it's configurable
<pitti> kees: personally I don't want any timeout; I need it so often during the day, and it's quite a long one
<pitti> kees: ideally it would be forgotten on suspend
<wgrant> Speaking of credentials timing out... is anybody else finding that maverick's seahorse-agent isn't prompting to reuse GPG passphrases?
<wgrant> It just does it silently without asking for confirmation :(
<jono> morning pitti
<wgrant> '/
<smb> pitti, Hi Martin, I am (once again) trying to get forward in the task of getting the Lucid proposed kernel to updates. There are a few more verifications done by now. But there are also 5 (including the one already marked) that sound like verification failed. All ALSA quirks which seem to have no effect.
<pitti> smb: as long as they just don't fix the bugs, but don't introduce regressions, it's fine; we can just keep them open
<pitti> or rather, reopen them after moving to -updates (since that autocloses bugs)
<smb> Would this require an additional upload with the bug numbers manually removed? All or at least most of the patches are coming through upstream stable
<smb> Ah ok, answers the question
<smb> I'd prefer that because generating a new upload is time consuming
<smb> pitti, I would set the verification failed tags then and I would write mail to Daniel and David to make them aware. Do you want to be on cc?
<pitti> smb: that's fine, I'm already sub'ed to the bugs
<pitti> (and we should keep the communication there)
<pitti> smb: if you mail them, perhaps CC: the bugs?
<smb> Hm, sounds reasonable to document it better
<smb> good iddea
<smb> will do so
<smb> pitti, Just want to avoid you getting scared by lots of bug verifications getting failed
<smb> All things seem to be related to the same sort of quirk
<smb> And people were able to have to module config parameter to make things working
<pitti> tseliot: how does plymouth get told which theme to use? I. e. ubuntu-logo by default?
<tseliot> pitti: let me check
<pitti> tseliot: the docs talk about a plymouth-set-default-theme program, but we don't seem to ship it
<tseliot> pitti: it's set as an alternative
<cjwatson> alternatives
<tseliot> default.plymouth
<pitti> ah, thanks
<tseliot> pitti: type: update-alternatives --display default.plymouth
<pitti> tseliot: thanks a lot!
<tseliot> np
<pitti> ah, plymouth-x11 is nice for testing a theme
<tseliot> yes, it makes it easier
<tseliot> it's what I used when I developed the ubuntu-logo theme
<pitti> I see it twice even :)
<pitti> a large and a small one; not sure why
<pitti> but *shrug*
<tseliot> yes, two windows
<tseliot> I'm not sure as to why
<pitti> tseliot: do you know a way to temporarily override the theme for development? I. e. have it point to ~/devel/my-plymouth-theme?
<pitti> or do I just change default.plymouth for that?
<tseliot> pitti: you can install a new alternative manually that points to your .plymouth file
<pitti> right
<pitti> I thought about something like plymouthd --theme=.., but it doesn't seem to exist
<pitti> but that's not a biggie, thanks
<persia> It was something more like that for lucid, but has since been improved
<tseliot> try with: update-alternatives --install /lib/plymouth/themes/default.plymouth default.plymouth /lib/plymouth/themes/$YOUR_THEME/$YOUR_THEME.plymouth 500
<tseliot> pitti: ^
<pitti> tseliot: right, I'll just temporarily change default.plymouth
<tseliot> well, the path depends on when you put your theme
<tseliot> pitti: are you working on a new theme?
<pitti> tseliot: yes
<tseliot> pitti: for ubuntu or some other project (no need for further details in the latter case)?
<pitti> an OEM project
<tseliot> I suspected that ;)
<pitti> don't worry, I won't replace maverick's ubuntu-logo theme with my recent vacation photos :)
<ogra> oh, why ?
<ogra> are they that bad ?
<pitti> no, but everyone would instantly jump on their bike and go tenting
<pitti> who fixes maverick then?
<ogra> lol
<tseliot> hehe
<pitti> martin
<pitti> bl4tch;
<pitti> sudo killall  plymouthd
<pitti> bl4tch;
<pitti> sudo plymouth --quit
<pitti> sudo plymouth --quit
<pitti> sudo plymouth --quit
<pitti> sudo plymouth --quit
<pitti> bl4tch;
<Laney> err
<soren> pitti: I think you're using the wrong keyboard.
<ogra> pitti, and a new sudo password would be good as well now
<tseliot> lol
<pitti> tseliot: ah, the two-screens are intended to test a two monitor setup (http://brej.org/blog/?p=158)
<CountDown> I'm developing a python app targeted to the Ubuntu desktop. Is there a way to configure distutils to add an application launcher menu item to the Ubuntu Applications menu? I'll eventually create a .deb to do this properly, but I"m wondering if there's a distutils way of doing this.
<persia> CountDown, Install your .desktop to /usr/share/applications/ : you may also find #ubuntu-app-devel to be a more targeted channel for that class of question.
<CountDown> persia: Thanks for both suggestions!
 * persia suspects it's in the "Files" section of setup.py or something
<CountDown> I know there's a scripts section of setup.py, but I don't see how to specify the path of each script. They seem to go to /usr/local/bin by default.
<tseliot> pitti: ah, it makes sense
<doko> tkamppeter: hi, is it ok to demote these binary packages for maverick? foomatic-db-gutenprint ijsgutenprint ijsgutenprint-ppds hpijs-ppds
<smoser> so, given binary package name and release, is there a way to retrive the source package? the info is in Packages.gz, but is there a way I can do it without all of that ?
<smoser> i didn't see anything in rmadison that would allow me to do that.
<pitti> smoser: apt-get source packagename?
<smoser> yeah, but for anothe rrelease.
<pitti> ah, unfortunately the /releasename syntax only works for apt-get install for some reason
<smoser> release other than that i'm running.
 * pitti looks at mvo
<pitti> smoser: what still works is apt-get source packagename=<version>
<Chipzz> pitti: can the same version be in 2 different pockets
<Chipzz> ?
<smoser> so i'd just have to add all repositories to apt for that other release and query that way.
<pitti> Chipzz: yes
<Chipzz> pitti: like updates and security?
<pitti> yes, if it gets copied there (not uploaded)
<pitti> we regularly copy -security to -updates, and -proposed to -updates
<smoser> (which would be downloading the Packages.gz).  i was just hoping there was some api-ish way to translate.
<Chipzz> pitti: but I guess that wouldn't actually matter, since they would be copied :P
<pitti> smoser: you could write a small shell wrapper around apt-cache madison, parsing out the pocket, grepping the version number, and apt-get source'ing that
<cjwatson> I'm sure it can be done with launchpadlib
<smoser> i looked and didn't see any notion of binary package
<smoser> there is a source package object
<smoser> (i now noticed i was looking at 'Beta' so i will look again at 1.0 an dev)
<geser> smoser: unfortunately there is no link from binary_package_publishing_history to the matching SPPH in the LP API
<geser> so you have to figure out the source package name for a binary package by other means
<smoser> geser, thanks.
<geser> smoser: see also bug 597041
<ubottu> Launchpad bug 597041 in Soyuz "No way to get from binary package to source package" [Low,Triaged] https://launchpad.net/bugs/597041
<smoser> geser, thank you.
<smoser> well, it looks like i coudl screen scrape
<smoser> https://bugs.launchpad.net/soyuz/+bug/53171
<ubottu> Launchpad bug 53171 in Soyuz "No obvious way to get from binary package page to source package page" [Medium,Fix released]
<ScottK> smoser: grep-dctrl is probably better.  I'm pretty sure you can get it using that.
<smoser> i dont have any control files to grep
<smoser> but maybe i'm missing something
<doko> slomo: https://launchpad.net/ubuntu/+source/gst-plugins-bad-multiverse0.10/0.10.20-1  are these build failures expected?
<slomo> doko: no, something broken in xvid... didrocks debugged it a bit
<didrocks> yeah, but I hadn't the time to finish looking at itâ¦ it's because of xvid not exporting a thread symbol (running two configure during build, first one set pthread to on, not the second oneâ¦)
<hallyn> is there a way to see the full changelog of a lp bug?  (i.e. when ppl were subscribed and states and priorities were set)?
<nigelb> yep
<JFo> hallyn, yes, but the how of it escapes me right now
<nigelb> hallyn: on the bottom
<hallyn> doh, thanks
<JFo> ah, that would be why it escaped me
<JFo> :)
<nigelb> hallyn: did you upload the debdiff to -proposed?
<hallyn> nigelb: i don't think i perms to do that?
<nigelb> hallyn: In that case you need to attach a debdiff (or branch) and subscribe sponsors
<nigelb> now the step is upload => review => accepted to proposed and testing
<hallyn> oh, i thought -sru was in place of -sponsors
<nigelb> hallyn: it used to be, but now you upload first and then get sru ack
<hallyn> nigelb: until now i've always gotten things sponsored through bzr, never yet with a debdiff
<hallyn> so all i do is subscribe sponsors?  (debdiff is pointed to from description)
<nigelb> hallyn: hey, brz is fine too!
<nigelb> Yep, subscribe sponsors, once its uploaded to proposed, then subscribe -sru (or I think sponsors will do it)
<hallyn> nigelb: but, bzr is how i started...
<hallyn> or did i pick the wrong group to subscribe to that merge proposal?
<nigelb> hallyn: ok, I might be blind :p
<nigelb> lemme look at that again
<hallyn> nigelb: hm, i never hit 'link to a bug report', maybe that makes a diff?
<nigelb> hallyn: I think so.  Did you close from changelog?
<nigelb> Like have a (lp: #12345) in changelog
<hallyn> nigelb: er, well, i did, but that was in revision 7 of 8
<nigelb> hallyn: I see the merge proposal, I guess LP doesn't like it automatically until you click or you do --fixes
<nigelb> hallyn: so, the reviewer needs to be changed to ubuntu-sponsors :)
<hallyn> nigelb: doh, you know i explicitly remember not expanding the details section, bc i had just seen an email saying the default was changed to, i thought, ubuntu-sponsors.  appraently i misunderstood
<hallyn> reviewer changed, thanks
<nigelb> great :)
<nigelb> hallyn: I would encourage you to poke somone you know who can upload :D
<hallyn> nigelb: well do, thanks much!
<lamont> so is there a sane reason that gutenprint does "-j 16" on a single core machine?
<doko> lamont: cusing build failures?
<lamont> doko: I'm cussing that it sets of my monitoring alarms, and is only fractionally different than the buildd just plain dying
<doko> lamont, tkamppeter: ok, fixing this
<lamont> that massively parallel is going to run much slower than with less parallelism unless you have more than 1 core
<lamont> thanks
<lamont> 2*NCPU is a perfectly good number for -j
<doko> lamont: no, the buildd admin should set the correct value in DEB_BUILD_OPTIONS ;)
<lamont> doko: there is no DEB_BUILD_OPTIONS
<lamont> this is a buildd
<lamont> not a manual operation
<doko> lamont: adam once did configure the buildds this way
<lamont> it's quite possibly still there then
<lamont> that'd be in launchpad-buildd somewhere
 * lamont freshens his source tree
<pitti> tseliot: (reviewing nvidia) oh, dpkg-trigger also needs --by-package in maintainer scripts?
<tseliot> pitti: yes, otherwise it will complain :/
<tseliot> pitti: I'm doing the same in fglrx plus some additional work so that fglrx doesn't break with 2.6.36 kernels
<pitti> tseliot: ok, thank you
<tseliot> np
<pitti> cjwatson: (reviewing sysvinit) I don't quite understand why we both make /lib/init/rw a symlink, and then do "for omitdir in /var/run/sendsigs.omit.d /lib/init/rw/sendsigs.omit.d" in the init script; won't that include them twice?
<pitti> cjwatson: I don't think it will actually do something wrong, but it seems redundant?
<pitti> cjwatson: ah, that's the "just in case" part in changelog?
<cjwatson> indeed
<cjwatson> pitti: if nothing else, there is one case where it's absolutely needed
<cjwatson> pitti: between installing the package and the next reboot :-)
<cjwatson> since umountroot comes after sendsigs
<pitti> ah, ok
<pitti> it could check whether it's a symlink
<pitti> but, nitpicking
<pitti> TTFN, have a nice weekend everyone!
<mvo> you too pitti
<cjwatson> hmm, messy ibus-client-clutter build failure
<cjwatson> looks like it's upset that /usr/lib/libgdk_pixbuf-2.0.la no longer exists
<cjwatson> I wonder if it's just a matter of rebuilding clutter-imcontext
<tseliot> cjwatson: can you approve fglrx, please? here's the debdiff: http://pastebin.ubuntu.com/499822/
<cjwatson> tseliot: is this the version in the queue?  if so I can review it from there
<tseliot> cjwatson: yes, it's the same version
<cjwatson> if you give it slightly more than three minutes from upload so that LP catches up :)
<tseliot> cjwatson: sorry, I tried to catch you before you're off for the weekend (and before I am too) ;)
<cjwatson> tseliot: accepted
<tseliot> cjwatson: thanks a lot
<tseliot> have a nice weekend everyone
<cjwatson> DktrKranz: any opinion on bug 646995?  you're one of the "recent" uploaders
<ubottu> Launchpad bug 646995 in stage (Ubuntu) "build-depends on NBS libplayercore2-dev/libplayerc2-dev; not fixed in Debian, removed from Debian testing" [Undecided,New] https://launchpad.net/bugs/646995
<DktrKranz> cjwatson: I agree with you. No uploads since months in Debian already, and IIRC I processed removals for some player rdeps because of the same problems stage currently has.
<brutimus> Hi folks.  I just installed the Maverick beta and noticed the installer still tells me about fspot like it's a default app.  A quick search through the installer team's bugs didn't lead me to anything related.
<jcastro> ScottK: can you make the specs foundations-n-blah instead of foundations-natty-blah
<ScottK> Sure.
<jcastro> (I can fix the backport one now since I'm in there)
<ScottK> That's the only one I did so far.
<jcastro> ok
<jcastro> on it
<ScottK> Thanks.
<ScottK> It would be nice to get some guidance out about the new track structure so people can understand how it's supposed to work.
<jcastro> there are appear to be tracks, but also other stuff
<ScottK> Right, so one is left a bit uncertain.
<jcastro> http://uds.ubuntu.com/tracks/
<sladen> or even better, make the 'n' at the front
<jcastro> yeah
<jcastro> I don't forsee people doing ubuntutheproject-n-whatever
<ScottK> Yeah.  I saw that.  Now I'm up from blissfully ignorant to horribly confused.
<sladen> so all the specs you need are *together* rather than interminged with the last 3 conferences' worth
<sladen> conference-track-what
<jcastro> sladen: they're not together
<sladen> logical
<jcastro> https://blueprints.edge.launchpad.net/sprints/uds-n
<sladen> jcastro: yes, that's the problem they're not together.  And that gets carried over to Gobby
<jcastro> they look together to me, per track
<sladen> jcastro: gobby, gobby, gobby
<sladen> jcastro: four conferences' worth of specs all, intermingled
<jcastro> but they clean out gobby every UDS
<sladen> (!)
<sladen> if it crashes ;-)
<ScottK> sladen: Last UDS they didn't even manage to have one conference worth of specs in there.
<sladen> given that the intent of UDS is to "plan the next cycle", it makes sense for this to go at the front
<jcastro> Let's just try to stick to $track-$letter-$title like we always do
<sladen> and then to be broken out into tracks
<jcastro> keeping in mind someone will always break from it /anyway/
<sladen> and then the tracks to be broken out into sessions
<jcastro> you don't even need the n in there at all, all the blueprints are targetted towards the right UDS
<jcastro> it's people just like to put the animal in the title so they can remember that that's specifically for that cycle
<sladen> jcastro: if (eutopia) we get a web page that links to IRC+Wiki+Gobby+everything directly then there won't be any need for people to /think/ and therefore not chance for them to screw up by inventing their own names
<jcastro> well, in the schedule there's a link to the icecast stream and the blueprint
<sladen> https://bugs.launchpad.net/summit/+bug/579164
<ubottu> Launchpad bug 579164 in summit "Add irc:// + audio links to timetable columns" [Undecided,Confirmed]
<jcastro> in my utopia the blueprint page is just an etherpad document. :)
<sladen> even better---anything that is a direct link from an auto-generated pre-agreed schema is user-proof
<sladen> my current intention (despite an invite otherwise) is to sit this UDS out and do it remotely, so I have interest in perfecting this
<jcastro> patches to summit are always gladly accepted
<jcastro> keeping in mind we never really designed summit
<jcastro> it just is
<sladen> mmm, patches...  I have this highlighter bar patch that shows the current position in the timetable (regardless of timezone), ... dating from 2 years ago
<jcastro> oh, one of those marcus baine lines?
<jcastro> I would kill for that feature. Daviey does a good job reviewing merge proposals if you want to do it
<sladen> Daviey: jcastro: http://www.paul.sladen.org/ubuntu/remember-to-rename-this-to-YYYY-mm-dd.diff  (I know it says 'jaunty' in it but...)
<sladen> Daviey: above adds a slowly-moving 'timebar' which shows the exact position in the timetable at any time during the conference, regardless of the user's timezone
<Daviey> sladen: awesome.... do you fancy making a bzr branch, and proposing a merge?
<sladen> Daviey: however, at that time (2008) it wasn't possible to know the timezone of the conference as that wasn't recorded anyway, everything being in localtime
<Daviey> sladen: lp:summit
<sladen> Daviey: are you happy if I just merge the patch---can you test it?
<sladen> Daviey: when the source was first released I spent a while day attempting to install a local copy, and failed
<sladen> w/while/whole/
<Daviey> sladen: Yeah... i think it should be easier to setup locally now
<Daviey> sladen: if you want a pointer, give one of us a ping
<sladen> Daviey: what happened to the history?  my previous tree contains only revno1 and revno2, the latter of which is keybuk adding the licence
<Laney> cjwatson: Is there anything special I can attach to an os-prober bug to help you? It's not detecting my W7 partition
<Daviey> sladen: I think you have the non-free version :/
<Daviey> sladen: lp:summit is the devel trunk
<sladen> Daviey: this new tree has no common history with that trunk
<Daviey> sladen: Yeah... i think you have the version which is "pre opensourced"
<sladen> Daviey: no, I have a GPLv3 one (I was the one who get it opened)
<Daviey> sladen: Ok.. i don't know.. I really do think you have the version which was redacted.. and later released.
<Daviey> other than i don't know
<sladen> Daviey: ah, this makes more sense.  What I have is the GPLv3 of schedule.  Not the whole of summit
<Daviey> ahh
<sladen> Daviey: perhaps it builds/installs more easily with the rest of it ;-)
<Daviey> lol
<sladen> jcastro: right, after that slight diversion.  Naming.  I know that in the US people write dates in a non-standard order, but is there any reason to (continue to) apply a similar system to the spec naming scheme?
<sladen> jcastro: if the heriachy of the conference is  ubuntu->release->tracks->sessions  it makes sense (to me at least) to have that heriachy carried over to the names
<sladen> jcastro: I can see the argument if people are intended to stay within one track, but not everyone does that
<sladen> jcastro: and with the intentional room-reshuffling there's an intent away from that
<jcastro> yeah but the blueprint already has fields for the release, and "ubuntu" is already a given
<jcastro> so why clutter every title with the obvious "ubuntu-10.04" or whatever?
<sladen> jcastro: I would have no objection to dropping components in order from left-to-right
<sladen> jcastro: at the moment it would be equivalent to dropping components 1 and 3, which (hopefully) highlights the current illogical naming
<sladen> jcastro: if the release needs to be there for globally unique naming in the global wiki/spec databases, then it might make sense to re-add the release, to the left-hand-side
<cjwatson> brutimus: it's been filed on ubiquity-slideshow-ubuntu
<brutimus> thanks for the info, cjwatson
<tkamppeter> doko, hi
<cjwatson> Laney: it's all shell, so putting 'set -x' at the top of relevant scripts and capturing stdout/stderr would be valuable
<doko> tkamppeter: see email
<Laney> cjwatson: Thanks. I think it may turn out to be PEBCAK thoughâ¦
<Laney> I think the partition has been somehow wiped
<tkamppeter> doko, it is about the demotion of the unseeded binary packages. The scenario is as follows. User has only main active as package source. H manually installed ijsgutenprint and foomatic-db-gutenprint and set up a print queue with it. In Maverick we demote these packages. What happens if this user updates to Maverick.
<tkamppeter> ?
<doko> tkamppeter: I don't know, I didn't test
<ScottK> tkamppeter: They get a warning that the packages are no longer supported, IIRC.
<tkamppeter> ScottK, but the update of libgutenprint will work (libgutenprint is used by ijsgutenprint)?
<tkamppeter> doko, mentioned case is rare as the packages were never seeded and so seeding them now would be absolutely wrong.
<Daviey> sladen / jcastro: the lack of a convention is hurting us... We can't process the blueprints to assign them to a track
<ScottK> Daviey: I think it's not very clear what will go in what track anyway since they are all different.
<sistpoty> tkamppeter: from an apt perspective, these packages will be left on the system as is (i.e. in the state of the last installed version)
<Daviey> ScottK: yeah.. kinda odd track names
<Daviey> ScottK: Where does the server stuff go?! :)
<ScottK> Daviey: It's all cloud now.
<ScottK> (thus sort of reinforcing my recent lack of motivation to work on server stuff.
<ScottK> )
<Daviey> ScottK: Yeah... I wonder if we'll still have a server release in 12.04
<ScottK> Eventually I figure someone will decide you need packages to do stuff in your cloud, but who knows when that will come.
<jcastro> Daviey: you mean for the automatic scheduling?
<jcastro> people can still drag and drop on the schedule
<Daviey> jcastro: yeah... but the colours?
<Daviey> jcastro: The css'ing colour is based on auto detecting the track.. based on names
<jcastro> I dunno man, I didn't rename all the tracks and the colors, I'll bring it up with jono before he pushes out his "go schedule stuff" email and address it then
<jcastro> Daviey: that's jorgesque for "It can wait until monday"
<jcastro> <-- EOD, have a good weekend folks
<Daviey> jcastro: heh
<Daviey> have a good weekend
<Daviey> (slacker)
<ogra_ac> heh
<tkamppeter> tahmks, sistpoty, doko, I think you can demote these four packages.
<doko> cool, thanks
<sistpoty> tkamppeter: I don't know how update-manager deals with that situation though
<avi_> does anyone know how to make an interface in glade that accepts user text input?
<GeniousAtWork> The Torque update in Maverick destroyed anything located in server_name so none of the nodes can find the server. This is very bad and ive sent an email in re.
<GeniousAtWork> to domibel
<GeniousAtWork> For the release of maverick, either see to it that this is fixed or backported to the previous version.
<GeniousAtWork> Or, well reconfiguring 2000 nodes is possibly not so nice.
<GeniousAtWork> "aptitude changelog torque-mom"
#ubuntu-devel 2010-09-25
<ricotz> bdrung_, hello, the latest ubuntu-dev-tools update broke pbuilder-dist for me
<ricotz> it fails with "Command line parameter [] is not a valid .dsc file name"
<persia> ricotz, Could you file a bug about that?  Specifically, detailing the precise command you used to generate that output, etc.
<ricotz> persia, it fails with a simple command like this "pbuilder-dist maverick build PACKAGE.dsc"
<persia> ricotz, I believe you.  I don't use pbuilder, and my python is questionable, so I'm not the right person to fix it.  Please file a bug.
<ricotz> RainCT, ^
<RainCT> Hi
<ricotz> it might be releated to this http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/revision/740
<ricotz> RainCT, hi, i was looking into the latest commit in ubunu-dev-tools and something seems to broke pbuilder-dist
<RainCT> ricotz: I see. "pbuilder-foo build *.dsc" fails but "pbuilder-foo *.dsc" (a shortcut for that) works. However both seem to run exactly the same command (which you can see with --debug-echo) :S
<ricotz> RainCT, seems like the arguments arent seperated the right way now
<ricotz> using --debug-echo results in a quoted dsc-filename with the newer version
<ricotz> RainCT, i hope you find the problem ;-)
<RainCT> ricotz: I've just found the problem, but I'm not sure why it's only happening after the quoting change.
<ricotz> RainCT, i havent had a deep look into it, i just suspected this change might have caused it
<RainCT> ricotz, persia: OK, pushed the fix. Should I upload this or better wait a day or two in case anyone else has something to get in?
<ricotz> RainCT, i think it is worth an update since it might break some custom build scripts on the weekend ;-)
<quidnunc> I have a regression on dovecot process restarting (Bug #646858). Is this a possible candidate for a freeze exception?
<ubottu> Launchpad bug 646858 in dovecot (Ubuntu) "dovecot-postfix and upstart incompatibility" [Undecided,New] https://launchpad.net/bugs/646858
<kklimonda> can someone take a look at, and sponsor if possible, bug 636482? It's getting late :)
<ubottu> Launchpad bug 636482 in python-django (Ubuntu) "Update python-django to 1.2.3 version to fix an XSS vulnerability" [High,New] https://launchpad.net/bugs/636482
<ScottK> RainCT: A LOT of people use pbuilder-dist.  I'd prefer it if you'd go ahead and upload the fix.
<ScottK> quidnunc: I've triaged the bug so it will get reviewed by the release team for inclusion.
<quidnunc> ScottK: Thanks
<ScottK> quidnunc: No problem.  Thanks for reporting it.
<RainCT> ScottK: Looks like bdrung_ already uploaded it.
<ScottK> RainCT: To Ubuntu?
<RainCT> ScottK: changelog says "experimental", but it shows up on https://launchpad.net/ubuntu/+source/ubuntu-dev-tools
<ScottK> RainCT: Thanks.
<bdrung_> ScottK, RainCT: i uploaded it to experimental and synced it with syncpackage
<ScottK> bdrung_: Thanks for taking care of it.
<bdrung_> ScottK: np
<bdrung_> release early, release often ;)
<bilalakhtar> Sorry for all those joins, was fiddling with Irssi, for some reason its -! flag to stop autoconnecting was not working
<lucas> cd
<lucas> oops
#ubuntu-devel 2010-09-26
<aroman> So I need to add another window (glade .ui file) to my quickly project. I have made the UI file and put it with the others, but I'm not sure how to get the rest of my project to be able to work with it. Thanks!
<ScottK> aroman: You might try #ubuntu-app-devel.  That's really not what this channel is for.
<aroman> Sure thing. Thanks
<dugger5688> Any ubuntu developers in here? I have a "papercut" that I think should be fixed. Namely, if you install eclipse in Software Center it's fairly broken, but through terminal is fine.
<beuno> dugger5688, file a bug!
<bdrung_> dugger5688: that's because the software center only installs eclipse-platform, which isn't enough if you want to install plugins
<dugger5688> I realized that now, was hoping to get some insight as to why that is the case.
<bdrung_> dugger5688: because that package contains the .desktop file
<dugger5688> Seems silly to not include what actually makes eclipse an IDE in the software center item titled "Eclipse Integrated Development Environment" Again, this is a minor annoyance for me but I know many people who would otherwise love to use Ubuntu to develop projects for research/class etc. that might be turned off by this.
<bdrung_> dugger5688: yes. IIRC there is already a bug report for that.
<directhex> i'm impressed it's even in the archive. i remember when it had been given up on as unpackageable
<bdrung_> directhex: it was hard work to get it packaged.
<dugger5688> Thanks, I had looked but couldn't find one. That's why I inquired here first. My friend yesterday was telling me he gave up on Ubuntu b/c of this very problem.
<directhex> i can imagine. i have nothing but sympathy for the java team
<dugger5688> I am glad it's packaged though :-)
<bdrung_> directhex: it's the DOA team. ;)
<dugger5688> DOA?
<bdrung_> Debian Orbital Alignment team ;)
<bdrung_> -> http://packages.qa.debian.org/e/eclipse.html
<bdrung_> we are two people working on it
<bdrung_> but we have a cool name :)
<directhex> surely eclipse is just a major example of the usual java packaging issues?
<dugger5688> Indeed, a very cool name. Good work too, Java used to be a nightmare but continues to improve for me.
<dugger5688> *on Ubuntu that is.
<bdrung_> directhex: yes. but it produces tools like the rewritten suspicious-source.
<dugger5688> Has anything changed since Oracle took over?
<bdrung_> i am not aware of any changes yet
<bdrung_> but i have to admit that my last change in eclipse is weeks ago.
<dugger5688> What makes Java packages so difficult? I'm not very experienced with it, I was employed doing Perl/Python but never had a reason to learn Java.
<bdrung_> directhex, dugger5688: it's much work to get it working: http://overbenny.wordpress.com/2010/03/19/eclipse-3-5-2-1-in-debian-unstable/
<dugger5688> So you are working on packaging PyDev? That's awesome!
<bdrung_> there is not one command that builds everything from source. some binaries file are generated by someone and used until someone updates them, but we need the source for them and build them.
<bdrung_> dugger5688: pydev is on the list, but nothing is done lately. we need more man power.
<bdrung_> other packages (like audacious and vlc) have stolen my time.
<dugger5688> Would love to contribute if I could, but like I said I suck at java.
<bdrung_> you don't know much about java. :) you need to know how to package, how to use the shell and how to use ant.
 * directhex slyly mentions to dugger5688 that monodevelop-python is in good shape ;)
<bdrung_> s/know/need to know/
<bdrung_> dugger5688: and a fast machine doesn't hurt.
<bdrung_> (requires 3 GiB on harddisk and 2 GiB RAM to compile)
<dugger5688> quad core, 4 gigs, 3-GHz fast? HAha, unfortunately I don't have time to get caught up. I'll remember next semester though, when I'm out of school!
<bdrung_> on my desktop system it takes 10 mins to compile (on the three years old laptop 80 mins)
<bdrung_> dugger5688: core 2 duo, 3.16 GHz, 8 GiB RAM and compiling in tmpfs.
<dugger5688> Nice. I must say I've never come close to 100% mem usage, except during the nasty chromium/google maps GPU bug where there's an infinite loop full of ALLOCs.
<directhex> bdrung_: what's with java and ram during compilation? i see the same thing with IKVM.NET, which needs to compile a whole bunch of openjdk for its own use - the javac process eats over a gig of ram
<persia> directhex, deferred garbage collection: most JREs only free memory when there is pressure.
<directhex> an insightful technical answer! how handy!
<bdrung_> directhex: as written before, it requires 2 gig of ram during compilation
<bilalakhtar> micahg: ping
<bilalakhtar> hmm, micahg: unping, you are away
<LLStarks> hi, are there any ubuntu boot devs worth talking to besides scott?
<ion> yes
<LLStarks> k
<LLStarks> like whom?
<soren> How about you just ask your question?
<lifeless> !ask | LLStarks
<ubottu> LLStarks: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<LLStarks> does scott have any plans to run a ppa for his last minute ureadahead changes?
<LLStarks> like https://launchpad.net/~ubuntu-boot/+archive/staging or https://launchpad.net/~ubuntu-boot/+archive/ppa
<LLStarks> ?
<lifeless> LLStarks: for that question, I'd mail the devel list
<LLStarks> devel mailing?
<LLStarks> k
<lifeless> sure. or devel-discuss
<ogra_cmpc> RAOF, around ?
<RAOF> ogra_cmpc: I am now.
<persia> I do believe you've missed him by ~20 minutes :)
 * ajmitch blames daylight saving time
 * persia would think that would make it easier to overlap
<ajmitch> it's a convenient scapegoat, I lost an hour's sleep in the weekend from it :)
<persia> Whilst you're still properly annoyed, start a write-in campaign to have it abolished.
<RAOF> ajmitch: Oh, is it daylight savings already?
<RAOF> o_O
<ajmitch> RAOF: sure, I thought you'd have it there already?
<RAOF> No, I don't think so.
<RAOF> We've harmonised with the filthy northerners.
 * persia thinks it's still waiting to pounce on RAOF some unexpected monday
<ajmitch> oh right, looks like it's next weekend for you
<RAOF> persia: Oh, totally. :)
<TheMuso> Yeah not yet in Australia, likely next weekend, or some time in October.
 * ajmitch wonders why NZ is ahead of australia for DST this year
<RAOF> Hm.  KDE needs to learn to not spawn hundreds of winebrowser processes each time I try to open a linkâ¦
<ion> raof: Nah, you just need to increase the number of available processes in the system. ;-)
#ubuntu-devel 2011-09-19
<pitti> Good morning
<pitti> bdmurray_: 298217 needs to be accepted into -proposed first
<didrocks> good morning
<pitti> stgraber: oh, ltsp-server-standalone recently became NBS?
<buxy> https://bugs.launchpad.net/~jerome-bouat I wonder if someone should just go ahead and close all its "/etc/logrotate.d/foo should not have compress option"
<buxy> (I closed one on dpkg already)
<geser> pitti: Hi, it is ok to ack one own uploads to -proposed? I already forgot that I uploaded a fix for bug 788943 to -proposed and it's still there (3 months later)
<ubottu> Launchpad bug 788943 in unscd (Ubuntu Natty) "Depends on libc6 < 2.13" [Undecided,Fix committed] https://launchpad.net/bugs/788943
<pitti> geser: uh, 3 months?
<pitti> geser: the oldest upload on https://launchpad.net/ubuntu/natty/+queue?queue_state=1 is from Friday, and unscd is not there
<pitti> geser: ah, I misunderstood, it's in -proposed already
<pitti> geser: yeah, as long as you test the actual -proposed package instead of a local build, it's fine for me
<geser> yes, it's waiting for sru verfication
<dholbach> good morning
<pitti> hey dholbach
<geser> good morning dholbach
<dholbach> hey pitti, hey geser
<fishor_> hallo all, are there any way to automatically find debug symbols, if they exist. I currently research a performance problem  connected with this library: libapt-pkg.so.4.11.0
<fishor_> but i just can't find the dbg package for it
<geser> fishor_: https://wiki.ubuntu.com/DebuggingProgramCrash describes how to install the -dbgsym packages (packages with the debug symbols)
<RAOF> There's even a script attached that'll list all the dbgsym packages you need to install.
<fishor_> geser, RAOF, thank you. But it looks like there is no apt-dbg package at all
<RAOF> fishor_: You need to enable the dbgsym repository.
<fishor_> RAOF, thank you!
<apw> slangasek, iirc its about getting the x-server started as soon as possble, we only ie, when fallback is not actually going to do anything, the dependancies also get themseleves started
<apw> s/ie,/delay/
<Daviey> doko: bug 831100 is fixed upstream, Werror issue.. 3 options really, disable the Werror fail, new upstream version or cherry pick the fixes.  I tried cherrypicking, but some of the patches are embedded in 1 commit with other stuff - was taking too long.  Therefore, i'm suggesting removing of the Werror for this release, how do you feel about that?
<ubottu> Launchpad bug 831100 in mysql-cluster-7.0 (Ubuntu Oneiric) "mysql-cluster-7.0 version 7.1.9a-0ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831100
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, I have discovered something strange: You know that if you have a script executable with a shellbang and the specified interpreter executable file does not exist, starting the script gives "No such file or directory". Now I have a compiled program which gives "No such file or directory". Have you ever seen such a thing?
<pitti> tkamppeter: what does "file" say on that program?
<pitti> tkamppeter: it might not be an ELF program but something else handled by binfmt_misc
<tkamppeter> /opt/epson-inkjet-printer-nx420/cups/lib/filter/epson_inkjet_printer_filter: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, not stripped
<geser> tkamppeter: does ldd work on that binary?
<pitti> tkamppeter: and you get the error if you run this directly? or through cups?
<tkamppeter> pitti, geser, here is the strace: http://paste.ubuntu.com/692867/
<pitti> hmm, never saw that one
<cjwatson> Daviey: I am generally wholeheartedly in support of nuking -Werror from orbit
<geser> tkamppeter: are the permissions correct (all paths accessible and the x-bit set on the binary)?
<tkamppeter> pitti, geser, here is the ldd, it finds all its libraries: http://paste.ubuntu.com/692869/
<pitti> tkamppeter: is /opt on a separate partition? might be mounted "noexec"?
<cjwatson> tkamppeter: readelf -l /opt/epson-inkjet-printer-nx420/cups/lib/filter/epson_inkjet_printer_filter | grep -A1 INTERP
<Daviey> cjwatson: heh
<tkamppeter> pitti, /opt is on the root partition, and I do not get "Permission denied".
<tkamppeter>   INTERP         0x0000000000000200 0x0000000000400200 0x0000000000400200
<tkamppeter>                  0x000000000000001a 0x000000000000001a  R      1
<tkamppeter> pitti ^^
<cjwatson> blast, it must be a different length on amd64.  Try a little after that (-A2?)
<tkamppeter> cjwatson ^^
<tkamppeter>   INTERP         0x0000000000000200 0x0000000000400200 0x0000000000400200
<tkamppeter>                  0x000000000000001a 0x000000000000001a  R      1
<tkamppeter>       [Requesting program interpreter: /lib64/ld-lsb-x86-64.so.3]
<tkamppeter>   LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
<tkamppeter> cjwatson ^^
<cjwatson> is /lib64/ld-lsb-x86-64.so.3 there and executable?
<pitti> it doesn't exist here, anyway
<geser> is .so.3 correct? I've here only a natty system to check and have only .so.2
<tkamppeter> cjwatson, found the problem:
<tkamppeter> till@till:~$ ll /lib64/ld-lsb-x86-64.so.3
<tkamppeter> lrwxrwxrwx 1 root root 25 2011-08-25 20:49 /lib64/ld-lsb-x86-64.so.3 -> /lib/ld-linux-x86-64.so.2
<tkamppeter> till@till:~$ ll /lib/ld-linux-x86-64.so.2
<tkamppeter> ls: cannot access /lib/ld-linux-x86-64.so.2: No such file or directory
<pitti> I only have /lib64/ld-linux-x86-64.so.2, the -lsb- one is probably a bad symlnk?
<tkamppeter> cjwatson, is this a bug in Oneiric? If yes, which package?
<cjwatson> bad symlink, the canonical path for ld-linux-x86-64.so.2 is under /lib64 not /lib
<cjwatson> ld-lsb-x86-64.so.3 is not shipped by any package in Ubuntu AFAICS
<cjwatson> oh, wait, lsb-core.postinst creates it
<cjwatson>             ln -sf /lib/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
<cjwatson> that is a little bizarre
<tkamppeter> cjwatson, how does this symlink get onto my system?
<tkamppeter> cjwatson, so it is a bug of lsb-core then?
<jamespage> doko: MP ready for bug 831399
<ubottu> Launchpad bug 831399 in docbook-defguide (Ubuntu Oneiric) "docbook-defguide version 2.0.17+svn7549-3 failed to build in oneiric" [High,In progress] https://launchpad.net/bugs/831399
<cjwatson> looks like it, yes
<cjwatson> nasty little lurking bug
<cjwatson> bug 837745
<ubottu> Launchpad bug 837745 in lsb (Ubuntu) "broken ld-lsb* symlinks" [Undecided,New] https://launchpad.net/bugs/837745
<cjwatson> milestoned for oneiric
<cjwatson> nice catch, thanks
<tkamppeter> cjwatson, pitti, geser: sudo ln -sf /lib64/ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3 solves the problem. So bug is in lsb-core, postinst needs to get updated. Thanks to you all.
<Chipzz> can't the package contain the symlink instead of it being created by the postinst?
<tkamppeter> cjwatson, pitti, geser, moved bug 840998 to lsb now.
<ubottu> Launchpad bug 840998 in lsb (Ubuntu) "LSB-based executable (printer driver) aborts with "No such file or directory"" [High,Triaged] https://launchpad.net/bugs/840998
<cjwatson> Chipzz: I'm going to go right ahead and guess there's a good reason, since the lsb maintainer generally knows what he's doing.  Feel free to investigate the history if you care
<Chipzz> cjwatson: more of a "wth" thing really
<Chipzz> cjwatson: if it's done from the postinstall, you would think it might also link elsewhere under specific circumstances (why else create it from postinst?)
<Chipzz> but if that is the case... isn't LSB supposed to be a standard? how does 2 possible destinations reconcile with the "standard" part?
<cjwatson> I believe that the symlinks used to be shipped by an Architecture: all package, which made it impossible to ship architecture-dependent symlinks
<cjwatson> nowadays it's Architecture: any but nobody went to clean that up
<Chipzz> that would explain idd
<Chipzz> sounds like one hell of a dirty mess (the original arch: all package)
<tkamppeter> doko, mvo: Can you fix the "lsb" package updating the amd64 and i386 (if needed) links done in postinst for the new multiarch changes in Oneiric? Thanks. See bug 840998.
<ubottu> Launchpad bug 837745 in lsb (Ubuntu Oneiric) "duplicate for #840998 broken ld-lsb* symlinks" [High,Confirmed] https://launchpad.net/bugs/837745
<cjwatson> tkamppeter: I'm fixing it now
<cjwatson> doko,mvo: ^-
<cjwatson> i386 is fine
<tkamppeter> cjwatson, thanks.
<doko> mvo, jibel: not sure what to do with bug 853688, the terminal log looks fine?
<ubottu> Launchpad bug 853688 in gcj-4.4 (Ubuntu Oneiric) "Natty to Oneiric - failed to calculate the upgrade with gcj-4.4-jre installed" [High,Confirmed] https://launchpad.net/bugs/853688
<jibel> doko, the terminal log is not relevant, only apt.log and main.log are interesting. apport attached it automatically. I'm removing it to avoid confusion.
<pitti> hm, I suddenly get a ton of mail wrt. openstack-packagers
<pitti> bug mail and merge proplsal
<pitti> proposals
<Laney> welcome to the club :-)
<Daviey> you lucky people :)
<Daviey> feel free to jump in.
<bluefoxicy> has anyone stumbled across the weird rhythmbox bug where it plays 2 songs?
<bluefoxicy> it seems pausing (which only pauses one song) and then advancing to the next song fixes it, but it's weird.  I don't understand how it decides to play 2 songs... what kind of coding error would do that
<bdrung> chrisccoulson: are you around? can you forward your patch from eclipse 3.5.2-11ubuntu2 to upstream (because the original patch author needs to send it upstream)
<cjwatson> plars: do you think you could fix bug 756043?  I started on it but it seems to have quite a few problems with the current version of Vala in Oneiric
<ubottu> Launchpad bug 756043 in moserial (Ubuntu Oneiric) "moserial version 2.28.2-0ubuntu2 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/756043
<cjwatson> plars: and it looks like it might be best addressed by a new upstream version, so ideally somebody familiar with the package would see if that needs a feature freeze exception
<pitti> plars: NB that the previous vala-0.12 is still in the archive as well, in case that's easier
<apw> pitti, i have been poking the compressed swap support we use in live-cd images on small memory systems and it seems it doesn't work at all anymore ... i have a proposed fix (for initramfs-tools) which you seem to have merged most recently ... i wonder if you might have time to look it over: lp:~apw/ubuntu/oneiric/initramfs-tools/compcache-zram/
<apw> (this may well explain the increased minimum memory requirement we had in natty)
<pitti> apw: compcache? sure that you don't mean ogra?
<cjwatson> I can have a look at that
<pitti> apw: anyway, can have a look over lunch, just not sure how qualified I am
<cjwatson> I've poked compcache in the past
<pitti> s/over/after/
<cjwatson> and doing something about it for this cycle had been vaguely on my list
<apw> cjwatson, that would be great.  its been worrying me for a while now
<cjwatson> yeah, that looks nice to me
<cjwatson> I assume you've tested it so I don't need to? :-)
<apw> i tested it before the rebase to ubuntu4, let me retest it just to be really sure
 * cjwatson <- lazy
<apw> cjwatson, i redo the testing with todays isos etc, so it'll take me an hour or so
<cjwatson> ok
<Quintasan> jcastro: ping
<Quintasan> jcastro: nvm
<Sweetshark> doko: your debian upload of gcc-4.6.1-10 causes breakage for mozilla and libreoffice. could you backport the revert patch at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50442 there?
<ubottu> gcc.gnu.org bug 50442 in c++ "[4.6 regression] Constructing T from implicit conversion to T& ambiguous in C++0x mode, not C++98" [Normal,Resolved: fixed]
<Sweetshark> see also: https://bugzilla.mozilla.org/show_bug.cgi?id=686280 and http://nabble.documentfoundation.org/Debian-gcc-or-LO-bug-td3347043.html
<ubottu> Mozilla bug 686280 in JavaScript Engine "build error in xpcwrappedjsclass.cpp" [Normal,New: ]
<doko> Sweetshark, do you have the source file at hand?
<Sweetshark> doko: nope (also I still have ubuntus 9ubuntu1, not debians -10)
<apw> cjwatson, know anything about /run and /var/run being switched round ?
<pitti> apw: /run is _the_ location now, everything else is backwards compat symlinks
<apw> just upgrading a chroot and my update has died and:
<apw> $ ls -l /var/run
<apw> lrwxrwxrwx 1 root root 4 Sep  3 08:06 /var/run -> /run
<apw> $ ls -l /run
<apw> lrwxrwxrwx 1 root root 8 Aug 24 16:31 /run -> /var/run
<Chipzz> pitti: oh? I was told several weeks ago that is not te situation?
<pitti> the first is correct
<apw> pitti, well the update has made this mess ... and isn't fixing it
<pitti> apw: /run is suposed to be a tmpfs mount
<apw> which ... it won't be in a chroot
<Chipzz> but a chroot doesn't need to boot?
<pitti> Chipzz: hm, Debian/Fedora switched to that a while ago, and we also followed; you might have more recent news than me, of course
<pitti> apw: my sid chroot has a normal /var/run/, and a /run -> /var/run
<cjwatson> apw: wiki.debian.org/ReleaseGoals/RunDirectory has full details
<Chipzz> pitti: no; there was breakage wrt the transition, and I made the comment that might be a good thing to find packages not using /run yet
<cjwatson> and people should read that before commenting further here, I think
<Chipzz> to which someone replied that not everything is supposed to use /run
<cjwatson> including Chipzz
<pitti> so it seems that it might mix up these two different scenarios?
<Chipzz> cjwatson: I don't recall the exact details, but I *think* the answer was that /run was only supposed to be used at boot (or sth)
<cjwatson> I suggest getting exact details first :-)
<Chipzz> cjwatson: did ubuntu's position on the subject change during the last nonths?
<cjwatson> /run as a symlink is definitely a bug, anyway
<cjwatson> yes, we merged the Debian changes
<pitti> ^ so that part affects Debian as well
<pitti> but if that's deliberate, it seems weird; seems easier to always have /var/run -> /run, and /run just not mounted (or bind-mounted) in a chroot
<apw> cjwatson, now i seem to remember /run -> /var/run being an early perhaps upstart ism
<apw> pitti, yep, if i was in that scenario i think i'd be fine
<cjwatson> apw: I don't remember any such thing
<pitti> apw: my sid chroot doesn't have upstart, and still this broken link
<apw> $ dpkg -S /run
<apw> initscripts, base-files: /run
<apw> can i tell what type it is meant to be
<cjwatson> Chipzz: anyway, I think what you've misremembered is that certain things aren't *required* to transition to /run in a hurry
<cjwatson> apw: it is meant to be a directory
<apw> cjwatson, sorry i mean what my _current_ dpkg database thinks it is meant to be
<cjwatson> no
<cjwatson> you can dpkg -c the relevant .debs
<cjwatson> but dpkg never converts a symlink to a directory or vice versa by itself; that quite intentionally requires maintainer script code
<Chipzz> cjwatson: that might have been it.. foggy memory etc, Monday and all that :)
<cjwatson> Chipzz: it is absolutely false that /run is only supposed to be used at boot (just to clarify so that nobody here picks up that idea and gets confused by it)
<Chipzz> cjwatson: and I stand corrected :)
 * Chipzz crawls back under the rock he came from :P
<apw> cjwatson, ok my latest base-files has /run and /var/run as directoris, the old one in my /var/cache/apt only has /var/run as a directory
<cjwatson> apw: I suspect anyway that dpkg -c will be unhelpful; as I say this is all about the maintainer script code
<cjwatson> so, there's stuff in initscripts.postinst about this
<cjwatson> in a chroot, we can't do bind-mount tricks to move things around (at least not and have them stick), so the only choice is to make /run a symlink to /var/run
<cjwatson> so in a chroot, the question is how /var/run became a symlink
<apw> cjwatson, ok i have another chroot updated at the same time as this one, but not yet updated which has a real /var/run, so its something i just installed which bust it
<cjwatson> (which means I was wrong above to say that /run as a symink is definitely a bug; chroots are a special case)
<apw> as far as i can tell neither initscripts nor base-files changed recently
<cjwatson> base-files makes /var/run a symlink to /run, but only on fresh installations
<cjwatson> nothing else in my /var/lib/dpkg/info appears to make /var/run a symlink
<cjwatson> can you check in /var/log/dpkg.log* for upgrades with the same timestamp as /var/run?
<cjwatson> that should be enough to isolate it quite precisely
<apw> cjwatson, according to my logs i did no updates between 2011-08-30 and this morning, and the link came into existance 2011-09-03 ...
<apw> which seems confusing.  i will upgrade my other chroot and see if that hits the same issue
<apw> if it does not then i will have to write it off as pilot error somehow
 * apw does not he has installed casper in this chroot
<apw> note
<cjwatson> casper doesn't touch /var/run
 * apw waits on the update, if it doesn't recur then we can assume its fixed i suspect
<stgraber> pitti: what? I uploaded a new ltsp source yesterday and didn't get any build failure
<stgraber> pitti: ouch, ok, looks like wrap-and-sort messed up debian/control with the last upload. Looking at it now
<pitti> stgraber: thanks
<stgraber> really weird, wrap-and-sort did what it's supposed to except that it also dropped ltsp-server-standalone...
<doko> jamespage,  eucalyptus-commons-ext b-d's on gcj, not openjdk?
<jamespage> doko: it pulls both for the build
<jamespage> some of the libraries it builds won't compile under Java 6 so it used gcj for those
<stgraber> pitti: uploaded
<Sweetshark> doko: at https://bugzilla.mozilla.org/show_bug.cgi?id=686280#c9 comment 9 there is a minimal testcase if you need one ...
<ubottu> Mozilla bug 686280 in JavaScript Engine "build error in xpcwrappedjsclass.cpp" [Normal,New: ]
<stgraber> pitti: argh, it's wrong. wrap-and-sort messed up more than I thought. please reject
<pitti> stgraber: will do once it hits unapproved
<pitti> stgraber: killed
<Chipzz> hrrrrm
<Chipzz> ubottu looks slightly broken?
<ubottu> Chipzz: I am only a bot, please don't think I'm intelligent :)
<Chipzz> " [Normal,New: ]"
<Pici> Chipzz: I'll pass it on.
<apw> cjwatson, ok other chroots are fine so i am going to write this off as an anomoly
<cjwatson> ok
<cjwatson> if it shows up again we can come back to it
<apw> ack
<barry> jelmer: ping
<jelmer> barry: hi Barry, how are you?
<barry> jelmer: doing good, how about yourself?
<jelmer> barry: I'm well too. What's up?
<barry> jelmer: debian bug 632225 - subvertpy
<ubottu> Debian bug 632225 in src:subvertpy "subvertpy: FTBFS on ia64: testsuite fails" [Serious,Open] http://bugs.debian.org/632225
<kees> wgrant: hi! when you get a chance, can you approve my membership to MOTU SWAT?
<barry> jelmer: i am unable to even build the source package from sid on oneiric, and i was just looking for clues :)
<jelmer> barry: this is on ia64 too?
<barry> jelmer: amd64
<jelmer> barry: oh, interesting, I haven't managed to reproduce it on amd64
<jelmer> barry: is it the same test that's failing?
<barry> jelmer: i don't even get that far: http://pastebin.ubuntu.com/693072/
<wgrant> kees: :( but done.
<barry> jelmer: yet this works just fine from a cli: python2.6 -c 'import apt_pkg'
<jelmer> barry: what about python-dbg -c 'import apkt_pkg' ?
<barry> jelmer: segfault
<barry> jelmer: i guess that's a clue :)
<jamespage> bdrung: whats the current status of eclipse 3.7?  anything I can help with?
<apw> cjwatson, ok ... i have built my own iso with the updated initramfs-tools bits and i now get a zram0 mounted as swap if i restrict ram to 480M
<kees> wgrant: thanks :)
<cjwatson> apw: excellent.  I shall merge right now
<apw> cjwatson, most appreciated
<bdmurray_> pitti: what was that regarding 298217 and -proposed?
<pitti> bdmurray: what about it? it needs review by ubuntu-sru and then testing
<bdmurray> pitti: oh that was about the verification-needed tag question - got it
<barry> jelmer: perhaps subvertpy is not multiarch aware?
<jelmer> barry: I'm not sure why it wouldn't be, it seems to build fine in Debian too.
<jelmer> barry: the bug in Debian is almost certainly due to a memory management bug.
<slangasek> is anyone here running with the nouveau driver who could test plymouth for bug #849954, please?
<ubottu> Launchpad bug 849954 in plymouth (Ubuntu Oneiric) "FFe: enable flicker-free boot with lightdm" [Medium,Incomplete] https://launchpad.net/bugs/849954
<broder> slangasek: give me a sec and i can switch my laptop over
<slangasek> broder: hurrah, thanks
<broder> slangasek: is there a ppa, or am i building off of that branch?
<slangasek> broder: build off branch, or just hand-hack the one-line change to /etc/init/plymouth-stop.conf
<slangasek> (pretty trivial change)
<broder> ok. back in a moment
<barry> jelmer: hmm, okay.  i say this because it complains about not finding the subversion dev files.  this is just during source package build
<jelmer> barry: do you have the apr util and svn dev packages installed?
<broder> slangasek: hmm..looks like nouveau doesn't actually work with my laptop's card, sorry
<barry> jelmer: ah, thanks, i was missing libsvn-dev
<mterry> debfx, I was working on building/testing the qtwebkit (amarok crash) patch, but if you want to take it, that's fine
<mterry> debfx, (just let me know, so I stop working on it)
<slangasek> broder: ah, blast.  well, thanks for checking
<debfx> mterry: I'm planning to update qtwebkit to 2.2 RC1 which includes that fix
<mterry> debfx, OK, then I'll stop.  I don't think amarok needs to be patched at all then, if I read the bug reports right
<debfx> hope you haven't spent too much time on it :/
<mterry> debfx, not a lot, no  :)  thanks for updating qtwebkit
<bdmurray> pitti: how is it that bug 849073 matches the pattern for bug 832745 and still was reported?
<ubottu> Launchpad bug 849073 in update-manager (Ubuntu) "[MASTER] update-manager crashed with TypeError in confirmChanges(): glib.markup_escape_text() takes at most 1 argument (2 given)" [Undecided,Confirmed] https://launchpad.net/bugs/849073
<ubottu> Launchpad bug 832745 in update-manager (Ubuntu) "TypeError: glib.markup_escape_text() takes at most 1 argument (2 given)" [High,Fix released] https://launchpad.net/bugs/832745
<pitti> bdmurray: hm, when was the pattern added?
<bdmurray> pitti: timestamp: Fri 2011-09-09 09:39:12 -0300 according to bzr log
<pitti> hm, last dupe is from 09-13, no newer ones since then
<pitti> but that coincides with the fix, not with the pattern
<bdmurray> pitti: I don't see 832745 at http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml
<bdmurray> oh there it is
<pitti> ./test-local 850748 looks quite fine from here..
<bdmurray> pitti: should donwloading the crash report using apport and then ubuntu-bug crash_file work?
<pitti> bdmurray: in theory yes
<bdmurray> pitti: hmm, it doesn't in this case at least
<bdmurray> pitti: it does with one of the duplicates though
<jmux> Hi. Can anyone with a (fresh) Natty system check, if /var/run and /var/lock are tmpfs mounts?
<pitti> jmux: they ought to be, anyway
<jmux> I upgraded from Natty to Oneiric and it seems the directory migration /var/lock => /run/lock and /var/run => /run is broken. base-files.postinst does an "rmdir /var/run; ln -s /run /var/run" but AFAIK both are tmpfs mounts, so this will fail.
<jmux> This broke my boot in various ways, as some services write their data to /run but look for their data in /var/run, which won't be a symlink. Same for /lock.
<bdmurray> pitti: I think it is because OriginalTitle is only in downloaded apport crashes so if a pattern is matching on OriginalTitle it will always fail
<pitti> bdmurray: aah
<pitti> yes, that's plausible
<jmux>  /lock should be /run/lock
<bdmurray> pitti: so perhaps apport's _check_bug_pattern should also check OriginalTitle?
<pitti> jmux: not in natty
<pitti> jmux: that was done in oneiric
<jmux> pitti: I know. I'm just not sure if a fresh Natty system has /var/run on tmpfs, since my system has gone a much longer upgrade path.
<jmux> And several system deamons (dbus, rpcbind) failed to start, because /var/run was still a directory after upgrade.
<pitti> james_w: you just approved https://code.launchpad.net/~mabac/launchpad-work-items-tracker/change-queries-through-storm/+merge/74725, are you merging as well?
<james_w> pitti, oh, sorry I missed which branch it was proposed for
<james_w> pitti, I can do it if you are happy with it
<pitti> james_w: well, I don't really understand it :) but if it was tested, fine for me
<doko> barry, could you have a look at bug 755971
<ubottu> Launchpad bug 755971 in swap-cwm (Ubuntu Oneiric) "swap-cwm version 1.2.1-4.1 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/755971
<SpamapS> Daviey: ack, will take another look at that MP
<james_w> pitti, that code is running on linaro's instance now
<bdmurray> pitti: can you change the pattern for bug 851169 on ubuntu-archive to match on originaltitle as I can recreate that crash and can test this theory
<ubottu> Launchpad bug 851169 in oneconf (Ubuntu) "oneconf-service crashed with ServerNotFoundError in _conn_request(): Unable to find the server at apps.ubuntu.com" [High,Fix released] https://launchpad.net/bugs/851169
<pitti> james_w: so, go ahead; bzr doesn't easily forget, so if things break, we can alwasy revert
<james_w> pitti, indeed, thanks I will do it shortly
<pitti> bdmurray: you mean locally in the bzr checkout?
<bdmurray> pitti: right locally on people.canonical.com
<pitti> bdmurray: changed
<bdmurray> pitti: okay thanks so now my crash doesn't match the pattern
<pitti> bdmurray: ok, reverted
<pitti> bdmurray: so in bzr we should do an s/OriginalTitle/Title/ then?
<bdmurray> pitti: yes but that's not a good long term solution I think
<pitti> bdmurray: hm, we could change launchpad.py to grab the "Title:" field from the metadata as OriginalTitle
<pitti> bdmurray: the code actually already tries to do that
<pitti> bdmurray: apport/crashdb_impl/launchpad.py line 294
<bdmurray> pitti: that's only in download though which isn't used when building a bug report right?
<pitti> bdmurray: ah, right, I got confused
<pitti> bdmurray: I think for the patterns it really needs to be Title:
<pitti> bdmurray: as at the point when you click "report" you can't actually set/change the title
<slangasek> seb128: regarding bug #851481, I certainly know what the right fix is (ignore all plugins of a different architecture), but I know nothing about where the plugin search code is implemented... do you know where I should start looking?
<ubottu> Launchpad bug 851481 in gst-plugins-base0.10 (Ubuntu) "totem and banshee prompt for i386 plugin to play QuckTime on 64 bit system" [Undecided,New] https://launchpad.net/bugs/851481
<bdmurray> pitti: right that makes sense my concern is using test-local and having it not match in some cases, but I'd rather the pattern matching work than test-local fail in some cases
<seb128> slangasek, gstreamer calls gnome-codec-install so I wonder if the bug is not there
<seb128> mvo might know better
<seb128> mvo, ^
<slangasek> right, it probably is
<pitti> bdmurray: *nod*
<seb128> slangasek, the gst code is in gst-plugins-base0.10 gst-libs/gst/pbutils/install-plugins.c
<seb128> slangasek, I don't know about gnome-codec-install much but mvo does and I think the code is small enough
<slangasek> seb128: the 'gnome-codec-install' keyword is probably what I needed to dig deeper on it :)
<slangasek> mvo: ^^ though if you have time to look at this, I'm sure you'll get it fixed far more efficiently than I
<seb128> ;-)
<bdmurray> pitti: are you planning on fixing the OriginalTitles in bugpatterns or shall I?
<pitti> bdmurray: if you have some time, please go ahead; I'm in "crunch mode" right now, I'm afraid
<bdmurray> pitti: I'll get it done
<pitti> bdmurray: thanks!
<pitti> that might explain a few extra bug floods indeed
<mvo> slangasek: I'm about to leave to play some hockey, but I can check #851481 in +12h
<slangasek> mvo: sounds fine, thanks.  I'll assign the bug to you so we don't forget
<mvo> ;) no way out for me then anymore now
<mvo> *kidding*
<GrueMaster> Can someone update ltp (Linux Test Project) in Universe?  The last rev hasn't been updated since 2009, and I'm sure there has been a few updates since then.
<slangasek> apw: getting the x-server started as soon as possible> I understand that much, but it still looks like this is being checked redundantly in two different jobs
<slangasek> apw: as in A starts on B or C, and B starts on C or D
<cjwatson> GrueMaster: would be easiest if somebody got a newer version into Debian first
<cjwatson> then it could just be a sync assuming that dtchen's recent upload was a backport
<GrueMaster> Well, since I am not a dev, I wouldn't know who or where to ping.  Thought I would try here first.
<cjwatson> a Debian bug report's the usual way ...
<apw> slangasek, but that ignores the udevtrigger rule on fallbackgraphics
<cjwatson> http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ltp hmm, looks like it could use some help
<slangasek> apw: sorry, I don't follow?
<apw> slangasek, if we have usable graphics then we start gdm as we are ready to go
<slangasek> apw: yes, I understand that
<apw> slangasek, if we don't then we must wait for the vesafb to be probed and then start gdm
<slangasek> but why are we checking for graphics-device-added or drm-device-added in *both* udev-fallback-graphics.conf, *and* gdm.conf?
<apw> so that gdm.conf can get on and start right now as soon as usable graphics appear
<apw> it doesn't have to wait for upstart to start fallback, which will do nothing and then start
<slangasek> yes, so *why are we checking for these events in udev-fallback-graphics at all*?
<apw> slangasek, i believe that is to make the job go away
<apw> slangasek, else it will always start when udevtrigger fires, and we cannot tell if we have graphics
<slangasek> ok, so we use the OR there to detect whether the modprobe vesafb is needed
<apw> essentially yes
<slangasek> and having the OR in the gdm job makes a genuine difference in boot speed, vs. waiting for udev-fallback-graphics to finish?
<apw> slangasek, that i do not know to be fair, iirc that was more about how it was already formed
<slangasek> ok
<apw> it was about the smallest number of changes as it was already mind-bendingly complex
<slangasek> hrm, the drm-device-added check is also different in lightdm/gdm vs. udev-fallback-graphics
<slangasek> drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1 vs drm-device-added PRIMARY_DEVICE_FOR_DISPLAY=1
<apw> yeah i just saw that, i don't think they were different originally
<SpamapS> slangasek: re bug 848823 .. your assumptions about what rc-sysinit used to have are unfortunately off a bit.
<ubottu> Launchpad bug 848823 in ifupdown (Ubuntu) "if all interfaces are configured via NM, static-network-up emitted when only lo is configured" [High,Triaged] https://launchpad.net/bugs/848823
<SpamapS> slangasek: pre 11.10, it was 'start on filesystem and net-device-up IFACE=lo'
<slangasek> SpamapS: oh
<slangasek> SpamapS: ok, so it's not a regression... still a bug though, yes? :)
<apw> slangasek, there might be milage in checking that there is any time benefit and if not, then we should scrap the dups
<SpamapS> I think we may have changed a race
<SpamapS> slangasek: My guess is that by slowing down runlevel 2 we've exposed some other race.
<slangasek> SpamapS: I mean, catching the networking before starting runlevel 2 is why you guys made these changes
<slangasek> apw: ok.  probably a P matter at this point; I'll document this in a bug report - thanks
<apw> slangasek, well i suspect those being differenet is a bug in O and needs review
<SpamapS> slangasek: the issue is very troubling
<slangasek> SpamapS: howso?
<slangasek> apw: yeah, am looking into the difference now
<SpamapS> slangasek: that the user would have to restart the kernel server once per day .. seems a bit odd!
<SpamapS> oh wait
<slangasek> SpamapS: well, he clarified that it's only after reboot - he seems to just reboot frequently :)
<SpamapS> ok reading through the comments
<blackz> hi people
<slangasek> blackz: hello
<slangasek> stgraber: I'm looking at the history of the gdm upstart job, and on 2011-05-02 you merged a new version from jhunt that readds the 'or graphics-device-added PRIMARY_DEVICE_FOR_DISPLAY=1' that had been deliberately removed by pitti in response to bug #615549... but there's no other explanation for this change except that it fixes single user mode (bug #436936).  Do you know of a good reason for readding this line, or is this a mismerge?
<ubottu> Launchpad bug 615549 in kdebase-workspace (Ubuntu Lucid) "gdm/kdm starting too early for DRM modules to load, no video" [High,Triaged] https://launchpad.net/bugs/615549
<ubottu> Launchpad bug 436936 in gdm (Ubuntu Natty) "gdm upstart job checks /proc/cmdline for single user mode, won't start on post-boot runlevel change" [Medium,Triaged] https://launchpad.net/bugs/436936
<stgraber> slangasek: Ouch, that was a while ago. I honestly don't remember the details except that it's very likely the single user mode fix isn't needed anymore with the changes to friendly-recovery
<slangasek> stgraber: no, single user mode still exists conceptually and still needs to be handled anyway... :)  But this particular line looks to me like a mismerge, so I'll aim to fix it
<slangasek> apw: the 'card0' delta exists from the first occurrence of this check on both the gdm and udev-fallback-graphics jobs
<apw> slangasek, i wish i could remember the details.  the conditions gdm i only switch from udevsettle to udev-fallback-graphics, the conditions for udev-fallback-graphics came from something it was enhancing
<apw> slangasek, but ... it does seem appropriate that if gdm doesn't think it can use !card0, then its not clear that udev-fallback should not also feel the same about things
<apw> slangasek, i assume card0 is there so we only load one gdm regardless of how many screens and cards we have
<slangasek> we would only load one gdm anyway
<slangasek> I'm not sure under what circumstances card0 would or wouldn't be included
<apw> well vesafb is really fallback for 'the one gdm will use' in my mind, so i suspect it needs card0 too
<slangasek> I'm not convinced, actually
<slangasek> surely if *any* drm-device-added is emitted, we know we don't need to modprobe vesafb?
<apw> it is a shame thinking about upstart rules is akin to putting ones sanity in a cross-cut shreader
<slangasek> hey, these are udev semantics, not upstart rules :)
<slangasek> or at least, the udev upstart bridge
<apw> slangasek, that is reasonable _if_ gdm will then use card1, cause it starts cause fallback finishes
<slangasek> apw: but what's the definition of "card0" vs. "card1"?  How can you have a card1 without a card0?
<apw> but it is odd to me that it will use card0 staight away, but not use card1 until we finish
<apw> but then, we'll finish pretty quick once card1 emits, so its probabally starting on fallback finish anyhow
<slangasek> oh, because they may start in parallel and we don't want to accidentally start on the wrong card due to a race
<slangasek> in that case, I think udev-fallback-graphics should be checking for card0
<ejat> bug 854008
<ubottu> Launchpad bug 854008 in gucharmap (Ubuntu) "package libgucharmap7 1:3.0.1-0ubuntu1 failed to install/upgrade: trying to overwrite '/usr/lib/libgucharmap_2_90.so.7.0.0', which is also in package libgucharmap-2-90-7 1:3.1.92-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/854008
<slangasek> so that if card1 initializes before card0 for any reason, gdm doesn't accidentally start on the wrong card or with the wrong driver
<apw> slangasek, though then we will load vesafb if we don't ahve a 0
<slangasek> apw: how do you not have a 0, though?
<apw> slangasek, as long as that very reasonable assumption is true, then yes i think card0 on both should work
<SpamapS> slangasek: you are pre-Moor occupation and just can't fathom algebra?
<apw> if its not true, then i think we are breaking the race order protection anyhow, and thats potentially serious too
 * SpamapS made a bad math/history joke. ;)
<slangasek> SpamapS: a cursory examination of my mudejar architecture will conclusively establish me as post-Moor
<SpamapS> slangasek: hmm, then I guess you can't not have a 0. :)
<slangasek> ;)
<apw> slangasek, i am more inclined to say drop us to dependancy on fallback-graphics, and move card0 there too, and lets see who hollars
<apw> it should be easy to check its still right for the common cases
<slangasek> apw: well, further digging shows that gdm should probably *not* start immediately on graphics-device-added because we may get a subsequent drm-device-added for the same video device... so I'm going to dig further
<slangasek> in my nearly-palindromic fashion
<apw> slangasek, ok .. yeah there is a another difference there, and we risk starting gdm early via -fallback- too
<slangasek> yep
<slangasek> hence the need for further digging
<slangasek> we may need to annotate the udev-fallback-graphics job somehow so we know whether we've loaded vesafb
<apw> slangasek, i am unsure you can represent that difference with a mear dependancy; i suspect it needs to emit something specific when it does not probe or something
<bdmurray> Could I get somebody to sponsor http://people.canonical.com/~brian/tmp/kerneloops_0.12+git20090217-1ubuntu15.debdiff
<slangasek> apw: we'll see what I can figure out :)
<apw> slangasek, i still have this lightdm white flash ... did you say your was gone ?
<slangasek> apw: I never saw a white flash, just a black one - but that's all the responsibility of lightdm
<slangasek> so long as you're not getting text mode, that is
<slangasek> apw: do you have unity-greeter installed?
<apw> slangasek, nope, just as lightdm initiliases ... i believe i have the new greeter yes, the slidey boxy off to the lefty one
<slangasek> right, that's the one
<htorque> apw: that's a greeter problem, if you switch to lightdm's gtk greeter, there's no such white flash.
<apw> htorque, ok that sounds good, is that easy to check so i can confirm
<apw> s/check/change
<htorque> apw: make sure you have 'lightdm-gtk-greeter' installed and change to it in the /etc/lightdm/lightdm.conf file (probably need to create one)
<htorque> apw: that's mine http://paste.ubuntu.com/693228/
<stgraber> apw: /usr/lib/lightdm/lightdm-set-defaults -g lightdm-gtk-greeter
<htorque> or that :)
<htorque> stgraber: thanks ;-)
<apw> ok i think that shows no flash, though there are other flashing things to confuse the mind... good, thanks
 * bdmurray is still looking for a sponsor for kerneloops
<slangasek> apw: I'm still getting the cursor between grub and kernel after upgrading to the latest grub-pc, and I've even run dpkg-reconfigure grub-pc to ensure that grub-install gets run (and isn't being bypassed).  Any idea how I should debug this further?
<chrisccoulson> slangasek, what am i looking for when i boot with plymouth:debug?
<slangasek> chrisccoulson: /var/log/plymouth-debug.log
<chrisccoulson> slangasek, oh, not sure why i didn't see that the first time around ;)
<cjwatson> slangasek: it would be update-grub not grub-install that matters, anyway
<slangasek> cjwatson: oh, it is?  I thought this was about license checking of the binary modules?
<cjwatson> slangasek: oh, errrrr
<cjwatson> ignore me
<cjwatson> brains
<slangasek> :)
<cjwatson> 16:12 <cjwatson> from the command line, try:
<cjwatson> 16:12 <cjwatson> hwmatch ${prefix}/gfxblacklist.txt 3
<cjwatson> 16:12 <cjwatson> echo $?
<cjwatson> 16:12 <cjwatson> echo $match
<slangasek> and I should do that from a reboot, right, I guess emulating that from a running system does no good?
<cjwatson> yeah, need that from the actual grub prompt not grub-emu or whatever
<cjwatson> (no idea whether it'd even work from grub-emu)
<seb128> slangasek, update-notifier should use libappindicator
<seb128> slangasek, neither the whitelist or the behaviour change seem a good reply to the issue you raised
<slangasek> seb128: critical bits of how we notify users of security updates should not regress in the absence of libappindicator support
<seb128> slangasek, there is no absence of libappindicator support
<slangasek> in update-notifier?
<seb128> slangasek, libappindicator fallback to a gtkstatusicon when there is no indicator loader
<seb128> slangasek, if update-notifier was using libappindicator it would work under unity and display an indicator and work out of unity and fallback to a gtkstatusicon
<slangasek> yes, and no one's patched update-notifier to use libappindicator - it's not ok for that to be silently broken becuase update-notifier "should" be updated to use libappindicator
<seb128> slangasek, well, argue with sabdfl and dx, half of the status icon users in the archive are in this case, it was a design decision that forced on us with unity
<seb128> they refused to use the whitelist to justify not porting code to the new apis
<slangasek> seb128: do you mean to say that unity no longer supports whitelisting?
<seb128> slangasek, not that I disagree with you but we fought that battle previous cycle and lost it
<seb128> slangasek, no, I say that whitelist has been made as way to support things we can't patch, i.e jave, skype, etc
<slangasek> if the whitelist is there, it's important that update-notifier be in it.  It's a no-op for the default case, but critical to security support for those who have opted in to the panel icon
<seb128> slangasek, sabdfl and dx refused to use it as a mean to not port code we can patch
<slangasek> seb128: where is the whitelist?
<seb128> slangasek, dconf
<seb128> it's trivial to add something to it technical
<slangasek> seb128: well, I don't know any of the technical details of adding it to the whitelist; which package would need to do what in order to have update-notifier in the whitelist?
<seb128> unity
<slangasek> once I can figure out what needs to be patched, I'll argue with whoever I need to :)
 * pitti wishes slangasek good luck, he's been through that several times, too
<pitti> perhaps more voices will have some more effect
<achiang> would a moderator please review the queue on ubuntu-devel@ please? i responded to the "Getting new packages into Ubuntu" and would like my mail delivered before the conversation goes stale
<Q-FUNK> about Bug #852887, I'm wondering how may more like this will come and bite us.
<ubottu> Launchpad bug 852887 in bluez (Ubuntu) "package bluez (not installed) failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New] https://launchpad.net/bugs/852887
<YokoZar> pitti: Do I need a new bug for https://bugs.launchpad.net/ubuntu/+source/wine1.0-gecko/+bug/814975  ?
<ubottu> Ubuntu bug 814975 in wine-gecko (Ubuntu) "please remove obsolete wine-gecko from oneiric" [Wishlist,Fix released]
<cjwatson> achiang: done
<achiang> cjwatson: thank you
<slangasek> Q-FUNK: have you manually enabled insserv on your system for some reason?
<slangasek> Q-FUNK: because by default we have /etc/init.d/.legacy-bootordering set, which should disable all insserv handling here
<Q-FUNK> slangasek: it might have remained enabled over a few years of upgrades
<Q-FUNK> slangasek: of course, it leaves me pondering why ubuntu's APT override hasn't simply demoted the package to e.g. optional or extra
<slangasek> Q-FUNK: the /etc/init.d/.legacy-bootordering file is created with a hammer by upstart; I've not heard of anyone hitting this issue due to an upgrade
<slangasek> Q-FUNK: as for insserv not being demoted to optional or extra, it's simpler to use the flag file in /etc/init.d to limit divergence from Debian
<Q-FUNK> slangasek: mind you, recent insserv releases have been pretty good at skipping packages that don't have the LSB header at all. it's literally been ages since I bumped into such an issue.
<Q-FUNK> slangasek: I haven't gone to extremes to enable insserv, so I'd asumed it simply remained on from pre-upstart days.
<slangasek> in fact, insserv (or rather, startpar) is known to fail in horrible ways with upstart
<slangasek> (I'm working on fixing this actually, to make upstart usable in Debian, but it's definitely broken today in Ubuntu)
<Q-FUNK> ah, that could be interesting.
<Q-FUNK> slangasek: I really don't have any /etc/init.d/.legacy-bootordering  here.
<Laney> why is a QA bot spamming me?
<ajmitch> in bug mail?
 * micahg blames bdmurray 
 * slangasek muses out loud that the dots-over-text plymouth error on shutdown could be caused by both gdm and lightdm being installed in the upgrade case, such that plymouth starts on 'stopped gdm and runlevel 6' because the gdm job starts and then stops before lightdm is done
<YokoZar> Were we actually trying to fix the shutdown screen this cycle?
 * YokoZar remembers discussing it last UDS
<broder> slangasek: no, that's not why it happens, because it happens on natty
<slangasek> broder: it didn't happen to me on natty
<slangasek> maybe there are multiple causes
<broder> slangasek: i see it all the time on natty. i assume it boils down to "omg shutdown is only semi-upstartified and therefore super racy"
<slangasek> YokoZar: we are generally trying to fix bugs
<slangasek> broder: that part of the shutdown is not semi-upstartified
<broder> hmm...i guess it should theoretically be sufficiently upstartified
<broder> there's definitely a race with casper, though
<slangasek> broder: this is /etc/init/plymouth.conf, start on ... or (runlevel [016] and stopped $fwibble)
<YokoZar> slangasek: what I mean is last UDS we mentioned it was broken in Natty (and possibly Maverick as well) and that no one had really paid attention to it since Lucid
<slangasek> YokoZar: well, a) it wasn't broken for me in either maverick or natty, b) I don't know where it was mentioned but it wasn't mentioned to me.  I only fix the bugs I know about :)
<slangasek> broder: by "casper", do you mean "ubiquity/oem-config", which I notice are listed in plymouth-stop.conf but not plymouth.conf?
<YokoZar> slangasek: Well, glad you're thinking about it, it has been an annoying bit of anti-polish lately :D
<broder> slangasek: no, i mean /etc/init.d/casper and its "please remove the installation media now" propmt
<slangasek> broder: oh, that, yes.  that's certainly distinct from the problem of plymouth rendering its progress bar on top of a text console
<broder> slangasek: i know; i've seen the dots-on-text issue as well since at least natty on some machines, possibly earlier
<slangasek> mmk
<broder> though now that you mention it, i do seem to see it consistently on the one machine i've upgraded to oneiric. i'll try removing gdm and see if it goes away
<bdrung> tumbleweed: can i release u-d-t in to days to sid?
<slangasek> broder: :)
<tumbleweed> bdrung: go for it
<bdrung> tumbleweed: sponsor-patch should handle sync requests correctly now
<broder> slangasek: no dice. i do get a flash of the full splash screen before i just get dots-on-text, though
<broder> (no idea whether i got that before or not)
<slangasek> hmm
<slangasek> broder: I suggest throwing an 'echo $UPSTART_EVENTS >> /path/to/writable/log' into the job and see what it says when you get this
<broder> i'll try just cranking the upstart log level
<slangasek> I guess that might work :)
<broder> slangasek: ...d'oh. i removed gdm, i didn't purge it
<broder> i bet that doesn't work :)
<ion> Every now and then i hit _ on the âuninstalled packagesâ line in aptitude. :-)
<broder> slangasek: we have a winner!
<slangasek> cool
<slangasek> now we just have to fix the darn thing
<broder> slangasek: yeah, i think that may prove to be harder
<slangasek> which means adding new initctls to all the affected dms
<Nafai> kirkland: Hey.  So, about dotdee.  I'm thinking about some things that I need for handling my local dotfiles and other files in ~ that are shared across machines.  I'm thinking that dotdee would solve some of the problems I am seeing.
<Nafai> kirkland: but, particularly with the use of alternatives, it is currently aimed at system-wide stuff
<kirkland> Nafai: interesting, okay
<kirkland> Nafai: right, I can see that
<Nafai> kirkland: curious as to what kind of changes you might suggest (I'm willing to write them, the dotdee code is very clean and I <3 shell scripts) to better support the user dir case?
<kirkland> Nafai: i suppose it would be easy to add a user-mode (in addition to admin mode)
<kirkland> Nafai: thanks for the code compliment :-)
<kirkland> Nafai: um, okay, so I think it should be pretty easy to tell if you're running in user mode, vs. admin mode -- (are you a) non-root, and b) operating on a file that you own)
 * Nafai nods
<kirkland> Nafai: that would probably be the first patch/commit
<kirkland> Nafai: let me take a look at the update-alternatives bit ...
<Nafai> k
<kirkland> Nafai: hmm, the inotify stuff is going to be tricky as non-root
<kirkland> Nafai: you'd need to start/run an inotify daemon as your non-root user
<kirkland> Nafai: currently, there's an upstart job that runs that at startup
<kirkland> Nafai: for the root case
<Nafai> ah
<Nafai> I hadn't looked at inotify enough to know that it needed a separate instance
<kirkland> Nafai: okay, so, the update-alternatives stuff would be easy to simulate for non-root users
<kirkland> Nafai: we would just create a couple of small functions in that shell script that either do update-alternatives (for real) if in admin mode, or if not, just shuffle symlinks somewhere in $HOME/.somewhere_xdg_compliant
<kirkland> Nafai: inotify is the harder part
 * Nafai nods
<kirkland> Nafai: inotify is a daemon that watches for filesystem events
<kirkland> Nafai: that match some configuration
<kirkland> Nafai: when you set something up in dotdee, it addes an inotify watch to the path you've dotdee'd
<kirkland> Nafai: iwatch is the actual daemon
<kirkland> Nafai: see /etc/init/dotdee
<kirkland> Nafai: see /etc/init/dotdee.conf
<kirkland> Nafai: exec iwatch -f /etc/dotdee.xml -p /var/run/dotdee.pid
<kirkland> Nafai: so each user wanting to dotdee stuff in their home dir would need to have a similar iwatch daemon running
<kirkland> Nafai: but with their own dotdee.xml and pid
<kirkland> Nafai: all quite doable
 * Nafai nods
<kirkland> Nafai: and then that user would need some way to start the daemon at boot (perhaps through an @reboot cronjob?)
<Nafai> sounds reasonable
<kirkland> Nafai: all of that is reasonable, i think
<kirkland> Nafai: if enough users come to me asking me to do this sort of thing, i could hack this out in a day or so
<kirkland> Nafai: if you want to branch it and work on it, that's cool too
<Nafai> I think I might, and send you branches to review
<kirkland> Nafai: if the changes are good, i think it's a reasonable feature to add
<kirkland> Nafai: fair enough
<kirkland> Nafai: advice:
<Nafai> cd ..
<kirkland> Nafai: detect that user/admin mode
<Nafai> whoops, wrong window :)
<kirkland> Nafai: wrap the current update-alternatives calls in a local function, that either does update-alternatives, or does our update-alternatives like things
<kirkland> Nafai: look at the xdg user dirs a bit, as some people get their panties in a wad about stuff like $HOME/.dotdee
<kirkland> Nafai: they want it in $HOME/.cache or $HOME/.config or some other less discoverable location
<Nafai> k, I'm used to using those, so not a problem
<kirkland> Nafai: cool
<kirkland> Nafai: happy to have you hacking on dotdee ;-)
<Nafai> thanks, it just happens to fit a niche of a problem I am trying to solve
<Nafai> for example, just right now I'm working with Arch in a vm. Python3 is the default, and I was installing some scripts in ~/bin I have in every box that just use /usr/bin/python.  I need to change those to python2, but only here on arch
<SpamapS> kirkland: note that upstart has some basic "user session" support
<kirkland> SpamapS: wow, rally?
<kirkland> really, even?
<SpamapS> kirkland: yeah, let me dig up the info on it..
<SpamapS> kirkland: you can have a $HOME/.init/ but I forget how to make upstart read it.
<SpamapS> kirkland: may want to hit up jhunt about it. IIRC there are some big caveats
<slangasek> cjwatson: so from grub shell, I get $? == 0 and $match == 0; is that the expected result?
<slangasek> (the hwmatch command itself succeeds with no output, of course)
<cjwatson> slangasek: that should amount to 'set gfxpayload=keep', so yes that's expected
<cjwatson> which I think means it may be apw's problem not mine
<slangasek> heh
<slangasek> ok :)
#ubuntu-devel 2011-09-20
<ScottK> cjwatson: Are you sponsoring libnet-server-perl?
<cjwatson> ScottK: yes, just did
<ScottK> OK.  Thanks.
<cjwatson> glad somebody dealt with that, it was in danger of languishing on my queue
<_min_> join #ubuntu
<slangasek> broder: bug #854329, fwiw
<ubottu> Launchpad bug 854329 in plymouth (Ubuntu Oneiric) "race condition on shutdown with more than one DM installed" [High,Triaged] https://launchpad.net/bugs/854329
<ScottK> If Firefox is so embarrassed about having crashed, why does it keep doing it ...
<lifeless> slow learner
<Lirodon> so I'm randomly throwing out ideas for making the boot process a little more elegant
<RAOF> It's worth noting that ideas are generally cheap; it's the implementation that's generally hard, and we've got lots of implementin' to do already.
<Lirodon> http://i.imgur.com/EH2AH.png how hard would it be to rig something like this up in GRUB 2?
<RAOF> I've not played with GRUB's theming myself, but from what I've seen of others' theming that looks perfectly doable.
<Lirodon> Yeah, for something that simple, I've seen WAY more complex things in gfxmenu
<Lirodon> I had another wayward plot of having Ubuntu converted into a console font
<ScottK> It's a little late in the release cycle for new ideas too.  We're mostly on "OMG - Broken" stuff now.
<Lirodon> well, for the next one
<RAOF> Eh.  It's the perfect time for ?I'd like to do some feature-work for the next cycle? though.
<jbicha> I'd like to see memtest & recovery hidden behind the second screen where the older kernels live
<Lirodon> Did they at least give us the right to change our GTK theme/window border/stuff? in Unity?
<jbicha> since so many normal users dual boot, having a cleaner grub is useful
<jbicha> Lirodon: yes, you can switch between Ambiance & Radiance in System Settings>Appearance, if you want more try gnome-tweak-tool
<Lirodon> Oh that is just a downgrade
<Lirodon> least its better than nothing at all *cough Gnome 3*
<pitti> Good morning
<pitti> bdmurray: do you mind if I reject the kerneloops upload? we certainly want to keep it enabled until release
<didrocks> good morning
<tkamppeter> pitti, hi
<pitti> hello tkamppeter
<tkamppeter> pitti, it is about bug 853921. Do you know why our CUPS depends on ttf-freefont? According to an upstream bug report the original source does not depend on this package.
<ubottu> Launchpad bug 853921 in cups (Ubuntu) "Drop depencency on ttf-freefont" [Undecided,New] https://launchpad.net/bugs/853921
<pitti> tkamppeter: it was you :) in 1.3.8-4
<pitti> Added "Depends: ttf-freefont" for the cups package, as the
<pitti>     texttopdf filter needs these fonts.
<tkamppeter> pitti, so it seems that I have to ask the author of the texttopdf filter whether there are alternatives (or simply uninstall ttf-freefont and see whether the filter keeps working).
<dholbach> good morning
<apw> slangasek, wass'up
<slangasek> apw: hiya
<apw> slangasek, i see my name in scrollback... any details on the problem?  (you were talking to master watson)
<slangasek> apw: right, I get a black text screen w/ cursor still in between grub and plymouth; and it's not the hwmatch issue anymore
<slangasek> apw: I can't offer much more than that currently, except to say that plymouth starts from my initramfs and I'm looking to see if I can rule that out as a cause
<apw> slangasek, i presume you've forced keep to confirm that in the specific grub entry for boot
<apw> slangasek, as if the previous boot was a fail you get =text regardless of hwmatch
<slangasek> sorry, done what?
<apw> if you edit the entry it has gfxpayload=$something in it, change that to =keep to be really sure we are handing off
<apw> as grub2 can turn off handling for reasons other than your h/w components.  previous failure to boot being one of them
<slangasek> ah; well, it's happened on every single boot, so unless grub is confused about what constitutes a boot failure it wouldn't seem to be that
<slangasek> but I can test with a forced 'keep', sure
<apw> slangasek, that'd be great as i wasted 2 days debugging one of mine to find it was doing that to me :/
<slangasek> yeesh
<slangasek> where does recordfail get recorded?
<apw> slangasek, it occurs to me we could do with some kind of debug mode here so we can tell who is making these black screens... perhaps by making themm all different colours
<apw> slangasek, now that i don't know
<tkamppeter> pitti, for getting CUPS independent of ttf-freefont I need to copy 4 font files from ttf-freefont into cups. It is around 900K. Is this OK?
<pitti> tkamppeter: no, why? we can just keep the dependency
<pitti> the point of that bug was to get rid of the need for it, not to copy the files around to all places which still need it -- in that case we should just keep the package around
<tkamppeter> pitti, how should we handle this bug then?
<pitti> tkamppeter: I'd just keep it as it is, and use it to track removing the dependency from texttopdf
<pitti> tkamppeter: at one point we had an alternative depends on gsfonts-x11 or something like htat
<tkamppeter> pitti, so we should better do changes inside texttopdf? Has this to be done for Oneiric or is this for the longer term?
<pitti> tkamppeter: this bug is in no way urgent
<tkamppeter> pitti, OK, so it is for P. P. ...
<tkamppeter> pitti, bug 853133 gives the impression that some icon got taken out of Oneiric which is needed by system-config-printer. What to do in such a case?
<ubottu> Launchpad bug 853133 in system-config-printer (Ubuntu) "scp-dbus-service.py crashed with GError in _set_job_status_icon(): L'icÃ´ne Â« gtk-media-pause Â» n'est pas prÃ©sente dans le thÃ¨me" [Undecided,New] https://launchpad.net/bugs/853133
<pitti> tkamppeter: hm, it's shipped in humanity-icon-theme
<pitti> so it should be there by default
<seb128> pitti, if people use humanity...
<tkamppeter> pitti, thanks, so I will ask the reporter of this bug to reinstall humanity-icon-theme.
<seb128> tkamppeter, you can ask what icon theme they use as well
<seb128> it's likely they use a different one
<tkamppeter> seb128, I have asked. Please also add a comment to the bug if you have better ideas how to ask the user for the needed info.
<mvo> tkamppeter: good morning! when testing a release upgrade in a vm I get a hang when cups is restarted early, it appears like its starting up but then terminates really quickly (status 27 is what syslog tells me). any idea how to debug this further?
<tkamppeter> mvo, can you set CUPS to debug logging ("cupsctl LogLevel=debug") and restart CUPS again? Can you also have a look into bug 854490? This seems to be something similar.
<ubottu> Launchpad bug 854490 in cups (Ubuntu Oneiric) "update from natty to oneiric hangs on libpam0g upgrade and cups reload" [Critical,New] https://launchpad.net/bugs/854490
<tkamppeter> pitti, it seems that there is a problem with CUPS and Upstart, can you have a look into bug 854490? mvo seems to have the problem, too.
<ubottu> Launchpad bug 854490 in cups (Ubuntu Oneiric) "update from natty to oneiric hangs on libpam0g upgrade and cups reload" [Critical,New] https://launchpad.net/bugs/854490
<tkamppeter> mvo, when the error occurs again, have a look into /etc/cups/cupsd.conf.
<tkamppeter> mvo, as usual, I am scrambling up everything. Trying again ...
<pitti> tkamppeter: it's not an upstart issue
<tkamppeter> mvo, ... when the problem occurs again, can you have a look into /var/log/cups/error_log?
<pitti> either the daemon is crashing or hanging, or the post-start script which does the PPD updates, and all the coldplugging is hanging
<pitti> we need error_log
<pitti> and possibly a set -x in the post-start script to see what's gong on
<mvo> tkamppeter: thanks, that is very helpful, I will re-run the test with the debug on
<pitti> 'going'
<mvo> tkamppeter, pitti: cups keeps crashing and init keeps restarting it, that is what i see in syslog
<tkamppeter> mvo, so the /usr/sbin/cupsd crashes? So then we need the error_log, perhaps better in extended debug mode ("cupsctl LogLevel=debug2").
<mvo> that is what I saw in the log, I restartedthe upgrade test, will take a couple of minutes until I hit the bug again
<tkamppeter> mvo, cups crashes with exit status 27 or 127?
<tkamppeter> mvo, if you do not get the "cupsctl" command to work due to no running CUPS daemon, edit /etc/cups/cupsd.conf, making sure it contains a line "LogLevel debug2" and no other LogLevel line.
<mvo> tkamppeter: 127
<mvo> tkamppeter: thanks, I added it to the level, its running now, we just need to be patient now
<mvo> tkamppeter: cupsd reports a missing symbol "_cups_strncasecmp" - I will attach the full log to the bugreport
<mvo> tkamppeter: updated with the full info
<tkamppeter> mvo, this look like the CUPS library and the CUPS daemon being updated in the wrong order, the daemon being restarted with a non-matching CUPS library being present.
<mvo> tkamppeter: right, at this point libcupsmime1 is unpacked but not configured yet
<tkamppeter> pitti, about the problem of mvo, how is the best way to assure that the restart of cupsd only happens if all libraries needed by cupsd are completely updated? Is the "Depends: ${shlibs:Depends}" in debian/control not enough?
<pitti> tkamppeter: which library is behind in particular? it already depends on >= 1.5.0 for libcups2 and libcupsmime1
<pitti> tkamppeter: but it only has >= 1.4 depends for libcupscgi1, libcupsdriver1, libcupsimage2, libcupsppdc1
<pitti> tkamppeter: these are determined using the symbols files, but I just recently fixed a bug in Debian which had a too weak libcupsmime1 dependency
<pitti> as cupsd was using private symbols from that library
<tkamppeter> pitti, the symbol is _cups_strncasecmp, looks like a private symbol, but I do not know which library provides it.
<pitti> sounds like debian bug 641182
<ubottu> Debian bug 641182 in libcupsmime1 "libcupsmime1: undefined symbol: _cups_strcasecmp" [Serious,Fixed] http://bugs.debian.org/641182
<tkamppeter> pitti, did you actually upload 1.5.0-6? In the BZR it is marked unreleased?
<pitti> I did, yes, and it's released in bzr (r1044)
<pitti> but it might very well be another library which is lagging behind
<pitti> I only bumped the dependency to libcupsmime1
<tkamppeter> pitti, perhaps you should bump the dependencies of all libraries, due to the problem of private symbols being used.
<Sp4rKy> W8
<pitti> tkamppeter: yeah, possibly
<pitti> tkamppeter: ah, mvo said it was libcupsmime1
<pitti> mvo: cups has a Depends: libcupsmime1 (>= 1.5.0-0ubuntu1), how can libcupsmime1 not be configured yet when cups gets configured?
<pitti> mvo: the symbols didn't change between -0ubuntu1 and -6
<pitti> I still don't understand this bug at all
<pitti> if libcupsmime1 1.4.0 was still installed, then this can happen
<tkamppeter> pitti, for me it looks like that libcupsmime uses the symbol _cups_strncasecmp which is provided by another CUPS library. This other CUPS library seems not to be up-to-date.
<pitti> that's from libcups2
<mvo> pitti: cups does not get configured at this point, its libpam0g triggering the restart
<pitti> but libcupsmime1 has Depends: libcups2 (>= 1.5~), so sohuld be fine
<pitti> mvo: oh
<pitti> that can't work
<pitti> as that could happen at any time, and we can't enforce any ordering there with depends?
<mvo> its pretty unfortunate timming, cups is unpacked, libcupsmime1 is unpacked, but both are not configured yet
<mvo> pitti: tricky, I guess we could try something with versionized breaks in libpam0g
<pitti> mvo: is cupsd actually running at that time?
<pitti> IMHO libpam0g's postinst shouldn't start services which aren't running
<pitti> as that's bound to fail, not only for cups
<pitti> AFAICS /var/lib/dpkg/info/libpam0g:amd64.postinst makes no attempt to determine if a service is running, except for gdm
<mvo> pitti: I don't know, I can check in a bit when triggering the next upgrade
<pitti> mvo, tkamppeter: bug updated
<tkamppeter> pitti, OK, thanks.
 * jml discovers libapr1.symbols
<Sweetshark> if someone knowing his way around ecryptfs could have a look at bug 745836 and see if he/she could drop a hint or give a clue that would be most helpful.
<ubottu> Launchpad bug 745836 in libreoffice (Ubuntu) "soffice.bin crashed with SIGSEGV in cppu::throwException()" [High,Confirmed] https://launchpad.net/bugs/745836
<tkamppeter> What does "package libgs9 9.04~dfsg-0ubuntu7 failed to install/upgrade: short read on buffer copy for backend dpkg-deb during `./usr/lib/libgs.so.9.04'" mean? Is this a problem of the packaging, the user's system, or the mirror?
<geser> IIRC there was a blog about it, let me find it
<geser> tkamppeter: http://raphaelhertzog.com/2011/06/27/deciphering-one-of-dpkgs-weirdest-errors-short-read-on-buffer-copy/
<tkamppeter> geser, thanks.
<doko> ScottK, webkitkde ping, bug 832933
<ubottu> Launchpad bug 832933 in webkitkde (Ubuntu Oneiric) "webkitkde version 0.9.6-0ubuntu2 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/832933
<doko> soren, ping on bug 836997
<ubottu> Launchpad bug 836997 in user-mode-linux (Ubuntu Oneiric) "user-mode-linux: Missing build dependencies: linux-source-2.6.35" [High,Confirmed] https://launchpad.net/bugs/836997
<soren> doko: I've not forgotten about it, but also haven't had a chance to look at it at all yet.
<ivoks> sta si kupio? :)
<soren> ivoks: *blink*
<ivoks> :)
<ivoks> wrong channel
<soren> :)
 * Sweetshark wonders if he can get below 800 open bugs in LO-packaging before release ..
<pitti> Sweetshark: you know, we have an API to close bugs :)
<Sweetshark> pitti: doesnt help really if I need to read them ...
<Sweetshark> pitti: ... or should I skip that? ;D
<ScottK> doko: Done.
<doko> ScottK, and my pings about dovecot-* ?
<ScottK> doko: You didn't get my ping back to ask Daviey?
<doko> sorry, no
<ScottK> Him or ivoks.
<ScottK> No problem.
<ScottK> doko: BTW, the only solution I see for bug 836830 is binary removal since the needed build-dep isn't even packaged in Debian.
<ubottu> Launchpad bug 836830 in r-cran-pscl (Ubuntu Oneiric) "r-cran-pscl ftbfs (missing b-d on r-cran-gam)" [High,Confirmed] https://launchpad.net/bugs/836830
<doko> binary+source
<ScottK> Doesn't hurt to leave the source for once it's fixed.
<ScottK> There's an ITP for the missing depends, so presumably it'll get sorted eventually.
<ScottK> Either way, but don't blacklist it.
<shnatsel> infinity: hello, I seek docs about live-build :) They are needed for UGR, elementary OS and local seed/ISO testing Ubuntu Studio. There seems to be a comprehensive guide at http://live.debian.net/manual/, but according to https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-live-build ubuntu did a lot of tweaks, so first of all I need a tutorial to reproducing Ubuntu images.
<ogra_> shnatsel, have a look at livecd-rootfs
<ogra_> it has all the ubuntu related additions
<shnatsel> ogra_: the blueprint says that it's abandoned and ISO builds are switched to live-build since Oneiric
<ogra_> it was implemented differently
<ogra_> all ubuntu realted bits that require non-upstream suitable changes are in livecd-rootfs ... everything else went upstream into live-build
<shnatsel> ogra_: ah-hah... so, how do I reproduce an Ubuntu ISO using these tools?
<ogra_> not at all, live-build produces livefs images
<ogra_> no isos
<ogra_> you would get a kernel, initrd and squashfs out of it ...
<ogra_> (on x86 at least)
<shnatsel> let's assume I'm familiar with it
<shnatsel> so, how do I reproduce the squashfs image then?
<shnatsel> ah, wait, livefs
<shnatsel> so I just have to pack it into ISO then, right?
<ogra_> you will have to do some isolinux/syslinux stuff to make it bootable, but yes
<shnatsel> and I can add stuff like wubi etc
<shnatsel> ah-hah
<dholbach> pitti, is there a new pango1.0 upload planed?
<dholbach> planned
<pitti> dholbach: I did one a few hours ago, a new upstream snapshot
<dholbach> ah
<pitti> dholbach: I haven't planned another one, but of course I can do one if you need something changed
<dholbach> no, I was just wondering because gtimelog was not installable
<dholbach> and I couldn't see a pango1.0 upload on oneiric-changes
<dholbach> :)
<doko> how do I make scons builds verbose by default?
<shnatsel> ogra_: so, are there any docs on using live-build, livecd-rootfs or whatever?
<ogra_> i dont think there is anything beyond the upstream documentation
<ogra_> but that should suffice
<shnatsel> upstream has never used live-build, ever
<shnatsel> and I don't even know where to get ubuntu code
<shnatsel> ooops
<shnatsel> mistake
<ogra_> you pointed to the upstream doc above
<shnatsel> ugh... so many confusing names...
<shnatsel> ogra_: yes but I still don't know where are the ubuntu tweaks, how do I get them etc
<ogra_> in livecd-rootfs
<shnatsel> upstream has never used livecd-rootfs, ever
<ogra_> there is a live-build subdir
<ogra_> that carries the additional scripts to put into the live-build tree
<shnatsel> ah-hah... thanks
<shnatsel> ogra_: so, shall I approach building ISOs using live-build directly or shall I use livecd-rootfs as a wrapper to live-build?
<ogra_> what we do is using BuildLiveCD from livecd-rootfs though thats adapted to the build inbfarstructure in the datacenter
<shnatsel> ogra_: and what are its requirements?
 * shnatsel expects something like write access to ubuntu archive mirror
<shnatsel> ugh... sorry g2g
<bdmurray> pitti: I was coordinating the kerneloops work with the kernel team so check with them.
<alexbligh> We are using the debian/ubuntu installer to install a custom version of Ubuntu Lucid from DVD. We have a working preseed file, but we need to ask the user a slightly complex question. We want to retrieve a list of options using curl, present them with the list of options (numbered), and allow them to choose a number (and write the option text somewhere on disk). We can't see how to do this directly from the preinst. We can write some perl or so
<alexbligh> mething to ask the question, but d-i and dpkg -i seem to fail when anything asks for user input other than through the debconf frontend. Any ideas on how we might do this?
<happyaron> doko: can you please try to sync the new version of ns3? it builds fine on most archs of Debian now.
<happyaron> ns3 3.12.1+dfsg1-2
<cjwatson> alexbligh: you should use debconf
<cjwatson> alexbligh: you can dynamically generate lists of choices and substitute them into a debconf template using db_subst
<cjwatson> it would be from a config script not the preinst, probably
<ahasenack> hi guys, can someone take a look and hopefully approve the following SRU updates that are sitting in the unapproved queue? smart for lucid, maverick and natty
<ahasenack> and landscape-client for maverick and natty
<doko> happyaron, still ftbfs
<doko> Daviey, zul: ping on bug 756107
<ubottu> Launchpad bug 756107 in php-imap (Ubuntu Oneiric) "php-imap version 5.3.5-0ubuntu1 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/756107
<zul> doko: ill take care of it right now
<Daviey> doko: Looking, can you use ~ubuntu-server for things like this?
<Daviey> ah, zul is ON THE CASE.
<happyaron> doko: OK, I see it's a DSO linking issue, will communicate with the maintainer.
<doko> happyaron, thanks
<wzssyqa> hi doko
<happyaron> doko: wzssyqa is the maintainer, he'd like to talk to you. (sorry I have to go offline now)
<bhm> Hep! I'm looking for a guide to maintain a deb-ppa for a project on launchpad. Any good suggestions out there?
<dtchen> bhm: e.g., https://help.launchpad.net/Packaging/PPA
<bhm> dtchen: thanks
<bdmurray> slangasek: so bug 553745 still seems to be happening in bug 849414
<ubottu> Launchpad bug 553745 in plymouth (Ubuntu Maverick) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [High,Triaged] https://launchpad.net/bugs/553745
<ubottu> Launchpad bug 849414 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [Medium,Confirmed] https://launchpad.net/bugs/849414
<slangasek> bdmurray: right, looks like it...
<MouraPsy> Hello
<smoser> sbeattie, around
<sbeattie> smoser: yeah, what's up?
<smoser> bug 854927.
<ubottu> Launchpad bug 854927 in openssl (Ubuntu) "wget, curl can't verify certificates" [Undecided,New] https://launchpad.net/bugs/854927
<smoser> you are last-touched openssl .
<smoser> :-(
<sbeattie> smoser: happy happy joy joy. I'll look, thanks.
<hallyn> adam_g: actually i don't even need any lvm partitions to get what looks like a udev hang
<hallyn> it takes a few tries, but not more than say 5
 * hallyn starts instrumenting initramfs scripts
 * hallyn wonders if 'udevadm control --exit' is waiting for an already-exited udev to exit.  Nah, that's be too obvious
<adam_g> hallyn: are you just using a standard guied partition table?
<adam_g> *guided
<hallyn> adam_g: yup, /dev/vda1 is a primary partition, /dev/vda3 is logical partition (swap)
<hallyn> adam_g: it's a vm created by vm-new in vm-tools, fwiw
<hallyn> (or, maybe it isn't.  anyway no lvm)
<smoser> hallyn, i thin its just the expected situation where udevadm control --exit is losing events.
<adam_g> yeah. on exit on udevd.c: /* close sources of new events and discard buffered events */
<mdeslaur> smoser: quick question: do you have ca-certificates installed?
<sbeattie> smoser: I'm unable to reproduce the wget/curl failure's you're seeing.
<smoser> mdeslaur, i do
<sbeattie> meh, failures.
<smoser> really?
<mdeslaur> I can't reproduce either
<sbeattie> really
<smoser> i see them on both my local system and on a new ec2 instance and new canonicalStack instance
<hallyn> adam_g: and I gather udevadm settle is deemed a hack bc between that call and the --exit we can still get new events?
<smoser> sbeattie, mdeslaur so i can very trivially give you access to a system that shows issues
<sbeattie> smoser: proxy in the way, perhaps?
<smoser> very unlikely.
<smoser> kirkland can also reproduce
<smoser> and i dont *think* he routes his traffic through my basement.
<adam_g> hallyn: yeah, it looks like thats the case. udev needs to have some option to --exit that will flush its queue
<kirkland> sbeattie: i've verified it both on my home machine, and ec2
<smoser> adam_g, well, its really quite silly that it would have any path to exit that would *not* flush its queue
<smoser> why would you nicely ask a daemon to exit, and expect it to lose data
<smoser> you can get that with kill -9
<adam_g> smoser: i dont disagree
<smoser> sbeattie, i only picked openssl because it seemed fairly recently updated.
<sbeattie> smoser|kirkland: these are all oneiric? two different oneiric systems succeed locally
<smoser> i could have picked wrong package entirely.
<smoser> sbeattie, dist-upgraded oneiric as of last night ~ 2am i think locally.
<adam_g> this is an interested note from udev upstream: http://www.spinics.net/lists/hotplug/msg04749.html
<tyhicks> I can't reproduce the ssl bug, either
<mdeslaur> I just updated a i386 chroot, and can reproduce it
<tyhicks> mdeslaur: and the report is on i386
<tyhicks> I'm on amd64
<tyhicks> and can't reproduce it
<sbeattie> yeah, my systems are amd64
 * sbeattie hrms
<sbeattie> kirkland: are you on i386?
 * micahg doesn't see the issue
<mdeslaur> oh, d'uh, I didn't have ca-certificates installed
<sbeattie> mdeslaur: heh, that would be a problem
<micahg> maybe wget should suggest or recommend ca-certificates
<mdeslaur> ok, still have the problem
 * sbeattie wonders what's causing all the skipping duplicate certs message on install of ca-certificates.
<kirkland> sbeattie: amd64
<micahg> mdeslaur: I get the same error before the openssl upgrade w/out ca-certificates, with ca-certificated with 1.0.0d and 1.0.0e, no issue (i386)
<mdeslaur> I can reproduce in my amd64 chroot also
<sbeattie> weird, I see it in my i386 chroot.
<sbeattie> well, I see the failure with curl + launchpad, wget against google works fine in my chroot
<micahg>  ah, didn't try the second case
<micahg> I get no curl error either
<mdeslaur> this looks very wrong: lrwxrwxrwx 1 root root     19 Sep 20 14:38 415660c1.0 -> ca-certificates.crt
<mdeslaur> I think ca-certificates is borked...it's linking all the cert files to ca-certificates.crt
<hallyn> adam_g: looking at the code trying ot think how to structure a reliable --settle-and-exit
<sbeattie> mdeslaur: ah, yeah, where things work, it's not like that.
<hallyn> not entirely sure it's possible
<sbeattie> smoser|kirkland: are you seeing this on systems that were installed recently or were upgrades?
<mdeslaur> sbeattie: frack...installing ca-certificates with the old openssl works
<Laney> it's been debugged in #-release, guys :-)
<adam_g> hallyn: its been a while since i looked, but i was thinking it should be possible to duplicate 'udevadm control settle' in the daemon, between closing its netlink sockets and exitting
<mdeslaur> Laney: thanks
<hallyn> adam_g: what exactly is getting lost though?  inotify events?  or kernel uevents?  If the latter, are those async?  If so then yes we can just close the kernel uevent socket, process our queue, and exit.
<hallyn> But if not, then there may not be a good way to make the events pile up while we are exited
<hallyn> oh, what, init fwds them over inotify to udev?
<hallyn> finally, there it is :)  udev_monitor_new_from_netlink_fd(udev, "kernel", fd_netlink);
<hallyn> (or rather, the non-sd version of course)
<adam_g> hallyn: sorry, ive been otp
<hallyn> adam_g: np, i'm just blabbing
<hallyn> adam_g: starting to get a feel for the code.  but trying to figure out exactly waht is magic during the 'udev_exit = 1'
<hallyn> adam_g: in fact, the code looks like it thinks it's waiting for both events and workers lists to be 0 before really exiting,
<hallyn> it stops taking ctrl msgs (from udevadm), that's sensible.  stops taking inotify - that may be our prolbem.  (it still takes netlink msgs from kernel, but since it will wait for any newly spawned workers to finish, that should be fine)
<hallyn> maybe it'll do better if we keep accepting inotify events while we're waiting
<adam_g> hallyn: what triggers inotify events? new nodes in /dev?
<hallyn> that's been my assumption.  I've not dug deep enough to know the full list
 * hallyn feels woefully under-informed at this point
<hallyn> didn't we used to have a uevent_helper during initramfs?
<hallyn> (guess not)
<hallyn> adam_g: well the kernel object uevents are broadcast.  So if that is waht we're losing, then settle before exit won't help :)
<hallyn> so, let me try just allowing inotify events while we're exiting.  stab in the dark, unlikely to help
<slangasek> SpamapS: so I think we should talk about bug #848823
<ubottu> Launchpad bug 848823 in nfs-utils (Ubuntu) "nfs-kernel-server requires a real interface to be up" [High,New] https://launchpad.net/bugs/848823
<slangasek> SpamapS: since I'm about to volley it back over to ifupdown where it belongs :)
<SpamapS> slangasek: on a call, in a bit?
<slangasek> ok
<SpamapS> slangasek: ok, so, what the problem is? :)
<slangasek> SpamapS: hey, sent a follow-up comment to the bug, but in summary, it has nothing to do with what interfaces it's listening on, it's about not being able to resolve the hostnames listed in /etc/exports and therefore discarding the entries
<SpamapS> slangasek: *OH*
<SpamapS> slangasek: so then its not really a bug at all. The interface needs to be listed in /etc/network/interfaces. :)
<slangasek> SpamapS: why not avoid emitting static-network-up when only lo is up?  nfs-kernel-server won't be the only package with an init script that hits a problem like this
<SpamapS> slangasek: hrm. Well we'll slow down boot speed quite a bit waiting for DHCP
<slangasek> SpamapS: I thought you server guys all agreed robust > fast ;)
<SpamapS> slangasek: we do, but this particular  user is a desktop user.
<SpamapS> slangasek: and NetworkManager != robust IMO
<slangasek> hmm
<slangasek> oh blast, lightdm is start on ... runlevel
<SpamapS> yeah
<slangasek> right, we don't want to slow that down in the desktop case :/
<SpamapS> another option is to integrate with insserv a bit and only delay if something that has Require-Start: $network in it.
<slangasek> nah, I think we probably should just worry about moving nfs-kernel-server to upstart
<SpamapS> slangasek: what would we make the start on condition though? I think runlevel [2345] would still make more sense than 'net-device-up IFACE!=lo' ...
<SpamapS> and filesystem and all that jive
<slangasek> hmm
<SpamapS> because what you really want is all static network interfaces up. :-P
<slangasek> no, for nfs what you want is "the network up"
<slangasek> staticness notwithstanding :)
<SpamapS> static is a terrible term and I must apologize for its use.
<SpamapS> server-network-up maybe? ;)
<slangasek> maybe
<slangasek> except that, as we see here, that's not always conclusive
<SpamapS> anyway, I haven't found a sane way to express it generically without having a special "I'm a desktop" flag somewhere.
<slangasek> yeah
<slangasek> well, punting for now then
 * SpamapS is still glad we had to work through to the roadblock.. learning can be useful
<ahasenack> hi guys, can someone take a look and hopefully approve the following SRU updates that are sitting in the unapproved queue? smart for lucid, maverick and natty
<ahasenack> and landscape-client for maverick and natty
<ahasenack> I believe they are not in proposed yet, lacking such an approval
<SpamapS> ahasenack: I'll look at them when I get back from lunch.
<ahasenack> SpamapS: cool, thanks
<slangasek> bdmurray: could you analyze the apport data on bugs 849414 and 533745 (and duplicates) to see if there's a pattern in the hardware in use?  (Video hardware in particular)
<ubottu> Launchpad bug 849414 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events()" [Medium,Confirmed] https://launchpad.net/bugs/849414
<ubottu> Launchpad bug 533745 in sitecmd "link() - move $params to 3rd parameter" [Low,Fix released] https://launchpad.net/bugs/533745
<slangasek> bdmurray: I don't think we're going to get to the bottom of this bug without a dev reproducing this in a controlled environment - i.e., running plymouth under valgrind or the like
<slangasek> so step one is to be able to reproduce it at all...
<bdmurray> step 2 ? and step 3 is fix it!
<slangasek> step 2 is raiding the fridge for snacks
<tedg> Uhm, I'm getting signature errors of archive.ubuntu.com.
<tedg> Like GPG errors on the package list.
<tedg> Is anyone else having issues?
<slangasek> tedg: probably my fault; try again in 10-20 minutes
<tedg> slangasek, Okay.  Cool.  Was getting a little nervous there :-)
<slangasek> hand-running the publisher during milestone prep has acquired a new and exciting failure mode
<Daviey> slangasek: Do you know if jhunt is working on bug 818177?
<ubottu> Launchpad bug 818177 in udev (Ubuntu) "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
<slangasek> Daviey: he's on vacation this week, so I would think "not right now"
<Daviey> slangasek: vacation! /me looks up what this means.
<Daviey> slangasek: fwiw, we seem to be seeing that issue on iscsi aswell now, not just LVM.
<hallyn> and on virtio with no iscsi or lvm
<Daviey> anything with slower io, by the seems of it.
<hallyn> and faster io, just less frequently
<hallyn> (at least, i'm assuming it's the same thing as what i see in kvm vm's every 5-10 boots)
<Daviey> hallyn: maybe even medium speed io at freq' between that of fast and slow?
<hallyn> uh
<hallyn> heck maybe that's why my euca instances occasionally don't come up
<hallyn> and why my milk didn't taste right this morning
<slangasek> no, the milk thing sounds like a dupe of a multiarch bug
<Daviey> Seems reasonable to attribute that to udev.
<Daviey> And this has all happend because jhunt went on vacation.  Damn Brits.
<bdmurray> slangasek: Does this help? http://pastebin.ubuntu.com/694067/
<hallyn> socialists
 * hallyn out - i'm going to do some debugging later tonight.  if you (anyone) finds anything more out, can you comment it in that bug so I don't duplicate effort?
<slangasek> bdmurray: hmm... less than it would if they all matched, but thanks :) good to know what we're looking at
<bdmurray> slangasek: that's from 849414 and its duplicates
<slangasek> bdmurray: ack
<slangasek> bdmurray: seems there are 5 video cards reported twice each - are these two dupes each from the same submitter, or is it actually more common on some hardware than on others?
<Daviey> bdmurray: does your bug bot check for Short read in buffer_copy" error with "dpkg"
<Daviey> ?
<bdmurray> Daviey: yes
<Daviey> bdmurray: how often does it run?
<bdmurray> slangasek: only one duplicate is from the same reporter
<slangasek> bdmurray: interesting, thanks
<bdmurray> Daviey: every 4 hours
<Daviey> bdmurray: thanks
<bdmurray> Daviey: did it miss one?
<Daviey> bdmurray: hmm, let me check the timestamps
<Daviey> bdmurray: ah, it was <2 hours.. so no.. i just beat the bot.
<SpamapS> slangasek: hah, async fail.. I responded to bug 848823 reversing my position before seeing the email that you wrote reversing yours. :)
<ubottu> Launchpad bug 848823 in nfs-utils (Ubuntu) "nfs-kernel-server requires a real interface to be up" [High,Triaged] https://launchpad.net/bugs/848823
<SpamapS> worst.. chess players.. ever
 * slangasek grins
<SpamapS> slangasek: I think its doable if we make static-network-up aware of NetworkManager's connections that are going to be brought up at boot time.
<slangasek> SpamapS: well, if there's a good way to query that, yes
<SpamapS> slangasek: right, thats the bit I'm not sure of. Either way, I think its worthwhile as a Medium bug in upstart (upstart owns the static-network-up event)
<Daviey> Turn the importance up to 11.
<SpamapS> /o/
<slangasek> SpamapS: how does upstart own it?  /etc/network/if-up.d/upstart is in ifupdown
<SpamapS> slangasek: indeed it is.. doh. ok.. well then back to ifupdown the bug goes.
<slangasek> alrighty... :)
<chrisccoulson> bryceh, ah, this is going to be fun. that drm delay only happens at startup, so i can't just run another xserver manually with strace :/
<bryceh> chrisccoulson, erf
#ubuntu-devel 2011-09-21
<mdeslaur> This is weird: bug 855171
<ubottu> Launchpad bug 855171 in ca-certificates (Ubuntu) "libnss3.so went missing after upgrade" [Undecided,New] https://launchpad.net/bugs/855171
<mdeslaur> I just hit that bug also
<RAOF> As did I.p
<mdeslaur> ROAF: do you have your dpkg.log to figure out what common packages we both upgraded?
<Nafai> Hey RAOF.  Feeling the last few week's crunch?
<RAOF> mdeslaur: Yup.
<RAOF> Nafai: I currently have three different systems up.  It's busy :)
<Nafai> :)
<htorque> mdeslaur: the package upgrade causing it is ca-certificates. ;-)
<mdeslaur> htorque: how can you tell?
<mdeslaur> bbl
<htorque> touch /usr/lib/x86_64-linux-gnu/libnss3.so ; sudo apt-get install --reinstall ca-certificates â that fails and libnss3.so is gone
<htorque> mdeslaur: my report is actually a dupe of the others, i just didn't see the java stacktrace
<Lirodon> RAOF, I'm going back into inkscape on those GRUB 2 mockups: you said you wanted Recovery stuff in its own menu?
<cyphermox> htorque: can't reproduce with that command
<htorque> :-/
<RAOF> Lirodon: Yup.  And less technical detail in general (ie: I don't think we need the kernel version number on the main screen).
<RAOF> htorque: Reproduced here.
<Lirodon> RAOF, hmm, but maybe "Boot with previous Linux kernel" could be a good option with a good "If a recent update to the Linux kernel powering Ubuntu has caused issues, you may boot with a backup copy of a previous one"
<RAOF> Lirodon: Absolutely.  Under the recovery options ?
<Lirodon> Yeah
<RAOF> Hm.  do_cleanup () ? rm -r $nssjdk/libnss3.so ?
<Lirodon> But hmm, do you think that having an explanation at all of GRUB's parameter/command line is needed?
<Lirodon> I had proposed patching the shortcuts to require a CTRL in them
<slangasek> RAOF: yeah, that's the culprit :P
<jcastro> mdeslaur: that nss missing bug just hit me too
<RAOF> slangasek: Is it?  I looks suspicious, but I'm not sure yet that it's actually what's killing it.
* slangasek changed the topic of #ubuntu-devel to: ca-certificates eats system libraries, DO NOT UPDATE | Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for h
<slangasek> RAOF: it definitely is
* leguin.freenode.net changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jcastro> ah, looks like I joined at the right time. :)
<RAOF> slangasek: You're on it, then?
<broder> does anybody have access to the @ubuntustatus account?
<jcastro> I believe I do, on it
<slangasek> RAOF: ish
<slangasek> RAOF: would help if someone else could work on fixing the code while I'm sounding the alarm
<RAOF> slangasek: Ok.  I'll see what I can do to hunt it down.
<Lirodon> RAOF, now, I wonder, while there were objections to moving ALL the recovery tools into the Recovery menu, what SHOULd be in there?
<doko_> slangasek, there was a suggestion to drop the libdir setting in nss.cfg. openjdk does have the multiarch path on the default libpath.
<doko_> the other safety check would be to check both arguments for -n before comparing
<doko_> both in the hook and the postinst
<cyphermox> RAOF: found the issue, I think
<slangasek> doko_: that last sounds sensible to me
<cyphermox> which dpkg-query --version fails every time
<RAOF> Well, and it's looking for libnss3.so which doesn't exist, rather than libnss3.so.1d, which does.
* slangasek changed the topic of #ubuntu-devel to: ca-certificates eats system libraries, DO NOT UPDATE (bug #855171) | Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubu
<slangasek> good enough for now
<slangasek> cyphermox, RAOF: which> that's a bug but not the bug
<cyphermox> ok
<slangasek> cyphermox: this is being triggered in the hook, not the postinst; the hook doesn't call which
<cyphermox> ok
<slangasek> libnss3.so which doesn't exist> er, you mean doesn't exist /any more/, I guess?
<RAOF> Right.  The hook looks for libnss3.so in libnss3-1d, doesn't find it, and hence merrily symlinks the real libnss3.
<Lirodon> okay, what would be the best name for a "run level 3"-type mode? "Boot without graphical desktop"?
<doko_> cyphermox, "which dpkg-query --version fails every time", what do you mean?
<slangasek> RAOF: ah
<RAOF> slangasek: No, it's looking for libnss3.so in libnss3-1d, and libnss3-1d contains libnss3.so.1d
<slangasek> doko_: the postinst calls 'which dpkg-query --version'; "which" takes a single argument
<RAOF> Which is why it compares an empty string with /usr/lib/x86_64-linux-gnu, merrily symlinks libnss3 to itself, then deletes it.
<RAOF> Actuall, that doesn't make sense.
<doko_> slangasek, I don't get it, sorry. exits with 0 with or without argument
<slangasek> $ which dpkg-query --version
<slangasek> /usr/bin/dpkg-query
<slangasek> $ echo $?
<slangasek> 1
<slangasek> doko_: ^^
<RAOF> Oh, no.  That does make perfect sense.  It's deleting libnss3.so from libnss3, rather than libnss3.so.1d from libnss3
<slangasek> but I don't think that's the issue
<cyphermox> it's not
<RAOF> So, what I think the issue is: nsspkg=$(dpkg-query -L libnss3-1d | sed -n 's,\(.*\)/libnss3\.so$,\1,p') is always empty, so the query against nss.cfg is always false, so ?ln -sf $nsspkg/libnss3.so $nssjdk/? always happens (which symlinks to itself), then do_cleanup kills $nssjdk/libnss3.so, which just happens to be /usr/lib/x86_64-linux-gnu/libnss3.so
<micahg> right, that's a transitional package now
<micahg> that should be libnss3
<RAOF> Or it should be looking for libnss3\.so\.1d$
<RAOF> One or the other.
<slangasek> doko_: ^^ that analysis seems correct to me; so we should update the dpkg-query for the correct package name, and we should add a guard in do_cleanup() to make sure we don't remove anything if either nsspkg or nssjdk is empty?
<Lirodon> RAOF, "Boot using previous Linux kernel", "If an update to the Linux kernel has caused hardware issues or other problems, you may boot using a backup of the previous kernel."
<RAOF> Lirodon: Probably better to do that in #ayatana.
<Lirodon> hmm
<doko_> slangasek, RAOF http://paste.ubuntu.com/694144/
<doko_> ahh, package name ...
<slangasek> doko_: yep, nearly identical to what I have here, except for fixing the pkg name check in the hook
<slangasek> doko_: bug #855171 for your changelog, btw
<ubottu> Launchpad bug 855171 in nss (Ubuntu) "libnss3.so went missing after upgrade" [Undecided,Confirmed] https://launchpad.net/bugs/855171
<slangasek> doko_: http://paste.ubuntu.com/694145/ is mine, if you want to compare / steal
<RAOF> doko_: ?if dpkg-query >/dev/null; then? is going to consistently fail, isn't it?  dpkg-query when called with no arguments returns an error.
<doko_> gahh, the postinst has it right
<doko_> RAOF, it's which dpkg-query
<slangasek> doko_: you changed two calls; one had 'which' in front (in the postinst), the other did not (in the hook)
<slangasek> RAOF: good catch
<RAOF> What slangasek said :)
<doko_> slangasek, go ahead, use your version
<doko_> I think I do more harm now ...
<slangasek> doko_: ok, uploading - thanks for your help
<slangasek> doko_: I think you can sleep easily now :)
<doko_> slangasek, will do, good night :-)
<doko_> infinity, ready for review
<Viper550> RAOF, Even though this may be better in a design channel, I still think that anything involving the bootloader/startup can be relevant in here
<RAOF> But what you're after is design feedback, right?
<Viper550> design, and functionality, and feasibilitiy
<RAOF> Well, it looks perfectly feasible to me.
<jcastro> slangasek: ok so I get the recovery instructions right, will a normal upgrade after this upload fix it or is there something else the user needs to do?
<Viper550> speaking of recovery ... I cannot believe there aren't GUI-based disk cloning programs on Linux
<slangasek> jcastro: if they've been hit by the fix, they should manually reinstall the libnss3 package
<slangasek> er, hit by the bug
<slangasek> we can look at doing a no-change rebuild of libnss3, but that will take *much* longer
<jcastro> ok so just dpkg -i it from the local archive?
<slangasek> yes
<slangasek> 'apt-get install --reinstall libnss3' *SHOULD* work, but is failing consistently for me and others
<jcastro> failed for me too
<RAOF> ?apt-get install --reinstall libnss3:i386 libnss3? worked for me.
<slangasek> RAOF: oh, clever
<RAOF> (And on i386 just apt-get install --reinstall libnss3 worked for me)
<RAOF> When apt does something weird, guess that it's multiarch fallout and kick it in the foreign-arch ?
<slangasek> 'apt-get install --reinstall libnss3:i386 libnss3' should also work on i386, fwiw, so it's probably safe to give everyone that command
<slangasek> RAOF: heh :)
<jcastro> got it, I'll put the word out on that
<slangasek> RAOF: btw, what's wrong with your quote characters :)
<jcastro> ok so that apt-get install command hits the network, which is impossible for people who are broken
<jcastro> so reinstalling the deb from /var/cache is probably the best way to go for those people?
 * RAOF 's network wasn't broken.
<jcastro> nor mine, but apparently it broke other people
<RAOF> But, yeah.  If the network is broken hope that the deb's in /var/cache.
<jcastro> do you have the exact version of the deb handy?
<slangasek> or boot from the liveCD you keep lying around when you're running betas
<slangasek> jcastro: 3.12.9+ckbi-1.82-0ubuntu5
 * ajmitch wonders how it could break the network enough for apt-get to not work
<RAOF> ajmitch: Because all sorts of things link to libnss3
<RAOF> network manager components, ecryptfs-*, ?
<ajmitch> I didn't think that apt would have been one of those
<ajmitch> ah right
<RAOF> I noticed this because logging in immediately dropped me back to unity-greeter.
 * ajmitch is too used to having a working network without n-m :)
<RAOF> Because it was no longer possible to mount my ecryptfs home.
<sgnb`> debian bug #620031 is present in natty... is it possible to fix it? the fix is trivial and non intrusive...
<sgnb> actually, it has been reported in Ubuntu as well... #696706
<doko> jtaylor, do you have an opinion/suggestion about dlr-languages?
<jamespage> doko: branch proposed for FTBFS for shrinksafe - which should fix the dojo build failure as well once published
<doko> jamespage, \o/
<jamespage> bug 831366
<ubottu> Launchpad bug 831366 in shrinksafe (Ubuntu Oneiric) "shrinksafe version 1.6.1-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831366
<jamespage> got to know rhino AST quite well :-)
<ricotz> doko, hello, do you know what happened to x264 v116?
<ricotz> the binaries arent available in the repos anymore
<doko> ricotz, what should I know?
<doko> which source package?
<ricotz> doko, i was hoping so since you commented on the mir of x264
<ricotz> https://launchpad.net/ubuntu/+source/x264/2:0.116.2042+git178455c-1ubuntu1
<ricotz> http://archive.ubuntu.com/ubuntu/pool/universe/x/x264/
<doko> ricotz, it's in the archive. what are you looking for?
<ricotz> doko, thank, i hope you can look at it
<ricotz> it isnt available for download
<ricotz> ok, now it is, again
<ricotz> looks like a glitch of some kind, but it really wasnt there a moment ago, sorry
<ricotz> E: Failed to fetch http://archive.ubuntu.com/ubuntu/pool/universe/x/x264/libx264-116_0.116.2042+git178455c-1ubuntu1_amd64.deb: 403  Forbidden [IP: 91.189.88.45 80]
<ricotz> i thought there went something wrong with the main transition
<ricotz> ok now it is gone again :\
<ricotz> doko, please look at http://archive.ubuntu.com/ubuntu/pool/universe/x/x264/
<lool> Hmm a debmirror on ubuntu fails on natty-updates with:
<lool> [GNUPG:] BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<lool> many other pockets have a good signature though
<lool> I've retried this and it failed again, so it doesn't seem to be temporary skew
<lool> I can wait one hour for the next run, but it seems odd that we'd be publishing invalid sigs
<lool> if I download natty-updates' Release and Release.gpg it gives a good signature, hmmm
<lool> apparently this was really a temporary skew, sorry for the noise; it just lasted surprisingly long as I had the time to fetch many suites 3 times with some inconsistency each time
<soren> Uh oh.
<tseliot> pitti: any ideas on bug #855396 ? I don't know what's going on. I have attached a patch which makes things a little better but the driver still doesn't show up
<ubottu> Launchpad bug 855396 in jockey (Ubuntu) "Jockey doesn't provide fglrx-updates" [High,Triaged] https://launchpad.net/bugs/855396
<pitti> tseliot: hey
<pitti> tseliot: looking
<tseliot> pitti: thanks
<pitti> tseliot: I also just got another interesting one in bug     855175
<ubottu> Launchpad bug 855175 in jockey (Ubuntu) "jockey fglrx driver error" [Undecided,New] https://launchpad.net/bugs/855175
<pitti> tseliot: seems it's picking up fglrx:i386 and showing that as a separate handler
<tseliot> pitti: I think we can create a subclass to catch that and make it fail so that it doesn't show up
<tseliot> pitti: that = fglrx:i386
<pitti> tseliot: I'd just fix it in OSLib to filter out the ones with non-matching arches
<tseliot> pitti: I don't see fglrx:amd64 (my current arch) but only fglrx and fglrx:i386 so maybe we can filter out anything with ":" in their name?
<pitti> tseliot: right
<pitti> I just need to ponder how to reproduce this, but shouldn't be too hard with a slight hack
<pitti> tseliot: hm, might that be the same issue?
<pitti> that> your bug
<tseliot> pitti: in my bug though, we can't get fglrx-updates but only fglrx and fglrx:i386
<pitti> tseliot: so your patch supplies an xorg_driver name
<pitti> tseliot: does that actually work, i. e. does it help to set a driver "fglrx_updates" in xorg.conf?
<pitti> tseliot: I thought we aren't supposed to actually set that any more, as otherwise we break the automatic fallback to ati
<tseliot> pitti: no, that's just for the kernel module
<tseliot> pitti: as the module alias would be fglrx_updates
<pitti> tseliot: oh, of course, I misread; that looks correct, nvidia.py does that as well
<pitti> tseliot: can you please commit that?
<tseliot> pitti: sure
<pitti> tseliot: I'll have a deeper look at this in a bit then
<tseliot> pitti: thanks
<s1aden> cjwatson: (last person to touch console-setup, noting console-terminus).  Do you know what the default font loaded for the VGA/framebuffer is.  Is it terminus.  I can't work out where in the initscripts the font loading is actually taking place.  (kirkland's colour setting is in vtrgb in console-setup)
<tjaalton> pitti: i filed a bug against jockey about removing the choice of installing "experimental nouveau 3d support", which is now installed by default anyway. should probably be targeted for oneiric release
<pitti> tjaalton: ah, thanks; which bug #?
<tjaalton> bug 839533
<ubottu> Launchpad bug 839533 in jockey (Ubuntu) "Please remove the handler for nouveau 3D" [Undecided,Confirmed] https://launchpad.net/bugs/839533
<pitti> tjaalton: thanks
<cjwatson> s1aden: locale-dependent
<sladen> locale-dependent
<cjwatson> sladen: /var/lib/dpkg/info/console-setup.config, search for CODESET and FONTFACE
<tjaalton> pitti: thank you :)
<pitti> tseliot: I think I'll compare the apt cache's package object .architecture() against c['xserver-xorg-core'].installed.architecture; that sounds most correct?
<sladen> cjwatson: oh, right.  So this is first-time install dependent/
<pitti> tseliot: in the crazy case that someone actually installs the :i386 xorg-server on an amd64 machine :)
<pitti> tseliot: ah no, we also have non-X drivers; I'll ask dpkg about the native arch instead
<tseliot> pitti: I haven't looked into the apt code after the work on multi-arch but I guess that would be correct
<tseliot> pitti: BTW I've just pushed my patch
<cjwatson> sladen: yes
<cjwatson> or dpkg-reconfigure console-setup
<sladen> cjwatson: got everything I needed.  thank you!
<pitti> tseliot: seems you pushed an empty changelog?
<pitti> tseliot: want me to add it for you?
<tseliot> pitti: yes, sorry, I'm used to write the changelog only before the release
<tseliot> *writing
<tseliot> pitti: but I also pushed the actual patch
<pitti> tseliot: yup, I saw, thanks! changelog committed as well
<pitti> tseliot: I usually write them right away and then use debcommit to construct an appropriate bzr commit changelog
<tseliot> pitti: oh, I see. In git I simply push commits and then use git-dch to fill the changelog
<tseliot> I'll keep in mind the debcommit command
<pitti> tseliot: that's fine
<pitti> tseliot: hah, your's is an easy one: fglrx-updates does not have any Modaliases: :)
<tseliot> pitti: oh, it's definitely easy to fix then. I wonder how it happened. BTW your bug seems to be fixed here
<pitti> tseliot: I updated the bug and added an fglrx-updates task
<tseliot> pitti: thanks
<tseliot> pitti: the code in fglrx-updates looks fine though. I have both XB-Modaliases: ${modaliases} in debian/control and the relevant code in debian/rules. I wonder why I didn't get any modaliases in the package
<pitti> tseliot: it seems to work fine for nvidia-*-updates, anyway
<pitti> tseliot: I suspect it's identical to the code in fglrx?
<pitti> tseliot, tjaalton: jockey fixes uploaded, will go in right after b2
<tseliot> pitti: well, the code in fglrx and fglrx-updates is the same. I can check nvidia-*-updates but it should be the same
<tjaalton> pitti: nice, thanks
<Sweetshark> tyhicks: could you take over nannying bug 745836?
<ubottu> Launchpad bug 745836 in ecryptfs-utils (Ubuntu) "soffice.bin crashed with SIGSEGV in cppu::throwException()" [High,Confirmed] https://launchpad.net/bugs/745836
<Sweetshark> tyhicks: that would be great.
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<Laney> ricotz: did you get any answerS?
<Laney> it seems to affect more packages than just that one
<elleuca_> seb128, https://bugs.launchpad.net/ubuntu/+source/gnome-utils/+bug/855460
<ubottu> Ubuntu bug 855460 in gnome-utils (Ubuntu) "Fonts Viewer and thumbnailers not installed" [Undecided,New]
<seb128> elleuca_, yes?
<elleuca_> seb128, GNOME font viewer and thumbnailer are no longer installed by oneiric, package build issue
<tkamppeter> pitti, it is about bug 855445 and bug 855026. It is a CUPS crash which happened to me yesterday and today, when creating a print queue. I have submitted the automatic reports hoping to get a stack trace for an upstream bug report. Unfortunately, Apport refuses to retrace as it seems to not have the correct dbgsym packages on the server (and my system was always up-to-date). Can this be a bug in Apport?
<ubottu> Launchpad bug 855445 in cups (Ubuntu) "cupsd crashed with SIGSEGV in _cups_strcasecmp()" [Undecided,Invalid] https://launchpad.net/bugs/855445
<ubottu> Launchpad bug 855445 in cups (Ubuntu) "duplicate for #855026 cupsd crashed with SIGSEGV in _cups_strcasecmp()" [Undecided,Invalid] https://launchpad.net/bugs/855445
<pitti> tkamppeter: oh, I think that's fixed with the update I uploaded this moring
<pitti> ah, ignore me
<pitti> it's  acrash, not _cups_strcasecmp() not existing, sorry
<seb128> elleuca_, see bug #839407
<ubottu> Launchpad bug 839407 in gnome-utils (Ubuntu) "gnome-font-viewer missing in oneiric" [Undecided,Confirmed] https://launchpad.net/bugs/839407
<pitti> tkamppeter: yeah, sorry about that; seems our debug symbols are very far behind, so the retracer can't get an useful trace out of it
<tkamppeter> pitti, yes, it is a crash. Has nothing to do with the Natty->Oneiric update. My box is a daily-grown Oneiric.
<Sweetshark> pitti: does the retracer retry later?
<pitti> Sweetshark: no; why should it work better later on?
<pitti> some ddebs seem to be missing
<Sweetshark> pitti: ah, ok. I misunderstood that.
<elleuca_> seb128, ok, sorry for duplicate, it seems I performed a bad search before opening mine
<seb128> elleuca_, no worry ;-)
<pitti> seems to affect a lot of crashes; I'll try whether I can fish out some lost ddebs
<tkamppeter> pitti, that is bad for the development, as one cannot make use of Apport's retracer during the development period. pitti, is there a chance that I can retrace these bugs later, and how do I trigger a new retrace?
<pitti> tkamppeter: you need to reuplaod the crash, I'm afraid
<pitti> tkamppeter: but right now it won't make too much sense, it won't be any better
<tkamppeter> pitti, you need the file in /var/crash? How long do I have to wait?
<pitti> tkamppeter: I'm re-running ddeb-retriever to fetch all ddebs from teh last 7 days; that might help a bit; I'll ping you when it's done
<ricotz> Laney, hi, no, i didnt get a real answer -- good that you can confirm this problem
<ricotz> they are just disappear from time to time
<Laney> jpds is fixing it
<ricotz> ok :)
<barry> pitti: ping
<pitti> hey barry
<barry> pitti: hi.  i wonder if you have any ideas about a weird problem i'm having with gtimelog 0.6.1.  i've added the ppa you mentioned, and built a pkg from trunk's 0.6.1, but something very strange is happening
<barry> pitti: when i run 'gtimelog' say from a shell, none of the key presses get sent to the app.  e.g. ctrl-q doesn't work, but neither does alt-1 or alt-2, etc.  when i run it from lp:gtimelog via ./gtimelog, everything works fine.
<pitti> barry: right, compiz/unity currently has a bug with eating keypresses
<pitti> F10 and Alt+Letter also don't work anywhre
<pitti> barry: you can work around it with UBUNTU_MENUPROXY= gtimelog
<barry> pitti: oh wow, trying!
<pitti> that'll use the per-app menu instead of the global menu bar
<barry> pitti: bingo.
<barry> pitti: but why does it work when running from source but not when running from an installed pkg?
<pitti> barry: hah!
<pitti> barry: it's because trunk prefers pygtk
<pitti> barry: we have a "force-gi" patch which makes it use pygi
<pitti> barry: if you apply it to trunk (the "raise ImportError"), it's the very same
<barry> pitti: wait though, that patch was installed upstream, so it shoudl be the same (remember, i'm running a pkg built from trunk and both are 0.6.1)
<pitti> barry: no, it wasn't; upstream said they prefer using pygtk
<barry> oh wait
<barry> right, it was the other gi patch that was added upstream
<barry> pitti: well, i think by default i am now the upstream maintainer :)  should i just go ahead and apply force-gi?
<pitti> barry: it's not a nice upstreamable patch, as it effectively just totally disables pygi
<pitti> barry: for upstream it should rather swapa around the try/except ImportError:
<pitti> barry: i. e. try to import the GI bits, and if that fails, fall back to pygtk
<pitti> barry: force-gi is just a minimally intrusive hack which is easy to maintain in our packages
<pitti> barry: at some point we should just drop the pygtk bits, though, which will make the code a whole lot easier
<barry> pitti: that makes sense.  thanks for the explanation.  let me look at doing exactly that.  do you happen to have a bug # handy for the compiz/unity keypress gluttony?
<pitti> didrocks: ^ do you happen to know?
 * didrocks backlogs
<didrocks> yep, one sec
<didrocks> the is bug #849732 for Alt + key
<ubottu> Launchpad bug 849732 in unity-2d "Alt + <application menubar shorcut> doesn't work" [Critical,Triaged] https://launchpad.net/bugs/849732
<didrocks> F10 should work now though since last release
<barry> didrocks: thanks. note that if this is the bug affecting gtimelog, it's not just alt that gets eaten, but ctrl too
<barry> didrocks: i'll add a comment to the bug
<didrocks> Ctrl + w/q, those weren't reported, I think it's the same than the alt one, adding some news
<didrocks> barry: retitled
<barry> didrocks: ack
<kelemengabor> tedg: hi, do you have a minute to review the proposed branch to bug #853130?
<ubottu> Launchpad bug 853130 in Ubuntu Translations "Untranslated string in indicator-datetime" [Medium,Triaged] https://launchpad.net/bugs/853130
<tedg> kelemengabor, Hmm, it's merged, not sure why LP didn't pick that up..  http://bazaar.launchpad.net/~indicator-applet-developers/indicator-datetime/trunk/revision/132
<hrw> someone know which package I need to isntall for "from gi.repository import AppIndicator3 as AppIndicator"?
<seb128> hrw, gir1.2-appindicator3-0.1
<kelemengabor> tedg: no, it isn't, this is the same problem in another file
<kelemengabor> and another bug too
<tedg> kelemengabor, Ah, okay.  Sorry.
<hrw> thx
<tedg> kelemengabor, Done
<kelemengabor> thanks!
<kelemengabor> mvo: ping, got a few minutes to review some proposed branches in bug #853231?
<ubottu> Launchpad bug 853231 in Ubuntu Translations "Make the software-properties .policy file dynamically translatable" [Medium,Triaged] https://launchpad.net/bugs/853231
<pitti> barry: "we'll actually have a working app"> oh, is my 0.6.0 upload broken?
<pitti> barry: but with 0.6.1 we should be down to just the force-gi patch, so that's nice :)
<barry> pitti: no, i'm sorry, my comment was misleading.  i merged your gi-fixes patch to upstream 0.6.1
<pitti> ah, that'd be a working upstream release indeed
<barry> pitti: right!  i'm going to rework the gi-by-default patch for upstream 0.7 too (it'll be overridable from an envar)
<pitti> barry: simply swapping around the imports seems easiest, though? i. e. first try GI, then try static?
<barry> pitti: yep, with just a tiny bit of goo to read an envar first.  or do you think that's not worth it?  (i.e. upstream should always default to gi).  would someone ever want pygtk if gi were available?
<pitti> barry: I don't know; pygtk and gtk2 are dead in my view of the world, but some other people might still use it; but _if_ they have gtk 3 and GI, I can't think of why they wouldn't use it
<barry> pitti: fair enough.  you know i have the same general rule (e.g. python3, though py2 is still twitching in my world.  :).  i'll make it unconditional and let bug reports drive any further change.  thanks!
<pitti> barry: the only thing that actually works better with pygtk2 is the dynamic adaption of the panel tray icon (it looks bad with Radiance)
<pitti> with indicators that hack doesn't seem to work any more
<pitti> (pygtk mode doesn't use indicators)
<barry> pitti: and this bug ;) https://bugs.launchpad.net/ubuntu/+source/computer-janitor/+bug/806574
<ubottu> Ubuntu bug 806574 in computer-janitor (Ubuntu Oneiric) "computer-janitor-gtk crashed with AttributeError in reorder(): 'ListStore' object has no attribute 'reorder'" [Medium,Triaged]
<pitti> barry: does that affect gtimelog, too?
<pitti> barry: ah, not introspectable as the array has an unknown size
<pitti> barry: hm, I thought I've seen that before
<pitti> right, I even followed up there :)
<barry> pitti: :)
<barry> pitti: but tbh, i don't think anyone actually *likes* cj so i'm not particularly motivated to fix it ;)
<pitti> I'm actually using it occasionally, as it's quite good at picking up some cruft
<pitti> but yeah, it's become a step child
<barry> pitti: i kind of like it too, but i think some people have had catastrophes with it
<pitti> barry: perhaps the reordering could just be disabled
<barry> pitti: that's probably a fine solution, since i really don't know how useful the feature is
<jml> stgraber: hello. For ARB submitted apps, what's the process like for submitting a new version of an app?
<stgraber> jml: same process as for getting it in initially though you can skip the screenshots and logo step if they're the same. Code review is usually easier as we usually just check the delta.
<jml> stgraber: thanks. I guess https://wiki.ubuntu.com/PostReleaseApps/Process is the relevant doc?
<stgraber> jml: yep
<jml> stgraber: thanks!
 * mneptok reboots and prays libnss3 is back where it should be
<pitti> mneptok: hang on
<pitti> mneptok: it won't come back automatically
<pitti> mneptok: we just fixed the bug that kills it
<pitti> mneptok: you have to reinstall libnss3 if it got zapped
<mneptok> pitti: i brought up eth0 by hand, used --reinstall, and then update && upgrade && dist-upgrade
<mneptok> pitti: my nm-applet icon is back, Chrome is launching (depends on libnss3-0d) and all seems well.
<mneptok> i guess i should have said "prays libnss3 is back where it should be, *AFTER* a manual --reinstall"  :)
<doko> #include <Python.h>
<doko> namespace sf {
<doko> #include <cstddef>
<doko> }
<doko> #include <stddef.h>
<doko> typedef ptrdiff_t GLintptr;
<doko> g++ -c -I/usr/include/python2.7 foo.cc
<doko> foo.cc:9:9: error: 'ptrdiff_t' does not name a type
<mneptok> doko: can i blame you for the broken ca-certificates-java issue? mind you, i don;t care if you are actually responsible. i just want a blame target. O:)
<slangasek> mneptok: you're meant to blame me, it's all multiarch's fault
<doko> mneptok, blame as you can ...
<doko> I just did upload it, didn't approve it ;-P
<mneptok> slangasek: drat. if i blame you, The Mighty Missus Slangasek will beat me to a pulp. less because she's burly and mostly because i'm a wuss.
<mneptok> doko: in better news, with the certs update Pidgin no longer warns about AOL servers being untrusted when trying to enable an AIM account. that's quite nice.
<hyperair> ScottK: could you ack my upload of banshee to oneiric please? no FFe required. just a new upstream bugfix release from an unstable version to a stable.
<tkamppeter> pitti, is are the dbgsyms of Apport up-to-date now?
<dpm> mvo, I can't remember, does app-install-data-ubuntu contain translation for the descriptions of all desktop files in the Ubuntu archive, regardless of whether the packages containing them are in main, universe, etc?
<mvo> dpm: yeah, I'm not sure though if those are striped during build
<kirkland> mterry: ping
<kirkland> mterry: i have an ecryptfs-verify script here
<dpm> mvo, let me ask pitti: Martin, do you happen to know if the descriptions from non-main/restricted package are striped from app-install-data-ubuntu at build time?
<kirkland> mterry: i was wondering if you might help with a bit of testing
<mterry> kirkland, oooh, ok
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: ca-certificates eats system libraries, DO NOT UPDATE (bug #855171) | Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubu
<kirkland> mterry: give me a minute, i'll get you a branch
<infinity> Aaaaand, topic overflow.
<kirkland> mterry: bzr branch lp:ecryptfs, r566.  see: src/utils/ecryptfs-verify
<kirkland> mterry: you can run it in place
<mterry> kirkland, k
<kirkland> mterry: ie, no need to build/install
<kirkland> mterry: i've tested it a bit here, works for my test cases
<jtaylor> mterry: can you reproduce bug 745119?
<ubottu> Launchpad bug 745119 in meld (Ubuntu) "meld crashed with IndexError in get_chunk(): list index out of range" [Undecided,Confirmed] https://launchpad.net/bugs/745119
<mterry> jtaylor, I think so.  I believe it has to do with activating View->Refresh
<jtaylor> k, gotta go now, if you ahve more information please post it in the bug, I'll have a look when I'm back. thx
<jtaylor> also if oneiric is still affected, natty has a very buggy -dev version
<mterry> kirkland, it seems to report 0 (ecryptfs enabled) on a user that isn't using it
<kirkland> mterry: doh
<kirkland> mterry: can you pastebin the output?
<mterry> kirkland, though I'm running as a user that is.  (src/utils/ecryptfs-verify -u tester) where tester is the username
<mterry> kirkland, "INFO: Configuration valid" is all I get
<kirkland> mterry: hrm, okay, let me reproduce
<kirkland> mterry: can you pastebin the sh -x ?
<mterry> kirkland, ah, I didn't give it any tests to run.  Sorry, should have read --help first
<kirkland> mterry: oh, good call though -- i should error out in that case
<mterry> kirkland, maybe add a quiet mode too, for ease of calling without redirecting output to /dev/null?
<mterry> kirkland, though that's not hard to do
<kirkland> mterry: i thought about that, and I could ... however, I figured >/dev/null was pretty simple?
<mterry> kirkland, yeah, that's fine
<kirkland> mterry: it's not hard for me to do, though
<mterry> kirkland, eh, don't listen to me trying to feature creep this simple utility
<kirkland> mterry: :-)
<mterry> kirkland, ok, works for me
<kirkland> mterry: stdout and stderr are seperate too
<kirkland> mterry: so you can filter one or the other or both
<mterry> cool
<kirkland> mterry: pull r567, and see that the no-checks-given error gets you
<mterry> kirkland, yup
<kirkland> mterry: sweet, i'll release and upload as soon as the archive thaws
<mterry> kirkland, thank you!
<kirkland> mterry: np, thanks for the reminder
<ahasenack> hi guys, can someone please take a look and hopefully approve the landscape-client packages which are in the upload queue for maverick and natty?
<ahasenack> https://launchpad.net/ubuntu/maverick/+queue?queue_state=1 and https://launchpad.net/ubuntu/maverick/+queue?queue_state=1
<ScottK> hyperair: It doesn't need a pre-upload approval, but we're frozen for beta 2, so it won't be looked at until after.
<hyperair> ScottK: alright. it's already uploaded, and waiting in the queue.
<slangasek> apw: bug #855764 filed on linux about the grub->linux flicker that persists here; insight welcome
<ubottu> Launchpad bug 855764 in linux (Ubuntu) "text console between grub and plymouth in oneiric, with current grub" [Undecided,Confirmed] https://launchpad.net/bugs/855764
<SpamapS> slangasek: question on multiarch..
 * slangasek hides under an ld.so.conf
<SpamapS> slangasek: my binary only printer drivers from canon are i386 only as well.. they depend on libpopt0 .. which only exists in /lib
<SpamapS> slangasek: so effectively, they are now uninstallable.. where before they actually worked fine with my amd64 libpopt
<slangasek> SpamapS: libpopt0 is still shipped in ia32-libs for this reason (and others)
<slangasek> ehm, how do you mean "worked fine"?
<SpamapS> slangasek: works fine
<SpamapS> I can extract the binaries and use it.. it runs
<slangasek> you mean it depends on libpopt0 but doesn't use the library?
<slangasek> right
<slangasek> so you can install with --force-depends
<SpamapS> heh.. I didn't think of that. :-P
<slangasek> rather, you *need* to install with --force-depends... and whether you bother to fix up the libpopt.so.0 dependency by installing ia32-libs afterwards is up to you
<slangasek> mvo: if I search for skype in software-center on oneiric, it offers to install it for me from natty-partner even though the i386 package is now available in oneiric-partner... I guess something needs updating to know about oneiric-partner?
<slangasek> bjf: http://reports.qa.ubuntu.com/reports/boot-speed/dell-latitude-e6510/2011-09-20_00-00-03/bootchart.png shows a lot of time spent in /usr/lib/update-notifier/update-motd-updates-available, which wouldn't be the case on a typical boot.  Should/could we correct for this somehow, possibly by making sure there's an 'apt-get update' as part of what's run on the system before the boot test?
<bjf> slangasek, that's a good point
<bjf> slangasek, i normally 1. install the daily iso, and reboot, 2. install bootchart and modify /etc/default/grub and update-grub, 3. reboot for speed test
<bjf> slangasek, there is an 'apt-get update' before installing bootchart (step 2)
<slangasek> bjf: hmm, I guess we need to dig into that then to find out why update-motd-updates-available is still doing work after an apt-get update
<mvo> slangasek: yeah, that needs a update, there is a bzr branch already, I will upload tomorrow morning latest
<slangasek> bjf: I notice too that in some of these, ureadahead looks like it's reprofiling the boot; do we need an additional reboot in there, to make sure we're measuring with an up-to-date ureadahead pack?
<slangasek> mvo: aha - thanks, man :)
<bjf> slangasek, could be
<slangasek> I wonder why we call dbus-uuidgen at boot when we also call it in the postinst
<mvo> slangasek: new app-install-data-partner with multiarch skype is up
<slangasek> mvo: huzzah :)
<broder> slangasek: i think livecd-rootfs removes the dbus uuid, so there isn't actually one at install time
<broder> (and you wouldn't want there to be, anyway, because then it makes for a crappy universally unique id :-p)
<slangasek> broder: that seems like something ubiquity should fix up as part of the install to disk, though, not something we should do on every boot
<broder> slangasek: i looked into this once; my recollection is that it short-circuits fairly quickly if the uuid is there
<slangasek> broder: it's actually popping up on my radar because it's showing up in boot charts as taking a non-trivial amount of time :)
<broder> yeah, that was why i was looking at it :)
<broder> but +1 from me to fixing this in the installer and dropping it from the upstart job
<slangasek> kirkland: do you know why setvtrgb seems to take .25s to 1s to do its thing at boot?  it's possible it's just stuck waiting on the kernel and has no impact on boot speed, but it's strange that it should take this long
<ryoohki> would this be the place to ask for help with pbuilder?
<Daviey> ryoohki: depending on the volume, yes - #ubuntu-motu is another very good place for things like that.
* infinity changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: infinity
<smoser> hey all.
<smoser> i'm looking at https://code.launchpad.net/~menesis/ubuntu/oneiric/paste/oneiric/+merge/75584
<Daviey> smoser: if it gets rid of that annoying warning every time i invoke python, great
<ximion> hi! I would love to see bug 847815 - I get messages about duplicates, but I don't have the required rights to see this bug :(
<ubottu> Error: Launchpad bug 847815 could not be found
<ximion> if someone would be so kind to make it public... :P
<infinity> smoser: Can you test if building the Debian paste on oneiric fixes the bug?  If so, I say we just sync instead of merging that patch.
<Daviey> ximion: looking
<infinity> smoser: Oh, except that ours already has changes.  What are those?  *looks*
<Laney> yeah, we already have .1-2
<infinity> Yeah, indeed.
<Daviey> ximion: public.
<infinity> So, ScottK's comment stops making sense to me at this point. ;)
<infinity> smoser: Nevermind me.  I was assuming ScottK's comment on the bug made sense. :P
<ScottK> What bug?
<infinity> https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/810019
<ubottu> Ubuntu bug 810019 in distribute (Ubuntu Oneiric) "UserWarning printed on import pkg_resources'" [Medium,Confirmed]
<Laney> that bug affects Debian too
<ximion> Daviey: thanks!
<Laney> ah, already there
<ScottK> It was a drive by comment based on the one before, so indeed, there's no guarantee it makes sense.
<smoser> ok. i can verify this
<smoser> i built binaries of the ubuntu version and the proposed
<smoser> http://paste.ubuntu.com/694722/
<smoser> is the diff
<ximion> Daviey, I still don't have permission... But maybe LP is just slow today...
<smoser> and installed, and it doesn't give the issue anymore
<Daviey> ximion: odd, try now.
<smoser> so, to me, its a straight forward fix.
<Daviey> smoser: well it looks safe, but does it work? :)
<smoser> but i really dont know what the namespace_packages.txt does
<ximion> Daviey: works now, thanks again! :)
<smoser> yes, verified it works.
<ximion> oh nooo, it's Russian :D
<Daviey> ximion: hug google translate.. feel free to add your own words to the description.
<ScottK> Considering the paste maintainer is also the dh_python2 author, I think the chances of a bad dh_python2 conversion are low.
<Daviey> ScottK: well seems something is wrong he missed.
<ScottK> Perhaps.
<ScottK> I'd run it by him first.
<ximion> Daviey: Apparently he asks if he can write russian text there :D
<ScottK> IIRC automatic handling of namespaces is one thing that's changed.
<Daviey> So, the big task is against distribute, not paste
<Daviey> but we only see this issue when paste is installed.
<Daviey> s/big/bug
<smoser> no
<smoser> see the debian bug
<smoser> it affects other python packages too
<Daviey> The Debian bug is pretty stale.
<Daviey> barry: do you have thoughts on this?
 * barry reads back
<Laney> he explicitly touched that line when doing the dh_python2 conversion
<jtaylor> you get the same working with argparse installed btw
<jtaylor> warning
<smoser> jtaylor, thank you.
<smoser> jtaylor, wait..i dont think so
<Laney> jtaylor: i can't reproduce that. how?
<smoser> i have argparse, and i have the proposed fix installed for paste, and i no longer see any warnings with
<smoser>  python -c 'import pkg_resources'
<jtaylor> I get it when starting ipython qtconsole
<ScottK> I think the fix is wrong.
<Daviey> jtaylor: i don', without touching paste
<jtaylor> it seem sconnected with pygments
<ScottK> With dh_python2 we shouldn't have to extend sys.path.
<jtaylor>  /usr/lib/python2.7/dist-packages/pygments/plugin.py:39: UserWarning: Module argparse was alrea...
<ScottK> The current package has /usr/share/pyshared/Paste-1.7.5.1-nspkg.pth
<jtaylor> ah because that includes pkg_resources
<ScottK> So I think the actual problem is that file getting installed.
<barry> so, interestingly enough, piotr originally suggested removal of *.pth files, but then backtracked
<barry> (this was in reference to flufl.lock getting into debian)
<barry> actually i think it was jakub who said:
<ScottK> AIUI his debian/rules tries to remove it, but fails.
<jtaylor> neither argparse nor pygments install pth files
<barry> which would make sense because i don't think either provides a namespace
<ScottK> If I manually remove the pth file, the warning doesn't happen.
<Laney> indeed
<barry> jtaylor: so you're getting two pkg_resources?
<smoser> ScottK, you're saying if you remove /usr/lib/python2.7/dist-packages/Paste-1.7.5.1-nspkg.pth the problem goes away ?
<smoser> because i do not see that.
<ScottK> Yes.
<ScottK> Actually, not quite.
<jtaylor> barry: I only see one
<ScottK> I removed rm /usr/share/pyshared/Paste-1.7.5.1-nspkg.pth
<Laney> smoser: http://paste.debian.net/131463/
<smoser> http://paste.ubuntu.com/694741/
<jbicha> yesterday's ca-certificates bugfix doesn't actually restore libnss3 to those who lost it, would a libnss3 rebuild help?
<barry> indeed, after installing python-paste, and importing pkg_resources, it's getting it from where i'd expect
<smoser> jbicha, only those who did a fresh install were affected. i assume you're one of them.
<smoser> so, Laney, what did i do wrong ?
<barry> it's very disconcerting that you get a warning about module Paste when you don't even import it
<infinity> jbicha: Yes, but ideally not in the middle of a freeze.
<Laney> the find line fails to remove the pth file
<jtaylor> pkg_resources does some weird stuff when you import it
<Laney> find /srv/home/laney/temp/paste-1.7.5.1/debian/python-paste -name '*.pth' -or -name 'namespace_packages.txt' -print -delete
<Laney> /srv/home/laney/temp/paste-1.7.5.1/debian/python-paste/usr/lib/python2.6/dist-packages/Paste-1.7.5.1.egg-info/namespace_packages.txt
<ScottK> Laney: Yes.  That's what needs fixing.
<jbicha> smoser: no, not a fresh install, anyone who had been using Oneiric & happened to upgrade to the broken ca-certificates yesterday
<barry> yeah, try turning on -v to see the imports that happen as a result of pkg_resources.  zope, then lazr, and it's there i get the warning
<barry> ScottK: so you're saying that it's python-paste that needs fixing?  if so, i think i agree :)
<jbicha> infinity: people's systems are quite broken, and it's easier to tell people to update then for them to find a random .deb to install
<doko> barry, you can give back cardstories on the regular buildds
<ScottK> barry: Yes, but I think someone should also talk to POX before fixing it.
<Laney> just needs some parens
<jtaylor> in my argparse case it comes after lazr
<barry> doko: build retried
<ScottK> I don't agree that the proposed change is correct.
<Laney> find /srv/home/laney/temp/paste-1.7.5.1/debian/python-paste \( -name '*.pth' -or -name 'namespace_packages.txt' \) -print -delete
<Laney> like that
<barry> ScottK: i asked pox for his opinion of bug 810019 on #debian-python
<ubottu> Launchpad bug 810019 in distribute (Ubuntu Oneiric) "UserWarning printed on import pkg_resources'" [Medium,Confirmed] https://launchpad.net/bugs/810019
<ScottK> OK.  Thanks.
<barry> he may not be around now though
<barry> well, i subscribed him to the lp bug
<jbicha> infinity: thanks
<ScottK> It's just (IIRC) part of supported, so we can get this fix in when it's ready.
<ScottK> No need to sweat the beta 2 milestone.
<smoser> jbicha, i dont think you're right though
<smoser> because i upgraded to the busted openssl
<smoser> and i'm not broken
<infinity> smoser: And by "openssl", you mean "ca-certificates"?
<jbicha> smoser: it was ca-certificates and I had to manually install libnss3
<smoser> so, Laney ScottK if i remove those .pth files, my problem does not go away.
<smoser> i'm on updated to the moment-ish oneiric
<smoser> granted i do have some ppas installed for openstack
<doko> jelmer, do you want to propose heimdal 1.5 for the final release?
<ScottK> You may have more than one package installed with the same issue.
<jtaylor> so got a way to reproduce argparse issue: mkdir -p external/argparse; touch external/__init__.py; echo "import argparse > external/argparse/__init__.py"; python -c import external.argparse; import pkg_resources"
<jtaylor> not related to any pth files
<smoser> ScottK, but it is still paste that complains
<smoser> or, is complained of
<ScottK> Hmmm.
<Daviey> smoser: what file did you rm?
<smoser> see pastebin, daviey
<smoser> http://paste.ubuntu.com/694741/
<Daviey> /usr/share/pyshared/Paste-1.7.5.1-nspkg.pth ?
<smoser> yes.
<Laney> smoser: do you have /usr/lib/python2.7/dist-packages/PasteDeploy-1.5.0-nspkg.pth ?
<Laney> seems pastedeploy has the same issue
<smoser> i was just suspecting that.
<barry> from #debian-python:
<barry> <POX> barry: well, I am actually *not* removing this damn Egg stuff  [16:42]
<barry> <POX> will fix in next upload
<barry>  
<Laney> confirm/deny plz
<smoser> sudo rm $(dpkg -L python-pastedeploy | grep pth$)
<Daviey> smoser: it also doesn't help me
<smoser> that fixed my problem
<Laney> right, so pastedeploy has it too
<smoser> Daviey, you also have paste-deploy probably
<smoser> yeah
<Laney> which is unsurprising because it has exactly the same line in its rules file
<Daviey> smoser: confirmed
<Laney> barry: can you pass that info to POX?
<barry> Laney: sorry, which info exactly?
<ScottK> barry: Since POX was heading to bed, why don't you file some nice bug reports in Debian once this is sorted?
<infinity> barry: That if his find syntax was correct, this would all be working. ;)
<Laney> that python-pastedeploy needs fixing too
<ScottK> barry: That paste-deploy is broken too
<ScottK> err, that one.
<Daviey> seems to be evil, /usr/share/pyshared/*.pth
<ScottK> Yes.
 * Laney has NFI what .pth files actually are :-)
<barry> Laney: http://docs.python.org/library/site.html#module-site
<jtaylor> I don't think removing the pth file is a proper solution
<jtaylor> or is my argparse example somehow wrong?
<jtaylor> that method is quite important to ipython
<barry> so, sounds like pox will fix those in the next debian uploads
<barry> (of paste*)
<Daviey> jtaylor: Nobody else has been able to reproduce your argpath example?
<Laney> does he agree with our assessment?
<doko> I'll disallow imports from /ust/share/pyshared directly for the p-series
<Laney> i.e. should we upload fixes like that?
<jtaylor> Daviey: https://bugs.launchpad.net/ubuntu/+source/distribute/+bug/810019/comments/9
<ubottu> Ubuntu bug 810019 in distribute (Ubuntu Oneiric) "UserWarning printed on import pkg_resources'" [Medium,Confirmed]
<doko> jtaylor, did you see my dlr-languages question?
<jtaylor> no
<Daviey> jtaylor: dropping the .pth files breaks ipython?
<ScottK> since POX says he'll upload fixed versions tomorrow, my recommendation is just wait and sync that.
<Daviey> smoser / jtaylor: removing the pth files does break ipython
<barry> okay, so pox is going to upload fixed versions tomorrow.  we'll need to sync that once it's uploaded and then our problem should be fixed
<jtaylor> no
<Daviey> infact, it breaks paste.
<Daviey> you can't import paste full stop, without the pth files.
<smoser> well, thats hardly of concern.
<smoser> i dont want to see the error!
<smoser> :)
<barry> exactly.  installing paste should not cause that warning for unrelated modules
<jtaylor> ah ok now I get it, the argparse issue is caused by paste ._.
<jtaylor> doko which dlr-languages question?
<barry> doko: dang.  cardstories 1.0.6-1 still ftbfs, but it builds fine for me locally.  i'll keep digging
<OdyX> tkamppeter: is your foomatic-db patch upstream'ed ?
<doko> jtaylor, ahh, sorry, that was Laney, not you
<Laney> regarding my email?
<doko> will remove it now
<ryoohki> Daviey: thanks!
<doko> Laney, yes, I do not want to care about the whole dlr stack, and ironpython is now part of that (mess)
<Laney> :-)
<Laney> can it be split up?
<doko> I didn't check anymore. let's address this for p
<Laney> no probs
<jelmer> doko: are you asking whether that's what I had planned, or requesting I do so?
<doko> jelmer, have you been a diplomat in your former life?
<jelmer> doko: Sorry :)
<jelmer> doko: I didn't have any plans to upload the final 1.5 release into oneiric.
<doko> jelmer, no, was a question what should be supported, and if the changes are worth (the risk) including it
<doko> ok
<doko> Laney, could you have a look at bug 756121?
<ubottu> Launchpad bug 756121 in nemerle (Ubuntu Oneiric) "nemerle version 0.9.3+dfsg-3 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/756121
<Laney> doko: we are removing it
<Laney> i thought directhex filed the rm bug
<Laney> but no, I will do it now
<doko> jelmer, what's the status about bug 831375
<ubottu> Launchpad bug 831375 in bzr-hg (Ubuntu Oneiric) "bzr-hg version 0.2.0~bzr409-1.1 failed to build in oneiric" [High,In progress] https://launchpad.net/bugs/831375
<Laibsch> I have added http://paste.debian.net/131459/ to my pbuilderrc s suggested in http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#altcompiler to build with gcc 4.4 (4.6 has a bug on my CPU), but logging in to the pbuilder and doing "gcc --version" still show 4.6.1.  What's wrong?
<doko> Laney, same for bug 831373
<ubottu> Launchpad bug 831373 in ikvm (Ubuntu Oneiric) "ikvm version 0.46.0.1+ds-3 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831373
<jelmer> doko: it's on my todo list, I'm hoping to address it before the end of the week (as well as some other bzr-hg issues)
<Laney> looking
<Laney> doko: debian bug #642361 for nemerle
<ubottu> Debian bug 642361 in ftp.debian.org "RM: nemerle -- ROM; FTBFS, not buildable with Mono" [Normal,Open] http://bugs.debian.org/642361
<Laney> fire ze missiles
<doko> Laney, thanks, fired
<Laney> ivkm looks like a missing --exclude-modeuleref
<slangasek> does anyone here see plymouth crashes on boot?
<slangasek> ever?
<slangasek> we get plenty of bug reports about it... but it's a deep bug that needs to be reproduced locally to fix
<RAOF> What would a plymouth crash look like?
<slangasek> RAOF: an apport pop-up :)
<RAOF> Heh.  So, no, none of my systems do that :)
<slangasek> somewhere there's a reference counting bug in the event loop code, but my eyes can't find it.... I need to get at a gdb session, but the retracer helpfully scrubs all core files from the bugs before it shows them to me :P
<tkamppeter> OdyX, the upstream repo for foomatic-db is still down, I will upstreamize the patch as soon as it gets possible.
#ubuntu-devel 2011-09-22
<pitti> Good morning
<pitti> tkamppeter: it's worth a try now, anyway
<Nafai> good morning pitti! :)
<didrocks> good morning
<tkamppeter> pitti, what do you mean with "It is worth a try now"?
<pitti> tkamppeter: reuploading your crash report
<tkamppeter> pitti, will try.
<tkamppeter> pitti, bug 856139, let's see ...
<ubottu> Launchpad bug 856139 in cups (Ubuntu) "cupsd crashed with SIGSEGV in _cups_strcasecmp()" [Undecided,New] https://launchpad.net/bugs/856139
<pitti> tkamppeter: meh -- seems it just doesn't like that crash; I don't think it's the oboslete dbgsyms, seems the memory is just too disrupted
<pitti> tkamppeter: do you get anything sensible in gdb?
<tkamppeter> pitti, I did not try gdb, how do I proceed for that, especially as I cannot reliably reproduce the problem.
<pitti> tkamppeter: you can install apport-retrace, and try
<poolie> hi pitti
<pitti> apport-retrace -S system -g -v /var/crash/yourcrashfile.crash
<pitti> hey poolie
<pitti> tkamppeter: that'll build a temp dir with all debug symbols it can get, and put you into a gdb session with that crash
<pitti> tkamppeter: so you can do "bt full", poke around in the frames, etc.
<dholbach> good morning
<robert_ancell> mr_pouit, hey, did you get that lightdm alternatives patch to work?
<OdyX> tkamppeter: oh, right.
<doko_> cyphermox, ping
<ricotz> doko_, the new clutter/cogl upload includes the armhf bits which will hopefully work in 12.04
<tkamppeter> pitti, it seems that apport-retrace has a bug, see http://paste.ubuntu.com/695005/
<Sweetshark> pitti: fyi: I have a 3.4.3-1ubuntu3 locked and loaded -- it compiled locally and is currently testcompiling on armel -- it fixes bug 835153, bug 835663, bug 779798, bug 841562 and bug 850372. When would you be allowed to upload that for final?
<ubottu> Launchpad bug 835153 in libreoffice (Ubuntu Oneiric) "oosplash.bin crashed with SIGSEGV in XSetForeground()" [High,In progress] https://launchpad.net/bugs/835153
<ubottu> Launchpad bug 832435 in compizconfig-settings-manager (Ubuntu) "duplicate for #835663 ccsm crashed with KeyError in compizconfig.Plugin.ApplyStringExtensions (src/compizconfig.c:6780)(): 'PbP\x01'" [Undecided,Confirmed] https://launchpad.net/bugs/832435
<ubottu> Launchpad bug 779798 in libreoffice (Ubuntu) "Report Builder does not open" [Undecided,Confirmed] https://launchpad.net/bugs/779798
<ubottu> Launchpad bug 841562 in libreoffice (Ubuntu) "package libreoffice-common 1:3.4.2-2ubuntu3 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [Undecided,Confirmed] https://launchpad.net/bugs/841562
<ubottu> Launchpad bug 850372 in libreoffice (Ubuntu) "/usr/lib/libreoffice/program/soffice.bin: error while loading shared libraries: libsofficeapp.so: cannot open shared object file: No such file or directory" [Undecided,New] https://launchpad.net/bugs/850372
<Sweetshark> eh, thats bug 835662 (not 835663)
<ubottu> Launchpad bug 835662 in libreoffice (Ubuntu) "LibreOffice Base forms become extremely slow after switching from currently unusable PostgreSQL SDBC driver to JDBC" [Undecided,New] https://launchpad.net/bugs/835662
<tkamppeter> pitti, see bug 856216 for my experience with apport-retracer.
<ubottu> Launchpad bug 856216 in apport (Ubuntu) "apport-retrace crashed with , E in update()" [Undecided,New] https://launchpad.net/bugs/856216
<pitti> Sweetshark: we can upload it right now, i'll be caught in unapproved
<pitti> tkamppeter: will look in a bit, still doing release-y stuff
<pitti> tkamppeter: "No keyring installed", uh
<pitti> tkamppeter: you don't need root there, btw; all user stuff
<pitti> tkamppeter: can you please add the output of "apt-key list" to the bug?
<tkamppeter> pitti, which keyring does it need and how do I get such a keyring?
<pitti> you knock on elmo's door with some chocolate and ask nicely
<pitti> no, it should be there already
<pitti> tkamppeter: it complained about the standard ubuntu archive one
<pitti> tkamppeter: I'll try to reproduce this, but I need the apt-key output
<tkamppeter> pitti, done.
<pitti> tkamppeter: do you have anything in /etc/apt/trusted.gpg.d/ ?
<tkamppeter> pitti, crash file attached.
<tkamppeter> pitti, yes, see bug
<pitti> tkamppeter: can you attach /etc/apt/trusted.gpg.d/jockey-drivers.gpg to the bug? just to ensure that I have the same files?
<pitti> tkamppeter: (it's nothing secret, just the public GPG keys from epson, etc.)
<tkamppeter> pitti, attached.
<tkamppeter> pitti, can you have a look at bug 856274? It seems that it has a problem with its i386 version.
<ubottu> Launchpad bug 856274 in cups (Ubuntu) "Unable to upgrade libcups2" [Undecided,New] https://launchpad.net/bugs/856274
<pitti> tkamppeter: seems like mirror lag
<pitti> tkamppeter: followed up
<pitti> tkamppeter: hm, still can't reproduce that apport-retrace bug
<pitti> tkamppeter: if you do a normal "sudo apt-get update", do you see similar GPG errors?
<pitti> tkamppeter: anyway, as for the actual crash, I think there's a bug in python-apt or in apport-retrace, it doesn't seem to install all debug symbols that it downloaded
 * pitti investigates tthis
<pitti> ah, no, it's there, I just mislooked
<pitti> tkamppeter: oooh, I know
<pitti> tkamppeter: cups-dbg only has debug symbols for libcups2, nothing else; in particular, not for /usr/sbin/cupsd
<pitti> it seems the upstream build system already strips the daemon
<tkamppeter> pitti, perhaps we should patch the build system for Oneiric so that it does not strip any executable or library from CUPS, so that we can investigate crashes. Can you look into this?
<pitti> yeah, usually the build system shoudln't do this, especially not if you build with -g -O2
<tkamppeter> pitti, if I run "apt-get update" manually I do not get any GPG errors, only a not available http://ftp.freestandards.org/.
<pitti> tkamppeter: can you reproduce that crash?
<pitti> tkamppeter: I have rebuilt cups with debugging symbols now, but as the core dump is from a different binary, it doesn't match any more
<tkamppeter> pitti, no. I get it here and there when I create CUPS queues.
<pitti> tkamppeter: so, I'm afraid this .crash file is useless :(
<pitti> tkamppeter: I'll look into fixing cups-dbg
<tkamppeter> pitti, AFAIR it happens preferably if creating queues with the dnssd backend pointing to CUPS queues on other servers.
<pitti> without my "sudo ln -s /bin/true  /usr/bin/strip" hack, that is :)
<tkamppeter> pitti, when you have the fixed package up, with debug symbols for all executables and libs of CUPS, please tell me, then I will update and try to get the crash again by quickly creating many print queues.
<pitti> tkamppeter: test build running
<pitti> tkamppeter: do you have cups-dbg installed? If so, even the locally created StackTrace in the .crash file should be useful
<apw> slangasek, when you say brief clear to black is that literally just before plymouth, and does the backlight turn off in teh gap, ie. could it be a mode switch?
<pitti> tkamppeter: that also explains why we don't have any -dbgsym packages
<tkamppeter> pitti, I have it installed, but apport-retracer still crashes for me.
<pitti> tkamppeter: for that one, perhaps you can tar up /etc/apt/ and attach it? I'll try to replace mine with your's
<pitti> mvo: do you have an idea what could be wrong in bug 856216?
<ubottu> Launchpad bug 856216 in apport (Ubuntu) "apport-retrace crashed with FetchFailedException in update()" [Undecided,New] https://launchpad.net/bugs/856216
<pitti> mvo: apt-get update doesn't complain, and I installed the very same /etc/apt/trusted.gpg.d/jockey-thing as Till has, but I don't get the error
<pitti> tkamppeter: cups-dbg fix pushed to bzr
<pitti> tkamppeter: if you install cups-dbg, you won't actually need apport-retrace; just say "report" to the crash report, and then cancel when it asks you to upload to launchpad, then the .crash file will have the stack trace
<tkamppeter> pitti, /etc/apt attached.
<mvo> pitti: you modify dir::etc::trusted where it should be trustedparts maybe? check apt-config dump|grep trusted
<tkamppeter> pitti, then it has it already, as it is from the report.
<mvo> pitti: just a wild guess without having looked at this in more detail though
<pitti> mvo: actually not, I just set RootDir
<pitti>         apt.apt_pkg.config.set('RootDir', apt_root)
<pitti>         apt.apt_pkg.config.set('Debug::NoLocking', 'true')
<pitti>         apt.apt_pkg.config.clear('APT::Update::Post-Invoke-Success')
<pitti> mvo: ^ that's all it does
<pitti> mvo: but if it was a general bug, I should get it, too
<pitti> mvo: something on Till's system is different than mine
<mvo> pitti: ok, then I need to look a bit close, I'm in a call now, I can check after that. a permissions problem is ruled out as well? gpg is pretty picky here sometimes
<pitti> anyway, post-lunch problem, bbl
<pitti> mvo: thanks; I'll poke this some more
<tkamppeter> pitti, http://paste.ubuntu.com/695060/
<pitti> tkamppeter: "(no debugging symbols found)"
<pitti> tkamppeter: is that with the current bzr packages?
<pitti> tkamppeter: when I do "gdb /usr/sbin/cupsd", I get (no debugging symbols found)"; but after installing the locally built cups-dbg, I get "Reading symbols from /usr/sbin/cupsd...Reading symbols from /usr/lib/debug/usr/sbin/cupsd...done."
<doko_> pitti, seb128 please have a look at bug 831143, the package doesn't seem to work at all, but is a dependency of ephiphany-browser
<ubottu> Launchpad bug 831143 in seed (Ubuntu Oneiric) "seed version 3.0.0-2 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831143
<tkamppeter> pitti, the paste was of before today's BZR, so still without your cups-dbg fix.
<pitti> ah
<tkamppeter> pitti, building CUPS from BZR ...
<cyphermox> doko_: pong
<tkamppeter> pitti, installed the new CUPS, now I must get the bug triggered again ...
<doko_> cyphermox, looking at the wireless-regdb ftbfs, wondering which package in Ubuntu does have this information?
<cyphermox> doko_: crda
<cyphermox> afaik it should be the only one
<cyphermox> doko_: actually, I mean crda is, I think, the only package to use this
<doko_> cyphermox, well, wireless-regdb was never built
<doko_> so we maybe should remove these two packages
<cyphermox> oh, yeah probably
<cyphermox> weird, because I could have sworn we always did have a package to do this
<cyphermox> doko_: ok, found what I was looking for, I was thinking of iw
<cyphermox> so yeah, I do agree these packages could be removed
<cyphermox> shoudln't it be easy to just not sign the reg data?
<doko_> cyphermox, please go ahead and upload a fix
<cyphermox> doko_: ok I'll have a look
<dobey> do packages seeded for default install/CD *have* to be in something else's Depends/Recommends that's already there?
<cjwatson> I don't think you mean the same thing by the term "seeded" as I do
<cjwatson> can you rephrase your question?
<cjwatson> (I use "seeded" to mean "explicitly added to a seed as opposed to pulled in purely by dependencies")
<cyphermox> doko_: I'll need sponsoring shortly
<dobey> cjwatson: oh; typically whwenever we wanted something on CD, we always got the "something needs to Depends/Recommends it"
<dobey> cjwatson: perhaps that created some confusion :)
<cjwatson> dobey: in order for something to be on the CD, it must either be explicitly listed in a seed, or listed in Depends/Recommends of something that's already there
<cjwatson> (listing it in (e.g.) the desktop seed will cause it eventually to be depended upon by ubuntu-desktop)
<dobey> ok
<cjwatson> the rule of thumb is that you explicitly seed things that are top-level requirements
<Chipzz> cjwatson: would it be incorrect to say that to have stuff included on the CD, you have dependency-trees, and the seeds are the roots of those that pull in all other dependencies?
<cjwatson> Chipzz: that's roughly correct
<dobey> and eww; but i always end up uninstalling ubuntu-desktop anyway, so i can uninstall things it depends on
<cjwatson> dobey: that's orthogonal
<cjwatson> dobey: and in any case there is a syntax for causing ubuntu-desktop to only Recommends something
<cjwatson> if it's not core desktop infrastructure, it should typically be Recommends
<Chipzz> cjwatson: are seeds always meta-packages?
<dobey> ok
<cjwatson> Chipzz: no
<cjwatson> for example the ship seed (which defines the set of packages added to the pool on the alternate CD but not installed by default) is not a metapackage
<cjwatson> or rather is not used to generate a metapackage
<Laney> recommends> I wish :-)
<cyphermox> doko_: well, forget this, crda is not installable, it tries to install /sbin/crda which is already provided by wireless-crda (which is required by the kernel)
<doko_> apw, ogasawara: any idea why crda cannot be used?
<apw> doko_, sounds like something rtg would be most familiar with
<cyphermox> oh fun, it's just a duplicate package
<apw> cyphermox, could well be
<cyphermox> I'm trying to figure out which is the latest version
<apw> i suspect we added wireless-crda, as we had kernels requiring it before debian, so we might be able to merge them.  rtg was point man on crda so i'd recommend bring it to his attention
<ScottK> mvo: I'm just upgrading my test server via ssh and I noticed that the dialogue around the alternate sshd is much improved (particularly around firewalls).  Thanks.
<mvo> ScottK: great, thanks!
<apw> cyphermox, doko_, ok tgardner is looking into it
<cyphermox> ok
<apw> cyphermox, when was crda last sync'd and how would if find out the real debian version now
<cjwatson> https://launchpad.net/ubuntu/+source/crda/+publishinghistory  http://packages.qa.debian.org/crda
<doko_> apw, http://packages.qa.debian.org/c/crda.html
<cyphermox> apw: crda was probably auto-imported
<cyphermox> I doubt anyone touched it :)
<cjwatson> we're in sync with Debian
<apw> then i suspect its pretty out of date.  the DB it contains is updated fairly often
<cyphermox> apw: then you mean wireless-regdb and the database from the wireless-crda package, those are in sync
<doko_> apw, the db is packaged in wireless-regdb
<cyphermox> it's both 2011-04-28, the debian package adds an EU domain
<apw> ahh ok
<cyphermox> your package appears to only have just a bit of extra code to crda to have it work with libnl3
<apw> cyphermox, then it osunds like potential for a merge ...
<tgardner> cjwatson, given that wireless-crda is in the desktop seed, do you really want to change that right now ?
<tgardner> I suggest we change to crda+wireless-regdb during the P cycle.
<doko_> nobody said right now. seen while cleaning up the archive. it's fine if this is done for P
<tgardner> doko_, works for me
<tgardner> I'll git it on my todo list for when P opens
<cyphermox> yeah, I think we should probably do this in P
<tgardner> I'll start a bug so tha it doesn't get forgotten
<tgardner> skaet, sure would be handy to be able to specify milestones for the P series already. do we have to wait until the P archive is opened ?
<ScottK> tgardner: You can.
<ScottK> (IIRC)
<skaet> tgardner,  we need a name for p-series first before the milestones can get populated.
<ScottK> Ah, right - milestones, not series.
<ScottK> skaet: It would also be nice to have a name so we can update development tools in oneiric to know what to call P.
<skaet> ScottK,  agreed.  absence of a name is starting to get in the way. :P
<tkamppeter> pitti, I succeeded the stacktrace now, with CUPS locally built from BZR and doing ~60 queue addition/removal operations, and on one removal it actually crashed. Will paste the stacktrace into the bug.
<pitti> tkamppeter: ah, great
<cjwatson> tgardner: yeah, P is fine
<tgardner> cjwatson, ack
<tkamppeter> pitti, bug 855445
<ubottu> Launchpad bug 855445 in cups (Ubuntu) "cupsd crashed with SIGSEGV in _cups_strcasecmp()" [Undecided,Confirmed] https://launchpad.net/bugs/855445
<pitti> tkamppeter: ah, that looks a lot more useful
<ScottK> mvo: As I mentioned, I just upgraded my test server to oneiric.  It appears that I've no packages left that require python-central, but it wasn't removed on upgrade.  Is that something you could check for?  Would you like a bug about this?
<mvo> ScottK: that is interessting, yes, a bug would be nice
<ScottK> OK.
<ScottK> mvo: Bug 856458
<ubottu> Launchpad bug 856458 in update-manager (Ubuntu) "python-central no longer needed, but not removed" [Undecided,New] https://launchpad.net/bugs/856458
<mvo> thanks scottk!
<rbasak> hey cyphermox, sorry I didn't understand https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/856209/comments/3 at all. Which same default route, and what do I point to the same device with link-local?
<ubottu> Ubuntu bug 856209 in network-manager (Ubuntu) "NM fails to set IPv6 default route when IPv6 details entered manually" [High,Confirmed]
<cyphermox> rbasak: ah, I mean, could you try with the link-local address to your router
<cyphermox> here I get a standard global ipv6 address from dhcp, and my defualt route is automatically set properly by NM, to the link-local address of the router
<rbasak> Ah, so you want me to see what happens if I specify the link-local router address as the gateway in the settings?
<doko_> plars, pitti: please could you have a look at bug 756043 ?
<ubottu> Launchpad bug 756043 in moserial (Ubuntu Oneiric) "moserial version 2.28.2-0ubuntu2 failed to build on i386" [High,Confirmed] https://launchpad.net/bugs/756043
<pitti> doko_: yeah, can do
<plars> doko_: I haven't looked at it in a while, but I know there's a new upstream version
<cyphermox> rbasak: yup
<doko_> yeah for configure modularization ...
<doko_> dnl insert here your program name and version number
<doko_> AC_PROG_CC
<doko_> KDE_DO_IT_ALL(phaseshift,0.4)
<slangasek> apw: I'm not sure if the backlight turns off; I get different behavior based on whether I have an external monitor plugged in or not, in one of these cases I briefly get a cursor and in the other I don't.  (I think the cursor is with the external monitor plugged in.)
<rbasak> cyphermox: didn't work; I've commented in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/856209/comments/4
<ubottu> Ubuntu bug 856209 in network-manager (Ubuntu) "NM fails to set IPv6 default route when IPv6 details entered manually" [High,Confirmed]
<Laibsch> I have added http://paste.debian.net/131459/ to my pbuilderrc s suggested in http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#altcompiler to build with gcc 4.4 (4.6 has a bug on my CPU), but logging in to the pbuilder and doing "gcc --version" still show 4.6.1.  What's wrong?
<seb128> mvo, is /usr/share/update-notifier/notify-reboot-required still used nowadays?
<mvo> seb128: yes
<seb128> it seems to do nothing there
<seb128> like I did sudo /usr/share/update-notifier/notify-reboot-required
<seb128> it created the files in /var/run
<seb128> but neither update-manager nor the indicator nor anything says I need to restart
<cyphermox> rbasak: ok, so there's really something very broken there, I'll see what I can make with this
<rbasak> OK thanks
<mvo> seb128: right, you need to touch /var/lib/update-notifier/dpkg-was-run as well, this is done automatically by apt after it ran dpkg
<seb128> mvo, thanks
<mvo> yw
<apw> slangasek, i guess i'd like to see it boot in total.  might you be able to video it on your phone or something
<slangasek> apw: ok, will try to do that later today.  First I'm trying to see if I can reproduce it on my old T60, since that would give me more flexibility to play
<apw> slangasek, if you arn't using crypto, installing and removing those tools moves the mode switch about in the boot and is a good way to know if it is the modeset
<slangasek> apw: I am using crypto ;)
<apw> damn
<slangasek> part of why I want to reproduce it on another box first
<slangasek> though I do have an unencrypted VG on here partly for just this sort of thing, so I can install to that if needed for testing
<slangasek> mdeslaur: bug #856534 looks like something we should get fixed for release; do you have interest/time to work on this?
<ubottu> Launchpad bug 856534 in flashplugin-nonfree (Ubuntu) "flashplugin-downloader installs wrong alternative if nspluginwrapper not yet unpacked" [High,Triaged] https://launchpad.net/bugs/856534
<mdeslaur> slangasek: I'll take a look, thanks
<pitti> doko_: moserial uploaded
<pitti> plars: ^ FYI
<plars> pitti: awesome, you rock!
<plars> pitti: according to comments from the author, that one should work better with current vala versions
<pitti> yep, it works fine with 0.14
<pitti> 2.32 didn't work either
<pitti> and 3.0 makes more sense in oneiric anyway
<doko_> lucas, is libdb-ruby worth fixing, or better just remove it?
<pitti> kees, mdz, cjwatson: oh, we have TB meeting today; apparently no selected chair, but not much of an agenda anyway
<mdz> pitti, indeed
<cjwatson> oh, hmm, it's inconvenient for me this week - my brainstorm update is that a couple of people have responded but so far the response rate is not great; I'll start harassing people soon
<cjwatson> I'll try to attend but possibly only by IRC-from-phone
<chmrr> I'm one of the upstream maintainers of https://launchpad.net/rt/ -- https://launchpad.net/rt/+packages shows that request-tracker3.8 packages list rt/4.0 as upstream, instead of rt/3.8  What's the right way to fix this on launchpad, as I don't seem to have rights to change them myself?
<cjwatson> it'd be best to ask #launchpad
<chmrr> Will do; thanks!
<cjwatson> oh, that interacts with an Ubuntu package, hmm
<cjwatson> let me see
<Laney> I see remove/link buttons, don't know what gave me permissions there though
<cjwatson> chmrr: I've fixed it for you
<chmrr> Thanks!
<cjwatson> I guess I need to fix natty/maverick too ...
<cjwatson> ignore the "Bilimbi Test" one, that's an LP test of derived distributions
<chmrr> Yeah, I was wondering what was up with that
<cjwatson> the Ubuntu ones should all be fixed now
<cjwatson> Laney: upload privileges to the package
<Laney> thought as much
<cjwatson> (at least, I expect so)
<chmrr> lucid's request-tracker3.8 reports it's against master, which is also wrong
<cjwatson> OK, I've made that 3.8 too
<chmrr> Thanks!
<kees> pitti: cool, I'm around
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber, infinity
<stgraber> infinity: still piloting?
<infinity> stgraber: Oh, no, just retarded.
<infinity> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<slangasek> mterry: bug #854202> who did you hear from that we're not dropping these packages from the CD?  I expect that's correct, but ubuntuone-couch is currently out of main and has other dependencies, so I want to be sure to follow up with the primary source before simply promoting the packages
<ubottu> Launchpad bug 854202 in deja-dup (Ubuntu) "deja-dup should depend on ubuntuone-couch" [Undecided,Fix released] https://launchpad.net/bugs/854202
<mterry> slangasek, from pitti and dobey.  It was only dropped from main because deja-dup dropped the recommends recently
<Laney> slangasek: https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/856405
<ubottu> Ubuntu bug 856405 in ubuntu-meta (Ubuntu Oneiric) "Add Ubuntu One packages back to default install and CD" [High,Fix released]
<slangasek> mterry: ok; is that true of python-mocker as well?
<mterry> slangasek, I don't know about mocker
<slangasek> mterry: is there a channel log for this that I can peruse to my satisfaction, or should I just leave it to pitti?
<slangasek> the latter may be simpler :)
<Laney> it was discussed a bit in #-release earlier, but only retrospectively
<mterry> slangasek, I think it was brought up in last #ubuntu-desktop meeting, but again, retrospectively
<mterry> slangasek, https://wiki.ubuntu.com/DesktopTeam/Meeting/2011-09-20 (the meeting I mentioned)
<cnd> it looks like there's some support for pkg-create-dbgsym in ppas
<cnd> looking at the source for pkg-create-dbgsym, it seems that if "Build-Debug-Symbols: yes" is set somewhere, it will build them
<cnd> is there any docs on this?
<cnd> pitti, ^^ ?
<slangasek> mterry: thanks - and I found the previous MIR for mocker, so I've repromoted both packages
<doko_> slangasek, do you mind updating qemu-linaro to the recent release, fixing the build failure?
<slangasek> doko_: I don't /mind/, no, but it requires a FFe... was just discussing that on #ubuntu-release this morning, I'll go ahead with it soon
<bladernr> Does anyone off hand know who maintains mesa-utils (glxinfo, glxgears, glxheads) or who/where to poke with bugs and questions?  I keep running into dead ends on Launchpad and google gives me blog posts about mesa-utils, but nothing useful
<doko> seb128: could you pitti please have a look at the seed build failure? looks like you did request the sync and did ignore the build failures
<seb128> doko, will do if I've time next week
<seb128> doko, if pitti doesn't beat me to it but it called it a week already
<doko> seb128, sorry, but next time please spend your time before doing syncs like these
<Sarvatt> bladernr: ubuntu-x-swat, #ubuntu-x. its a new package which was split off from the mesa source is probably why there's a dearth of info
<bladernr> Sarvatt:  awesome! thanks a lot :)
<seb128> doko, 3.0.0-1 built
<doko> yeah, but not -2
<seb128> it has no code change
<doko> and no reaction from your side
<seb128> we would have got the same issue without syncing it
<seb128> right, it's a toolchain segfault
<seb128> not a seed issue
<doko> seb128, bullshit
<seb128> well -1 built fine and there is no code change
<seb128> well "toolchain" can be "build-depends"
<seb128> but seed didn't change between the version which built and the one which didn't, it was only packaging cleaning
<seb128> the same version built in debian and is in testing
<doko> seb128, when will you learn that the toolchain uncovers issues in broken code?
<seb128> well nothing tell you that it doesn't expose a bug in the toolchain either
<seb128> doko, you are just doing claims, it could be either way
<seb128> only debugging will tell us, but -1 built and -2 which is what we have built in Debian and is in testing
<doko> usually I'm right with my "claims". it's the non-action on your side which concerns me
<seb128> well, it's not in the default install so I don't really care
<seb128> which I admit is not a position everybody share, but we have the resources to either make our default install good or everything medium, I prefer to focus on what is most used
<seb128> but feel free to drop seed from oneiric and epiphany-browser with it if nobody fixes it
<seb128> seems similar to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582774
<ubottu> Debian bug 582774 in seed "seed FTBFS on ia64" [Important,Open]
<doko> seb128, please could you reply to the launchpad issue that it is ok to remove epiphany-browser? I'm fine with this
<seb128> well, I'm not deciding with that but if the issue is not fixed that's what we should do
<seb128> but if somebody cares and want to fix the issue they should be able to do it
<seb128> it's true for any ftbfs not fixed by oneiric...
<micahg> doko: seb128, can we just remove the binaries and not the source in case someone wants to fix it?
<doko> we can, but still shows up as a ftbfs. I don't see any harm to remove the sources too. cjwatson does want to improve the sync script to not accept the same version again, if it was already in ubuntu
<seb128> well no reason to not sync that one next cycle
<micahg> doko: I don't think showing up as an FTBFS is a bad thing, it might encourage someone to fix it
<seb128> it could well be a toolchain bug since it built before in the cycle and builds in debian
<doko> removal doesn't mean not syncing new versions
<doko> seb128, just be honest and clear, that you even that you didn't event check to build the package with -g
<doko> s/even/even check/
<doko> damn mousepad
<seb128> what -g would change?
<stgraber> kenvandine: ping
<doko> get a backtrack which you could look at?
<kenvandine> stgraber, pong
<stgraber> kenvandine: Currently reviewing https://code.launchpad.net/~vanvugt/ubuntu/natty/light-themes/fix-772972-natty/+merge/70667 but don't know much about the design stuff, is that something we want in natty as an SRU?
<seb128> doko, right, I could fix an issue in the default installation that most users will run into or debug something nobody use...
<doko> seb128, then we should remove it. agreed?
<seb128> not that I don't like epiphany-browser but be realistic most users run firefox and chromium
<kenvandine> stgraber, i haven't seen the bug... but it might be worthy of a SRU
<kenvandine> jitters sound annoying
<seb128> doko, well I personally don't care enough to spend my time on it but others might do
<seb128> so I will not speak for them there
<doko> ok, removing
<seb128> we should let them a chance to fix it if somebody cares enough to step for it
<seb128> ok
<seb128> doko, you will probably not make friends over it ;-) I would rather let people who care another week chance to fix it
<doko> seb128, I disagree. the bug report was filed a month ago. there is no reason why we cannot reintroduce the sources again
<seb128> doko, well your call, I've nothing to do with it ;-)
<micahg> doko: post-release, it's easier if the sources are there already
<doko> besides syncing in the first place :-/
<micahg> it's not like it's abandoned upstream
<seb128> doko, I synced a debian revision with no code change, we would have got the same issue without that sync
<seb128> -1 built, -2 doesn't without code change
<seb128> it's something else which changed
<seb128> it would have showed up in your rebuilt test
<doko> seb128, and you din't care about the build results
<doko> repat loop on
<doko> repeat even
<seb128> how that has to do with the issue?
<seb128> you would have got the same issue if -2 wouldn't have been synced
<stgraber> kenvandine: ok, diff looks reasonable and the change seems to be in Oneiric (though a lot more changed so not too easy to check). I'm going to sponsor that and get more testing once it's in -proposed
<doko> seb128, expose the issue months earlier, and not hiding with "let's wait one more week"?
<seb128> well if anything the sync exposed the issue earlier
<seb128> because it failed to build at the sync, not in an archive rebuilt later on
<smoser> slangasek, around ?
<slangasek> smoser: hey there
<smoser> i'm playing around with a cloud-image booting locally in kvm
<smoser> and after a bunch of poking / digging, i'm seeing stuff like
<smoser> /sbin/dhclient-script: line 73: /etc/resolv.conf.dhclient-new: Read-only file sy
<smoser> chmod: cannot access `/etc/resolv.conf.dhclient-new': No such file or directory
<smoser> can't create /var/lib/dhcp3/dhclient.eth0.leases: No such file or directory
<smoser> oh...
<micahg> doko: FTBFS are SRU worthy, so please just remove the binaries
<smoser> slangasek, i think that network-interface.conf is coming up before / is RW
<smoser> and nothing is enforcing it to wait, although it clearly needs it.
<chrisccoulson> politcally, removing epiphany will be very bad for us btw ;)
<slangasek> smoser: what do you mean, "clearly needs it"?
<smoser> well, if it can't write resolv.conf, then i can't resolve hostnames
<slangasek> network-interface.conf should certainly not be writing to the root fs
<smoser> and i don't want to pass /etc/hosts files around
<smoser> :)
<micahg> chrisccoulson: right :)
<seb128> yeah, removing epiphany would be an error
<slangasek> smoser: what's writing to /etc/resolv.conf?  That's not the standard behavior of ifupdown
<smoser> dhclient is
<slangasek> smoser: God forbid
<smoser> dhclient is getting called on the add of eth0
<smoser> which is happening before / is rw
<slangasek> smoser: no, dhclient does not write to /etc/resolv.conf either; it'll be some hook script called by dhclient in /etc/dhcp3/dhclient-{enter,exit}-hooks.d - and not a standard one
<smoser> well... i dont knwo about not a standard one
<ScottK> jbicha: One of the changes in http://launchpadlibrarian.net/80663925/yelp-tools_3.1.6-0ubuntu1_3.1.7-0ubuntu1.diff.gz is that it now refers to files in /opt/gnome.  That seems "bad".  Would you please double check this.
<slangasek> smoser: point is, writing this to /etc/resolv.conf is *wrong*, and whatever is doing that is *buggy*.  If something wants to provide interfaces for managing resolv.conf dynamically, it should be symlinking this file to somewhere in /run and managing it there
<smoser> i'll see what i can find, but there is nothing in the image that is not in main.
<seb128> ScottK, is that an autogenerated file? i.e one that will be overwritten on build? it's often the case with GNOME components
<slangasek> it is not correct to wait for writable root before bringing up the network interfaces - in some configurations, / may never be made writable
<smoser> slangasek, well, its /sbin/dhclient-script that is writing it
<smoser> isc-dhcp-client
<seb128> doko, chrisccoulson, micahg: seed 3.2 builds fine it seems, I will upload it
<smoser> depended on by isc-dhcp-client and ubuntu-minimal
<smoser> errr... well not depnedend on by itself, but by ubuntu-minimal
<smoser> why exactly i have ubuntu-minimal installed i'm not sure.
<slangasek> because it's not an Ubuntu system without ubuntu-minimal? :)
<slangasek> so I'm surprised that isc-dhcp-client is doing this... let me dig into the history and get back to you
<smoser> slangasek, so how would you think i should get entries in resolv.conf on a dhcp system ?
<ScottK> seb128: I don't know.  It's possible.
<ScottK> seb128: I don't know much about Gnome stuff, but the diff seemed worth a second look.
<seb128> ScottK, well I didn't look at this one but it's 99% chance
<ScottK> OK.
<ScottK> I'll accept it then.
<seb128> thanks
<slangasek> smoser: /etc/resolv.conf should be a symlink to somewhere managed in /run
<slangasek> smoser: which *used* to be how we did this; I don't understand why we've regressed here
<smoser> hmph.
<smoser> on my sys, i have resolvconf managing it so it is a symlink, but i know on installation i it complains it is not a symlink and I end up fixing it.
<smoser> slangasek, but in the non-dhcp case, then, what would be managing resolv.conf ?
<seb128> doko, ok, seed 3.2 uploaded and in approved, it builds fine there
<seb128> the new version is part of GNOME and has a small diff so it shouldn't need a feature freeze exception
<slangasek> smoser: well, that's a question - I don't have an immediate answer for you.  I can just say that architecturally, assuming /etc/resolv.conf should be managed in-place is wrong :)
<slangasek> smoser: btw, /sbin/dhclient-script has a loop that waits for / to become writable... is that not working?
<smoser> must not be working
<slangasek> smoser: does your /etc/fstab not have a line for the rootfs?
<smoser> LABEL=cloudimg-rootfs              /               ext4    defaults        0
<smoser>  0
<slangasek> should work
<smoser> nope
<smoser> oh.
<slangasek> *should* work :)
<smoser> yeah, it should
<smoser> slangasek, yeah, that loop seems sane
<smoser> i'll poke more at this later.
<slangasek> smoser: ok... I'll continue poking at the history to see where things have gone astray, and see what we can do about getting this all properly architected for p
<smoser> interestingly, if /etc/resolv.conf *were* a symlink to /run, it would sit and wait until root is rw
<smoser> it waits for '-w /etc/'
<slangasek> yep
<smoser> later.
<slangasek> enjoy :)
<smoser> thanks for your help, slangasek
<micahg> seb128: will epiphany 3.0 work with it though?
<seb128> micahg, there is like 25 commits between 3.0 and 3.2 and mostly translation updates and bug fixes, so I guess so
<seb128> micahg, if not we will fix epiphany
<jtaylor> doko: glib2.0 fails to build with APPEND {CFLAGS,LDFLAGS} -flto (binutils 2.21.53.20110810-0ubuntu3 with PR ld/13201 "fixed")
<jtaylor> http://paste.ubuntu.com/695329/ bug should get filed soon by the guy who found it
<jtaylor> is flto still not ready for general use or could this be an as-needed related bug?
<doko> jtaylor, is this with the glib2.0 in the archive?
<jtaylor> yes
<jtaylor> 2.29.92-0ubuntu1
<jtaylor> its weird ldd -r libglib.so does not list any undefined references
<doko> in general, anything else than -g -O2 (distribution defaults) should be handled by the package maintainer
<jtaylor> those functions are connected to FORTIFY_SOURCE or?
<doko> jtaylor, please check with -U_FORTIFY_SOURCE if you can
<jtaylor> running
<jtaylor> ok now I get this: /tmp/glib2.0-2.29.92/./glib/tests/mem-overflow.c:137:1: sorry, unimplemented: gimple bytecode streams do not support the optimization attribute
<jtaylor> but it got past the linking issue from before
<doko> I'll look at it tomorrow, but not now
<jtaylor> no problem thanks
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Beta 2 Freeze | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<jtaylor> bug 856839
<ubottu> Launchpad bug 856839 in glib2.0 (Ubuntu) "libglib2.0-0 fails to build using dpkg-buildpackage when added "-flto" to CFLAGS and LDFLAGS" [Low,Confirmed] https://launchpad.net/bugs/856839
<Sweetshark> Hi all. I have a question about bug status handling: Could somebody have a look at https://bugs.launchpad.net/df-libreoffice/+bug/745836/comments/51 and give me an opinion/judgement before that escalates into a bug-state-war? (asking here because ubuntu-bugs is silent)
<ubottu> Ubuntu bug 745836 in libreoffice (Ubuntu) "soffice.bin crashed with SIGSEGV in cppu::throwException()" [High,Confirmed]
* infinity changed the topic of #ubuntu-devel to: Beta 2 Released | Archive: Feature/UI Freeze | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Viper550> Hello
<bdrung> tumbleweed: $ syncpackage ubuntu-dev-tools
<bdrung> syncpackage: Error: Debian version 0.132 does not exist!
<Laney> https://launchpad.net/debian/+source/ubuntu-dev-tools
#ubuntu-devel 2011-09-23
<micahg> Sweetshark: I'd suggest discussing with tyhicks about ecryptfs and how likely it is to be impacting this bug
<tyhicks> micahg: Good suggestion - I've read through it and don't have any good ideas about what eCryptfs could be doing incorrectly
<tyhicks> Digging in deeper is next on my todo list
<micahg> tyhicks: sweetshark is in UTC +2 I believe, maybe you could chat with him at some point
<Laibsch> Sweetshark: My opinion (which I've already given you in private before) is that you've been trying too aggressively to "close the ticket" and get it off your radar.  When what should really be done is analyze and fix the problem.
<Laibsch> Sweetshark: Case in point: Your recent setting to invalid state for the office package when no matter what ecryptfs does or doesn't do, a program should never segfault.  Or your closing as wontfix without any explanation.  You're doing better with the latest comments and explanations.
<Laibsch> Sweetshark: thank you for the work you're doing. Much appreciated.
 * Laibsch is one of the affected people and in UTC+8
<tyhicks> Laibsch: hello - upstream eCryptfs kernel maintainer here
<Laibsch> I know
<Laibsch> I'm the 50G/140G false positive guy ;-)
<tyhicks> Laibsch: I tend to agree - since eCryptfs isn't oopsing or falling completely on its face, it sounds like something that could be handled better in userspace
<Laibsch> so we meet again (we can talk privately if you want)
<tyhicks> Laibsch: ah, that's right :)
<Laibsch> the problem is 100% reproducible for me.  So, if you can cook up something to collect data, I'm here.
<tyhicks> Laibsch: I've looked through the report and traces provided and I didn't see much to work off of
<tyhicks> Laibsch: I think I'm going to need to reproduce it locally (I haven't had a chance to try yet) and then start poking from there
<tyhicks> Laibsch: I really appreciate the offer and will keep it in mind
<Laibsch> tyhicks: Yes, best is of course if you can reproduce it locally.  But apparently Sweetshark had some trouble doing that.
<Laibsch> tyhicks: I find that Ian guy a bit of a pain in the ... but he says he can reproduce file corruption (comment 53).  Whether that's the root cause of the crashes or even a false claim, I don't know.  But maybe he can give you some valuable data as well on supposedly ecryptfs-induced file corruption.
<tyhicks> Laibsch: Yeah - just read that comment... I'll definitely have to follow up on that claim
<Laibsch> would it help if I ran Office through valgrind?
 * Laibsch wonders what upstream discussion Sweetshark was referring to
<Laibsch> probably http://nabble.documentfoundation.org/Multiple-issues-with-cppuhelper-source-exc-thrower-cxx-td2992234.html
<smoser> slangasek, heres a strange (to me) console log http://paste.ubuntu.com/695394/
<lamont> I wonder, how do I get do-release-upgrade to _NOT_ run screen?
<micahg> why would you want that?
<lamont> because the serial console hates screen
<smoser> slangasek, ok. i opened bug 856984.  i know whats wrong, and *a* fix is fairly straight forward.
<ubottu> Launchpad bug 856984 in isc-dhcp (Ubuntu) "dhclient-script attempts to write /etc/resolv.conf before it is writable" [Undecided,New] https://launchpad.net/bugs/856984
<lamont> seems that removing screen fixes the issue
<smoser> nice
<TheMuso> /c/c
<ScottK> Man, where's barry when you need him.
 * ScottK wanted to see him headdesk: https://github.com/whymirror/unholy
<infinity> ScottK: That's vile.  And a thing of beauty.
 * ScottK thinks barry will love it.
<StevenK> Or he will claw his eyes out.
<micahg> reminded me of this: http://www.linuxjournal.com/article/9282
<ScottK> Entertaining either way.
<broder> you guys have seen perl's Inline::C and Inline::Python, right?
<broder> (well, s/perl/CPAN/)
<infinity> Inlining is a bit different than this python/ruby translation madness.
<StevenK> I've *used* Inline::Python.
<infinity> I'm reminded of Facebook's PHP-to-C compiler.
<StevenK> It's utter crack.
<broder> infinity: but similarly terrifying :)
<didrocks> good morning
<ScottK> Good morning.
<ScottK> didrocks: Bad news on the Qt front ...
<ScottK> It looks like it's going to fail on armel (already did on powerpc)
<ScottK> With that bit of joy, I'm off to bed.
<ScottK> Have a nice $TIME_OF_DAY.
<didrocks> ScottK: argh, ok, I'll try to have a look
<ScottK> Thanks.
<didrocks> ScottK: have a good night :)
<lucas> doko_: libdb-ruby was entirely superseded by ruby-bdb, it just needs decruft to disappear
<dholbach> good morning
<doko_> lucas, right seen now. but the source is still in unstable too (and libcairo-ruby)
<tkamppeter> pitti, hi
<doko_> mvo, slangasek: I think the break is correct (bug 853688), but I could remove it as well, if it cannot be addressed otherwise
<ubottu> Launchpad bug 853688 in gcj-4.4 (Ubuntu Oneiric) "Natty to Oneiric - failed to calculate the upgrade with gcj-4.4-jre installed" [High,Triaged] https://launchpad.net/bugs/853688
<mvo> doko_: sorry, I haven't had a chance yet to properly look at this
<doko_> SpamapS, barry: could you have a look at bug 771121? the easiest way would be to disable the python3 package
<ubottu> Launchpad bug 771121 in gearman-interface (Ubuntu Oneiric) "gearman-interface version 0.13.2-2build2 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/771121
<TLE> pitti: hallo, I was wondering if you have a few minutes for some language packs?
<bryceh> TLE, think he's on vacation currently
<tkamppeter> I have uploaded a new HPLIP package which fixes bug 560849 with a tiny patch. The package hangs in the "wait for approval" queue. Can someone approve it (is beta2 not unfrozen yet?).
<ubottu> Launchpad bug 560849 in hplip (Ubuntu) "hpfax crashed with NameError in bug()" [Undecided,Fix committed] https://launchpad.net/bugs/560849
<seb128> tkamppeter, we don't unfreeze
<TLE> bryceh: ok, do you know who might be filling in for him on stuff like copying newly generated language packs to a proposed repository?
<seb128> tkamppeter, uploads until Oneiric need to get reviewed
<tkamppeter> seb128, do I need to do anything special for the uploads to get reviewed?
<seb128> tkamppeter, no
<seb128> tkamppeter, they will just be regularly reviewed when release team member look at the queue
<bryceh> TLE, seb128.
<TLE> bryceh: thanks
<seb128> heh
<TLE> ahh, you got volouteered there
<TLE> *G*
<seb128> TLE, better to wait for pitti to be back, he will be back for monday for sure but it's likely he will be around before that so if you need anything important drop him an email I guess
<TLE> well, we are trying to release language pack updates according to a schedule, so that translators know what they have to aim for, and that isn't much good if we keep postponing them. In any case, I'll talk to dpm first and see what he thinks and then maybe I'll be back later
<TLE> seb128: ^"
<seb128> TLE: ok, if pitti get online during the day I will ping him about it, I've no real clue how the langpacks work and how to do the copy so I would prefer for him to do it
<TLE> I already pinged him, I can talk to him about it and them we'll bug you if necessary ;)
<dpm> TLE, let's have a chat later on in the day about langpacks if that works for you
<TLE> dpm: absolutely, in the office all day
<dpm> cool, thanks TLE
<TLE> no worries
<doko_> pitti: bad pittivi FFe ;-P
<soren> pitti: Any idea why the libvirt package in lucid-proposed hasn't propagated to -updates?
<cjwatson> bug 823638 hasn't been marked v-done
<ubottu> Launchpad bug 823638 in libvirt (Ubuntu Natty) "Please put comment in /etc/default/libvirt-bin or remove it from the .deb" [Undecided,Fix committed] https://launchpad.net/bugs/823638
<cjwatson> which may be trivial from that bug description; I'm just reading the dashboard
<soren> Oh, I see.
<ScottK> janimo: The glmark2 package you uploaded seems very much like it's not just bug fix only, so I'm going to reject it.  Please coordinate with the person you're sponsoring for (Alexandros Frantzis) and follow the FFe process.
<Daviey> Any AA's around that can promote an approved MIR please?
<janimo> ScottK, it is sponsoring by alf_ via pm request this morning
<ScottK> janimo: Right.  I'm not saying who needs to fill out the FFe, but you're the one that's supposed to know about such things.
<janimo> ScottK, honestly had no idea FFE applies to universe
<ScottK> OK.
<ScottK> It applies to the entire archive.  It always has.
<ScottK> Lesson learned I guess.
<janimo> always? Even for GNOME components?
<soren> Everything that doesn't have a standing exception.
<Daviey> janimo: Are you thinking of feature defintion freeze?
<Daviey> That doesn't apply to universe.
<janimo> Daviey, not sure about the naming. Thinking along the lines, of blanket exception for universe packages where upstream collaborates closely with Ubuntu (e.g linaro in this case) and where they know what they're doing
<janimo> soren, yes, I assumed there was a standing exception for universe
<Daviey> https://wiki.ubuntu.com/StandingFeatureFreeze
<Daviey> Hardy :)
<Daviey> janimo: No, standing applies to packages or groups of, not whole components. :o
<janimo> Daviey, what does it take to add a new group there? A lot of Linaro stuff - on a different schedule than ours - keeps happening after our freezes. For ARM users and devs it helps to get access to these via the official archives
<janimo> not talking about landing new kernels/bootloaders which can break stuff, but universe apps
<Daviey> janimo: A blanket standing exception to the release team via a bug of nominated packages, and who is responsible for making sure they are kosher.
<janimo> ScottK, https://bugs.launchpad.net/ubuntu/+source/glmark2/+bug/857279
<ubottu> Ubuntu bug 857279 in glmark2 (Ubuntu) "FFE for Oneiric" [Undecided,New]
<Daviey> janimo: https://wiki.ubuntu.com/FreezeExceptionProcess should be a good guide
<Daviey> janimo: That bug really needs more detail
<janimo> asac, rsalveti see what Daviey says above. You may want to add this to the discussion at UDS
<cjwatson> janimo: freeze doesn't mean you can't upload stuff, it just means it requires some thought
<cjwatson> Linaro does too much core stuff for me to be comfortable with a standing feature freeze exception for everything they do
<cjwatson> for universe applications, I'd have thought that we could easily just work case-by-case?
<janimo> cjwatson, no core stuff, no kernel/bootloader/X is sane to upload with features at this point. I was talking about blanket for the sundry apps/tests/tools they do that affect hardly anyone but ARM users
<janimo> Daviey, I'll ask alf I merely sponsored him, have no idea what is in the new release
<Daviey> janimo: Are you talking features or bugs?
<Daviey> I mean, if you are fixing FTBFS's on arm for example, that wouldn't need a FFe.
<janimo> Daviey, features but for fringe apps
<janimo> sure, bugs  I know
<htorque> soren: hi! are you currently testing the suggested patch at https://bugs.freedesktop.org/show_bug.cgi?id=41059 ?
<ubottu> Freedesktop bug 41059 in Driver/intel "XRANDR operations very slow unless (phantom) HDMI1 disabled" [Major,New]
<janimo> Daviey,  universe apps which do not affect non-ARM images
<janimo> and mostly developer stuff
<Daviey> janimo: Something that adds weight is that those working on it will /use/ it before release to spot regressions, and committing to fixing them.
<Daviey> for example, we decided not to update to the latest qemu as we knew that if it did go bang - we'd not have the time/resources to fix it.
<Daviey> although slangasek is thinking about doing that for qemu-linaro :)
<janimo> Daviey, I sure hope Linaro uses their tools. They use PPA's a lot so they are not much pressured to upload or do not know the hops that need to be jumped through
<janimo> Daviey, QEMu breaking would mean the whole cloud/server things being affected, very different :)
<janimo> glmark2 having a regression? pfft
<janimo> anyway something to discuss with the Linaro guys at UDS
<ogra_> janimo, well, its our job to care for the archive and get the bits into it
<ogra_> i dont think there is much to discuss
<Daviey> Yeah, too much policy/hoops can make people choose not to bother :(..  Having done a few FFe's, it becomes a reasonably fast process.. it's a reasonable balance atm, i feel.
<janimo> they move at a fast pace with their development, monthly releases and PPAs, need to find a good match between their interrests and the fact that we'd also like to ship ARM stuff  that is not too stale
<soren> htorque: Not really :( If someone could toss me a kernel image that I could try, then sure. I'm a bit too busy to sort that out myself right now :(
<ogra_> janimo, in the past we simply used to have a team member in the universe release team
<ogra_> we should probably revive that
<Daviey> ogra_: arm or linaro?
<ogra_> Daviey, ??
<janimo> ogra_, 1) so we could just approve all our FFEs? Nice 2) You are not talking me into becoming that person
<ogra_> lol
<ogra_> Daviey, i'm ubuntu-arm
<Daviey> ogra_: "in the past 'we' had a tam member", who is we?
<Daviey> team*
 * ogra_ doesnt talk for linaro 
<cjwatson> I don't think we should have people who are in ubuntu-release just to approve their team's exceptions
<cjwatson> cross-fertilisation and cross-checking is extremely valuable
<htorque> soren: ok, in that case i'll test it with 3.1-rc7 here. just hope my tailored config is enough to reproduce the bug. don't wanna build a full ubuntu-config kernel.
<janimo> cjwatson, I forgot a smiley there in 1)
<ogra_> cjwatson, well, but having the people knowing the code also reviewing it makes everything a bit easier
<cjwatson> ogra_: certainly having people available is helpful, but I will definitely nack any attempt to add people to the release team simply in order to work around exception requirements
<ogra_> (and not only knowing but being able to verify on HW)
<ogra_> cjwatson, i didnt intend that with the suggestion
<cjwatson> the release team is the Ubuntu release team, not just the Ubuntu ARM release team - I expect team members to be concerned for the health of the project as a whole
<ogra_> we used to do it in the past simply because the process was faster
<ogra_> not because we handled the execptions more losely
<Daviey> ogra_: It should be possible to demostrate a good level of confidence to someone who doesn't understand the issue IMO.
<Daviey> Yeah, i don't think ogra_ is suggesting bypass of process.
<ogra_> oh, sure, i dont say i mistrust anyone :)
<cjwatson> I trust the people involved, but I've found for myself that when you're the person who's acting for the release team for your own team's requests, there is a lot of psychological pressure to say yes despite reservations because you know that your teammates have put a lot of work into this
<doko_> Laney, janest-core, remove or fix it?
<cjwatson> a degree of separation helps to avoid that and can actually reduce stress
<janimo> cjwatson, true.
<ogra_> but it also slows down the process since you need to work yourself into code other know in and out
<ogra_> *others
<cjwatson> I think that's an acceptable price to pay
<cjwatson> anyway, reviewing freeze exceptions doesn't mean a complete code review
<ogra_> indeed
<cjwatson> it's more an assessment of its likely impact and sanity
<ogra_> which an arm person can judge better than a non arm person in this case
<cjwatson> I do not in general agree
<cjwatson> if the ARM person can't explain it in a way that's clear enough for a non-ARM person to understand, I find that questionable
<cjwatson> and non-ARM people are perfectly capable of judging when things essentially only affect ARM and when they may affect other architectures too
<cjwatson> and acting accordingly
<ogra_> well, you save the need for the explanation in that case, indeed one asking for a freeze exception should always be able to explain it to non arm people
<ogra_> (and thats not arm specific at all)
<Daviey> Inverse, unless the package only builds on arm target - can they measure the impact for other arches with confidence?
<cjwatson> I don't agree that saving the need for the explanation is a good thing
<asac> has we/linaro requested a standing freeze exception? :)
<ogra_> lol
<ogra_> no
<asac> ok. got the impression we had from the lines i saw above :)
<cjwatson> where possible, we should be finding points of commonality across architectures, and it's important that (especially) release team people learn the rough parameters of the differences between ARM and everything else
<cjwatson> saying "don't worry, the ARM people will sort it all out and don't need to explain it to you" just encourages siloing
<cjwatson> and I really think it's important to find ways to avoid that
<ogra_> asac, i was only suggesting to have an arm person back in the universe approval team for FFes as we had it in the past
<asac> I think we are happy with the process until we complain. however, we are on a monthly release cadance so keeping process lean for stuff that doesnt risk ubuntu release would make sense
<asac> ogra_: ok i see
<asac> ogra_: any cases of slow turnaround of current team? or "stupid" quesitons of release team because they were not familiar enough with ARM topics?
<cjwatson> tjaalton: can we merge libx11 from unstable (or can I)?  It has a cross-building fix I'd like to have
<ogra_> asac, neither, just janimo not knowing we need FFes for universe that lead to this discussion
<cjwatson> tjaalton: I don't know if you manage it in revision control
<asac> ogra_: ah. that feels is a different problem :)
<tjaalton> cjwatson: i merged it yesterday already
<tjaalton> and uploaded
<tjaalton> appears to be in the archive too :)
<cjwatson> oh :)
<cjwatson> sudo apt-get --reinstall install brain
<cjwatson> thanks
<janimo> asac, exception requests aside, it is not clear what Linaro wants to have in the main archives, if there is such a position at all, or left for each WG/developer to sort it out
<asac> ogra_: I think one thing that could be done better is to what a feature really is ... is it if it changes the the software (current) or rather if it changes the behaviour/featureset availbale in one of the seeds
<asac> better define (or maybe improve) what a feature really is
<asac> but thats just a guts feeling
<cjwatson> well, it's already well-defined that simply changing the software does not amount to a feature
<cjwatson> bug-fixes are fine
<asac> sure
<cjwatson> TBH I've not had any developer enquire what a feature is before :-)
<tjaalton> cjwatson: yeah jcristau mentioned the bug on irc, and later Sarvatt noticed that the fix was uploaded so I merged it right away
<cjwatson> it's just the plain English meaning
<asac> i was meaning: is a package view really what is important or should we rather take a seed/image view to identify if something is a feature worth spending review cycles on
<cjwatson> we certainly do not have anything which ties it to seeds or images, otherwise FFes would be meaningless for universe
<cjwatson> and I think the consensus among universe mavens has been that they want to have a degree of review there
<asac> so xubuntu etc. dont use universe at all?
<cjwatson> well, OK, there are images built out of universe
<cjwatson> but I mean MOTU leaders have historically expressed a preference for having a consistent feature freeze *process* across the board, even if the actual reviews are often pretty rubberstampy for things whose effect is minimal
<asac> right
<Daviey> doko_: thanks for the promotion.
<cjwatson> and I do think it's clearer to be able to just say "if you're adding features after feature freeze, you need an exception" rather than having to figure out whether something is in an image or not
<cjwatson> (which is actually kind of non-trivial for many people to work out)
<asac> true
<doko_> pitti, seb128, didrocks: is there a gnome-shell upload pending?
<seb128> doko_, not sure, I need to check with jbicha when he will be online, the current one is depwaiting on caribou
<seb128> doko_, which he was trying to get in for some time, so not sure if we should wait on caribou on try to reverse the depends on it
<seb128> revert
<seb128> same for pitivi, waiting on jbicha to be online
<ogra_> ogra@horus:~$ echo "FileVersion:     14.0.4756.1000"| sed "/^FileVersion: */!d; s///;q"
<ogra_> echo "FileVersion:     14.0.4756.1000"| sed "/^FileVersion: */dmesg; s///;q"
<ogra_> sed: -e expression #1, char 19: extra characters after command
<ogra_> wow, wher does that autocompletion come from ?
<ogra_> *where
<cjwatson> ogra_: history expansion
<sladen> ogra_: the  '!'
<cjwatson> ogra_: use single quotes instead; you have no need for double-quote expansion there
<ogra_> intresting
 * ogra_ doesnt actually have a usecase for this, i just verified something from the ubuntu-devel ML ... but found it surprising to see what happens :)
<cjwatson> I turn off history expansion on my systems because (a) I find it too annoying (b) I never actually want to use it (c) it conflicts with more useful expansions enabled by extglob
<sladen> ogra_: echo "!emacs"  etc
<cjwatson> so I have 'set +H; shopt -s extglob' in .bashrc
<Laney> doko: I have no idea what that is
<Laney> is there some reason I should?
<ogra_> sladen, heh, that would require that any of my systems has ever seen emacs :) but yeah, i get it
<cjwatson> so for me the command line ogra_ quotes works as presumably intended, but it's not portable
<ogra_> thaks for the exaplanation !
<cjwatson> np
<doko> Laney, I don't know, didn't you fix some other ocaml stuff?
<Laney> probably not intentionally
<Laney> i did once write some ocaml
<cjwatson> doko: you might be mixing up ocaml and haskell
<Daviey> Everytime i forget to sudo a command, i follow it with a "sudo !!" on the next line
<doko> ahh, ok. removing then!
<Laney> I recommend you ask sgnb about it
<Laney> give peace a chance!
<doko> ok, ok ...
<Laney> it looks like something you'd be able to fix if you know what the error means
<cjwatson> Daviey: yeah, I know some people use that - I've got used to up-arrow ctrl-a sudo space enter, and !(...) is such an incredibly useful extended glob expansion that it's worth it
<sgnb> Laney: about what?
<cjwatson> ("any file that does not match these patterns")
<Laney> oh, you're here
<Laney> sgnb: https://bugs.launchpad.net/ubuntu/+source/janest-core/+bug/831106
<ubottu> Ubuntu bug 831106 in janest-core (Ubuntu Oneiric) "janest-core version 0.6.0-3 failed to build in oneiric" [High,Confirmed]
<Laney> doko is on an FTBFS busting exercise
<cjwatson> Daviey: plus the way that if you mistakenly type ! in something it disappears from your history really bugs me
<sgnb> Laney: ah, known issue
<Laney> known fix?
<sgnb> upgrade to latest upstream
<sgnb> but ENOTIME these days
<sgnb> (and there are also dependencies to upgrade)
<Daviey> cjwatson: I can see benefit for using extglob, might start.
<doko> sgnb, so better remove it for oneiric, or will you have a chance to update it
<sgnb> remove it
<doko> ok
<sgnb> (it has been removed from testing, fwiw)
<sgnb> but uninstallability of ocamlgraph is unexpected
<sgnb> I guess a recompilation should fix it
<cjwatson> Daviey: oh, hmm, it looks as though nowadays you can use extglob sensibly even with history expansion turned on, so my (c) no longer applies
<Daviey> bah
<cjwatson> Daviey: this wasn't true in Feb 2003 when I made this change to my .bashrc :)
<Daviey> cjwatson: you've kept the same .bashrc since 2003? crikey.
<Chipzz> 14:13 < sgnb> Laney: ah, known issue
<Chipzz> oops
<cjwatson> Daviey: no, but I've had it in revision control since 2002 :)
<Chipzz> I hate it when you select sth and just when you copy the terminal scrolls under you
<cjwatson> certainly a linear descendant; I see no reason to rewrite it ...
<Chipzz> 14:13 < cjwatson> Daviey: plus the way that if you mistakenly type ! in something it disappears from your history really bugs me -> this indeed, I hate that you have to copy/paste the original command and fix it
<Daviey> My rule of thumb is that .bashrc should be younger than your current underwear.
 * cjwatson spots a cloud person
<Laney> ah indeed, I'll see about rebuilding ocamlgraph frama-c
<cjwatson> (please tell me you don't store your underwear in the cloud)
<sgnb> Laney: ocamlgraph should definitely be recompiled (and has been since lablgtk2 was upgraded)
<Chipzz> cjwatson: at least it's dry-cleaned that way ^^
<doko> Daviey, iiuc ScottK, bug 831121 and bug 831179 are on the server radar?
<ubottu> Launchpad bug 831121 in dovecot-antispam (Ubuntu Oneiric) "dovecot-antispam version 1.4~rc3-1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831121
<ubottu> Launchpad bug 831179 in dovecot-metadata-plugin (Ubuntu Oneiric) "dovecot-metadata-plugin version 0.0.1~hg144-0ubuntu1 failed to build in oneiric" [High,Confirmed] https://launchpad.net/bugs/831179
<sgnb> Laney: and maybe frama-c as well, but I'd wait for ocamlgraph to be installable again
<Laney> aye
 * Laney is familiar with the dance
<Daviey> doko: dovecot-antispam wasn't
<Daviey> thanks
<Chipzz> cjwatson: IMO a "blog your .bashrc/.vimrc/.screenrc" meme would be interesting and useful :)
<Chipzz> especially from debian/ubuntu developers
<cjwatson> there was a point in job[-1] when my .vim directory was simultaneously stored in CVS and Subversion
<cjwatson> that was exciting
<Chipzz> exciting? sounds confusing instead
<Laney> scary
<Laney> I just got a prompt which just said "Password: " and kept respawning when dismissed
<Nafai> Chipzz: I keep meaning to blog about my .bashrc and .emacs.d; both are set up to dynamically handle being on multiple machines and custom parts on each
<Chipzz> Nafai: I recently fixed my .vimrc to work with vim-tiny
<Chipzz> I was getting annoyed at vim-tiny throwing sh*tload of errors upon starting with my .vimrc
<Chipzz> (first thing I do when I install a new machine is wget my .vimrc, but I sometimes forget to replace vim-tiny with regular vim)
<cjwatson> I used to have shell configuration which was capable of setting up a sane terminal configuration on all of Linux, HP-UX, SunOS, UnixWare, and IRIX, and various bits in ~/bin/ to try to smooth over the more annoying differences
<cjwatson> (the current /usr/bin/which on Debian/Ubuntu actually descends from that)
<Chipzz> http://chipzz.safehex.be/docs/vimrc | http://chipzz.safehex.be/docs/bashrc | http://chipzz.safehex.be/docs/screenrc
<Chipzz> hrrrrm my .bashrc is missing some useful stuff
<Chipzz> http://chipzz.safehex.be/docs/bashrc | http://chipzz.safehex.be/docs/sshrc
<Chipzz> [ "$SSH_AUTH_SOCK" ] && export SSH_AUTH_SOCK=$HOME/.ssh/@`hostname -s`.agent
<Chipzz> that in conjunction with my .ssh/rc is a nice way of getting screen and ssh agent forwarding to work together
<Chipzz> (but keep in mind to set proper permissions on ~/.ssh !)
<dholbach> can somebody moderate my mail through u-d-a?
<hallyn> kees: hey, regarding the lvm udev rules, you said in email there were specific reasons you had to do it how you did - are those documented, and are there testcases?
<hallyn> smb: when you say 'pkill of udev was a problem on xen guests and had to be redone' - you mean udev didn't really die?
<smb> hallyn, On the attempts I did it at least did not immediately. So there I had a loop re-doing pkill untill no udev was to be seen anymore
<smb> hallyn, Maybe bashing it repeatedly with that hammer was not neede dand it was just waiting for all the numerous helpers to be done
<hallyn> smb: well you're not doin gpkill -9 right?  I assume it was hanging for the same reason it sometimes hangs with udevadm control --exit
<hallyn> smb: what kills me is anytime i try to have udevd print out the list of pending events, i can't reproduce it :)
<smb> hallyn, I think there were two problems there: 1. it not getting done with what it was doing when next steps were tried and 2. it never get done (this seems to still happen sometimes with --exit, I was trying to have some dumps of that but xen pv dumps were broken (maybe because of my pvgrub))
<smb> hallyn, And yes, a pretty Heissen-bug
<hallyn> makes me feel like i wasted the afternoon, btw
<hallyn> smb: are you working that bug today?
<smb> hallyn, No its sort of on a backlog
<hallyn> k
<hallyn> smb: with xen, is there a way from the host to slow down (renice) the backign store process separately from the domain itself?
<smb> hallyn, If there is I don't know of one. It seemed to happen relatively reliable on some boots on my server
<smb> But I yet, have to confirm whether the dumps would be usable in crash now with the new pvgrub I got
<hallyn> ok, thx smb.  ttyl
<ScottK> barry: I ran across something yesterday I thought you'd love: https://github.com/whymirror/unholy
<barry> ScottK: oh wow
<doko> ScottK, please could you have a look at the patch in bug 770975? still ftbfs for me ...
<ubottu> Launchpad bug 770975 in mm3d (Ubuntu Oneiric) "mm3d version 1.3.7-1.2 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/770975
<ScottK> doko: Seems mostly OK, but hard codes multi-arch paths.  I think slangasek should review.  I'm sure he'd know the best way.
<cjwatson> mvo: do you have any updated assessment of whether porting update-notifier to libappindicator might be feasible for oneiric (bug 779382)?
<ubottu> Launchpad bug 779382 in unity (Ubuntu Natty) "update-notifier not visible under unity" [High,Triaged] https://launchpad.net/bugs/779382
<cjwatson> mvo: also I don't suppose you've managed to get anywhere with bug 848659 ...
<ubottu> Launchpad bug 848659 in update-manager (Ubuntu Oneiric) "Upgrade from natty fails with 64-bit oneiric beta cd" [High,Confirmed] https://launchpad.net/bugs/848659
<kees> hallyn: not very well documented, but the reasoning was to bring up a root-on-lvm-on-md system without races. the testcase was that my system boots. :)
<mvo> cjwatson: let me check
<Nafallo> cjwatson: hi there. was just looking at bug 736743. would it be appropiate to hide the error message from 11.10 you reckon? just comment it out sort of thing.
<ubottu> Launchpad bug 736743 in grub2 (Ubuntu Oneiric) "environment block not implemented on btrfs" [Wishlist,Triaged] https://launchpad.net/bugs/736743
<cjwatson> Nafallo: uh, maybe, I'm not in general comfortable with that approach but would need to look
<cjwatson> I mean, it does genuinely cause limited functionality
<didrocks> cjwatson: I just tried ubuntu-defaults-image with a local --package option. Like ubuntu-defaults-image --package ~/work/isofr/ubuntu-defaults-french_0.1_all.deb. I'm under the impression that despite the package having been copied to config/chroot_packages/, this one wasn't installed in the chroot (I don't see it), and so, all the localization failed.
<slangasek> doko: 853688> well, we also don't know if dropping the breaks on libgcc1 is sufficient... if we have to drop the breaks from both libgcc1 and libc6-dev to get apt to solve it, maybe we want to try a different way
<Nafallo> cjwatson: nope. it's just an obstacle in the experience. people notice it, and I bet the splash would come up faster without the message getting displayed.
<cjwatson> Nafallo: pretty sure it makes sod-all difference to speed
<didrocks> cjwatson: PACKAGE and PACKAGENAME are correct though, and all the sedding as well, I'm not familiar with lb, does lb config really need to be called before copying those package? (and then lb build should do the right thing?)
<Nafallo> cjwatson: heh, you might be right. I'm happy to clock the difference if you want to give it a go :-)
<cjwatson> didrocks: well, lb config *is* called before, isn't it?
<cjwatson> didrocks: and yes, pretty sure it needs to be
<didrocks> cjwatson: indeed, ok, so not that, I don't see any log of the package being installed
<mvo> cjwatson: I'm on it, seb128 is a great help
<mvo> cjwatson: on the indicator stuff
<cjwatson> didrocks: it ought to work from what I can see - can you file a bug with a log?
<didrocks> mvo: cjwatson: FYI, update-notifier should be visible in unity since beta2, I whitelisted it
<cjwatson> mvo: great, thanks
<cjwatson> didrocks: yeah, I noticed that, but not unity-2d right?
<didrocks> cjwatson: sure, doing that
<didrocks> cjwatson: unity-2d as well
<didrocks> at least, was working when I tested it
<didrocks> (if you turn the right gsettings options of course to get update-notifier showing its icon)
<mvo> didrocks: ? awsome
<cjwatson> oh, right, I missed that that task had been marked Invalid
<mvo> didrocks: so the fix is actually not that urgent anymore? that is good news and may safe my friday
<didrocks> there is a bug about glitches in the icon rendering, but it's rather it being big that hidden (and only under unity): bug #856125
<ubottu> Launchpad bug 856125 in unity (Ubuntu) "update-notifier systray icons showed and the wrong place and size" [Medium,Triaged] https://launchpad.net/bugs/856125
<didrocks> mvo: yeah, you can enjoy your week-end and it's just a "nice to have" now  :)
<didrocks> cjwatson: if it's considered as a security issue, we should whitelist it in natty as well btw
<cjwatson> we should either whitelist it or port it there, yes
<didrocks> port it for natty? doesn't it sound risky? (whitelist is just a gsettings key away, not that I found the WMCLASS)
<hallyn> kees: i kinda wish boris was to be found here on irc :)  I don't know how far he's gotten in looking at this
<smoser> slangasek, would you consider the trivial patch to bug 856984 for oneiric ?
<ubottu> Launchpad bug 856984 in isc-dhcp (Ubuntu) "dhclient-script attempts to write /etc/resolv.conf before it is writable" [Undecided,New] https://launchpad.net/bugs/856984
<hallyn> ppetraki: do you have a root-on-lvm-on-md system we'd be able to use as  a test for whether oneiric with new udev-lvm rules works?
<ppetraki> hallyn, readily available, no, but I can spare a blade for you.
<cjwatson> didrocks: yeah, agreed
<slangasek> smoser: I think your { } are redundant and should be dropped, but otherwise yes, I think that looks sane
<smoser> they're not redundant
<smoser> to avoid the error of failed write going to stderr
<smoser> you can test if you'd like
<smoser> $ sh -c ': >> /etc/passwd 2>/dev/null'
<smoser> sh: /etc/passwd: Permission denied
<smoser> versus
<smoser> sh -c '{ : >> /etc/passwd; } 2>/dev/null'
<hallyn> ppetraki: ok, thanks.  At this point tbh i'm afraid we have to wait for P to open up, and address lvm2, dmsetup, and udev packages alltogether.
<ppetraki> hallyn, sounds like fun :)
<hallyn> ppetraki: which, i suppose, is really a foundations team thing...
<hallyn> but we can beg to be in the loop :)
<ppetraki> heh
<smoser> i probably *do* uses {} more than other people in shell scripts (especially around variable names), but here they're actually useful
<slangasek> smoser: ah, because the redirect is done by the parent shell, not by :, check
<slangasek> smoser: yes, go for it then
<smoser> well, the {} mean its all one shell
<smoser> no subshell
<smoser> just redirect
<smoser> but yeah.
<smoser> thanks.
<smoser> slangasek, what do you think about the general behavior of '[ -w file ]' not working during a remount,rw ?
<didrocks> cjwatson: bug #857494 FYI
<ubottu> Launchpad bug 857494 in live-build (Ubuntu) "package in config/chroot_packages/ isn't installed in the chroot" [Undecided,New] https://launchpad.net/bugs/857494
<slangasek> smoser: sounds like a kernel bug to me
<cjwatson> thanks
<cjwatson> smoser: access(3) (which is what that does) has always been a bit wonky
<didrocks> yw :)
<smoser> i suspect it is not a kernel bug, slangasek but user space
<cjwatson> it basically tests the permission bits on the inode
<cjwatson> sorry, access(2)
<slangasek> smoser: I defer to cjwatson
<smoser> yeah, me too
<cjwatson> I think I would want to attempt an actual open(O_WRONLY|O_APPEND) or something in order to tell whether writes are really possible
<cjwatson> oh, and that's what >> does
<jdstrand> doko: heh, thanks for the honor of ubuntu-mir membership :)
<cjwatson> hm, admittedly the man page says:
<cjwatson>        EROFS  Write permission was requested for a file on a read-only file system.
<jdstrand> doko: I guess I need to read up on the MIR docs ;)
<doko> jdstrand, I thought you wouldn't mind :)
<cjwatson> so maybe this is a kernel bug, although I suspect you might find they say the docs are misleading :)
<cjwatson> but you can try asing
<cjwatson> *asking
<doko> slangasek, I'll check with mvo on Monday
<tkamppeter> To the release team: I have uploaded ghostscript -0ubuntu9 and -0ubuntu10, it is important to take -0ubuntu10 as it completes an uncomplete fix in -0ubuntu9 (bug 856766).
<ubottu> Launchpad bug 856766 in GS-GPL "gs crashed with SIGSEGV in gx_num_components_ICC()" [Medium,Confirmed] https://launchpad.net/bugs/856766
<dholbach> can somebody moderate my mail through u-d-a please?
<cjwatson> dholbach: done
<dholbach> thanks a lot cjwatson
<doko> jtaylor, what about the upload for bug 845552?
<ubottu> Launchpad bug 845552 in gfire (Ubuntu) "[FFE] Too old Gfire in repo for use, update version or remove from archive" [Undecided,Confirmed] https://launchpad.net/bugs/845552
<SpamapS> doko: re bug 771121 it actually just needs swig 2.0
<ubottu> Launchpad bug 771121 in gearman-interface (Ubuntu Oneiric) "gearman-interface version 0.13.2-2build2 failed to build on amd64 with GCC-4.6/oneiric" [High,Confirmed] https://launchpad.net/bugs/771121
<doko> SpamapS, could you upload a fix for oneiric?
<SpamapS> doko: in progress :)
<doko> thanks!
<bambee> pitivi is not installable... (it depends on python-gst0.10 >= 0.10.28, this dependency is not found) -> is it a bug or my mirrors are outdated?
<bambee> http://paste.ubuntu.com/695730/
<SpamapS> gst0.10-python | 0.10.21-2ubuntu1 |       oneiric | source
<SpamapS> bambee: archives are up to date
<bambee> 0.10.21 < 0.10.28 :)
<SpamapS> yep
<SpamapS> meaning its a bug
<SpamapS> bambee: I suggest you report it.. I'll raise it to Critical and target to ubuntu-11.10
<bambee> SpamapS: ok
<ScottK> I think that's fixed already
<ScottK> bambee: Check for a newer pitivi.
<SpamapS> oh like, in the last 2 hours? :p
<bambee> ScottK: already tried, nothing changed
<ScottK> Like earlier today.
<bambee> oh
<SpamapS> indeed, uploaded but not done building
<SpamapS>     pitivi | 0.14.91-0ubuntu2 |       oneiric | source
<ScottK> https://launchpad.net/ubuntu/+source/pitivi/0.14.91-0ubuntu2
<seb128> SpamapS, that's the correct version
<bambee> "Fix python-gst0.10 dependency which made PiTiVi uninstallable" <-- indeed, already fixed
<SpamapS> uploaded 2 hours ago
<seb128> it's done building
<bambee> ok, thanks
<SpamapS> bambee: so yeah, your mirror just needs to catch up :)
<bambee> hehe ;)
<jtaylor> 17:50 <doko> jtaylor, what about the upload for bug 845552?  <-- still no upload rights :/
<ubottu> Launchpad bug 845552 in gfire (Ubuntu) "[FFE] Too old Gfire in repo for use, update version or remove from archive" [Undecided,Confirmed] https://launchpad.net/bugs/845552
<ScottK> jtaylor: Is it in the sponsor's queue?
<jtaylor> merge requests are there automatically or?
<jtaylor> yup it is
<ScottK> K.
<tkamppeter> My upload of ghostscript 9.04~dfsg-0ubuntu9 got rejected. Is something wrong with it or is it because I have uploaded the -0ubuntu10?
<seb128> tkamppeter, 0ubuntu10 got accepted to I guess it's the later
<infinity> tkamppeter: What Seb said.
<seb128> tkamppeter, no need to accept a version which is included and deprecated by the next one
<infinity> tkamppeter: I rejected 9 and accepted 10.
<tkamppeter> Not -0ubuntu10 appeares. Thanks and sorry for the noise.
<slangasek> cjwatson: I happened to notice that I have ubuntu-xsplash-artwork installed here, and xsplash seems to be on autopilot since karmic; do you know if this package is still useful or if we should be looking at removing it?
<SpamapS> smoser: nice fix on isc-dhcp-4 .. funny how there can be too very different versions of what "writable" means ;)
<smoser> yeah, i'm wondering if there are other pars of boot that are making similar assumptions/mistakes
<smoser> s/pars/parts/
<broder> i'm still confused why access() would say yes when open() would say no
<SpamapS> you're allowed
<SpamapS> you're just not ABLE
<SpamapS> its like giving a two year old a driver's license. :)
<broder> SpamapS: no, i don't think it's that. smoser's bug report makes it sound like there's actually a race there
<smoser> no
<smoser> its not a race
<smoser> its consistent
<smoser> [ -w file ] says yes, attempt says no
<smoser> and then again
<smoser> and then both say yes
<broder> oh, i see. [ -w ] returns yes when it's ro?
<smoser> i suspect that what is happening is this:
<smoser>  a.) mount is read-only (at which point both say 'not writable')
<smoser>  b.) mountall invokes 'mount()' system call for remount,rw
<smoser>  c.) [ -w file ] says "YES", but attempts to actually write fail
<smoser>  d.) kernel finishes actually making filesystem rw
<smoser>  e.) [ -w file ] says yes, attempts to write succeed
<broder> right. and my question is why are the paths that access() and open() take sufficiently different that (c) is even possible
<smoser> window between b and d is very small, i'm only seeing it here because i'm using qcow compressed image that is freaking crazy slow read and write
<smoser> broder, well, cjwatson's comment was that 'access()' has always been 'a bit wonky'
<broder> yeah, that just seems unfortunate and error-prone. even if we audit for things that depend on access() actually working, that doesn't solve the problem in the long term
<broder> and it's just another thing we have to add to the list of "weird unix arcana that will bite you in the rear one day"
<smoser> i recall having seen issues like this with nfs also
<broder> i can accept network filesystems as being a special case
<broder> maybe the better solution would be to change bash to implement -r, -w, etc. using open directly
<broder> since i don't actually think people use access() that often from C
<smoser> broder, the issue with open is that actually has side affects
<smoser> even if file exists, you would be updating ctime.
<broder> there's a O_NOATIME at least, but yeah, i guess you can't prevent it from affecting ctime
<smoser> well, and you'd actually be creating it
<smoser> if it did not exist
<broder> only if you pass O_CREAT
<smoser> but if the file did not exist, how would you know if you could write to it using open unless you passed O_CREATE?
<smoser> access() i think is supposed to say "yeah, you could potentially create that file"
<cjwatson> slangasek: I think we should probably kill it though I'm not certain
<cjwatson> access() from C is pretty common
<cjwatson> I think it's probably better to fix access(), I just don't know whether it's sanely possible
<SpamapS> Somebody remind me.. a Breaks + Replaces will cause dist-upgrade to remove the broken/replaced package and install the new one, right?
<micahg> SpamapS: it should and generally, breaks/replaces is versioned
<SpamapS> indeed
<slangasek> SpamapS: to be sure, it causes the broken/replaced package to be removed when upgrading or installing the breaking package; if the breaking package is not already going to be pulled in, having the breaks/replaces doesn't cause a dist-upgrade to pull it in
<SpamapS> slangasek: right.. hm
<SpamapS> slangasek: if I have a Provides does that force dist-upgrade's hand?
<slangasek> SpamapS: nope
<infinity> SpamapS: Provides doesn't imply a Conflict.  What are you actually trying to achieve?
<slangasek> SpamapS: generally for that, you add a transitional package with the name of the old one
<slangasek> or you make your metapackage depend on the new one or something
<slangasek> smoser: how reproducible is bug #833783?  this is going to take some iterating
<ubottu> Launchpad bug 833783 in initramfs-tools (Ubuntu Oneiric) "boot failure: can't open /root/dev/console: no such file" [High,Confirmed] https://launchpad.net/bugs/833783
<smoser> slangasek, hm..
<smoser> unfortunately, i dont really know.
<smoser> i would have told you it was on the order of 1/30
<smoser> but the last set of tests, i believe that I saw a failure where the kernel rebooted itself.
<smoser> ie, as if i a watchdog kicked in.
<smoser> i didn't think that i'd seen that behavior before
<smoser> but if that is happening, then we may be hitting it more than i thought, and i just didn't know it.
<smoser> i know. that wasn't very helpful.
<slangasek> smoser: ok.  basically, my *suspicion* is that we're racing udev because the initramfs has so little to do that it gets to the bottom faster than udev can blink; but I'd like to be able to verify that
<smoser> that makes sense.
<slangasek> smoser: you could test this by adding [ -e /dev/console ] || udevadm settle to /usr/share/initramfs-tools/scripts/init-bottom/udev and testing
<smoser> is /dev/console always the same major minor?
<slangasek> if that works, it's probably the same as our other udevadm --exit bug
<slangasek> (*probably*)
<smoser> or does it depend on platform....
<slangasek> I think it's always the same major/minor
<slangasek> so yes, this could be hacked around with hard-coding
<smoser> if its always 5,1, then just having that in /dev/ would fix this issue
<smoser> right
<smoser> i realize htat is a hack
<slangasek> in fact, you'll see initramfs scripts have code for a mknod fallback already
<slangasek> right at the top of init
<smoser> ok.
<smoser> so we're hitting the bottom, calling udevadm --exit, before udev makes /dev/console
<slangasek> I'm afraid I don't understand this bit of the kernel either, though... can we be sure that /dev/console is always there on the kernel side?
<slangasek> i.e., would mknod be sufficient, or is it possible the kernel itself would throw errors?
<slangasek> I'm to the point where I don't trust devices to really be there until udev tells me they are ;)
<smoser> i'm not certain. but it would surely seem that /dev/console is pretty basic. the kernel has to printk to somewher,e and i always just assumed that was "dev/console"
<slangasek> smoser: but definitely a '[ -e /dev/console ] || udevadm settle' is the first thing to try
<slangasek> oh sure, it's pretty basic
<slangasek> but everything's getting so fast now that we're racing every last bit of the kernel's init code, AFAICS
<smoser> slangasek, https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/682831
<ubottu> Ubuntu bug 682831 in plymouth (Ubuntu Lucid) "lost console output early in boot" [Undecided,Triaged]
<smoser> thats my prior experience with /dev/console, and it not always being there :)
<smoser> oh, but wait, that was a plymouth issue
<slangasek> see! I'm not just paranoid :)
<smoser> never mind that.
<slangasek> ah ;)
<superm1> archive admin, can you please axe the libhdhomerun upload that i just sponsored?  Daviey raised a point that we didn't realize it was in debian and synced from there and we've got a bad delta in the debian/ stuff now for it
<infinity> superm1: Sure.
<slangasek> infinity: too slow
<slangasek> superm1: done
<superm1> thanks slangasek
<infinity> :P
 * ScottK is even more too slow.
<slangasek> :)
<smoser> slangasek, tell ya what.
<smoser> if you can give me a diff of the file to change, then i'll attempt leave a script launching instances on CanoniStack all weekend with and without
<smoser> and see if we see actual improvements
<slangasek> smoser: yeh, diff is in preparation now :)
<slangasek> smoser: so in general, would an initramfsless boot do you guys some good?
<smoser> we've been there
<smoser> and came back
<slangasek> whyso?
<smoser> we dont need an initramfs really. and in lucid, we didn't have it.
<slangasek> the kernel package tooling needs help for supporting the initramfsless case
<smoser> it was a real benefit in it was less things to manage on ec2, where you had to upload a kernel and a ramdisk separately
<slangasek> but that's solvable
<slangasek> and helps with several different problems in parallel
<smoser> but when we moved to using pv-grub, which allowed us kenrel upgrades!!!! i never bothered to fight update-initramfs and the kernel hooks and such to stay a different path.
<smoser> so we got our initramfs back.
<slangasek> the other Good fix for the problems you guys've been seeing in the initramfs is to get event-based initramfs... too bad we didn't make it there for this cycle :/
<smoser> and then, i built a feature or 2 into our cloud initramfs that i'm not likely to want to give up.
<slangasek> hah
<SpamapS> ensemble has been renamed to juju
<SpamapS> to answer the question late
<SpamapS> so we want the bin package to be called juju.. but anybody who has had ensemble up to now we want to get juju to replace it.
<slangasek> SpamapS: right, ensemble dummy package Depends: juju package Replaces:/Breaks: real version of ensemble package is the canonical solution
<SpamapS> slangasek: ty :)
<smoser> slangasek, http://ubuntu-smoser.blogspot.com/2011/07/getting-larger-root-volume-on-cluster.html is a feature that is very useful.
<slangasek> SpamapS: or, if ensemble would always be installed as a dependency of some other leaf package that would be installed, you can just switch the dependency and dispense with the dummy package... but I suspect 'ensemble' will be in the name of the relevant top-level packages :)
<smoser> much less so on ec2, but now on openstack all instances will take that path.
<slangasek> smoser: heh, too bad.  I guess we should regroup on the event-based initramfs question for next cycle then
<slangasek> apw: btw, I think my black screen between grub and plymouth is an initramfs-specific issue... I can reproduce it on my T60, and should have a cryptsetup-less test soon for comparison.  I think either something's missing from the initramfs, or we're again racing udev somehow
<smoser> slangasek, is there a bug open that we consider *the* bug for "udev --exit does not flush queue" ?
<smoser> it seems its coming up more and more often, and i think it is the root of many bugs, but i didn't know if there was one bug that those others should actually be duped to
<slangasek> smoser: bug #818177 is the one I know about
<ubottu> Launchpad bug 818177 in udev (Ubuntu Oneiric) "HP DL380G5 root disk mounted read-only on boot and boot fails" [High,Confirmed] https://launchpad.net/bugs/818177
<slangasek> smoser: I wouldn't start duping bugs to it until we actually prove that's what's happening though
<smoser> i thought it was known fact that it does not flush queue
<slangasek> not known to me
<slangasek> but I'm not a udev expert, either :/
<slangasek> smoser: patch posted: https://bugs.launchpad.net/ubuntu/oneiric/+source/udev/+bug/833783/+attachment/2449493/+files/udev-must-provide-console-833783.patch
<ubottu> Ubuntu bug 833783 in udev (Ubuntu Oneiric) "boot failure: can't open /root/dev/console: no such file" [High,Confirmed]
<cjwatson> I think it's true that it doesn't flush the queue, but nobody worried about it before because udev in the real root was meant to catch up all events
<cjwatson> but /dev/console is used between udevadm control --exit and udev starting in the real root ...
<slangasek> indeed
<slangasek> and previously, udev happened to always get around to creating /dev/console before being stopped
<cjwatson> I don't think it would be desperately hard to fix in udev for somebody who had a spare couple of hours
<cjwatson> smoser: so, speaking of Xen, today I've found and am fixing three separate bugs all of which were independently installation blockers for a friend's colo hosting company that uses Xen guests
<cjwatson> smoser: I'm kind of interested that none of those bugs appeared to be biting us :-)
<cjwatson> bug 720558, bug 857548, and bug 857662
<ubottu> Launchpad bug 720558 in grub (Ubuntu Natty) "Ubuntu 10.04 currently requires groot= workaround with pvgrub" [High,Triaged] https://launchpad.net/bugs/720558
<ubottu> Launchpad bug 857548 in grub-installer (Ubuntu Oneiric) "no longer possible to select GRUB Legacy by preseeding" [High,Triaged] https://launchpad.net/bugs/857548
<ubottu> Launchpad bug 857662 in hw-detect (Ubuntu Oneiric) "Should xenbus_probe_frontend be built-in?" [High,Triaged] https://launchpad.net/bugs/857662
<cjwatson> smoser: do you have workarounds for any of those that I don't know about, or is it just that your boot setup is sufficiently different that you dodge them?
<cjwatson> I guess you're using preinstalled AMIs ...
<cjwatson> kind of surprised that xen-netfront autoloading isn't a problem though
<cjwatson> unless you use -virtual I guess
<smoser> 720558 is worked around by grub-legacy-ec2
<smoser> 857548 is worked around by the presense of grub-legacy-ec2 (as it does not conflict with grub2)
<smoser> 857662 we dont hit that in our installs because we dont install with installer
<smoser> that said, i do know that installation as a guest under xen has been broken
<smoser> i believe that xen-netfront autoloading is a problem...i think there was a discussion recently on ubuntu-server mailing list to that reguard.
<cjwatson> smoser: conflicts aren't relevant to 857548, but not using d-i would be :-)
<smoser> right.
<cjwatson> smoser: so I wonder if grub-legacy-ec2 can go away once I've fixed that bug in grub?  or is there more?
<cjwatson> I'm going to work around xen-*front autoloading in hw-detect
<smoser> the only real reason for grub-legacy-ec2 is to manage /boot/grub/menu.lst and install along side grub2
<cjwatson> it'll work as long as you're using the -virtual flavour
<cjwatson> (for the installed system, since then we don't need userspace tweaks too)
<cjwatson> can you remind me why you need grub2 installed?
<smoser> because those images work with "normal bios booting" via grub2 and pv-grub booting via the managed /boot/grub/menu.lst
<cjwatson> oh, dual running
<cjwatson> ok
<smoser> so as soon as you get me a pv-grub2, *then* we can ditch the grub-legacy-ec2
<smoser> and i'll be happy
<smoser> :)
<cjwatson> yeah, that's a *little* further off
<cjwatson> owing to no time this cycle
<smoser> oh comeon... its not like have anything else to work on
<cjwatson> heh
<Daviey> cjwatson: Is it too late to change the d-i background colour slightly?
 * Daviey jests.
<cjwatson> ahahabonk
<slangasek> blah, why is launchpad marking bugs like 798509 confirmed?
<micahg>  slangasek: they affect multiple people
<charlie-tca> newest thing. any comment or duplicate lets launchpad automatically confirm the bug
<slangasek> micahg: "like 798509" is the key expression there :)
<slangasek> it's a duplicate of a fix-released bug
<charlie-tca> It really fails on most, since nothing but a comment by anyone will cause it to go "confirmed"
<micahg> slangasek: that should be a bug
<ScottK> superm1: Is the hdhomerun-config-gui upload you just sponsored bug fix only?
<micahg> slangasek: do you want to file the report or should I ?
<slangasek> micahg: filing
<slangasek> micahg: bug #857777
<ubottu> Launchpad bug 857777 in Launchpad itself "launchpad janitor generating noise by 'confirm'ing duplicate bugs" [Undecided,New] https://launchpad.net/bugs/857777
<micahg> slangasek: thanks
<ScottK> Nice.  Because it didn't send enough bugmail already, I guess.
<charlie-tca> It is kind of frustrating to see a bug report, someone asks a question on it, and leaves it in "New", and launchpad confirms it because of the comment
<slangasek> pitti: the fix for bug #854329 is staged in bzr for gdm and lightdm; any objections to me uploading it?  (I can't upload the plymouth side until those are uploaded)
<ubottu> Launchpad bug 854329 in xdm (Ubuntu Oneiric) "race condition on shutdown with more than one DM installed" [Low,Triaged] https://launchpad.net/bugs/854329
<micahg> slangasek: FYI, he's on holiday today
<slangasek> oh, well, that makes it easy then... no one around to tell me no ;)
<micahg> heh
<slangasek> ScottK: do you know if anyone's interested in working on the kdm part of bug #854329?
<ubottu> Launchpad bug 854329 in xdm (Ubuntu Oneiric) "race condition on shutdown with more than one DM installed" [Low,Triaged] https://launchpad.net/bugs/854329
<ScottK> slangasek: No.  If it's cargo culting something from some other DM, I can probably manage, but maybe debfx.
<slangasek> ScottK: it's pretty cargo-cult, yeah :)
<superm1> ScottK, yes, silicon dust hasn't added new features in ages
<ScottK> superm1: Accepted.
<ScottK> OK.  Taking a look.
<ScottK> Amazing how cleanly gdm.upstart and kdm.upstart diff against each other and yet they have completely different authors listed.
<mr_pouit> Archive admins: I've synced garcon, and I guess it sits in unapproved. I can't link to the bug report though, so if needed, the FFe is Bug #857718. Thanks.
<ubottu> Launchpad bug 857718 in garcon (Ubuntu) "[FFe] garcon 0.1.9" [Undecided,Confirmed] https://launchpad.net/bugs/857718
<slangasek> ScottK: there seems to have been some confusion about the meaning of the field; I'm pretty sure the gdm upstart job wasn't written by GDM upstream...
<slangasek> mr_pouit: accepted
<ScottK> slangasek: Seems sufficiently cargo cultable.  I got it.
<jbicha> ooh, dpkg 1.16.1 automatically unapplies patches at the end of building
<slangasek> ScottK: yay :)
<mr_pouit> slangasek: thanks!
<jbicha> that should help clean up the .pc mess, right?
<ScottK> Nice.  Found some additional changes to steal.
<ScottK> jbicha: Only if they weren't applied at the start.
 * SpamapS wonders why display managers don't have one upstart job that calls the currently selected default....
<slangasek> SpamapS: because the way you call the currently selected default varies significantly
<SpamapS> of course it does, that makes perfect sense, every DM is a special snowflake
<slangasek> SpamapS: feel free to impose a standard invocation on all the upstreams in your copious free time :)
<SpamapS> slangasek: indeed, I will have to go in search of more round tuits.
<ScottK> SpamapS: FYI, just for added fun, kdm upstream is widely viewed as one of the most socially ept KDE developers ....
<ScottK> slangasek: I pushed it to kde-workspace bzr.  Need to finish looking at patches to cherrypick from upstream before uploading.
<slangasek> ScottK: spiff, thanks
<ScottK> barry: Accepted.
<barry> ScottK: awesome, thanks.  i probably won't get to retrying omniorb until tomorrow
#ubuntu-devel 2011-09-24
<ScottK> slangasek: Is this issue relevant to a non-upstartified DM?
<ScottK> (nodm)
<slangasek> ScottK: only in the sense that a non-upstartified DM won't get pretty splash on shutdown
<slangasek> the nodm init script could also call initctl emit, though, without itself being upstartified
<ScottK> It doesn't.
<ScottK> Most of the point of nodm is to be invisible anyway, so sounds like it doesn't matter.
<ScottK> doko_: Please retry python-omniorb in the rebuild now.  It builds for me locally with the newest dh_python2.
<ScottK> barry: ^^^ I'm rejecting your upload too.
<doko_> ScottK, python-omniorb did build
<koud> Hello, I am loking for pointers on where to discuss input methods in ubuntu
<ScottK> doko_: Cool.
<ScottK> barry: ^^^ - Win.
<barry> ScottK, doko_ thanks.  i was worrying about what to do with the version numbers for omniorb, but now i don't have to. :)
<koud> has there been anywork done for creating a unified input method experience with ubuntu?
<koud> what group should I get incontact with to discuss input methods?
<koud> ah maybe papercuts
<Laibsch> koud: no, that's not a papercut
<koud> ok where should it be discussed?
<koud> it seems like a simple usability problem to me
<koud> problem is there are both keyboardlayouts and then there are inputmethods under language support
<Laibsch> which makes sense, doesn't it?
<koud> making many layers of changing keyboard language
<koud> no
<koud> it does not
<Laibsch> really?
<koud> yes I can give example
<Laibsch> do you even know what you are talking about then?
<koud> I use swedish and english
<koud> I can change to swedish keyboard layout
<koud> and then I can type swedish
<koud> if I change to korean keyboard layout
<koud> I cant type in korean
<koud> then I need inputmeathod
<koud> but inputmethod include both english and korean together
<koud> so then I suddenly have 2 english
<koud> there is 3rd layer of changing layout
<koud> windows also does this way
<koud> mac does not
<koud> opensolaris does not
<koud> those are only two I know that has easy keyboard language setup
<Laibsch> I suggest you take this up with the person doing whichever GUI config tool it is you are using
<koud> hmm?
<koud> I am using default ubuntu change keyboard layout
<Laibsch> what you are describing is a GUI choice issue
<koud> no
<Laibsch> alright
<Laibsch> enough of you
<Laibsch> welcome to ignore
<koud> oh thats openminded of you
<koud> to let me explain
<Laibsch> I simply don't like your style of discussion
<koud> ok I am sorry
<Laibsch> you don't know what you are talking about but insist on your position firmly
<koud> ok
<koud> how can I find out who is responsible for the GUI?
<koud> I will take your suggestion and ask that person
<koud> do you use multiple keyboard languages?
<zone51> what this channel about?
<charlie-tca> !topic
<ubottu> Please read the channel topic whenever you enter, as it contains important information. To view it at any time after joining, simply type /topic
<shnatsel> cjwatson: hello again. I have "dpkg-gencontrol: warning: Depends field of package elementary-minimal: unknown substitution variable ${germinate:Depends}" errors in recipe builds despite germinate being installed. It produces packages with blank dependencies. How do I fix it? Full log: https://launchpadlibrarian.net/80824082/buildlog_ubuntu-oneiric-i386.elementary-seed-meta_1.242-0%7E300%7Eoneiric1_BUILDING.txt.gz
<shnatsel> cjwatson: ok, nvm, I've figured out that it's caused by an invalid metapackage map
<shnatsel> thanks!
#ubuntu-devel 2011-09-25
<jincreator> Is it possible to fix package in Universe after FinalFreeze without Freeze Exception?
<micahg> jincreator: if it's not on any images
<micahg> jincreator: universe final freeze is about a week and a half after FinalFreeze
<jincreator> micahg: You mean univese packages freeze even after ReleaseCandidate?
<micahg> jincreator: yes, since they're not on any images
<micahg> jincreator: well, at least the ones not on any images that is...
<jincreator> micahg: You mean if the package is not at ubuntu, Kubuntu, Xubuntu, and so on?
<micahg> jincreator: right, even those can be fixed if the bug is release critical
<jincreator> micahg: Thanks! I was worried about a certain package can be fixed until Oneiric release. Then I must wait more times...
<micahg> jincreator: well, the sooner the better, which package by the way?
<jincreator> micahg: ttf-nanum. https://bugs.launchpad.net/ubuntu/+source/ttf-nanum/+bug/835304
<ubottu> Ubuntu bug 835304 in Ubuntu Translations "contained fontconfig setting files force to make it default font" [Medium,Triaged]
<hyperair> doko__: you could have just synced gtk2-engines-aurora you know...
<hyperair> but nevermind, i'll do it now
<doko__> hyperair, you could have just filed a sync request you know...
<hyperair> doko__: yeah i could have, but you just made a redundant patch.
<hyperair> for linking with -lm
<hyperair> all that was already in -2, which i didn't think was needed for ubuntu, considering we're all frozen and all.
<Rovanion> Is the wine installed on 64-bit Ubuntu 11.10 32-bit? I get the fallowing error when trying to run something trough wine: wine: '/home/rov/.wine' is a 64-bit installation, it cannot be used with a 32-bit wineserver.
<Rovanion> uname -a clearly states that I'm running a 64-bit kernel
<Laibsch> recently the sponsor process has been working better (after being abyssmal for a while), but I wonder if there is a reason why bug 379382 is lingering like in the old days?
<ubottu> Launchpad bug 379382 in gnome-utils (Ubuntu) "gnome-screenshot (Alt-Printscreen) black/blanks out top of windows in multi monitor xinerama" [Low,In progress] https://launchpad.net/bugs/379382
<stgraber> Laibsch: it's currently at the middle of the queue (appeared on it on the 18th) so my guess is that someone will get to it next week
<stgraber> the queue is currently pretty long (114 entries)
<Laibsch> stgraber: I see, thank you.  Is my observation correct that time-through-queue has increased recently?
<stgraber> Laibsch: yeah, I think the processing time increased a bit recently though my feeling is that we also are getting more submissions than we used to
<Laibsch> stgraber: If I were to resubmit a slightly modified patch (like adding Ubuntu-Bug line for DEP-3) would that put me back at the end of the queue?
<stgraber> Laibsch: I'm not sure how that specific script works but I wouldn't think so. I'd think it works by bugnumber or by URL, neither of which should change if you just change the debdiff in the bug
<Laibsch> OK, I will try.  I'd love if you were to have another look afterwards
<broder> it's based on when ubuntu-sponsors is subscribed
<Laibsch> I see
<Laibsch> Thanks
<broder> specifically the most recent time
<Laibsch> I'll subscribe sponsors to all my pet bug ahead of time, then ;-)
<Laibsch> delivery of patch will be just-in-time ;-)
<Laibsch> what is the correct and supported way to specify a non-default gcc version to use in pbuilder/pbuilder-dist?  I thought http://www.netfort.gr.jp/~dancer/software/pbuilder-doc/pbuilder-doc.html#altcompiler would tell me but it doesn't seem to work.
<micahg> jbicha: can you have a look at the gdb-doc failure?
<jbicha> micahg: sure, thanks for the heads up
#ubuntu-devel 2012-09-17
<pitti> Good morning
<pitti> infinity: I don't think they were
<pitti> infinity: I checked the upload log, and there was just one package that it tried to upload to ppa.launchpad.net, failed with "connection refused", and then it stopped
<pitti> nothing else
<pitti> infinity: the log timestamps coincide with the failed upload log at least
<pitti> WTF??
 * pitti mass-rejects
<pitti> infinity: so this remains a complete and utter mystery to me; PPA upload seems broken again (firewall changes?), but then the script should (and according to the log, did) break, not upload to other places
<pitti> infinity: oooh *headdeask* I know what happened
<pitti> infinity: I guess the next time it auto-uploaded quantal packages, the failed list of precise/lucid packages were still in "updated-packages" (the file with the upload list), and so it uploaded those along
<pitti> I'm not sure how that dodged the "if test -s updated-packages; then exit 1" command, though
<StevenK> test -s updated-packages && exit 1 ? :-)
<pitti> well, there's an echo in between as well
<pitti> StevenK: but that should essentially be the same?
 * pitti asks IS for fixing firewall rules
<StevenK> pitti: Yeah, that's why I suggested it, it avoids an if, but since there's an echo there's no point.
<pitti> aah, I know
 * pitti fixes
<dholbach> good morning
<jamespage> morning all
<tjaalton> i've forgot again.. how to disable multiarch on quantal? just getting rid of /etc/dpkg/dpkg.cfg.d/multiarch isn't enough
<tjaalton> not that useful on chroots
<tjaalton> at least when not mirroring i386 locally, making sbuild-update fail
<jodh> /whois Daviey Daviey
<jodh>  
<jodh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jodh
<ev> mpt: we're getting kernel crashes sent to daisy.ubuntu.com. I know this because the code mistakenly attempts to insert their very large core files into Cassandra.
<mpt> ev, that's a problem then, because (as far as I could tell from the code) the UI for that class of error doesn't exist, so whatever UI is being used to send them is bound to be confusing.
<mpt> (doesn't exist yet, anyway)
<ev> KernelCrash?
<mpt> Hm, did I just read it and then completely forget it existed? :-]
 * mpt looks again
<mpt> ev, it calls get_system_application_title(), which shows "Sorry, Ubuntu has experienced an internal error." I guess that's strictly accurate, but not the intended text. <https://wiki.ubuntu.com/ErrorTracker#kernel-oops>
<ev> indeed
<ev> mind that we're only seeing these a few times a day
<ev> and we don't have the ability to retrace them yet
<ev> (lp:apport, bin/apport-retrace:354)
<ev> that's not to say we shouldn't fix the dialog
<mpt> Sure, though fixing bug 1033902 would be much more important if it happens much more often
<ubottu> Launchpad bug 1033902 in apport (Ubuntu) "Application thread crash shows application crash error alert" [Undecided,Confirmed] https://launchpad.net/bugs/1033902
<ev> yeah, definitely
<mpt> Annoying that that missed UI Freeze
<mpt> ev, so do you think we're getting only a small percentage of kernel crashes from typically-reporting machines? "A few times a day" might actually be right, compared with (for example) 173/day for the current #1.
<ev> I think so. If you look at https://errors.ubuntu.com/oops-local, any exception with MaximumRetryException is likely a kernel crash.
<cjwatson> slangasek: A ucf prompt that isn't actually displayed to you seems like it must be a package management bug rather than a bug in the package
<ev> mpt: I'll silently drop them at daisy.ubuntu.com and increment a counter for the day period so we at least know how many we would be getting
<cjwatson> tjaalton: dpkg --remove-architecture i386
<cjwatson> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jodh, cjwatson
<mpt> ev, there are four bugs apparently reducing the proportion of kernel errors reported: bug 401370, bug 480421, bug 527026, and bug 624562.
<ubottu> Launchpad bug 401370 in apport (Ubuntu) "when attempting to report a kernel crash, apport-gtk enter D wait state" [Undecided,New] https://launchpad.net/bugs/401370
<ubottu> Launchpad bug 480421 in apport (Ubuntu) "apport won't report vanilla kernel oops" [Undecided,New] https://launchpad.net/bugs/480421
<ubottu> Launchpad bug 527026 in apport (Ubuntu) "Apport is unable to report a bug on a kernel that you are not booted into" [Undecided,Confirmed] https://launchpad.net/bugs/527026
<ubottu> Launchpad bug 624562 in apport (Ubuntu) "Reporting kerneloops fails with "permission denied"" [Undecided,Confirmed] https://launchpad.net/bugs/624562
<mpt> and I just reported bug 1051891 about the UI text.
<ubottu> Launchpad bug 1051891 in apport (Ubuntu) "Kernel crash/oops shows confusing UI text" [Undecided,New] https://launchpad.net/bugs/1051891
<ev> mpt: to be clear, kernel crashes and kernel oops are different
<ev> the former is when you get a full kernel panic and it dumps its brain into a file (if it even can)
<ev> the latter is a sort of recoverable error
<ev> things keep chugging along and you get an OOPS! in the syslog
<mpt> Ok ... they're treated the same in apport-gtk currently.
<mpt> So, an oops *should* have the "Ubuntu just had an internal error" text, then
<mpt> it's only a crash that shouldn't
<ev> yes, I reckon
<mpt> ?
<ev> correct
<ev> at least that's my understanding
<mpt> updated the bug report
<mpt> fixed the specification too <https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=97&rev1=95>
<tjaalton> cjwatson: thanks, found it on the debin wiki too, added to the askubuntu question
<didrocks> xnox: hey, is ubiquity still in gtk2 or using pygi?
<xnox> didrocks: it's using pygi & python3
<akheron> cjwatson: currently installing quantal beta 1 to another machine from exactly the same usb stick, and seems to work great
<cjwatson> akheron: ok, I still have a task for today to investigate it though
<akheron> cjwatson: fwiw, I had to use the nomodeset kernel option with the first one
<xnox> didrocks: some elements do not use width-for-height widgets, e.g. there are GtkBox here and there.
<cjwatson> nomodeset -> not my problem
<akheron> with the machine that fails
<akheron> ok
<cjwatson> akheron: I didn't mean to say that the name server was broken, BTW, only that something had gone wrong with resolver configuration within the target chroot
<didrocks> xnox: hum, ok, I'm wondering about bug #1049215 as gnome-bluetooth stacktrace is about using pygi as well
<ubottu> Launchpad bug 1049215 in gnome-bluetooth (Ubuntu) "ubiquity-bluetooth-agent crashed with ImportError in /usr/lib/python3/dist-packages/gi/__init__.py: could not import gobject (error was: EOFError('EOF read where not expected',))" [Medium,New] https://launchpad.net/bugs/1049215
<cjwatson> This is a plausible enough failure mode, sadly
<didrocks> not sure what imported gobject
<akheron> cjwatson: yeah
<cjwatson> didrocks: ubiquity doesn't even support python2 any more
<cjwatson> didrocks: but if it's calling some external process which uses python2, that's a different mattere
<cjwatson> -e
<cjwatson> yeah, bluetooth-applet
<didrocks> cjwatson: I guess it's the case
<cjwatson> nowt to do with ubiquity
<cjwatson> it's pretty obvious from the traceback :)
<didrocks> cjwatson: hum? bluetooth-applet is using pygi
<didrocks>     from gi.repository import GObject
<didrocks> ?
<cjwatson> Wait, that's actually ubiquity's substitute bluetooth-agent
<xnox> hmmm.... I totally missed that....
<pitti> didrocks: I usually sudo vi /usr/share/pyshared/gobject/constants.py and do something like raise TypeError("not static")
<didrocks> cjwatson: you lost me :)
<pitti> this will give a proper backtrace which sub-sub-submodule imports the static bindings
<cjwatson> didrocks: I lost myself for a bit
<xnox> didrocks: ubiquity-dm fakes a desktop session and half of indicators to provide "ubuntu style session" which only shows ubiquity =)
<xnox> but I didn't think bluetooth was one of them.
<cjwatson> I can run the imports at the top of ubiquity-bluetooth-agent without any problem though
<cjwatson> Puzzling.  Anyway I should get back to piloting ...
<didrocks> xnox: cjwatson: I confirm gnome-bluetooth is using pygi
<didrocks> xnox: did you reproduce it?
<pitti> I've seen this strange EOFError on a totally different context recently (in a bug report); I think doko attributed it to mis-installation
<pitti> bug 1029683
<ubottu> Launchpad bug 1029683 in Ubuntu "import causes EOFError: EOF read where not expected" [Medium,Invalid] https://launchpad.net/bugs/1029683
<didrocks> xnox: if so, you can do what pitti is telling to know which component is the guilty one :)
<xnox> didrocks: if you cannot reproduce, maybe something else happened, e.g. somebody yanked their installation media hence that file was actually empty / EOF =)
<didrocks> possibly
<doko> pitti, wasn't this one where the reporter even did say that the machine was hanging?
<pitti> but as that's the third report in a few days, I'm beginning to become suspicious
<cjwatson> didrocks: gnome-bluetooth is irrelevant
<pitti> perhaps something does create zero-byte files somewhere
 * didrocks retarget on xnox's plate then :)
<cjwatson> didrocks: casper dpkg-diverts away the bluetooth-agent from gnome-bluetooth, and replaces it with a symlink to ubiquity-bluetooth-agent
<pitti> doko: no, not this one; there might be more dupes, though
<didrocks> cjwatson: ah ok, so the /usr/bin/ is not the one we can expect, thanks for the info :)
<cjwatson> tumbleweed: looking at bug 1049343 and slightly puzzled by it being a sync - doesn't the reporter say there's a patch to be reapplied?  and he seems to be right
<ubottu> Launchpad bug 1049343 in Ubuntu "FFe: Un-blacklist and sync sensors-applet 3.0.0-0.2 (universe) from Debian testing (main)" [Wishlist,Triaged] https://launchpad.net/bugs/1049343
<xnox> didrocks: ok ;-)(
<xnox> didrocks: ok ;-)
<tumbleweed> cjwatson: ah, whoops, I forgot about that
<tumbleweed> cjwatson: I did ask him on IRC to prepare the patch, a week ago, and clearly he hasn't
<tumbleweed> (and today, I just saw that it built, and remembered that it had seemed reasonable)
<xnox> didrocks: looking at the code, there were GObject vs Gobject typos fixed in the past, maybe this is a bug report from an acient image?!
<didrocks> xnox: hum, I think you would get an import error and not this "library mixture" error one (pygtk was gobject, not Gobject)
<cjwatson> xnox: the report makes the image version clear
<xnox> didrocks: cjwatson: yeah, it's a recent image and the import is the correct gi one GObject.
<didrocks> hum, seems I can't nominate for Quantal anymore? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1045845/+nominate
<ubottu> Launchpad bug 1045845 in xorg-server (Ubuntu) "12.10 guest crash on login when using 12.04 qemu-kvm with cirrus driver" [Medium,Confirmed]
<cjwatson> didrocks: screenshot?
<ogra_> hmm, same for me with that link
<ogra_> nothing between the precise and r-series checkboxes
<didrocks> right, same
<didrocks> cjwatson: do you still want a screenshot?
<cjwatson> Yes.
<cjwatson> Oh, wait, I see what you mean.  No.
<didrocks> ok :)
<cjwatson> You can't nominate for quantal because apparently it was already nominated for quantal and that bug task was then deleted.
<cjwatson> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1045845/+activity
<ubottu> Launchpad bug 1045845 in xorg-server (Ubuntu) "12.10 guest crash on login when using 12.04 qemu-kvm with cirrus driver" [Medium,Confirmed]
<didrocks> cjwatson: oh interested, I didn't know about that feature :)
<ogra_> http://people.canonical.com/~ogra/quantal.png
<ogra_> oh,. wow
<cjwatson> You'll find you can nominate other bugs just fine.
<didrocks> ok, but I guess jamespage just nominated them by error and then reverted
<cjwatson> It's arguably a Launchpad bug that you can't re-nominate, so please make sure that's filed.
<cjwatson> Well, re-target.
<didrocks> but no way to give it back then?
<cjwatson> Not that I can see.
<cjwatson> Please file an LP bug.
<didrocks> cjwatson: will do, thanks :)
<jamespage> didrocks, gah - sorry - I was not aware of that bug
<didrocks> jamespage: well, I wasn't as well :)
<didrocks> bug #1051918
<ubottu> Launchpad bug 1051918 in Launchpad itself "Can't renominate a bug when a nominated task was deleted" [Undecided,New] https://launchpad.net/bugs/1051918
<melodie> hi
<melodie> can someone help me understanding a piece of bash in a cron daily script ? it's related to the permissions on a file
<melodie> it's about this version of mlocate : http://packages.ubuntu.com/precise/mlocate
<cjwatson> Sure.  What don't you understand?
<melodie> hi cjwatson : I would like to know if the file /usr/bin/updatedb.mlocate is supposed to be executable. is it, or is it not ? and is the cron supposed to make it executable "on the fly" ?
<geser> it should be executable (at least it's here)
<melodie> it's lines number 3 to 5 whic make me think so: http://pastebin.com/N2CWL1TR
<cjwatson> melodie: It's shipped executable in the package.
<cjwatson> melodie: There is no reason the cron script should need to change its permissions.
<melodie> cjwatson, ok, I thank you.
<melodie> geser, thank you too
<cjwatson> The -x test there is really just "is it there", actually.  -f would have been fine too but -x is a bit more exact.
<melodie> all right
<cjwatson> (Or -e, for that matter.)
<cjwatson> But it's correct as it is.
<melodie> is this package issued from Debian sid, or Debian testing ? in testing they have the same version number, but I am unable to find how the permissions are setup in the package (which bugs me)
<cjwatson> It doesn't matter where it came from.  Testing comes from unstable.
<geser> melodie: as you can remove the package (but leave the configuration files installed incl. the cron-snippet), the cron-snippet has to check if the binary is still there
<cjwatson> I expect that the permissions are not explicitly set up at all.  The compiler will emit binaries as executable right from the start.
<melodie> oh ! I see !
<cjwatson> There's no need to override permissions explicitly when they're correct already.
<melodie> cjwatson, so if the permissions are not right, it can be the fault of the configurations done in the compiler ?
<Laney> Most packages will run the dh_fixperms program during building which does some normalisation of permissions and owners (by default).
<cjwatson> melodie: Are the permissions wrong, or is this theoretical?
<cjwatson> melodie: In fifteen years of working on Unix I have never seen the compiler get this wrong, so I don't think the theoretical point is interesting.
<melodie> cjwatson, the permissions are wrong in my virtualbox machine. Your information allowed me to eliminate a possible source for this issue. the guilty one is the vbox machine.
<cjwatson> melodie: Is this an environment that has been upgraded from some earlier version?
<cjwatson> And does reinstalling the mlocate package fix it?
<melodie> the original system has the right permissions. the spin has wrong permissions
<cjwatson> "spin"?
<melodie> a remix if you prefer
<cjwatson> I still don't know what you're talking about :)
<cjwatson> *Which* remix?
<melodie> a project I am training on in a vbox machine. :)
<cjwatson> Does reinstalling the mlocate package fix it?
<melodie> nothing very important but I was wondering if there was a bug somewhere
<melodie> cjwatson, this could be, I am going to check.
<cjwatson> I expect this is a bug in the remix's image build process.
<melodie> I think it can also come from something in the virtualbox machine. I am not hundred percent sure that using it for remix is a good idea
<melodie> cjwatson, reinstalling does fix the issue. thank you !
<geser> cjwatson: got the embedded image of grub2 bigger with the recent package upload? because I got hit by bug #1051154 with the recent updated (it worked till now with RAID and LVM)
<ubottu> Launchpad bug 1051154 in grub2 (Ubuntu) "[quantal] warning: your embedding area is unusually small. core.img won't fit in it." [Undecided,Confirmed] https://launchpad.net/bugs/1051154
<cjwatson> geser: wouldn't be surprising.  I'll look later
<cjwatson> geser: may not be terribly fixable
<cjwatson> 62 sectors is very little space to fit anything useful in ...
<cjwatson> wait, "embedding area is unusually small" means there's even less than 62 sectors
<cjwatson> I wonder if that's lying, since it doesn't match the fdisk output there
<cjwatson> anyway, must finish piloting first.
<geser> I can add my fdisk output too to that bug later (if it helps)
<cjwatson> sure
<alkisg1> cjwatson: re: LP bug #978654, I believe the correct thing to do there is to leave the .decode() call for as long as pkcompat.py is python2 (i.e. 12.04/12.10). When it's ported to python 3, that change should be reverted.
<ubottu> Launchpad bug 978654 in aptdaemon (Ubuntu) "<type 'exceptions.UnicodeDecodeError'>: 'ascii' codec can't decode byte 0xc3 in position 24: ordinal not in range(128)" [Medium,In progress] https://launchpad.net/bugs/978654
<alkisg1> cjwatson: it's not the only call to dbus.String(), and I don't think we want to change all the calls to include the decode() + the guard if...
<jodh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: cjwatson
<cjwatson> alkisg1: No, I disagree.  Leaving timebombs around for ourselves is unwise.
<cjwatson> alkisg1: The guard I suggested is safe in Python 2 as well.
<cjwatson> alkisg1: Unless pkcompat will *never* be ported to Python 3.
<alkisg1> cjwatson: there are multiple dbus.String() calls in the code, a wrapper function for dbus.String() should probably be defined then
<cjwatson> In fact, there is already a python3-aptdaemon.pkcompat package.
<alkisg1> cjwatson: my idea is that when it's ported to python3, decode() won't be needed, so it should only be there until it is
<cjwatson> So the "it's only Python 2" argument is definitely invalid.
<cjwatson> A better counterargument, if you wanted to avoid this, would be to demonstrate that last_update can never be assigned a Unicode string.
<cjwatson> But I don't know whether that's true.
<alkisg1> So, you'd vote for a call-dbus-string() wrapper for all of the calls?
<alkisg1> Or just for this one call?
<cjwatson> I don't know enough of the context.  It would depend.
<cjwatson> I suggest you look into how these functions are called (i.e. answer my question above).
<alkisg1> aptdaemon$ grep -r dbus.String * | wc -l
<alkisg1> 109
<alkisg1> I think that looking into 109 calls would be too much work
<cjwatson> Well, I'm not going to sponsor a change when I'm not convinced it's safe
<alkisg1> I.e. some wrapper would be easier. Or, just leave it without a wrapper, since it's more clearly written for python 3, and only fix that one call for the python2 in 12.04/12.10 problem
<ogra_> you could train your sed skills with it ;)
<cjwatson> But since this is implementing a (presumably) defined interface, why not look into what defines that interface ...
<cjwatson> I wouldn't have expected most of those calls to be relevant; many of them may well be operating on always-bytes data
<cjwatson> Or, sorry, I mean always-text (Unicode)
<cjwatson> As usual with Python 2/3 porting you need to make sure that you know whether each object is binary or text.
<alkisg1> So the idea is that the code should be python2 compatible even if it's ported to python3?
<alkisg1> What I don't understand is why would we want the decode() functions in a python3 port of the code
<cjwatson> We don't want to have to maintain separate Python 2 and 3 versions.
<cjwatson> It's a horrendous hassle.
<alkisg1> OK, I thought the python2 version wouldn't be developed anymore
<cjwatson> For most packages, as long as they still build Python 2 versions, they should be written in code that's compatible with both.
<cjwatson> That's not usually how it works.
<alkisg1> Gotcha
<cjwatson> The Python 2 binary package comes from the same source package as the Python 3 one.
<alkisg1> OK, then it's a bigger problem than what I have time for. I can't study someone else's code for 109 occurances of possible time bombs...
<alkisg1> Thank you very much for your input, I'll unassign the bug
<cjwatson> Looking at the code, it seems clearly possible for this method to receive text input.
<cjwatson> alkisg1: I think you're overreacting
<cjwatson> alkisg1: You don't need to do any such study
<cjwatson> alkisg1: You're proposing a change to this one method, and it may well be that in practice this is the only method where this is a problem
<alkisg1> cjwatson: my idea was that this would be a quick patch, and that the person undertaking the python3 port would solve it properly
<cjwatson> alkisg1: If written in the style I suggest, this change would be harmless; it might not fix everything, but it would be an improvement
<alkisg1> I.e. either make a wrapper function for all dbus.string calls, or fix the ones that need decoding, etc
<cjwatson> alkisg1: You seem to be suggesting that no change should be made until it is perfect, which is not usually a wise approach
<cjwatson> All I'm saying is that this change should be written in a way that means it's clearly not a regression
<cjwatson> I'm not saying you need to audit all those dbus.String calls, at all
<alkisg1> Well, currently the script isn't runnable with python3
<alkisg1> So it wouldn't be a regression
<cjwatson> Which script?
<alkisg1> pkcompat.py
<cjwatson> The file you're editing is shipped in python3-aptdaemon.pkcompat
<cjwatson> It may have '#!/usr/bin/env python' at the top, but it is principally a module to be imported from other programs, not principally a script to be run standalone
<cjwatson> So I don't consider the #! line very relevant
<alkisg1> OK, I thought it was to be revisited by someone for python3 compatibility
<cjwatson> If you run python3 you can then say 'from aptdaemon import pkcompat' and it works
<cjwatson> It has already been ported to Python 3
<cjwatson> I suspect that in fact the reported problem that you're debugging only exists in Python 2
<alkisg1> True, dbus.String() can accept unicode strings in python3
<cjwatson> So it's not a lack of port to Python 3, it's (perhaps) a slightly overenthusiastic port, if anything
<cjwatson> dbus.String can accept Unicode strings in Python 2
<cjwatson> as well
<cjwatson> What it can't accept is a Unicode string encoded as bytes
<cjwatson> >>> dbus.String(u"Ã©")
<cjwatson> dbus.String(u'\xe9')
<cjwatson> >>> dbus.String(u"Ã©".encode("UTF-8"))
<cjwatson> Traceback (most recent call last):
<cjwatson> If you pass bytes to dbus.String() in Python 3, in an odd reversal of the usual situation, it doesn't crash, but it produces incorrect results due to the behaviour of str(bytes):
<cjwatson> >>> dbus.String("Ã©")
<cjwatson> dbus.String('Ã©')
<cjwatson> >>> dbus.String("Ã©".encode("UTF-8"))
<cjwatson> dbus.String("b'\\xc3\\xa9'")
<cjwatson> So this demonstrates that in both Python 2 and 3 you *must* pass text (Unicode) to dbus.String and it is incorrect in both worlds to do otherwise
<alkisg1> Aaah I didn't realize that part
<cjwatson> Thus, I'd suggest that perhaps you should be looking further up in the traceback heree
<alkisg1> I did say it wrongly above (unicode instead of utf8 strings), but I thought python3 would correctly handle utf8 strings (byte sequences)
<cjwatson> i.e. don't change last_package_setter at all - leave its interface as being defined to take Unicode strings only
<alkisg1> What I'm saying though, is that someone needs to have a look at all those calls
<alkisg1> My only part in this is because students get an apport dialog
<cjwatson> For this bug, somebody needs to have a look at *this* call
<cjwatson> Please don't let the perfect be the enemy of the good
<alkisg1> And instead of disabling apport, I thought I'd invest a few minutes to help there
<alkisg1> I understand the problem, and I really think it's a job for the maintainer
<cjwatson> It shouldn't need to be
<alkisg1> I really thank you for your time, and I'm not avoiding this due only to time constrains. I really feel that it's a bigger problem that I shouldn't tackle. It needs a better solution, and personally I'd go for a wrapper function, to avoid all possible cases at once.
<cjwatson> I really don't think that's right
<cjwatson> A wrapper function is missing the point
<cjwatson> These functions are (implicitly) defined to take Unicode strings only - a wrapper function would be masking bugs elsewhere
<cjwatson> In this case, I believe I see the bug
<cjwatson> Look in 'def _get_id_from_version'
<cjwatson> origin = version.origins[0].label
<alkisg1> A wrapper function could log + fix the problems elsewhere
<cjwatson> No
<cjwatson> I'm not going to pursue that
<alkisg1> I.e. have the devs notified without having the users apps breaking
<cjwatson> I bet (though I'll check) that version.origins[0].label is bytes, not text
<cjwatson> alkisg1: What is the URL for the PPA you used in your example (https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/978654/comments/12)?
<ubottu> Launchpad bug 978654 in aptdaemon (Ubuntu) "<type 'exceptions.UnicodeDecodeError'>: 'ascii' codec can't decode byte 0xc3 in position 24: ordinal not in range(128)" [Medium,In progress]
<alkisg1> cjwatson: https://launchpad.net/~ts.sch.gr/+archive/ppa/+packages
<cjwatson> Thanks
<alkisg1> We have about 20 papercut-like problems in schools here. E.g. we can't type greek due to lightdm not supporting multiple layouts, we have aptd, colord, apport etc crashes, sshfs problems... we try to help where the fixes are simple, but we don't have time to dive + properly fix all those cases
<davmor2> pitti: I'm just wondering if bug #1051951 could be related to bug #952933  but I'm pretty sure I saw you and seb128 say that you would push the fix upstream to debian, it's just it has the exact same symptoms
<ubottu> Launchpad bug 1051951 in gvfs (Ubuntu) "sansa fuze and samsung s3 phone are both shown as usb drive not devices" [Undecided,New] https://launchpad.net/bugs/1051951
<ubottu> Launchpad bug 952933 in gvfs (Ubuntu) "media players do not trigger "Open with Music Player" dialog" [Medium,Fix released] https://launchpad.net/bugs/952933
<cjwatson> Sure, you can do whatever you like locally of course, but this is a merge proposal into Ubuntu so I want to do the right thing and not mask bugs
<alkisg1> So e.g. for lightdm we're using an /etc/X11/Xkbmap override, and we have to leave the proper fix up to the maintainer, even if it needs more than 1 year now
<cjwatson> Especially since it doesn't look too hard to do the right thing here
<cjwatson> In fact, add-apt-repository has a similar problem (still :-/)
<juliank> cjwatson: Origin's label has Python's standard string type.
<cjwatson> Indeed.
<cjwatson> So in Python 2 that needs to be encoded if the desired type is in fact text.
<doko> tjaalton, yeah for http://people.canonical.com/~ubuntu-archive/nbs.html \o/
<doko> what did break the build dependencies?
<tjaalton> doko: libglu not accepted yet?
<cjwatson> eh, that's transient
<tjaalton> it's in NEW I think, mesa dropped it
<cjwatson> yeah
<cjwatson> doko: feel free to process that in NEW :)
<doko> ok, looking at it
<juliank> cjwatson: Yes, and placing something like get_dbus_string() in tests/regressions/aptdaemon/core.py into a common module would be useful for fixing this aptdaemon bug. (try: return dbus.String(text), except ...: return dbus.String(text.encode("utf-8"))
<cjwatson> juliank: Well, I think the fix in aptdaemon actually belongs several layers up.
<doko> tjaalton, all the code was in mesa before?
<tjaalton> doko: yes
<tjaalton> should be safe to accept
<juliank> cjwatson: I don't think it can be fixed on any other level. The fact is that python-apt has a 'str' API, and python-dbus a 'unicode' API. You could change python-dbus to accept utf-8 encoded byte strings, but I don't think this is sensible. You can also change the applications to set the default encoding to UTF-8, which fixes this as well.
<tjaalton> packaging was copied straight from it, debian/copyright should be accurate etc :)
<cjwatson> juliank: I think you're misunderstanding me.
<cjwatson> juliank: The fix in aptdaemon belongs at the point where it retrieves data from python-apt, not in the methods that construct dbus.Strings from values.
<cjwatson> juliank: These are several layers apart in the call stack.
<cjwatson> juliank: I didn't mean to say that it should not be fixed in aptdaemon; it clearly should.  I meant several layers up *within aptdaemon* from where alkisg1 was suggesting.
<doko> accepted
<cjwatson> alkisg1: It seems fairly complicated to set up a reproduction environment for this bug.  Would you mind testing http://paste.ubuntu.com/1211094/, which I believe should fix it?
<alkisg1> cjwatson: sure, give me a minute to test with the other guy that set up the reproduction environment...
<cjwatson> Hah, although python-aptdaemon.pkcompat has actually been removed from quantal
<cjwatson> But this won't hurt and will provide a better basis for an SRU
<alkisg1> cjwatson: works as expected :)
<alkisg1> (tested with python2, precise)
<cjwatson> Hooray
<cjwatson> alkisg1: Perhaps somebody could add a test case to the bug description, in the form required by https://wiki.ubuntu.com/StableReleaseUpdates?
<alkisg1> I can try to
<cjwatson> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * dholbach hugs cjwatson :)
<cjwatson> alkisg1: I've uploaded a fix to precise-proposed, pending approval.  The test case will help that. :-)
<alkisg1> cjwatson: ty, /me is still writing... :)
<alkisg1> cjwatson: done, as well as I could write those... :)
<cjwatson> alkisg1: thans
<cjwatson> *thanks
<alkisg1> np, thank you too and sorry for not doing it myself the way you pointed
<cjwatson> np
<alkisg1> I just feel that larger bugs should be handled by the maintainers... /me is probably just getting too old for this... :)
<cjwatson> Well, I'm not an aptdaemon maintainer
<cjwatson> So unless you're saying I shouldn't have handled it ...
<ogra_> age is not an excuse
<ogra_> (i think colin is older than you :P )
<alkisg1> I surely appreciate that you've handled it, but shouldn't the maintainer have a look at all the other 108 dbus.String() calls?
<cjwatson> No, because that's a red herring
<cjwatson> The problem is not dbus.String; the problem is the interaction with a different string model in python-apt
<cjwatson> And I grepped for other uses of Origin.label, and fixed the one other case of that
<doko> bryceh, about 1050674: is this a copy of the existing driver packaging, or are these maintained somehow together?
<cjwatson> It's sometimes a mistake to microfocus on the bottom level of the traceback - what you want is for types to be correct all the way through the program
<alkisg1> So e.g. "BackendAuthor": dbus.String(__author__), => are we sure that won't be utf8?
<cjwatson> Yes, because it is a hardcoded constant!
<alkisg1> And  we're sure no e.g. chinese guy will be the author in the next year?
<cjwatson> Any future changes will be to the Python 3 code where this won't arise.
<cjwatson> Since "..." is a Unicode type in Python 3.
<alkisg1> I thought we wanted to maintain a python2 + python3 compatible version
<cjwatson> Can you just drop it?
<alkisg1> Sure
<cjwatson> python-aptdaemon.pkcompat actually no longer exists in quantal.
<alkisg1> I don't mean to chat just for the ...fun of it
<alkisg1> We both have lots of things to better invest our time in :)
<alkisg1> Thank you again.
<cjwatson> And the reason I'm not harping on dbus.String is that any problems of that form would be *separate bugs*.
<cjwatson> They wouldn't really be the same as this one; they would need to be addressed in entirely separate ways.
<cjwatson> I don't think it's worth doing a full audit for that.
<cjwatson> This bug isn't really about dbus.String, it's about incorrectly fetching information from python-apt.
<cjwatson> So I focused on the general case of that, not on the general case of dbus.String handling.
<alkisg1> Much appreciated; let's move on to other matters :)
<cjwatson> I don't mean to snap; I just feel you were pushing me about a generalisation of the problem that I don't actually think is the right generalisation to be looking at.  I did look at the generalised version of what I felt was the correct characterisation of the bug.
<alkisg1> cjwatson: I honestly have/had etc no hard feelings or anything else bad for you; I also didn't mean to push anywhere etc. I _am_ actually not always understanding the way you (and all ubuntu devs) choose to handle some stuff.
<alkisg1> That's probably because after 4 years I'm still not sure where the upstream / distro maintainer / bug triager seperation is, exactly
<melodie> hi again
<alkisg1> I think after 20 years of being upstream for some programs, it's hard for me to think as a bug reporter / distro maintainer
<melodie> I do have a general question. I have tried to follow the "UbuntuFromScratch" howto at the Ubuntu website and I have almost reached the end of it (while building the way it is explained). At the end, I see things that I am almost sure I will not be able to handle without some extra help, either because I don't understand, or because it might be outdated for some parts. Is there a chan where I could get help on making a Remix (from scratch)
<melodie>  ?
<cjwatson> Well, ideally upstream (who's mostly glatzor) would have addressed this, but since it's mostly a legacy Python 2 matter I decided to just go ahead and fix it and he can pick up the patch if he wants to.
<bryceh> doko, the packaging is maintained in the same git tree as the normal driver, on its own branch.  So yes to both.
 * Laney is glad that he enjoys playing whack a mole on broken fontconfig configuration files
 * ogra_ wonders why such a little script http://paste.ubuntu.com/1211296/ actually reserves 3MB when running it 
<ogra_> gtk2-perl clearly got bloated since i looked last
<infinity> pitti: So, I assume you rejected all those lucid uploads?
<infinity> pitti: If so, you missed the ones in NEW.
 * infinity finds the others in the rejected queue and confirms before dumping the new ones too.
<blackbug> I have a fix for a bug, how can I submit?
<xnox> blackbug: attach a patch to that bug?!
<blackbug> xnox: sorry, i am doing this first time on ubuntu. By path you mean, tarball of the package in which i have fixed? or in some other form?
<blackbug> i mean patch*
<xnox> blackbug: by patch I mean: $ diff -r -U 4 original-dir/ modified-dir/
<xnox> blackbug: google for "how to create a patch", or google for "how to create a merge proposal"
<blackbug> xnox: thanks, i will google for the same. As of now, i have created branch using lp and did my changes over that.
<xnox> blackbug: great
<xnox> blackbug: $ bzr diff --old lp:ubuntu/package
<xnox> will make a patch
<xnox> blackbug: or simply go to your branch web page and click "Propose a merge"
<blackbug> xnox: Thanks for the guidance :) . I will do as suggested.
<cjwatson> -U 4?  Weirdo. :-)
<blackbug> xnox: just 1 last question, after running bzr diff --old lp:ubuntu/package i got the differences on the console. So, I need to redirect them to a file or some patch file is created somewhere? ( posting again, as I got disconnected )
<cjwatson> blackbug: redirect
<cjwatson> it's a straightforward Unix command, it outputs to standard output by default :)
<blackbug> cjwatson: Thanks, I will redirect. I thought may be its creates some compress file in background, and also shows output on console :). Thanks :)
<cjwatson> No.
<sbeattie> doko: so one issue I'm noticing with openjdk-7/precise is that update-manager doesn't want to install it because it needs to remove icedtea-7-jre-cacao, which got pulled in by default because openjdk-7-jre-headless used to recommend it.
<blackbug> cjwatson: one more question......i redirected the output to text file. When i tried to upload it as patch on launchpad, it displayed "Attachment, doesnt seem to be a patch file, Are you sure its patch?". So, everything is cool or I need to change the format?
<jdstrand> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jdstrand
<slangasek> cjwatson: yep, found where the prompt went and filed a bug on u-m
<pitti> infinity: ah, forgot the NEW ones, indeed; but they should be rejected either way; thanks!
<doko> sbeattie, what do you suggest? adding a conflict?
<sbeattie> doko: I *think* we need an empty stub icedtea-7-jre-cacao package (for precise only), but perhaps slangasek has a better idea?
<jdstrand> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<StevenK> RAOF: Using Do's MPD plugin makes my computer sad
<RAOF> StevenK: In what way sad?
<StevenK> RAOF: Every action creates a zombie mpc process
<ogra_> resident evil Do
<RAOF> StevenK: Ah, yeah.
<RAOF> StevenK: That's actually a mono bug I should track down.
<StevenK> RAOF: Yeah, I got annoyed enough to read the plugin code
<StevenK> When I found the process code and found it looked suspiciously like the example code on microsoft's site, I figured it was probably lower down the stack.
<RAOF> Yeah. Something in the BCL isn't waiting properly on the child.
#ubuntu-devel 2012-09-18
<ndowens> I have a quick question pertaining to packaging.uscan reports that an older version is newer than what I am packaging. How would I stop that?
<cjwatson> ndowens: You probably want to do something with uversionmangle to get the upstream version into a canonical form that uscan can compare consistently with dpkg --compare-versions, or else tighten up the regex.  See 'man uscan' for details.
<ndowens> cjwatson: I haven't a idea on how I would mangle it
<cjwatson> Nor do I, since you haven't given any details :-)
<ndowens> it is from SF. it gives me that version 0.20 is newer than 1.3. I just tried to s/0.20// in uversionmangle and then it reported that 0.15 is newer
<infinity> ndowens: What's the current package version, and the filename of the upstream version?
<cjwatson> Full 'uscan --verbose --report' output and the current contents of debian/watch would help.
<cjwatson> (Use paste.ubuntu.com or similar)
<ndowens> http://dpaste.com/802354/
<cjwatson> That's saying that 1.3 is newer than 0.20.
<cjwatson> So I think you've misunderstood the output.
<cjwatson> Where did the source for your 1.3 package come from, given that uscan is reporting that nothing called lince 1.3 is available on the upstream site?
<cjwatson> (And a quick browse around sourceforge.net/projects/lince seems to confirm that)
 * infinity guesses http://sourceforge.net/projects/lincetorrent/files/
<ndowens> yup
<ndowens> wait hmm
<infinity> So, it also seems likely what your debian/watch is wrong. :P
<cjwatson> Ah.  Fix your watch file to point to the right upstream URL then.
<ndowens> maybe because it is named lincetorrent instead of lince
<ndowens> duh me!
<cjwatson> And I'd recommend naming the package after the upstream name, too.
<ndowens> there we go
<cjwatson> Otherwise it'll be trouble for somebody who comes along later and wants to package sourceforge.net/projects/lince
<ndowens> There named the package lincetorrent
<ndowens> Eventually my Debian package will be available to Ubuntu. Dwb, suppose to be in the latest version of Ubuntu coming out
<ndowens> Maybe some people will like it. It is a terminal browser
<bryceh> are there any archive admins available?
<bryceh> alberto uploaded nvidia-graphics-drivers-experimental on Friday and has been in the acceptance queue over the weekend.
<bryceh> we're going to need to rename that package as per the Tech Board decision today, so if that package is still in the queue please reject it.  We'll get a properly renamed package in soon.
<RAOF> Will do.
<RAOF> bryceh: That's in quantal, yes?
<RAOF> Too late; it's accepted.
<bryceh> ah well
<infinity> We can, however, remove it. :P
<RAOF> You can :)
 * infinity does so.
<bryceh> thanks
 * RAOF probably has the power to, but doesn't know how, and definitely doesn't have the authority to :)
<infinity> bryceh: Done.
<bryceh> RAOF, infinity procedural question...
<bryceh> since instead of having a single nvidia-experimental package where we can do the package-acceptance, MIR, SRU processes one time, we're presumably going to have a series of nvidia-experimental-NNN packages - are we going to need to go through these processes every time we add another experimental driver, or can we simplify that process overhead down?
<RAOF> bryceh: Are we going to have one nvidia-experimental-NNN per driver series? I'd have thought that would just contain the latest experimental series?
<bryceh> RAOF, yeah one per driver series.  It solves two issues.
<bryceh> RAOF, the first being that if a user installs say 123.11 required by game A, and then later on game B requires 130.08 so we update nvidia-experimental to 130.08, that would get automatically loaded, so we're exposing the user to a new beta driver unnecessarily
<bryceh> RAOF, the second is that in order to ensure the user gets moved to nvidia-current when they do a distro upgrade, at upgrade time the package is a dummy that will depend on nvidia-current.  So having the package named nvidia-experimental-NNN will allow this to be done.
<RAOF> Ah, ok. I've got an incorrect understanding of the purpose of -experimental, then.
<bryceh> yeah, it's not really intended to be "xorg-edgers for the nvidia masses" but a way to resolve dependencies for games
<bryceh> RAOF, infinity so, thoughts on my question above^^ ?
<RAOF> My understanding is that the tech board can remove arbitrarily many process constraints.
<RAOF> So, there could conceivably be some special-casing for it.
<bryceh> ok, great.  I'll clarify with them.
<stgraber> bryceh: I'm assuming you have a well documented procedure on how to create one of these new source packages?
<stgraber> bryceh: if so, I'd think that we could agree to simplify the New processing as long as the packaging is identical and the "source tarball" comes from the same place
<bryceh> stgraber, yes there is a README.debian that covers how to create nvidia packages in general.  The only additional step is the actual rename, which is just a setting in one .in file.
<bryceh> stgraber, yes we should be able to arrange for that.  My goal is to basically script the whole process (it's already mostly scripted with a few paint-by-numbers steps).  So the packaging is going to be very predictable.
<bryceh> anyway, thanks everyone.  I'm EOD and going afk.
<StevenK> steven@undermined:~% ps aux | grep mpc | grep -c 'ZN'
<StevenK> 183
<StevenK> RAOF: ^
<StevenK> Awesome, is it not? :-)
<ajmitch> the zombie hordes are attacking?
<StevenK> ajmitch: It's a mono bug I'm trying to guilt RAOF into fixing.
<StevenK> I'm not sure if its working.
<ajmitch> yeah I know, bug with it not waiting properly on children
<ScottK> micahg: How do you feel about releasing the chromium-browser SRU in precise?
<TheMuso> 4;3~/c
<ScottK> ;b!?
<pitti> Good morning
<dholbach> good morning
<slangasek> sbeattie: is this stub icedtea-7-jre-cacao needed for upgrades to precise from an earlier release, or for upgrades within precise?
<dholbach> TheMuso, hey Luke - how are you doing?
<dholbach> do you know if pyatspi has a ~ubuntu-desktop branch or something?
<dholbach> I just uploaded a small fix for it
<didrocks> dholbach: are you fixing bug #1052331? (seems to only be missing () around print)
<ubottu> Launchpad bug 1052331 in pyatspi (Ubuntu Quantal) "package python3-pyatspi2 2.5.92+dfsg-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Triaged] https://launchpad.net/bugs/1052331
<didrocks> hey btw :)
<dholbach> didrocks, yes
<didrocks> dholbach: doesn't seem to have an ubuntu-desktop branch to me
<dholbach> ok good
<didrocks> thanks dholbach :)
<tsdgeos> could the builder bot besides building also install the package?
<tsdgeos> this solve this kind of problem, would it?
 * Laney spots a dholbach fixing upgrade bugs!
<dholbach> Laney, I felt in the mood for it this morning ;-)
<mitya57> barry: good morning
<mitya57> did you have a look at my py3-defaults fix?
<jamespage> doko_, whens the next rebuild test scheduled for? looking at a fix for maven-debian-helper to auto-install to /usr/share/java if the package is a java library
 * ogra_ thinks that will likely happen during the freeze
<ogra_> since the buildds will be idling anyway
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<cjwatson> bryceh: we can simplify the process requirements, but I do not think it is worth special-case code in Launchpad to stop them going through NEW at all
<jamespage> dholbach, hmm - that sync of uglifyjs might create a problem
<jamespage> I'd not noticed that the nodejs/node conflict had been resolved in Debian
<cjwatson> by way of a Debian Technical Committee resolution, yes
<jamespage> yep - but quantal still carries pre-fixed nodejs version
<jamespage> so that will generate an unfulfilable dependency
<jamespage> nodejs (>= 0.6.19~dfsg1-3)
<dholbach> ugh :(
<dholbach> sorry, let me take a look at it
<cjwatson> is there any chance we can move forward rather than back on this?
<cjwatson> i.e. take the new nodejs?
<jamespage> cjwatson, I think so; the breaks are pretty explicitly defined in nodejs 0.6.19~dfsg1-3
<cjwatson> I realise that would be a merge, and tracking down the other things that need to be synced/merged as consequences
<jamespage> ~90 packages (probably)
<cjwatson> substantial enough; happy to defer to your judgement on whether that's best
<dholbach> maybe it's less packages, 0.6.19~dfsg1-4 says:
<dholbach> +    + Break only packages actually calling /usr/bin/node (directly or
<dholbach> +      via env).
<jamespage> yeah - I just looked at the Breaks in latest Debian unstable
<jamespage> its much shorter
<ogra_> lol, dholbach thanks for sponsoring the classmate-tools fix, that remonds me that i forgot to ask for package removal ...
<ogra_> *reminds
<dholbach> ogra_, did you have a good time in Berlin without me? :-P
<ogra_> dholbach, not at all ... i had a horrid drive (6h for 350km) and was just super exhausted when i arrived
<dholbach> next time then :)
<dholbach> I can't believe we never manage to meet
<ogra_> and given that i usually dont get much sleep on the sofa over there, my sat. wasnt much better
<ogra_> but for the ride back i picked up a cute hitchhiker ;)
 * xnox ponders at what point did above conversation drift to #-offtopic?! =)
<ogra_> dholbach, yeah, next time i'll drive on thu and return on monday evening, that should give me some time to actually do something
<dholbach> sounds good :)
<dholbach> xnox, all my fault
 * xnox no worries, it's funny though how both of you are avoiding each other, not on purpose ;-)
<ogra_> xnox, its not offtopic we are coordinating workplace joint ventures :P
<xnox> trinken sprint?
<ogra_> heh, exactly
<davmor2> Hey guys the light blue hue around the password box on lightdm is it meant to be blue?  it just looks odd considering all the others hilights are orange on the system
<ev> mpt: https://errors.ubuntu.com/ - ever so slowly 12.04 is creeping upward and 12.10 is moving further and further away from it. Yikes.
<mpt> ev, I predict that the former is bug 1046269 -- i.e. once we fix that, the 12.04 graph will flat-line
<ubottu> Launchpad bug 1046269 in Whoopsie ""Errors/day" wrongly depends on how many hours Ubuntu is used" [Undecided,New] https://launchpad.net/bugs/1046269
<mpt> ev, the latter might be the same bug -- Q has always been that unstable, it's just that until recently people haven't been using it for hours on end.
<ogra_> ev, its is totally normal that the amout of bugs rises after beta1
<mpt> ev, and still the #1 problem is the ubiquity crash, which people would typically only ever encounter 0 or 1 times.
<ogra_> (thats why we shouldnt drop milestones :) they give users confidence)
<xnox> ev: I would expect stable release to eventually creep up, and +1 to move down. See for example these charts http://bugs.debian.org/release-critical/ blue is stable, green is +1, when they "reset" it's a release.
<mpt> ogra_, xnox, these aren't bug reports. The number of errors encountered per calendar day is poorly correlated, if at all, with the number of open bug reports.
<xnox> i wonder how this is solved in economics with e.g. daily sales figures. In different sectors there will be different "business-lunch" & "weekend-brunch" sales variations, which is ~ same as we are seeing here. Plus unlike sandwich shops we are open 24/7 in all time-zones.... not just one tiem-zone....
<mpt> The huge temporary dips in the red line on <http://bugs.debian.org/release-critical/> tells me that each release they delude themselves about whether a bug is release-critical or not :-/
<mpt> (I'd expect that if they had time-based releases, but not when they don't)
<ogra_> well, they try to make a scheduled release date even though they arent time based
<ev> ogra_: I don't care what's normal. I care about defining what we think is acceptable. If we really think that each release should creep up in instability and then make a massive effort to get the next LTS more stable than what we've recorded for the past, then lets stand behind that statement.
<xnox> mpt: no, the dip in the red-line is the delta of the RC-bugs |stable - testing|, such that the dip is all the bugs closed in new release.
<xnox> mpt: in debian they track all bugs per-series, we only track SRU worthy bugs per-series.
<ogra_> ev, if we walk with "it *has* to be more stable than the last one from day one" we will kill progress completely ... i think what we need is a compromise or a new way to doing out work to make your requirements work
<ogra_> s/to/of/
<xnox> mpt: and after the release there is a flood of experimental -> testing uploads with many bugs =)
<ogra_> s/out/our/
<xnox> hence the jump-back after ~6 month freeze
<ev> ogra_: and that conversation is what interests me.
<ogra_> ev, right, i dont disagree with your view bit i disagree with the timeline you want to implement it in ... it can only work once we changed our way of working
<ogra_> *but
<ev> so lets change that come UDS.
<ogra_> i think changing development processes has to come first here
<mpt> xnox, even so, that curve is implausible. :-) The easy-to-fix bugs would get picked off first, so with genuine prioritization the curve would asymptotically approach zero, not plummet towards it.
<ogra_> (and before thet infrastructure changes have to happen so the infrastructure can cope with the new processes)
<ogra_> imho measuring comeas last :)
<mpt> If you don't measure first you don't know whether any process changes helped
<xnox> mpt: the red line is pointless, look at the growing delta between blue & green. release means that blue line becomes the green one. instantly on the day they release.
<ogra_> mpt, oh, sure, measure as you like, just dont make policies out of it before we have infarstructure and processes right :)
<mpt> xnox, I understand that part, but it's only the red line that interests me, sorry :-)
<ev> policies drive process
<ogra_> ev, but that doesnt help if the infrastructure cant cope :)
<ev> it's simple science
<ev> hypothesis: Ubuntu is progressively less stable
<ev> we now have data that supports this
<ogra_> experience tells differently i think
<ev> then comes the solution
<ev> ogra_: I trust data infinitely more than personal experience
<ogra_> its constantly having instabilities i dont think it degrades
<xnox> mpt: if the red line is the only one that interests you, why doesn't error.ubuntu.com show the total of all errors reported? e.g. 12.04 & 12.10 combined then?
<ogra_> the areas of problems move around with each release
<ricotz> infinity, hi, i don't know the details about the nvidia-experimental thing, but there is a "nvidia-settings-experimental" package too
<xnox> mpt: the equivalent of the red line. (bundling together development and stable releases)
<mpt> xnox, no it isn't. Once again, open bug reports and error reports are not even close to being the same thing.
<ogra_> ev, the point is that with our current process you cant really do the measuring you plan ... we currently explicitly break stuff for 3 months to then fix it again in the other three months
<ev> ogra_: that was the old model.
<xnox> mpt: because 100 bugs hitting 1 user each != 1 bug hitting 10 000 users. I see. Ok.
<ogra_> so you have on half of the cycle where it has to rise massively
<mpt> ev, it's way too soon to make that kind of statement. We'll know once we have six months data.
<ogra_> ev, well, thats still the used model
<ev> no, it isn't.
<ev> ogra_: my understanding from what I've been told is that the archive must remain stable from day 1
<ev> the CDs must always be installable
<xnox> but they weren't
<ogra_> it had minor tweaks, but we still have three monts until FF
<ev> and that we're now allowed to push things out past Feature Freeze if we can show test coverage and stability
<ev> we're moving to a much more fluid, test-first model
<ogra_> and during these first three months new code and new bugs land
<xnox> ev: we don't redirect all uploads to  dev-proposed, so by definition we cannot make CD installable every day, we can't even build CDs every day.
<ev> ogra_: lets be honest - new code and bugs land for six months
<xnox> ev: so maybe next cycle.
<ogra_> ev, right, "we are moving to" ... thats what i mean
<ev> xnox: I'm not saying it's impossible for CDs to be broken
<ogra_> ev, well, not if people actually stick to the processes
<ogra_> (which i agree not all of us do)
<ev> I'm saying that the engineering leadership stood up and said it's unacceptable that CDs are uninstallable
<ogra_> and withoout an infrastucture that catches that (staging areas for testing etc) we cant change the process yet
<mpt> xnox, bugs almost certainly follow a Zipf distribution, e.g. Microsoft's statement that 1% of bugs account for 50% of errors, and 20% of bugs for 80% of errors
<ogra_> while we have minor process tweaks (upload to proposed etc) that doesnt fix the whole yet and is only a start
<mpt> Zipf or Pareto
<ev> ogra_: we have these things. We need to drive people into them faster. We can't sit around waiting for the perfect infrastructure.
<ev> If we slow down before we speed up, so be it.
<ogra_> i.e. for installer changes we would need a staging area for the images since you can only really test the installer in context
<ogra_> etc etc
 * ogra_ looks forward to discuss that at UDS and have some proper planning afterwards 
<ogra_> all this "we have to .... " without proper technical, process and infrastructure backing doesnt really help
 * xnox really wants generate ISOs -> let jenkins auto-test images -> only then release them to cdimage.ubuntu.com
<ogra_> xnox, ++
<ogra_> so we have at least the installability covered automatic
 * xnox had "fun" remarking tens of reported bugs as dupes.... it's like well can I yank the image from cdimage, cause it's borked for ~ 50% of people?
<ogra_> but even that has its traps :)
<mpt> xnox, and #1 is assigned to you ;-)
<ogra_> do you hold back all images of one build if ppc fails this teast (to make sure to not break image consistency across areces) ?
<Laney> what do you mean by installability?
<xnox> true, but you know basic things.... e.g. if it doesn't boot in a VM / panda-feeder
<Laney> you can't even build the live images if you don't have that
<ogra_> s/areces/arches/
<xnox> ogra_: no, i would hold off just the ppc image. Plus we don't have automatic way to test ppc =)
<ogra_> well, then take arm
<xnox> ogra_: autotest ppc images that is =)
<ogra_> currently we try to keep all images in snyc
<ogra_> especially during milestones ...
<ogra_> if we drop milestones, how do we guarantee thois consistency ?
<ogra_> i doubt all this is doable in one release ... too many established processes that grew over years have to be changed completely
<soren> xnox: How'd you debug the problems found by Jenkins if you can't get to the images?
<xnox> soren: good point. How'd you stop manual auto testing if the images are borked?
<xnox> soren: after jenkins / first person finds out they are borked?
 * xnox s/manual auto testing/manual testing/
<ogra_> soren, you just fish it out of the staging area where jenkins pulled it from
 * ogra_ is out to customs office
<soren> xnox: What's "manual auto testing"?
<soren> xnox: Anyways, we could probably make Jenkins push a .b0rken file to cdimage akin to the .oversized marker we have.
<pitti> ev: hey Evan, how are you?
<pitti> ev: do you have an opinion on https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1050853/comments/3 wrt. the tags we should use?
<ev> pitti: excellent, thanks. How are you?
<ubottu> Launchpad bug 1050853 in apport (Ubuntu) "Not recorded whether an error is in a -proposed or -updates package" [Undecided,New]
<pitti> ev: je suis bien, merci :)
<pitti> err, "je vais bien"
<ev> pitti: :)
<ev> pitti: I'm not sure where the tags even come in. http://daisy.ubuntu.com definitely doesn't pay attention to tags from Launchpad.
<pitti> ev: ah, it can't/won't look at report['Tags']?
<ev> ohhh
<pitti> I think Launchpad-wise a "proposed" tag woudl make mose sense
<pitti> most
<pitti> but of course this needs to work for errors.u.c. as well, otherwise it's missing the point
<pitti> ev: I'm also fine with a different field, but on LP bugs this would be more clutter and harder to search for
<cjwatson> ev: I was very clear that the intent of the +1 maintenance effort was to make CDs installable *from alpha-1 onwards*, and Rick has supported that qualification; so I'd appreciate it if you didn't generalise that beyond what's promised.
<ev> cjwatson: I misunderstood then. Sorry.
<cjwatson> (Well, an intent.  There are several.)
<cjwatson> Sigh.  You know what I hate?  Reaching a bug on my to-do list, and the first thing I have to do is undo lots of misguided metadata changes.
<ev> pitti: so where apport puts it really doesn't matter to me, so long as it's done independent of the Launchpad infrastructure
<pitti> ev: it'd be something like 'proposed' in report['Tags']
<ev> that is, as long as it's in a field that whoopsie can parse at the time we mark the report for uploading, then that's sufficient
<pitti> ev: or to be really correct, 'proposed' in report['Tags'].split()
<ev> hmm, so "precise proposed" would be in the tags?
<pitti> yes, and potentially lots more
<ev> and never precise quantal proposed?
<pitti> well, I can't really promise what tags package hooks add
<ev> :)
<pitti> ev: for the release I'd advise to look at DistroRelease:
<ev> ah yes, of course
<ev> and that solves my next concern
<pitti> (I guess/hope that's what you are using already0
<ev> which would've been mapping from the release nicknames to the actual numbers
<ev> which we're getting from DistroRelease
<ev> so excellent
<ev> sounds like we have a solution
<pitti> splendid
<pitti> we can also call it "package-from-proposed" to reduce the chance of hitting an already existing tag with a different meaning
<pitti> mvo: OOI, how does apt manage to record the origin of an installed package?
<pitti> mvo: I do understand how the origin of the candidate works, but I didn't think that the installed package origin was recorded anywhere
<pitti> mvo: or does it just mix'n'match the installed version number against the available candidates?
<cjwatson> It doesn't
<cjwatson> I mean, it doesn't record it.  Any notion of the origin is synthesised later
<pitti> mvo: i. e. if I see archive:'precise-proposed', can I rely on that it really came from -proposed, or only that it is in -proposed (but it might have the same version in -updates)?
<pitti> cjwatson: ok, that's what I thought, thanks
<mvo> pitti: yes, its just picking from the available ones, it would be great if it would record the origin but it does not currently
<pitti> so I guess to answer "is this a proposed package", I'd rather check the available version numbers myself
<mvo> pitti: you can iterate over the available origins
<mvo> pitti: if its both in -updates and in -proposed then it should have them both in pkg.installed.origins
<pitti> mvo: ah, that's helpful
<jamespage> cjwatson, please could you accept the nodejs-legacy binary package in the quantal NEW queue
<pitti> == Tags =================================
<pitti>  precise package-from-proposed running-unity
<pitti> ev: ^ voila
<pitti> ev, mvo: crude, but effective (I don't want to call Pyton and wait for an apt.Cache() object, apt-cache showpkg is faster): http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/quantal/apport/ubuntu/revision/2088
<pitti> ev: this should hopefully be SRUable, too
<cjwatson> jamespage: done - sorry for the delay
<jamespage> cjwatson, np - thanks
<ev> pitti: cheers! Do we not also want a tag for -updates?
<xnox> -security?
<xnox> backports?
<doko> jamespage, was waiting for the gnome update, so I should be able to start Wed/Thu
<jamespage> doko, OK - I have a fix for m-d-h to make it a little more intelligent with regards to when it installs to /usr/share/java
<jamespage> but the test suite in the package is rubbish - its not deterministic
<jamespage> I can run it three times a get different results each time
<jamespage> it also in no way simulates what m-d-h does when it actually builds a package either...
<pitti> ev: would that be any useful?
<ev> I guess not as it's really the same view as the release by itself
<ev> so ignore me :)
<cjwatson> So, I'm working on bug 1047550, and am slightly freaked that this didn't come up in beta-1 testing output as far as I saw
<ubottu> Launchpad bug 1047550 in ubiquity (Ubuntu Quantal) "Resolver configuration goes wrong while trying to install grub-efi-amd64 during installation" [Critical,Triaged] https://launchpad.net/bugs/1047550
<cjwatson> Did I miss it, or do we not do any (non-Mac!) UEFI ISO testing at the moment?
<xnox> My laptop doesn't boot ISOs in UEFI mode =( and I am yet to convert my laptop to UEFI manually.
<xnox> cjwatson: maybe we need to add another test case / config to the iso tracker with non-mac UEFI
<xnox> such that it will hopefully be tested.
<cjwatson> Possibly, but I'd like to know first whether I just missed the output
<dholbach> can somebody please reject https://code.launchpad.net/~bkerensa/ubuntu/quantal/wulfware/move-homepage-field/+merge/124137?
<pitti> dholbach: *zap*
<dholbach> thanks
 * didrocks wonders where his libsecret, gcr, gnome-keyring, libcryptui, seahorse-nautilus upload went
<pitti> right -> there? https://launchpad.net/ubuntu/+source/libsecret/0.10-0ubuntu1
<didrocks> did you get some emails on quantal-changes?
 * pitti chuckles about didrocks's most intriguing changelog in https://launchpad.net/ubuntu/+source/gnome-keyring/3.5.92-0ubuntu1
<pitti> didrocks: it seems emails are stalled
<didrocks> pitti: urgh :)
<pitti> I didn't get an ack mail for apport either
<didrocks> pitti: it's a secret!
<pitti> didrocks: *shh* it's secret!
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * pitti ^5s didrocks
<didrocks> pitti: ok, when I saw the email for linux-meta at 14:59, knowing I updated those 30 minutes ago, I started to wonder
 * didrocks ^5s pitti :)
<jamespage> broder, ping re lintian.ubuntuwire.org
<jamespage> I'd like to get a experimental check enabled for quantal - is that possible?
<cjwatson> Ah.  The UEFI installation bug above is a bit more constrained than I previously thought, so even if we do test it I have an explanation for why ISO testing wouldn't have run across it.
<xnox> bug 1024202 apport crash report about apport crashing =) oh the irony
<ubottu> Launchpad bug 1024202 in apport (Ubuntu) "apport-gtk crashed with SIGABRT in __assert_fail_base()" [Medium,Confirmed] https://launchpad.net/bugs/1024202
<xnox> ... marking as being affected.
<TheLordOfTime> lol, i've seen taht before, that's not the first time i've seen that in the past few days :P
<sbeattie> slangasek: upgrades within precise
<barry> mitya57: thanks for the reminder, i'm looking at it right now
<mitya57> barry: great!
<broder> jamespage: hey - i'm swamped this week, but could do it next, or maybe this weekend. can you send me an email with the details?
<jamespage> broder, thanks - details on the way
<tkamppeter> Laney, doko, hi
<tkamppeter> Laney, doko, I have a problem with Avahi
<doko> tkamppeter, why do you ask me? ;)
<tkamppeter> Laney, doko, host names with NAME.local do not get resolved and an Avahi service (remote printer) does not get resolved via avahi_service_resolver_new()
<tkamppeter> doko, sorry, you were in debian/changelog of avahi-daemon
<didrocks> dholbach: I will probably switch my patch pilot for next week
<didrocks> dholbach: can't do it tomorrow with all PS crazyness
<tkamppeter> slangasek, can you help me with an Avahi issue?
<ev> mpt: http://poppy-dev.local/?launchpad=false - should asynchronously load the colors
<mpt> ev, works in Firefox :-)
<ev> mpt: I tested it there too :)
<mpt> ev, have you figured out why bug 1027648 is highlighted as a regression? It was never marked fixed.
<ubottu> Launchpad bug 1027648 in ubiquity (Ubuntu Quantal) "ubiquity crashed with ValueError in command(): I/O operation on closed file." [High,Confirmed] https://launchpad.net/bugs/1027648
<ev> I'll have a look in a moment
<xnox> ev, mpt: well.... maybe it should be as it is resurrected bug 792652 and should have the same crash signature
<ubottu> Launchpad bug 792652 in ubiquity (Ubuntu Precise) "ubiquity crashed with ValueError in command(): I/O operation on closed file" [High,Fix released] https://launchpad.net/bugs/792652
<mpt> ok
<ev> mpt: fixed
<elmo> tkamppeter: around?
<dholbach> didrocks, sure sure
<paultag> jodh: Hey, I saw your ITP, and replied without thinking to ask if I got it right. Any idea if I used a silly argument? I'd be happy to clear it up without causing more of a ruckus
<paultag> Ah, I see you already replied, jodh. Toodles.
<xnox> jbicha: what installation about ubiquity is there?
<xnox> jbicha: I want some UIFe for ubiquity crypt & regression w.r.t. scrollbars
<xnox> bug 1042649 and bug 1052040
<ubottu> Launchpad bug 1042649 in ubiquity (Ubuntu) "[FFe] [UIFe] Manual Partitioning Crypt" [Undecided,New] https://launchpad.net/bugs/1042649
<ubottu> Launchpad bug 1052040 in ubiquity (Ubuntu) "[regression] [UIFe] ubiquity greeter does not have overlay scrollbars in quantal, but it did in precise" [Medium,Fix committed] https://launchpad.net/bugs/1052040
<xnox> jbicha: installation docs that is.
<Laney> poor docs team
<jbicha> xnox: oh, I was out this morning and didn't get a chance to reply to your email; the Docs Team handles help.ubuntu.com but we don't have any control over ubuntu.com
<xnox> jbicha: ok. And how about granting those UIFe =)))) from docs team perspective? do they affect docs much.
<xnox> jbicha: there is only screenshots from 10.04 on the Graphical install wiki page.
<xnox> jbicha: nothing that I can see on the plain help.ubuntu.com
<jbicha> right, ubuntu-docs doesn't really have ubiquity docs; so no objections from the Docs Team
<TheLordOfTime> jbicha, so if help.ubuntu.com needs updating, do i go poke the docs team, or...?
<xnox> jbicha: but I don't know about about localised and / or ubuntu books etc.
<xnox> jbicha: ok, thanks.
<jbicha> I've not heard any one from the Ubuntu books complain yet, I don't think it will cause a problem for the Ubuntu Manual
<TheLordOfTime> whoops, wrong location to ask, sorry
<jbicha> does the crypt stuff add new strings for translation though?
<jbicha> TheLordOfTime: if it's help.ubuntu.com/community you should be able to update the wiki yourself; otherwise yeah you can file a bug
<xnox> jbicha: no it does not. I have added the strings in advance before translation freeze.
<xnox> jbicha: I had all the mock-ups so I new the strings up front =) and I withhold urges to change strings.
 * xnox withheld?
<Laney> i'd say resisted
 * xnox chooses native speaker option. 
<xnox> I resisted urges to change strings =)
<Caesar> Could someone running quantal please do cal | hexdump -C and stick the output in a pastebin for me? Want to see if a bug in precise is still in quantal
<xnox> Caesar: http://paste.ubuntu.com/1213597/
<Caesar> Thanks xnox
<trism> weird message from launchpad about being unable to import the translations in es.po from gnome-control-center 1:3.4.2-0ubuntu15, looking at the file there are a bunch of carriage returns which it seems to be failing on. It isn't part of the diff from ubuntu14 to ubuntu15 so it must have been in the last upload as well, should I worry about it?
<xnox> trism: don't worry about it =)
 * xnox had similar one before
<trism> xnox: alright, thanks :)
<xnox> trism: lp side fails to parse some bits which are actually valid or something like that.
<bdmurray> stgraber: testing bug 946406 with a 12.04.1 iso I am not able to recreate it
<ubottu> Launchpad bug 946406 in casper (Ubuntu Quantal) "suspect race condition Keyboard layout, oem-config not set on persistent USB image" [High,Incomplete] https://launchpad.net/bugs/946406
<stgraber> bdmurray: yeah, I know but the italians say they can...
<stgraber> bdmurray: added a comment asking for a lot more details on what exactly they're doing
<mwhudson> obscure question i guess, but why might an upstart job that has
<mwhudson> start on runlevel [23]
<mwhudson> not start on boot?
<mwhudson> this is on a nano image on a beagle xm fwiw
<mwhudson> i've added --verbose to the kernels args and see _some_ upstart activity...
<sarnold> what does runlevel(8) report as the runlevel once your system is running?
<mwhudson> ah so you see
<mwhudson> the fun thing is that i can't get into the system :-)
<sarnold> oh! that's fun. :)
<mwhudson> the upstart job i am curious about is the one that starts a console on the serial line
<mwhudson> and the image doesn't have openssh or anything like that
<sarnold> is openssh-server too large for th...
<sarnold> drat :)
<mwhudson> i can mount the sd card and play chroot games i guess
<mwhudson> not sure how i'd determine the ip address though
<sarnold> dhcpd logs?
<mwhudson> i guess
<sarnold> tcpdump and look for arp who-has requests? IIRC the Linux stack will query for its own IP when coming online..
<mwhudson> hee /sbin/ldconfig: 15: cannot create /dev/null: Permission denied
<mwhudson> i guess i forgot something when chrooting then
<mwhudson> oh what, i boot it with a network cable attached and i get the console on the serial line
<mwhudson> nevermind though
<sarnold> mwhudson: heh, but if you unplug the nic the serial console goes away too?
<mwhudson> sarnold: don't know
<mwhudson> sarnold: don't actually care either :)
<sarnold> :)
<mwhudson> (i'm just using the device to test some host-side debugging stuff, i just need it running)
#ubuntu-devel 2012-09-19
<ndowens> I am packaging newlisp to be put into a PPA, and it is version 10.4.4, when I try ucan --report-status it gives me newlisp-wiki and newlisp-ide is newer. I am only packaging newlisp itself
<ndowens> The download url is http://newlisp.org/downloads/newlisp-(.*)\.tgz
<ndowens> in the watch file
<ndowens> i tried to mangle wiki and then it gives that ide is newer, I can't figure out how to use multiple mangle
<ndowens> never mind figured it out
<infinity> ndowens: newlisp-([\d\.]*).tgz?
<infinity> Or nevermind, if you got there just now. :P
<ndowens> heh. yea the \d\ thing worked :)
<infinity> \d and \. actually.
<infinity> As in "only strings that match a sequence of \d (digits) and/or \. (dot).
<infinity> "
<cjwatson> Except \. doesn't mean that within [].
<ndowens> Can you point me to where if arch=386 it would use a dependency than x86_64. It needs ffi.h so i386 would use libffi-dev and then x86_64 would use lib64ffi-dev
<infinity> ndowens: Erm.  What?  It should always be libffi-dev.
<cjwatson> [\d] isn't documented in perlrecharclass(1).  I think uscan(1) is being naughty in documenting this.
<ndowens> ah
<cjwatson> I'd write it either [[:digit:].]* or (?:\d|\.)*
<ndowens> figured there would be a different dep, because there is a libffi-dev package and then lib64ffi-dev
<infinity> cjwatson: It's documented in pcrepattern(3)
<cjwatson> ndowens: lib64ffi-dev is only for when building 64-bit programs on i386, which is a rare case.
<infinity> cjwatson: Generic character types.
<ndowens> k. i package newlisp for Fedora, so I have to use conditonals for the diff deps
<cjwatson> infinity: Yes.  I think that's cheating since uscan uses actual Perl regexps, though :)
<infinity> cjwatson: Oh, I didn't realise it was actually perl.
<infinity> Though, I suppose it makes sense that it is.
<infinity> What sort of loon would write that in C?
<cjwatson> ndowens: There is a syntax for that (libffi-dev [i386] | lib64ffi-dev [amd64]) but you almost certainly do not want to use it here.
<infinity> cjwatson: So, this is a case of the tail wagging the dog, and Perl has become PCRE-compatible? :P
<ndowens> heh. Seems Perl is used alot for code replacement annd such
<cjwatson> ndowens: As a matter of design we try to avoid using different library paths or package names for the default form of a library on different architectures.
<infinity> (Or, knowing Perl, it probably always had the undocumented shorthand forms, and PCRE just dutifully replicated it)
<cjwatson> Yeah, more likely that the docs are incomplete.
<cjwatson> Or that I'm failing to find the documentation of this.
<sarnold> cjwatson: perlreref(1) documents  \d and \D as "work within or without a character class."
<infinity> cjwatson: The strange bit here being that my brain saw the perlre(1) reference at the end of uscan(1) and just went "finger, yo, type 'man pcre'".
<ndowens> I use to dislike Ubuntu, so I used Debian. Main reason was because I like the rolling-distro idea, and I used Debian unstable for the latest apps
<ndowens> Ihave a package in Debian currently. So I figure I would just play around with packaging in PPA
<cjwatson> sarnold: Ah, yes.  Thanks.
<cjwatson> perlre has expanded, er, rather a lot since I last read it start-to-finish.
<infinity> That's because you started cheating on Perl with Python.  You know, that language where you fork sed when you want to do things.
<cjwatson> Which was in about 1999.
<cjwatson> infinity: You're going to make me fix that just as an anti-shaming device, aren't you
<infinity> Nonsense.  If you fix it, I'll have to find something else to pick on you for.
<infinity> And when I run out of code examples, it's going to get nasty and personal instead.
<infinity> So, best to leave it there.
<cjwatson> # XXX: do not fix this bug or else infinity's going to mention that time with the watermelon
<infinity> I thought it was a cantaloupe?
<cjwatson> Shhh.
<jetsaredim> is there a way to get a given package updated from upstream?
<RAOF> jetsaredim: If the package has an active maintainer, they know about the new upstream. If the package does not have an active maintainer, you can become one :)
<jetsaredim> RAOF: i was afraid you'd say that
<RAOF> You were asking for it :)
<RAOF> We're also after feature-freeze, so the default answer to âshould we update this package to a new upstreamâ is going to be ânoâ.
<jetsaredim> its broken
<cjwatson> You can also file a bug, of course, but there's no particular guarantee of when anyone will look at it.  Most of the time the best way to get a package updated is to follow its downstreams step by step: that is, if it's packaged in Debian, file a Debian bug to get the Debian maintainer to package a new version, and then we can sync/merge that into Ubuntu.
<RAOF> If there are particularly good reasons for updating then that answer can become âyesâ :)
<cjwatson> (As a general rule.  There are always exceptions.)
<jetsaredim> how would i figure out if there is a downstream?
<cjwatson> Look at the package changelog and see if it's all Ubuntu or if there are Debian entries there too
<cjwatson> Or http://packages.qa.debian.org/<package name>
 * cjwatson -> second attempt to sleep
<jetsaredim> interestingly enough there is a downstream but its older than the 12.10 package
<pitti> Good morning
<ion> rning
<dholbach> good morning
<didrocks> hey Mr Holbach
<dholbach> Salut Monsieur Rouche - comment Ã§a va aujourd'hui?
<didrocks> dholbach: Ã§a va bien, et toi?
<didrocks> (toujours en train de tousser par contre)
<dholbach> oui, Ã§a va - encore un peu malade, mais Ã§a va
<panchiniak> Hi. This page http://people.canonical.com/~ogra/mobile/ links to a not found one. Is there an update on "Ubuntu UMPC Edition"? Where could I find the cool .img used by ogra?
<xnox> panchiniak: maybe #ubuntu-arm people will know.
<xnox> panchiniak: looks very old, e.g. old branding. Currently for quantal regular Ubuntu Desktop is used on panda boards.
<ev> those of you who use https://errors.ubuntu.com/, please be aware that the latest version of the website drops the launchpad=false option. The information fetched from Launchpad is now loaded asynchronously, so it will not slow down the loading of the most common problems table or cause it to hit a timeout.
<xnox> nice & slick =)
<ev> thanks
<ev> that said, it's still way too slow
<ev> I'm continuously looking into this
<xnox> well I opened the page. Loaded a graph & table; 1-2 seconds and the launchpad settings flashed in for the whole page.
<xnox> ... switching to "most common problems in the past year" failed with "An error occured while trying to load the most common problems" =(
<ev> xnox: what does your javascript console say?
<ev> any errors?
<xnox> hmm... Failed to load resource: the server responded with a status of 504 (Gateway Time-out)
<ev> right
<ev> the request is taking too long
<xnox> ev.... did you create a big website to make fun of my internet connection? =)))))) *giggle*
<ev> I'll see what I can do as I rework the month view into a 30 day window and the day view into a 24 hour one
<ev> xnox: oh no, it's entirely on our side
<xnox> Well past month & day work =)
<ev> xnox: your standard British broadband connection of bits of string and blue tack is not to blame here
<ev> yeah, but at the start of every day the totals drop to 0 and the same goes for the start of the month
<ev> https://bugs.launchpad.net/errors/+bug/1033813 https://bugs.launchpad.net/errors/+bug/1008730
<ubottu> Launchpad bug 1033813 in Errors "report of most common crashes "today" tracks calendar days, becomes useless when the clock rolls over" [Undecided,New]
<ubottu> Launchpad bug 1008730 in Errors ""most common problems in" period label wrong" [Medium,Confirmed]
<xnox> ev: well actually I have Virgin Media cheese strings: 100 Mbps, which actually is 30 Mbps.....
<Laney> it's very location dependent. My VM 100mbit actually is :-)
<Laney> cdimage is good for maxing me out
<ev> :)
<panchiniak> xnox: thank you by the advice. I've seen a regular Ubuntu Desktop running on a Galaxy Tab, but it needs keyboard and mouse attachments. So I thought that that "Ubuntu UMPC Edition" would be enough to take the risks of hacking a non panda board (closed) machine. Otherwise I think I'm going just withdraw from the game.
<tsdgeos> if i have a patch against ubuntu gtk patches, which bzr branch do i have to branch and submit a MR against?
<tsdgeos> https://code.launchpad.net/~ubuntu-branches/ubuntu/quantal/gtk+3.0/quantal ?
<cjwatson> $ apt-cache showsrc gtk+3.0 | grep -m1 Vcs-Bzr
<cjwatson> Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3
<doko> lucas__, do you have any quick ideas about the ruby-* ftbfs in universe (see http://qa.ubuntuwire.com/ftbfs/)
<tsdgeos> cjwatson: that makes much mroe sense, thanks
<pitti> tsdgeos: FYI, 'debcheckout gtk+3.0' DTRT
<tsdgeos> pitti: neat!
 * tsdgeos shakes fist against quilt
<smoser> anyone around familiar with libvirt?  kind of specific quesiton though.
<smoser> i'm interested in getting it to not run dns server on  network.
<ev> mpt: as it turns out, top-k is complex for arbitrary ranges
<ev> who could've guessed
<mpt> ev, I don't know what that means. What is top-k?
<ev> so for a set of dates, get the 100 items with the greatest count
<SpamapS> oh yeah
<SpamapS> thats been perplexing database folks for years
<SpamapS> ev: materialized views of common ranges are the simplest answer
<SpamapS> but, not the most flexible
<lifeless> ev: distributed map reduce.
<lifeless> ev: clearly the answer.
<ev> lifeless: storm?
<ev> have you played with it yet, or any alternatives for that matter?
<lifeless> its on my when-I-get-time-to-scratch-myself list.
<ev> SpamapS: indeed - we can do that for the month view (get the past 30 days once a day, calculate, stuff somewhere), but for anything where realtime counts (like the past 24 hours making up a day) we're boned
<ev> this is for the most common problems table on errors.ubuntu.com, for what it's worth
<ev> lifeless: looks like I've got an itch :)
<lifeless> ev: I can suggest an iterative algorithm that will stop short of a full scan
<ev> lifeless: please do
<ev> SpamapS: or indeed when people select arbitrary date ranges for the table
<lifeless> ev: take the topk from each bucket, sum common values together and order; take lowest value V, then retrieve all items from each bucket where the count in that bucket is >= V/buckets.
<lifeless> ev: sum and order again, cut at k, and say fuckit, thats good enough.
<ev> ah excellent
<ev> so that will require sorted buckets
<lifeless> this is off the cuff at 1am.
<lifeless> It may be terrible.
<ev> so intermediary column families as cassandra doesn't support counters as part of a composite column name
<ev> so no real time
<ev> hm
<lifeless> alternatively, maintain a sliding window topK family
<lifeless> pick the ranges you want to support, and walk them forward
<ev> still trying to wrap my head around this: http://www.acunu.com/2/post/2012/07/approximate-analytics.html
<ev> and this http://www.cs.ucsb.edu/research/tech_reports/reports/2005-14.pdf
<lifeless> in my tabs now, will read tomorrow
<ev> lifeless: can you elaborate? (whenever you have time, that is)
<ev> I don't want to keep you up
<ev> but I'm not sure I follow what you mean by a sliding window top k family
<ev> I'm assuming this involves timeuuids, I'm just not sure how :)
<lifeless> ev: so, I'm thinking about the following two questions
<lifeless> if you have a time range T, and some topK data in it - e.g. the top(K*2) or something
<lifeless> and you wanted to know for range T+1, ending one bucket width later
<lifeless> what the topK would be
<lifeless> under what conditions would something that isn't topK in T become topK in T+1
<lifeless> under what conditions would something that is topK in T stop being topK in T+1
<lifeless> then repeat that for the case where you have T but want to know for T where you reduce it by one day
<lifeless> bucket
<lifeless> thing
<lifeless> if you could do that fairly efficiently
<lifeless> you could get T shifted by - say- 2 buckets, in realtime
<lifeless> and just keep some number of T's prepped ready to roll, and a 'head' T that you update every day to keep things moving forward and answer 'lastT' queries
 * lifeless stops handwaving
<ev> yeah, I'm just not sure the data makes that possible. Of course these papers I'm skimming seem to argue in your direction :)
<lifeless> ev: things like, if in the +1 bucket you have some count for value V of N, it can only become topK, if the count of V in T +N > topk[k]
<xnox> for what it's worth postgres 9.2 supports ranges natively, I don't know how good the performance is as I have not played with it yet.
<xnox> http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.2#Range_Types
<xnox> and it can give you intersections....
<xnox> but you are not using posgres at all are you, ev?
<xnox> use postgres 9.2. db as a "cache" for the top-k view..... lol
<ev> lifeless: right, but if we looked at 24 hours of data, broken down in to hour buckets, and in all the hours except the most recent, a key has a value of 0, but has a value greater than the highest in top-k, it breaks down surely
<ev> which is entirely possible when we're talking about crash signatures mapping to their frequency
<ev> an issue lands and it suddenly spikes
<ev> xnox: well you joke, but one option (before we got into this arbitrary range thing) was to use redis for the top-k
<lifeless> ev: well, say your T range is 24 hours
<lifeless> ev: so you want to merge in one additional hour
<lifeless> ev: if its greater than any of the top-k in that hour, that key will be added in, no prob
<ev> right
<ev> ah
<lifeless> ev: you can get to two hours by induction
<lifeless> ev: so if it takes 10 seconds to load the nearest T range
<lifeless> ev: and 20 seconds per day
<lifeless> ev: you could do 3 days out in 70 seconds
<lifeless> ev: and run T's overlapping by day, with <=3 days to the nearest T
<lifeless> ev: night
<ev> lifeless: thanks and goodnight
<ev> I'll try to make sense of all that now :)
<SpamapS> ev: to the map/reduce point, this is pretty much the approach the twitters of the world use to get realtime stats
<ev> SpamapS: ja. Nathan Marz of Twitter wrote Storm
<ev> though I think they had something in place before that came on the scene
<SpamapS> probably
<stokachu> xnox: whats the imap sync package you maintain?
<xnox> stokachu: offlineimap ?
<stokachu> xnox: yea, does that fetch all sub-folders too?
<xnox> stokachu: yeah
<stokachu> ok cool thanks
<xnox> stokachu: you can specify python filters if you need to e.g. include only those folders that contain interesting names/topics/ and e.g. to exclude big and boring.
<xnox> stokachu: I then sync all of that to a local imap server and access it with thunderbird or any other sensible client (emacs)
<stokachu> xnox: cool yea this is exactly what i was looking for
<stokachu> fetchmail doesn't do all folders without specifying each one
<xnox> stokachu: offlineimap can sync all the read/unread flags two-way =) which fetchmail can't
<xnox> stokachu: and offlineimap is two-way sync
<xnox> stokachu: you can set read-only if you need / want
<stokachu> xnox: do i have to run it on my shell for canonical email?
<stokachu> for the 2-way sync
<xnox> stokachu: no. you run it anywhere. It works via IMAP(S) protocol.
<stokachu> ah ok
<xnox> stokachu: e.g. I run offlineimap on my laptop.
<stokachu> folderfilter = lambda folder: folder.startswith('MyLabel')  <- thats awesome
<stokachu> xnox: this app is so awesome
<xnox> stokachu: mind the gap.... that is mind the memory leaks, you may want to do `offlineimap -o` (run-once) if you are affected by the memory leaks
<xnox> patches welcome ;-)
<stokachu> haha ok
<xnox> stokachu: also if you have a lot of mail use: status_backend = sqlite
<xnox> to speed things up.
<stokachu> xnox: cool yea i set that up with max connections 2
<mpt> ev, what time of day does the graph update?
<ev> mpt: I suspect that's broken.
<ev> I've been manually updating it despite my branch to do it in cron landing
<ev> will look at that in a bit
<ev> still trying to brain dump the previous conversation
<mpt> k
<smoser> anyone have ideas?
<smoser> if i run ubuntu-bug on a quantal instance today i see
<smoser> Cannot connect to crash database, please check your Internet connection.
<smoser> 'int' object has no attribute 'isspace'
<mitya57> smoser: bug 1052754
<ubottu> Launchpad bug 1052754 in apport (Ubuntu) "apport-gtk crashed with AttributeError in _filter_tag_names(): 'int' object has no attribute 'isspace'" [Medium,Confirmed] https://launchpad.net/bugs/1052754
<smoser> mitya57, thanks
<bgamari> Does anyone know anything about Xorg crashing in quantal right after logging in?
<bgamari> This is on an Intel i915 box
<bgamari> It might not be a crash since from the backtrace it seems that Xorg is falling gracefully out of its event loop
<bgamari> unfortunately I'm not really sure what else to blame it on
<bgamari> On attempting to login lightdm disappears, things look for a second like I'll be dropped into a session, then suddenly I'm back at lightdm
<bgamari> Ahh, the guest session works so it seems the user's session is crashing
<xnox> bgamari: does it crash with a brand-spanking new user account?
<bgamari> about to find out
<bgamari> looking through the failing user's .xsession-errors turns up quite a number of errors
<xnox> bgamari: $ ubuntu-bug xorg ?
<bgamari> although it's unclear whether this is the failing session or simply the end of the last working session
<bgamari> xnox, Brand new user succeeds
<xnox> bgamari: check your user settings or start-up apps? did you tinker with compiz or .profile?
<bgamari> xnox, .xession-errors isn't touched during login of the failing account
<xnox> horum
<bgamari> So it's unlikely that compiz or start-up apps are the culprit
<cjwatson> bryceh: the package-team-mapping spreadsheet I have maps coq to universe, but https://bazaar.launchpad.net/~bryce/arsenal/2.x/view/head:/reports/package-team-mapping.csv maps coq to foundations.  Do you know (a) what reports.qa actually looks at directly and (b) what needs to be done to fix this and get coq bugs off our list?
<jamespage> james_w, would you be able to take a look at the packaging branch for oprofile? it appears to be quite broken and arosales is trying to ressurect it for quantal
<james_w> jamespage, I'll take a look
<arosales> james_w: specifically when I do a branch of oprofile for oneiric I get http://paste.ubuntu.com/1215045/
<cjwatson> mvo: does bug 1016040 ring any bells?  I hope I was correct in reassigning to apt; the cache code breaks my head
<ubottu> Launchpad bug 1016040 in apt (Ubuntu) "apt_check.py crashed with SIGSEGV in FileName()" [Medium,Confirmed] https://launchpad.net/bugs/1016040
<james_w> arosales, ah
<mvo> cjwatson: that sounds right to reassign
<james_w> arosales, sounds like https://bugs.launchpad.net/bzr/+bug/888615 see the last two comments
<ubottu> Launchpad bug 888615 in Bazaar "UDD branch freshness checker breaks on incomplete history" [High,Confirmed]
<arosales> james_w: taking a look . . .
<arosales> james_w: doing the suggestion in comment 4 looks to have worked around the issue http://paste.ubuntu.com/1215054/
<james_w> great
<arosales> james_w: thanks for the pointer. Looks like the bug is still under investigation, but the work around does indeed work, thanks!
<arosales> jamespage: thanks for getting sync'ed up with james_w
<arosales> jamespage: I mean thanks for helping me get sync'ed up with james_w
<arosales> :-)
<jamespage> np
<plars> didrocks: hi, quick question for you.  I'm working on upgrade testing and upgrading from precise-quantal seems to fail to preserve keyboard shortcuts right now.  I think this is pretty much the same as https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1041169.  Is that something already on your radar, or do you want a different bug for this, since that one was against the +bzr package?
<ubottu> Launchpad bug 1041169 in compiz (Ubuntu) "custom keyboard shortcuts not migrated after upgrade to compiz 1:0.9.8+bzr3319-0ubuntu2 " [Low,Confirmed]
<cjwatson> psivaa: is there any way to get even manual logs for bug 1052605?
<ubottu> Launchpad bug 1052605 in update-manager (Ubuntu) "ERROR:root:getListFromFile: no '/usr/share/update-manager/removal_blacklist.cfg' found: exception during Precise to Quantal upgrade on amd64+mac" [Undecided,New] https://launchpad.net/bugs/1052605
<cjwatson> psivaa: a tarball of /var/log/, perhaps
<cjwatson> psivaa: I have some suspicions but I need to know the order in which things have happened here
<psivaa> cjwatson, just destroyed the machine and doing some fresh install, with released version of precise, with the intention of reproducing it
<didrocks> plars: it's on our radar, unfortunately, we don't have a good story to fix the bug
<didrocks> plars: it will get better, but not ideal
<didrocks> with tomorrow's update
<plars> didrocks: what do you mean by a good story? is that something I can help with?
<didrocks> plars: if you know about debugging glib/gsettings and the dconf writer at its root, yeah :)
<Riddell> stgraber: can you give me admin on http://packages.qa.dev.stgraber.org/ ?
<Riddell> me and baloons are looking at testcases
<plars> didrocks: no, sorry, but I'd be happy to provide more details or work with someone to help debug if needed
<cjwatson> psivaa: thanks; I'll mark incomplete for now
<didrocks> plars: we know exactly what is happening, just don't know how to fix it
<psivaa> cjwatson, ack
<plars> didrocks: on an unrelated note, I get a lot of compiz crashes trying to run tests under kvm, and not sure how to capture more on it.  apport fails to actually open a bug on it, and after rebooting I get kicked out on login.  Any idea if this is something well known already? I haven't seen it on real hardware so far, but most of my testing is on kvm at the moment
<cjwatson> psivaa: also, bug 1050436 - is it reasonably straightforward to find out if this happens on precise as well?
<ubottu> Launchpad bug 1050436 in grub2 (Ubuntu) "USB keyboard is not recognized on mac mini during the grub menu" [High,Confirmed] https://launchpad.net/bugs/1050436
<didrocks> plars: it's when you close a window right?
<plars> didrocks: near as I can tell, at least the xorg crash is the same as https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1043513
<ubottu> Launchpad bug 1043513 in xorg-server (Ubuntu) "Xorg crashed with SIGABRT in memcpy() via cirRefreshArea() under KVM virtual machine" [Medium,Confirmed]
<didrocks> plars: tomorrow, there is a compiz upload fixing most of them
<stgraber> Riddell: you should be admin as a member of ~ubuntu-release. Maybe try to logout and login again, making sure the ubuntu-release checkbox is ticked on the SSO login page?
<didrocks> plars: can you please ping me back after this upload?
<plars> didrocks: no, in this case, it was when trying to change the theme
<plars> didrocks: will do
<plars> thanks!
<didrocks> plars: yeah, same
<psivaa> cjwatson, i saw that's happening in precise as well
<didrocks> plars: juts keep me posted then, thanks :)
<plars> didrocks: will do, thanks
<didrocks> thanks to you :)
<cjwatson> psivaa: ok, thanks
<cjwatson> psivaa: if I threw up a random test package somewhere would you be able to give it a go?
<bgamari> xnox, Yeah, I'm not really sure how to approach this short of wiping ~/.*
<cjwatson> there's one post-2.00 patch upstream that *might* be relevant
<bgamari> It seems to throw up so early that there's no evidence to help identify the issue
<xnox> bgamari: ? i am sorry, context?
<bgamari> Anyone know how to debug issues early in X session setup?
<bgamari> xnox, Regarding the X session crash right after login on quantal
<psivaa> cjwatson, i also reported another bug re: usb keyboard on amd64+mac, bug 1050855. and yes i could try the fix later today
<ubottu> Launchpad bug 1050855 in linux (Ubuntu) "External USB keyboard stops working when d-i starts on mac mini" [High,Confirmed] https://launchpad.net/bugs/1050855
<bgamari> It seems that XFCE starts as expected
<bgamari> So it's just a Unity/Gnome issue
<cjwatson> psivaa: OK - not related to bug 1017879 FWIW, as in that case it worked in the desktop CD
<ubottu> Launchpad bug 1017879 in linux (Ubuntu Quantal) "External USB keyboard stops working when d-i starts" [Critical,Fix released] https://launchpad.net/bugs/1017879
<psivaa> cjwatson, yes hence a new bug :)
<cjwatson> right, but you said it was very similar to that other bug, and I'm just pointing out the important distinction that means it would require a different (and typically harder) kind of fix
<psivaa> cjwatson, understand
<bryceh> cjwatson, I've made the change in bzr and will coordinate with bdmurry on getting reports.qa updated.
<bryceh> cjwatson, I believe the data originates from kate so we may need to make sure her coq mapping is correct as well.
<bdmurray> cjwatson: I updated the spreadsheet during or after the meeting and the reports will be updated shortly
<cjwatson> bryceh,bdmurray: great, thanks
<cjwatson> bryceh: I did check the coq mapping in what I believe is Kate's spreadsheet
<brendand> before i go wasting my time, does anyone know of a very simple script to file bugs in launchpad against a specified project? i'm not talking about ubuntu-bug style, just want to give a project name, a title and description and be done
<bryceh> brendand, I don't know if such a script already exists but would be trivial to make using lpltk
<cjwatson> or plain launchpadlib come to that
<bryceh> even launchpadlib, although you'd need to muss with credentials and such, but probably could cargo cult that
<cjwatson> It's hardly difficult
<brendand> nope, hardly difficult
<cjwatson> launchpad = Launchpad.login_with("lp-file-bug", "production")
<cjwatson> done
<smoser> hey. maybe someone can help me.
<smoser> i'm really out of ideas.
<smoser> bug 1052664
<ubottu> Launchpad bug 1052664 in cloud-init (Ubuntu) "hostname intermittently contains comment from cloud-init" [Medium,Confirmed] https://launchpad.net/bugs/1052664
<smoser> it seems to me, that when invoked in boot (and only intermittently even then), 'hostname -b -F /etc/hostname' does not ignore '#' comments.
<smoser> i know you're going to tell me that doesnt make sense.
<smoser> it doesnt
<smoser> come on.
<smoser> someone has to be able to spot what i'm doing wrong there, or at least tell me i'm compeltely wrong.
<sarnold> smoser: is /bin/hostname at early boot provided by e.g. busybox in an initrd/initramfs and _doesn't_ ignore the # ?
<SpamapS> cjwatson: would you expect boot-time fscks on Ubuntu server to display the same level of detail on the plymouth details plugin as they do on the graphical plymouth bootup?
 * SpamapS apologizes for the weird parsing required to udnerstand that
<lamont> in the new world of quantal, how do I tell nautilus to burn an iso to the CDR?  "write to disk" seems to have gone *poof*
<smoser> sarnold, i had that thought, possibly that the initramfs was opening it. but my wrapped script did get called by the upstart job (which starts on 'starting').
<smoser> so really outside of the initramfs setting it, i dont know what would do it.
<smoser> and then, even if the initramfs set it wrong,the real /bin/hostname was told to set it, so it should have done that.
<bryceh> brendand, in any case let me know if you write the script, I'd like to include such a script in lpltk
<obounaim> Can anybody review my merge proposal.
<bryceh> infinity, if you're still around, alberto uploaded nvidia-graphics-drivers-experimental-304 to replace nvidia-graphics-drivers-experimental.  Same bits as before, just the corrected name.  Mind waving it through NEW?
<bryceh> infinity, there is also a nvidia-settings-experimental-304 to replace nvidia-settings-experimental, so the latter should be dropped from the archive
<sarnold> smoser: the /bin/hostname source code even looks like it should match the description given in the manpage. I'm as confused as you. Is something calling hostname(2) directly without going through the /bin/hostname program?
<infinity> bryceh: Looks like someone else NEWed them, but I'll make sure everything's sane WRT old versions being removed, etc.
<smoser> sarnold, oh. good you're still paying attention.
<smoser> i thoguht that too
<smoser> and that is possible
<smoser> however, i updated the wrapper program
<smoser> http://paste.ubuntu.com/1215249/
<smoser> so *if* that is the case, then that other hostname setter ran in between my read, invoke, read
<bryceh> infinity, thanks
<sarnold> smoser: that's a _good_ one. Wow.
<smoser> the other hint is that this seems a recent regression.
<smoser> i've only ever seen this in builds from today.
<smoser> i've also grepped through /etc/ for occurence of '/etc/hostname' in the hope that whatever was doing it would showup there.
<smoser> but the only time that string occurs is in the upstart job
<smoser> sarnold, you want to poke at this system and see if you cant make heads or tails of this ?
<smoser> i'm just completely baffled.
<smoser> i can't waste more time on it and i'm just going to remove the comment from the file
<smoser> but i'd love to knwo what is going on
<sarnold> smoser: I'm not sure what i'd do next. aiming the kernel tracing at it seems most likely, but I don't know that off the top of my head, sorry
<smoser> i straced
<smoser> and i see hostname calling without the '#'
<smoser> so it really seems like some other thing is reading that file
<mdeslaur> smoser: what's echo $HOSTNAME give you?
<smoser> the garbage
<smoser> its really annoying.
<smoser> its in my prompt
<mdeslaur> smoser: what about uname -a?
<smoser> garbage
<smoser> it *did* set the hostname to that.
<mdeslaur> smoser: dhcp or fixed ip?
<smoser> dhcp.
<smoser> i considered that too
<smoser> but the race just seems so odd
<mdeslaur> could it be racing with dhclient-script?
<smoser> you're thinking ddns ? and dhcp setting it.
<smoser> yeah.
<smoser> but *every time* i hit this race.
<mdeslaur> maybe try commenting it out in dhclient-script just for kicks?
<smoser> mdeslaur, it sure doesn't look like it is doing it.
<smoser> i put a print right there, and its not calling it
<mdeslaur> hrm
<smoser> fixed
<smoser> sudo apt-get --purge remove network-manager
<mdeslaur> smoser: oh! what was it?
<smoser> GAH!
<mdeslaur> on server??
<smoser> this was on desktop cloud image
<smoser> but i sweare i saw it in server
<smoser> but i must hvae been wrong
<sarnold> smoser: excellent! :) well. Sortof. Stupid NM.
<smoser> yeah, i'm gonna hope a bug on it.
<smoser> and then stop cloud-init from writing a comment there.
<cjwatson> SpamapS: I don't quite recall, TBH; I think I would expect them to provide whatever you'd get by calling the appropriate fsck command from a console
<cjwatson> it's possible the -C (?) progress interface gives the smarter splashes more than that
<SpamapS> indeed, we have 'console output' on mountall, which runs the fsck, and I don't see where mountall closes stdout/stderr so it should arrive on console
<brendand> bryceh - this is the basics. i used launchpadlib directly: https://code.launchpad.net/~brendan-donegan/+junk/lp-file-bug
<bryceh> brendand, thanks
<brendand> bryceh - where are you going to put it? i can propose a merge, no problem
<bryceh> brendand, the scripts directory of python-launchpadlib-toolkit, once I finish a couple MIR+SRUs
<bryceh> merge proposals to https://code.launchpad.net/~arsenal-devel/lpltk/2.x
<brendand> bryceh, LaunchpadService.create_bug insists on filing into a package?
<bryceh> brendand, it expects that yes, but that can certainly be changed to be optional.
<bryceh> bbiab (AC repairman coming)
<cjwatson> psivaa: deb http://people.canonical.com/~cjwatson/tmp/grub2/for-psivaa/ ./
<cjwatson> (unsigned)
<brendand> bryceh, hopefully all in order: https://code.launchpad.net/~brendan-donegan/lpltk/lp-file-bug-lpltk/+merge/125346
<ubottu> Launchpad bug 125346 in util-linux (Ubuntu) "package util-linux 2.12r-19ubuntu2 failed to install/upgrade: problemas de dependencias - se deja sin configurar" [Undecided,Invalid]
<psivaa> cjwatson, thanks, ill give it a try in a little while
<cjwatson> may not make much difference, but based on https://lists.gnu.org/archive/html/grub-devel/2012-07/msg00053.html and upthread
<cjwatson> "broken BIOSes" is often a decent characterisation of Macs, so it's possible :-)
<bryceh> brendand, thanks, merged
<brendand> bryceh, was it added to scripts so that if i install lpltk it will be in the path?
<bryceh> brendand, yep
<brendand> bryce - heh. tiny little typo in there :/
<bryceh> brendand, oh?
<brendand> yeah, i'll push something real quick
<bryceh> ok cool
<bryceh> $ ./scripts/lp-file-bug foobar
<bryceh> ... NameError: global name 'CalledProcessError' is not defined
<brendand> oh, sure i'll take care of that too
<brendand> but that's weird. CalledProcess is part of python subprocess. is it removed from your system somehow?
<jtaylor> its subprocess.CalledProcessError
<jtaylor> no global name
<bryceh> brendand, fwiw I ran it on a precise box, if that matters
<brendand> ok, i'm on it
<brendand> oh wait, do you have nano installed?
<brendand> and EDITOR is not set?
<brendand> it wants to use either EDITOR or nano if EDITOR isn't specified
<bryceh> $ echo $EDITOR
<bryceh> emacs -nw
<bryceh> maybe the space screwed it up?
<bryceh> yep
<bryceh> $ EDITOR=emacs ./scripts/lp-file-bug foobar
<bryceh> Unable to file bug in:
<bryceh> 	project: ubuntu
<jtaylor> the argumet brakes it use shlex.split
<psivaa> cjwatson, that did not make it work, i'm afraid.
<psivaa> cjwatson, so i had to make the grub timeout to be -1 inorder for the grub menu to be displayed, that made the grub menu displayed, but none of the keystrokes work on the grub menu
<psivaa> cjwatson, that has now left the system stay on grub menu forever and needs reinstalling :) ( which i will have to do anyway for further testing)
<cjwatson> psivaa: ok, worth a try, thanks.  (you could modify the grub configuration without reinstalling with the aid of a live CD)
<psivaa> cjwatson, i do not have an external cd drive though
<cjwatson> or live USB image
<psivaa> cjwatson, ahh ok, that i could do then, thanks that helps
<psivaa> cjwatson, editing the grub during live session persists?
<cjwatson> psivaa: mounting the target filesystem and saving changes to /boot/grub/grub.cfg within it does
<cjwatson> psivaa: you can also edit /etc/default/grub and run update-grub, which is technically better because you aren't editing generated code, but that's more effort as you have to bind-mount all of /dev, /proc, and /sys into the target system and chroot in
<cjwatson> which you may or may not be familiar with doing
<psivaa> cjwatson, thanks, ill try doing the first, the second option has more newer stuff :)
#ubuntu-devel 2012-09-20
<doko> bryceh, please could you have at the *nvidia* ftbfs in quantal?
<bryceh> doko, do you mean the one waiting on MIR #1053065?
<doko> bryceh, nividia-texture-tools, nvidia-cuda-toolkit, pycuda
<bryceh> doko, ok, those appear unrelated to the MIR but I'll take a look
<|Anthony|> are there any plans to support multiseat setups comparable to how fedora currently does?
<|Anthony|> not with systemd though, but through existing and currently in use (but being developed upstream) software?
<|Anthony|> for example, Xorg has a new -seat option in 7.7
<|Anthony|> is udev going to be forked/maintained for/by *buntu since it has been merged into systemd? If not will there be a replacement, or will it just age?
<sarnold> |Anthony|: ooh, -seat ? sounds cool
<|Anthony|> yeah
<|Anthony|> the more i look into this the more mad i get honestly
<|Anthony|> lennart et al has managed to get their hands into so many system critical things that all distros will have to use systemd
<|Anthony|> udev
<|Anthony|> consolekit
<|Anthony|> the -seat switch in Xorg was introduced to enhance systemd imo
<|Anthony|> </rant>
<|Anthony|> idk why -seat is needed tbh when there is -layout and -config
<|Anthony|> both of which are able to maintain a group of associated hardware
<sarnold> |Anthony|: I've coined the phrase "the lennartisation of Linux" to describe many of the things I've come to dislike or detest...
<sarnold> .. but that's just my own personal opinion. :)
<|Anthony|> it is one that is shared by many
<sarnold> I had hoped, when you first mentioned -seat, that it'd be that cleverl little final piece of glue to make it easy to piece together four video cards, four keyboards, four mice, into a single system with four separate X systems all at once.
<sarnold> (A dream I've seen discussed for 15 years at this point...)
<|Anthony|> if i understand it's purpose, it is used by udev (now systemd) for rule matching
<|Anthony|> sarnold, it already is easy to do that with the version of x included in 12.04
<|Anthony|> very actually
<sarnold> yay!
<|Anthony|> and some simple udev magic to allow hotplugging of input devices makes it nice
<|Anthony|> only headache i have atm is routing audio to each seat
<sarnold> ohhh
<|Anthony|> there is no audio support in X as far as i can tell
<|Anthony|> just video, keyboard and mouse
<|Anthony|> and guess who owns pulseaudio?
<|Anthony|> lennart
<sarnold> (just between you and me, every new install I do I find audio breaks soon... and after half-hour fiddling with knobs, I find that "apt-get purge pulseaudio" seems to fix all the problems and I haven't yet discovered what I'm missing..)
<|Anthony|> pulseaudio has been a fkn thorn in my side for... well since i started in linux 4 years ago
<|Anthony|> i came late to the linux party
<|Anthony|> heh
<sarnold> aha. :) That role used to be played by ALSA, which these days looks downright reliable in comparison.
<|Anthony|> what is the difference between alsa and pulse
<|Anthony|> cause they both run concurrently
<|Anthony|> pulse is a sound server, and alsa is...
<|Anthony|> i know the acronym but what it really is escapes me
<sarnold> ALSA is the kernel interface between the /dev/dsp, /dev/mixer, etc. userspace interfaces and the soundcards
<sarnold> ALSA is just a pile of modules that run in the kernel.
<|Anthony|> ah
<|Anthony|> and pulse manages it in userspace?
<sarnold> I _think_ pulse is supposed to provide per-application mixers, volume levels, etc.
<sarnold> but I've never seen that interface.
<|Anthony|> haha
<sarnold> anyway, dinner time. good luck :)
<|Anthony|> i'm actually stuck at configuring pulse/alsa for the multiseat setup here
<|Anthony|> and am banging my head cause i have no experience with configuring either one
<mwhudson> totally random underresearched question, but is it possible that something removes /etc/resolv.conf when networking goes down?
<mwhudson> one way to find out i guess
<slangasek> mwhudson: nothing that's not buggy does so :/
<mwhudson> heh
<mwhudson> slangasek: so this is a linaro/lava thing
<mwhudson> we deploy a test rootfs, boot into it, reboot into the master rootfs and the resolv.conf is gone from the testrootfs partition
<mwhudson> ... sometimes
<slangasek> hmm
<slangasek> is this using resolvconf?  i.e., /etc/resolv.conf is a symlink into /run?
<mwhudson> i think it's precise ubuntu-desktop based image
<mwhudson> which means... yes?  i think so?
<mwhudson> downloading the image now to poke at, but it's 600 megs compressed so...
<slangasek> mwhudson: ack, with precise it should be a symlink.  Is it /etc/resolv.conf itself that disappears, or only the target of it?
<mwhudson> slangasek: OperationFailed: executing 'cp -f /mnt/testrootfs/etc/resolv.conf /mnt/testrootfs/etc/resolv.conf.bak' failed with code 1
<mwhudson> slangasek: which suggests the symlink is gone
 * slangasek nods
<bryceh> doko_, found a patch for the first package, looks like upstream just doesn't test 64-bit.  Contacted Debian as they may want the patch too.  The other two build failures are basically due to bug #950963; dunno what to do there, but I'll contact alberto.
<ubottu> Launchpad bug 950963 in nvidia-graphics-drivers (Ubuntu) "nvidia-graphics-drivers needs to provide separate packages such as libcuda1" [High,Triaged] https://launchpad.net/bugs/950963
<pitti> Good morning
<lifeless> ev: looks like [1] B. Babcock and C. Olston. Distributed top-k moni-
<lifeless> toring. In Proc. of Intl. Conf. on Managment of Data
<lifeless> (SIGMOD), pages 563â574, 2003.
<lifeless> might be relevant
<lifeless> ev:  Threshold Algorithm
<lifeless> ev: appears to be what I off-the-cuffed, though I haven't read the details to be fully sure
<diwic> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: diwic
<pitti> cyphermox, stgraber: I just filed bug 1053236 after a friend's upgrade to precise got a bricked DNS; did that ever come up before? (I didn't find dupes)
<ubottu> Launchpad bug 1053236 in network-manager (Ubuntu) "does not write static nameservers into resolvconf config" [Undecided,New] https://launchpad.net/bugs/1053236
<dholbach> good morning
<diwic> good morning dholbach
<dholbach> hi diwic
<diwic> dholbach, if a commit contains changes in the .pc directory, is that a valid needs-fixing complaint?
<jibel> pitti, http://paste.ubuntu.com/1216255/ when I click on 'send' after running 'ubuntu-bug cloud-init' is it known ?
<pitti> jibel: yes, I uploaded the fix an hour or so ago
<jibel> pitti, ok, thanks.
<pitti> sorry about that
<jibel> pitti, no problem, I'll go the manual way
<dholbach> diwic, no, not really - I think I'd just fix it myself and upload it - in most cases it's our tools' fault :-(
<didrocks> pitti: wasn't that the secret solution for not having any new bug anymore? :)
<pitti> jibel: or download python-apport from https://launchpad.net/ubuntu/+source/apport/2.5.2-0ubuntu4/+build/3800238
<pitti> didrocks: *shht*
 * didrocks hugs pitti
 * pitti hugs didrocks back
<diwic> dholbach, ah ok. Well, that could have made sense if I could upload...as such I will try to spend my patch pilot time on alsa/pulseaudio bugs with patches in them
<dholbach> I guess you could just ask in the channel for somebody to upload it if it looks alright to you
 * dholbach takes the dog for a walk - brb
<jibel> all the autopackagetest runs will fail today (https://jenkins.qa.ubuntu.com/view/Quantal/view/AutoPkg%20Test/) until I figure how to manually fix it. There is a bug in cloud-init 0.7.0~bzr659-0ubuntu1 that breaks the images we use as testbed.
<pitti> that's actually not a bad test by itself :)
<kyan> Hi, where should I ask a build error question?
<xnox> !ask|kyan
<ubottu> kyan: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<kyan> xnox: okaaay, it's just that I've gotten blasted a few times for asking in the wrong channel.. Basically I'm trying to build Unity from source (via apt-get source --compile). When I'm building gettext, there's a missing operand error for the command cd debian/gettext/usr/lib && mv libgettextpo.so. ???
<xnox> kyan: please use pastebin (there is nifty commandline package pastebinit) with full error log & version numbers
<cjwatson> the source line for that is:
<cjwatson>         cd debian/$@/usr/lib && mv libgettextpo.so $(DEB_HOST_MULTIARCH)
<cjwatson> so that sounds like you're trying to build it on an older version of Ubuntu
<cjwatson> pre-natty
<cjwatson> kyan: ^- is that so?
<kyan> cjwatson: I'm trying to build it outside of stock Ubuntu.
<kyan> cjwatson: I'm using Wreathe (a Maverick fork) and trying to build Unity in it.
<cjwatson> kyan: then the answer is probably not one you're going to like
<kyan> xnox: Pastebin.com rejected it because it was too long; Pastebin.ca's server still hasn't replied
<kyan> cjwatson: umm, off topic? *That's* why I asked where I should ask the questionâ¦
<kyan> lol
<cjwatson> no, that's not what I meant
<kyan> cjwatson: oh?
<cjwatson> kyan: maverick is sufficiently old that, even if you could build current packages on it, they wouldn't run because the linker there doesn't know about the current multiarch library path
<kyan> cjwatson: Well how were the newer systems created? It seems that I'd need to update it to use the different library path.
<cjwatson> kyan: the only ways to make this work are (a) manually reverse the steps of http://wiki.debian.org/Multiarch/Implementation where applicable for each package you're attempting to build (b) update to a newer base system
<cjwatson> I would strongly recommend (b) if at all possible; (a) is not going to be even a little bit of fun
<kyan> cjwatson: Well why not just update the base system to multiarch?
<cjwatson> kyan: that's http://wiki.debian.org/Multiarch/Bootstrapping, but it is arduous
<kyan> cjwatson: hmmâ¦
<xnox> kyan: pastebin.ubuntu.com should accept large output.
<cjwatson> it would be easier to update to something based off a more recent version of Ubuntu rather than duplicating the (I think) man-weeks or more likely man-months of work involved there
<kyan> cjwatson: Hmm. Couldn't one bootstrap off the later repos though? It seems like the work's already done, so it ought to be easy enough to just build each of the relevant packages in order from the new repos.
<cjwatson> depends on how much you want to trust the directions above to be absolutely complete :)
<cjwatson> sounds like a waste of effort to me, but you can try
<cjwatson> you would probably want to start with natty rather than precise, but I don't recall any more whether there were bugs fixed in the interim that would be relevant ...
 * ogra_ would just upgrade the base ... essentially backporting the packages you need will leave you already with a partitally upgraded system, why not wlak the full distance then ?
<ogra_> *walk
<kyan> cjwatson: Well I'm a little doubtfulâ¦ given that I tried updating dpkg to 1.16 (for multiarch), but it requires a newer gettext (requires multiarch) to build dpkg. Chicken and egg.
<cjwatson> we did this all iteratively in our archive; it would take a long time to reproduce the steps and you won't necessarily be able to jump over multiple ones
<cjwatson> I would expect that the delta between maverick and wreathe is much smaller than the delta between maverick and natty (say)
<cjwatson> so if you think of it that way, it should be easier to rebase wreathe on >=natty
<kyan> ogra_: Well, basically all I want is Unity running simultaneously with the Wreathe Fusion Application Manager.
<cjwatson> wreathe will have to update sooner or later anyway to continue getting security patches
<ogra_> ++
<kyan> cjwatson: That's quite possibly true.
<ogra_> maverick starts to smell already
<kyan> (WFMA=basically it's KDE Plasma and applications mashed up with GNOME 2 and a bit of LXDE).
 * cjwatson looks at dpkg in natty
<cjwatson> it only build-depends on gettext (>= 0.18), which maverick has
<kyan> cjwatson: Hmm. Intriguingâ¦
<cjwatson> it's possible that apt-get source --compile tries to build all the build-deps without considering whether they're already available
<kyan> I was using the dpkg from Quantal, so that might be a problem right there
<cjwatson> or perhaps that if you install the build-deps before trying to build the package in question, that will help
<cjwatson> you definitely won't be able to use dpkg from quantal; maverick's tools won't be able to parse the gettext:any build-dep in use there
<cjwatson> don't try to skip over that much
<cjwatson> we didn't build dpkg/quantal using a maverick build system, after all
<ev> lifeless: cheers! I'll have a look
<kyan> cjwatson: lol good point
<cjwatson> at the very outside you should not expect to be able to skip over an LTS boundary; but in the special case of multiarch, extreme care is needed
<kyan> cjwatson; Aight, let's see how natty sources doâ¦
<kyan> cjwatson: Hmmâ¦ :-P
 * kyan is having his OS development crash course right now
<kyan> XD
<kyan> Huh. Building it from natty sources has dpkg give a bunch of test failuresâ¦
<kyan> http://pastebin.com/gT38BYrx
<kyan> That wasn't what I was expecting.
<kyan> cjwatson: So I guess what it looks like is it doesn't know what the test results ought to be, for some reason or anotherâ¦
<cjwatson> kyan: I'm not sure what that is.  It might indicate that the dpkg-divert program there is broken for some other reason.
<kyan> cjwatson: IDK either. I'm finding some missing development libraries (libbamf-dev wasn't available because of debhelper not being the right version), so I'm going to build them and hope they fix things.
<cjwatson> kyan: libbamf-dev isn't in dpkg's build-dependency chan
<cjwatson> *chain
<kyan> cjwatson: hmmâ¦â¦
<cjwatson> mvo: do you have some time to help me with apt and multiple signatures on a Release file?  I'm trying to upgrade the archive to sign with the new signing key as well, and I'm finding that if I only have the new key installed that gpgv refuses to process the signatures
 * kyan is confused
<kyan> then what was it showing up there for?? XD
<kyan> cjwatson: Anyway I'm trying just bypassing the tests for now.
<cjwatson> mvo: http://paste.ubuntu.com/1216392/
<mitya57> will we sync new lintian when it's released?
<cjwatson> kyan: perhaps you ought to build packages one by one using apt-get source and debuild -b; I'm not particularly sure what apt-get source --compile does these days
<mitya57> (according to nthykier, it will happen after 2012-09-27, when the previous one migrates to testing)
<kyan> cjwatson: ok. I haven't used that method before so it'll be a new experience :P
<Laney> mitya57: probably
 * mitya57 will now bump standards-version of his packages
<Laney> who doesn't love a shiny new Standards-Version?
<cjwatson> mvo: it does work if I have either both keys or only the old one, but this seems like anomalous behaviour
<mitya57> ;)
<mvo> cjwatson: yeah, that sounds wrong, does it matter if gpg or gpgv is used? or same result?
<cjwatson> mvo: looks similar: http://paste.ubuntu.com/1216397/
<cjwatson> mvo: and for completeness: http://paste.ubuntu.com/1216398/
<cjwatson> mvo: I suspect this is a long-running issue - see e.g. http://lists.debian.org/debian-release/2009/06/msg00070.html
<kyan> Now this is weird. grub-common in natty requires dpkg >= 1.15.4, or install-info, or dpkg <=1.14.25. According to gdebi-gtk, those dependencies are broken by updating to dpkg 1.16.0.
<kyan> It seems to me that the dependencies are quite alright.
<kyan> because 1.16.0 is undeniably >=1.15.4, and that *is*, after all, one of the options.
<mvo> cjwatson: let me read the mail
<cjwatson> mvo: oh, maybe it's because the new key uses a different digest algorithm from the old - see gnupg/g10/mainproc.c:2047-2061
<cjwatson> old used SHA-1, new uses SHA-512
<cjwatson> so I guess not really apt's fault - gpg just doesn't provide a way to do this
<lifeless> ev: still digesting more of the stuff
<mvo> cjwatson: right :/
<kyan> ah, just a bug in gdebi-gtk. plain old dpkg handles it fine.
<cjwatson> mvo: ah, here we go
<cjwatson> mvo: if I force --digest-algo SHA1 when signing with the new key, it works
<cjwatson> well, sort of
<mvo> cjwatson: cool
<cjwatson> I still get:
<cjwatson> W: There is no public key available for the following key IDs:
<cjwatson> 40976EAF437D05B5
<mvo> :/
<cjwatson> mvo: but it's non-fatal
<cjwatson> i.e. the archive is still considered properly signed and I can install from it
<mvo> cjwatson: funny coincidence, I was just reporting a upstream gnupg bug (or whishlist) for a --recv-key-strict that actually checks the keyid after the download
<cjwatson> so I think a plan is: for <=precise, sign with only the old key; for quantal, sign with the old key plus the new key with --digest-algo SHA1; at some future point, sign only with the new key with the default digest algorithm for that key
<mvo> cjwatson: right, sounds good
<cjwatson> glad I tested this :-)
<mvo> :)
<mvo> and that you found the sha1 workaround
<cjwatson> yeah.  I'll document it in commentary in lp:ubuntu-archive-publishing
<kyan> cjwatson: wow. dpkg hates me. http://paste.ubuntu.com/1216417/
<cjwatson> not a giant surprise.  use a chroot rather than building in your real system.
<kyan> cjwatson: hehe.
 * kyan asks, "best practices? what are those?!"
<kyan> Anyway is it even possible to run gnome3/Unity and gnome2 simultaneously?
<kyan> That somehow seems a littleâ¦ wrong somehow
<cjwatson> mvo: oh, hey, gpg supports using DSA keys (like the old one) with a SHA-512 hash
<cjwatson> and it seems to work
<cjwatson> I didn't know you could do that
<mvo> woah
<kyan> cjwatson: I'm running into this bug now: https://bugs.launchpad.net/compiz/+bug/1048964
<ubottu> Launchpad bug 1048964 in Compiz "cmake fails on python 2.6 as sys.version_info does not contain major_version or minor_version" [Medium,Confirmed]
 * mvo will go and switch networks
<kyan> cjwatson: I hit that trying to build compiz by itself a while ago.
<cjwatson> ok, sorry, I've run out of time to help with this crazy project :)
<cjwatson> but we've been using cmake on python 2.6 and 2.7 in Ubuntu for some time ...
<kyan> cjwatson: np XD
<kyan> cjwatson: I think the bug is because of a change in how the python version number is gotten by CMake.
<cjwatson> oh, maybe that's a problem in compiz's cmakelists rather than in cmake itself, considering where the bug's filed
<kyan> cjwatson: Yeah I think it is
<cjwatson> again, I wouldn't try to build absolute current compiz on such an old base system
<cjwatson> you are going to have to go step by step if you aren't willing to upgrade the base
<kyan> hmm, well.. that was the whole point of this craziness :P
<kyan> so basically the option is to upgrade to python2.7 (difficult, but I don't know why)
<kyan> and unfortunately I now no longer have a control key.
<kyan> wtf.
<kyan> oh well... back to the drawing board
<doko> tjaalton, bryceh: awake? bug #1053088 needs attention. looking into it now
<ubottu> Launchpad bug 1053088 in mesa (Ubuntu Quantal) "libglapi not linked against pthread" [High,Triaged] https://launchpad.net/bugs/1053088
<tjaalton> doko: yes
<doko> tjaalton, if you do, I won't
<tjaalton> doko: looks like there should be a patch in fedora, I'll steal it
<doko> ok, thanks
<cjwatson> OK, I have told the archive to start signing with both old and new keys
<cjwatson> for >= quantal
<cjwatson> Hopefully my testing was sufficient :-)
<cjwatson> I guess I'll find out in about half an hour ...
<diwic> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<davmor2> hey guys is there meant to be a network-manager indicator for guest sessions?
<davmor2> for me it showed up the first time I switch from my logged in user to guest, but from then on in it didn't show up
<Daviey> bdmurray: hey, what did you do to avoid the regression on bug 1043725 ?
<ubottu> Launchpad bug 1043725 in update-manager (Ubuntu Quantal) "dep8 test test_stop_update.TestStopUpdate failed: missing dependency on update-notifier (schema com.ubuntu.update-notifier missing)" [High,Fix released] https://launchpad.net/bugs/1043725
<cjwatson> Daviey: he put the update-notifier dependency in update-manager rather than in update-manager-core
<Daviey> cjwatson: thanks
<dutchie> cjwatson: popey told me to poke you about a broken boot on a dual-boot machine after updates
<dutchie> cjwatson: i have a grub rescue prompt, ls works, but that's about it
<cjwatson> dutchie: https://www.gnu.org/software/grub/manual/grub.html#GRUB-only-offers-a-rescue-shell
<popey> cjwatson, seems to affect dual-booters like dutchie and myself
<cjwatson> dutchie: then after you get back into the system you should check 'dpkg-reconfigure grub-pc'
<cjwatson> dual-boot systems are often misconfigured in how the boot loader is installed, for one reason or another
<cjwatson> so they end up trying to load half of one boot loader and half of another at boot
<cjwatson> this tends not to work so well
<dutchie> the prefix and root appear to be set right, but "insmod normal" just gives me a file not found
<cjwatson> you should make sure (in 'dpkg-reconfigure grub-pc') that only one of them thinks it owns the boot sector
<cjwatson> you'll need to tell me more about the layout, and what prefix and root currently are, for me to be able to help any further
<dutchie> layout is one disk with btrfs root, ext4 /boot on first disk, second disk with ext4 data (that happens to still have a bootable 12.04 install on it) and windows
<dutchie> prefix is (hd0,msdos1)/grub, root is (hd0,msdos1)
<dutchie> i have to go out now, but i'll leave irc on and have a look when i get back
<dutchie> thanks
<cjwatson> what is the exact file-not-found error message?
<cjwatson> you should be able to 'ls $prefix' to see what that looks like - if this is GRUB 2.00 (quantal) then it should include i386-pc/ somewhere in there
<smb> cjwatson, I believe to remember you doing installer testing in KVM VMs. Would you know why grub would think that qemu (Seabios) is a setup that should use EFI as a framebuffer. I am asking because I was looking at a problem resulting from that and wondering (as I have not heard of that being really used in anything else atm) why that is.
<cjwatson> That sounds like a partial diagnosis; any chance of the original symptoms?
<cjwatson> GRUB can only use EFI video if it's actually an EFI build
<smb> I am not aware that my Precise host is using an EFI build. But the Quantal installation does bring up an EFI FB
<cjwatson> So do you actually mean that Linux is using an EFI framebuffer?
<smb> Which leads to problems because Quantal tries to kick that out and replace it with the cirrusdrmfb in a KVM environment
<smb> cjwatson, yes
<smb> Enabling the text only grub console prevents it and I could not find anything in the kernel deciding for efi fb beside that some info has been set up before
<cjwatson> The only time GRUB will tell Linux to use an EFI framebuffer is if it is using one itself, which only happens if you're using grub-efi-* rather than grub-pc
<cjwatson> Oh, it might be setting GRUB_VIDEO_LINUX_TYPE_SIMPLE
<cjwatson> Which is 0x70
<smb> Ah
<smb> Yeah and I think to remember EFI value as 0x70, too
<doko> pitti, GCC trunk (gcc-snapshot) now has libbacktrace, a library providing stack traces including source name and line number. it's not installed by default, so you would have to look at the sources and the build
<Sweetshark> since there is talk about GRUB here right now:
<Sweetshark> hmmm, installing the quantal daily CD (amd64) in VirtualBox fails to install the bootloader. known issue?
<cjwatson> smb: But that's mostly been there for ages, in precise too I believe
<pitti> doko: ah, interesting; does that also provide function arguments?
<smb> Sweetshark, not that I know of... but I have not tried the daily today
<cjwatson> Sweetshark: yes, bug 1053317
<ubottu> Launchpad bug 1053317 in grub-installer (Ubuntu Quantal) "/usr/share/grub-installer/grub-installer: 57: local: not in a function" [Critical,Fix released] https://launchpad.net/bugs/1053317
<doko> pitti, didn't look, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54515 for an example traceback
<cjwatson> smb: Normally, though, GRUB would be using VBE in qemu/kvm
<smb> cjwatson, That is possible. The special drm driver for the cirrus card used in qemu just has been added with newer kernels
<ubottu> gcc.gnu.org bug 54515 in middle-end "cc1plus sigsegv -O2 anonymous namespace" [Normal,Resolved: fixed]
<cjwatson> smb: Possibly the all_video work has meant that it ends up preferring cirrus ...
<cjwatson> smb: Is this easily reproducible in kvm with quantal images and no funny business?
<dutchie> cjwatson: i can see i386-pc, which contains a normal.mod file. the message is just "error: file not found"
<Sweetshark> cjwatson: k, thanks.
<smb> cjwatson, Relative. The fact that it races on replacing the fb happens not always and the result is sometimes you can get unity desktop running and sometimes it crashes
<smb> cjwatson, Just because if it fails the cirrus X driver gets used (but that crashes), if not the modeset X driver gets used.
<smb> cjwatson, You would see the failure by grepping for "cirrus" in dmesg
<cjwatson> dutchie: I bet it says "GNU GRUB  version 1.99-something"
<dutchie> it doesn't say gnu grub version anything
<cjwatson> drat, maybe no version reporting if you get dumped to rescue mode
<dutchie> just "Loading Operating System..." from the bios, then "error: file not found" and then the prompt
<smb> cjwatson, If you are interested in the current status of it: bug 1038055
<ubottu> Launchpad bug 1038055 in linux (Ubuntu) "graphics fail to initialise correctly, in kvm with cirrus graphics (after LUKS install)" [High,Confirmed] https://launchpad.net/bugs/1038055
<smb> (the LUKS reference is a red herring, probably should drop it from the description)
<cjwatson> dutchie: well, "file not found" is a message from 1.99; 2.00 prints a more informative message including the file name
<cjwatson> dutchie: so this indicates that the core image is 1.99 and is pointing to 2.00 modules
<cjwatson> => misconfiguration
<dutchie> right, so i have to get a live image to work somehow?
<cjwatson> you might like to set root and prefix to the other installation on your second disk to get yourself going again
<dutchie> ah, hadn't thought of that
<cjwatson> since that's very likely where your core image comes from
<cjwatson> smb: right, I just mean this scenario comes from a straight install?
<cjwatson> smb: but that bug report predates GRUB 2.00; it's with more or less the same version of GRUB as was in precise
<cjwatson> So it is not at all clear that this is a regression in 2.00; if it is, then there are multiple problems
<smb> cjwatson, I would suspect it. Though I am reproducing it with an updated image. Let me check back with a precise image (whether efi fb is used). Though I am supecting the regression happens because the kernel suddenly has another fb driver
<cjwatson> takes a while to check unfortunately since you have to actually do an install rather than rely on the live image
<smb> cjwatson, It unfortunately will also take a while since I found the precise vm to be a bit behind on updates. Though at least with that there was no efifb lines to be found. But I want to get that updated to be sure.
<dutchie> cjwatson: got back in, thanks
<dutchie> did you say there was something else to do afterwards?
<cjwatson> dutchie: 'sudo dpkg-reconfigure grub-pc' in both OSes and make sure exactly one of them is trying to install to wherever your firmware boots from
<stgraber> pitti: nope, never heard of something like that. My understanding is that NM's DNS config writer is the same for all connections type so it should be writing into /run/resolvconf even when everything is statically configured...
<obounaim> Please can anybody sponsor me: http://goo.gl/PijNl and http://goo.gl/QQAHD. Thanks in advance
<mpt> ev, if you're having to update the graph manually, I guess bug 1039070 is fixed?
<ubottu> Launchpad bug 1039070 in Errors "Graph often plummets today" [Undecided,New] https://launchpad.net/bugs/1039070
<smb> cjwatson, Ok, so it is using efifb in Precise (with grub 1.99). So not a regression between grub versions. Probably lapse to not use VESA but we never noticed because there was not a drm driver for that virtual cirrus card.
<cjwatson> smb: Right.  It's possible it's even deliberate, as Steve suggests; if efifb is given dimensions in the boot parameter block, it's not actually as tied to EFI as the name suggests.
<ev> mpt: indeed, fixed
<cjwatson> smb: See e.g. http://comments.gmane.org/gmane.linux.kernel/1027491, which I never did get round to pushing all the way up the hill
<cjwatson> smb: But I *think* we intended to avoid efifb on BIOS systems in favour of KMS or whatever
<smb> cjwatson, Ah I see. Yeah, there seems to be something done done for at least i915 based systems as I could not see the efifb show up on any netbooks/laptops I did look at
 * smb notices word bouncing... maybe I should stop the coffee consumption...
<cjwatson> On real hardware, GRUB will typically be using its VBE driver, so it won't pass 0x70 to Linux.
<smb> If that would work with KVM instances, too it might avoid some issues right now. Not that it prevents us from having to look at the other issue at some time. Though somehow I doubt a bit that ripping out one fb and replace it by another one really helps the flicker free boot approach.
<ahasenack> hi, I need a sponsor to upload #1053057 to quantal, the bug has a debdiff and the fix has been tested
<cjwatson> psivaa: Did you manage to collect logs for bug 1052605?
<ubottu> Launchpad bug 1052605 in update-manager (Ubuntu) "ERROR:root:getListFromFile: no '/usr/share/update-manager/removal_blacklist.cfg' found: exception during Precise to Quantal upgrade on amd64+mac" [Undecided,Incomplete] https://launchpad.net/bugs/1052605
<psivaa> cjwatson, not yet, i have done a few ( about 4) with different precise being installed first and it did not occur lately
<mvo> cjwatson: hm, that location looks wrong, it should look at the local dir instead of the system dir really :/
<cjwatson> Hm
<mvo> cjwatson: is that reproducable ?
<cjwatson> mvo: Isn't removal_blacklist.cfg shipped in the package though?
<cjwatson> Or do you mean the one in the dist-upgrader tarball?
<cjwatson> mvo: Don't know :-)
<mvo> cjwatson: it should also be part of the release-upgrader-tarball and that is what should get used during the upgrade
<psivaa> it occured only once for me out of about 5 attmpts
<ahasenack> hi, I need a sponsor to upload bug #1053057 to quantal, the bug has a debdiff
<ubottu> Launchpad bug 1053057 in Landscape Client "Client queues up lshw calls if talking to old server" [Critical,Fix committed] https://launchpad.net/bugs/1053057
<ahasenack> it's bugfix only, no other changes
<ahasenack> hm, let me subscribe sponsors, I always forget that
<ahasenack> that's ubuntu-sponsors, right?
<geser> yes
<ahasenack> done
<brendand> bryceh, is there going to be a build of python-lpltk for precise and quantal?
<doko> mterry, did you look at nvidia-settings-experimental-304 too?
<mterry> doko, yeah briefly
<doko> could you comment?
<mterry> I thought I did..
<mterry> I put as fix committed?
<doko> no
<mterry> oh...
<mterry> doko, yeah, it's fix committed
<mterry> I didn't leave a comment, just changed the status
<doko> ohh, had to refresh. thanks
<ev> mpt: http://poppy-dev.local/ - ignore the fact that the milestone lines don't perfectly line up yet. Am I to assume the missing grid lines and accompanying dates in your mockup means I should be getting rid of them?
<mpt> ev, maybe not completely ... Try replacing them with dots where the horizontal and vertical grid lines currently cross?
<mpt> so it's like the dotted graph paper :-)
<ev> mpt: will you not rest until every interface looks like you drew it? ;)
<ev> what about the dates along the x axis?
<mdeslaur> someone should make an mpt gtk theme
<mpt> ev, if you add tick marks to the dates, it will be clear what the grid dots are lining up with.
<ev> okay
<mpt> mdeslaur, totally
<mdeslaur> :)
<ev> and font!
<mpt> ev, while you're at it, you could get rid of the years from the dates (at least until January)
<ev> yes
<ev> I was going to change the formatter to output "Sep 6"
<ev> as you have in your mock up
<mpt> good idea
<mpt> oh, I do?
<ev> yes :)
<mpt> No wonder it's a good idea
 * mpt flees
<ev> :D
<mpt> ev, and next step to extend the X axis to October 18?
<ev> ah yes, good thinking
<mpt> the finish line
<ev> mpt: also, while I have you here. Any thoughts on what selecting the SRU most common problems table would look like? I vaguely recall us talking about this before
<ev> is it just "most common errors for [ Ubuntu 12.04 SRU v]" or something like that?
<mpt> ev, "SRU most common problems"? Is that -proposed?
<ev> yes
<ev> will probably just call it "12.04 proposed" instead of SRU
<ev> as that doesn't get confused with -updates
<mpt> ev, how about this? https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=99&rev1=98
<mpt> or do you mean the table specifically?
<ev> oh yes!
<ev> that works
<ev> thanks
<ev> forgot you made that change
<mpt> ev, no worries, I made the change after you asked the question
<GrueMaster> I see slashdot is in an uproar about bug 966744.
<ubottu> Launchpad bug 966744 in xserver-xorg-video-intel (Ubuntu Quantal) "[i965] Resume from suspend leaves me with black screen or a screen of the desktop before it suspended. Compiz hung in intel_update_renderbuffers() from intel_prepare_render() from brw_draw_prims()" [Critical,Confirmed] https://launchpad.net/bugs/966744
<GrueMaster> It may be of interest to some, but here at work, my Lenovo T61 has very similar issues, except I am running Windows 7 on it (forced to use, not a choice I made).
<GrueMaster> It may be an acpi issue in the firmware.
<psivaa> cjwatson, i have been able to reproduce bug 1052605 and the logs are attached to it now
<ubottu> Launchpad bug 1052605 in update-manager (Ubuntu) "ERROR:root:getListFromFile: no '/usr/share/update-manager/removal_blacklist.cfg' found: exception during Precise to Quantal upgrade on amd64+mac" [Undecided,Confirmed] https://launchpad.net/bugs/1052605
<mfisch> Does anyone know what happened to the Inhibit/Uninhibit DBUS calls that were supposed to prevent the system from suspending/screen blanking?  https://wiki.ubuntu.com/GnomePowerManagerInhibitSpec
<mfisch> In Precise, I can't even find the dbus service
<mfisch> which is supposed to be: org.freedesktop.PowerManagement.  Update Manager (and other code) still references the service and method
<bdmurray> ev: do you know why version sorting and release mark up is strange on errors?
<bdmurray> ev: on a bucket page that is
<doko> is there really a reason to build qt4-x11 using GCC 4.6?
<SpamapS> nostalgia?
<doko> ahh, it's just the b-d
<ev> bdmurray: what do you mean?
<ev> oh, the sorting is busted, isn't it
<ev> rubbish
<bdmurray> ev: right and not every package version has a release by it - I wasn't sure if that was by design or not
<sarnold> doko: b-d?
<cjwatson> build-dependency
<sarnold> thanks cjwatson :)
<doko> started a local qt4-x11 build ...
<micahg> doko: are you thinking to demote gcc-4.6?
<doko> only if infinity starts building eglibc with 4.7 ;-P
<cjwatson> grub2 as well, which I don't plan to change for quantal
<cjwatson> GCC version bumps there have a habit of introducing size problems
<micahg> heh, ok
<ev> bdmurray: it doesn't have a release by it when we can't find that version published in any release
<bdmurray> ev: ah so ones that have been superceded won't show up?
<ev> bdmurray: ah yes
<ev> because we say status=Published in launchpad.py
<ev> so that would do it :)
<doko> didrocks, unity-lens-shopping has files generate by vala 0.16. is this really wanted?
<didrocks> doko: yeah, we usually do that with vala
<didrocks> doko: because it's so unstable that we prefer to have the generated file rather than rerunning vala
<doko> didrocks, yeah, but 0.16, not 0.18?
<didrocks> doko: all lenses are on 0.16, 0.18 isn't working well with them
<didrocks> doko: enjoy the world of vala instability :)
 * doko accepts and runs away
<didrocks> doko: ahah :)
<doko> bryceh, mterry: how are the plans for mesa's st2c recommend?
<didrocks> doko: can you binNEW them, please? (amd64 ready)
<doko> tkamppeter, pitti: any news about the foomatic-db recommends in universe?
 * mterry lets didrocks answer about st2c
<didrocks> I think bryceh is the best to answer on the status
<bryceh> doko, s2tc MIR is LP: #1053065.  Already added to quantal as LP: #1053029.  No plans for SRU at this time.
<zyga> pitti, ping
<doko> mterry, I'm away now for some hours, if needed today, please review
<mterry> doko, sorry, please review the s2tc mir?
<bdmurray> ev: how do you suggest we link https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fshare%2Fapport%2Fapportcheckresume%3AAssertionError%3A%3Cmodule%3E%3Amain%3Awrite%3A_assert_bin_mode to bug 1040353?
<ubottu> Launchpad bug 1040353 in Apport "apportcheckresume crashed with AssertionError in _assert_bin_mode(): file stream must be in binary mode" [Undecided,New] https://launchpad.net/bugs/1040353
<fginther> Can someone please help sanity check a merge proposal for a updated package in precise? https://code.launchpad.net/~fginther/ubuntu/precise/evemu/transitional-1051044/+merge/125214
<fginther> I've added a transitional package and need to repeat this for more packages. I'd just like to know if I've done this correctly.
<fginther> The MP shows more changes then it should, I only changed 2 files.
<tkamppeter> doko, still there? I have prepared everything so that the foomatic-db binary can get demoted. I have commented appropriately in the bug report.
<fginther> Can someone please help sanity check a merge proposal for a updated package in precise? https://code.launchpad.net/~fginther/ubuntu/precise/evemu/transitional-1051044/+merge/125214
<fginther> I've also attached a debdiff to https://bugs.launchpad.net/ubuntu/+source/evemu/+bug/1051044
<ubottu> Launchpad bug 1051044 in evemu (Ubuntu) "Need transitional package to the renamed libevemu1" [Undecided,New]
* infinity changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Frozen for Beta 2 | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<lifeless> ev: https://docs.google.com/viewer?a=v&q=cache:uI1lHPqS5P4J:crystal.uta.edu/~gdas/Courses/Courses/Spring2006/DBExploration/Arjun_Sushruth_fagin_ta.ppt+&hl=en&gl=nz&pid=bl&srcid=ADGEESgyf-tCOTGV7N93L35Sq3kmsdIXVm-vdGDks4fUIuehxfeXvm7qoqFr8v6BEk2XmnitikcZ0lLdvqXUuPIzFh-ANf5KG-UouzvGmf2EnztwtP8ZlzgZIJGUrrAHFLp3afmIHHIT&sig=AHIEtbQhRHF5CpZBgkXWgphpKenwj5MIPA
<lifeless> seems like the shit
<TheMuso> xnox: Revert which patch? We can either revert the patch in GTK, or apply the fix that I attached in bug 1053112 to at-spi2-atk, which is the proper fix.
<ubottu> Launchpad bug 1053112 in Ubuntu "ubiquity crashes when orca is running" [High,Confirmed] https://launchpad.net/bugs/1053112
<xnox> TheMuso: sorry, I didn't refresh the web-page before commening.
<xnox> TheMuso: your proposed patch is a better solution, please ignore my noise =)
<TheMuso> Just awaiting the release team approval, I subscribed them at least. Do I need to do anything else to get it on their radar?
<xnox> TheMuso: advertise the bug number on #ubuntu-release =) bribing #ubuntu-release channel with bird seeds also helps
<TheMuso> xnox: heh ok thanks.
<RAOF> Mmm, bird seed.
<sarnold> some of that delicious delicious suet? with insects??
<xnox> TheMuso: I have now hidden my confusing comment in shame ;-)
<TheMuso> heh
#ubuntu-devel 2012-09-21
<pitti> Good morning
 * pitti unleashes new quantal langpacks; builders, beware
<pitti> skaet_: ^ we aim to please
<dholbach> good morning
<dholbach> can somebody please reject https://code.launchpad.net/~jjesse/ubuntu/quantal/libstring-approx-perl/typo-fix/+merge/125547 and https://code.launchpad.net/~jjesse/ubuntu/quantal/liborigin/typo-fix/+merge/125549 and https://code.launchpad.net/~jjesse/ubuntu/quantal/libpam-foreground/typo-fix/+merge/125548?
<pitti> dholbach: done
<dholbach> thanks pitti
<StevenK> pitti: compinit is a zsh function to set up tab completion, it will write the runes for it into .zshrc
<pitti> StevenK: ah, thanks; as I said, /me <- zsh n00b
<StevenK> pitti: Yeah, I saw that bit, which is why I helped out. :-)
<doko> qt4-x11 built fine locally here ... and no build log available ...
<mvo> cjwatson: want me to have a look at #1052605 or are you on it already?
<cjwatson> mvo: I'm not on it yet - if you could that would be lovely
<mvo> cjwatson: ok
<jamespage> is ubuntu-devel an appropriate list to send call for testing type stuff?
<xnox> jamespage: if it is general, it can be.
<xnox> jamespage: tasting what stuff though?
<Laney> there's a dedicated testing ML I think
<jamespage> Laney, yeah - I was going to send it there as well
<jamespage> xnox, its specifically about testing of java apps with the transition of default java from openjdk-6 to openjdk-7
<xnox> sounds -devel worthy
<xnox> I tested the transition by checking that purging java from my machine still works ;-)
<jamespage> xnox, lol
<jamespage> should od
<xnox> jamespage: it is tricky though, trying to remove current implementation tries to install another one =)
<jamespage> xnox, they co-exists quite happily
<jamespage> managed via alternatives...
<xnox> jamespage: install default-jdk, then try to remove it. Apt says: ok but i will install 6. remove default and 6? Ok but i will install gcj. Remove default, 6 and gcj? Sorry can't do anything.
<xnox> jamespage: so you need to delete stuff like java-common & apps in a single go, for it to go away.
<heno> doko, Hi, I've filed a freeze exception request -- https://bugs.launchpad.net/ubuntu/+bug/1053933
<ubottu> Launchpad bug 1053933 in Ubuntu "Feature Freeze Exception - inclusion of OpenERP (quantal)" [Undecided,New]
<doko> heno, xnox already replied
<xnox> doko: ;-)
<heno> xnox, doko, ok thanks I'll pick it up on the bug :)
<lamont> ctl-alt-t not working with as of sometime recently (on quantal) - is that expected?
<didrocks> lamont: yeah, it's a keybinding conflict, bug #1050796
<ubottu> Launchpad bug 1050796 in compiz (Ubuntu Quantal) "Double shortcuts conflict with gnome-control-center ones" [High,Triaged] https://launchpad.net/bugs/1050796
<lamont> didrocks: but is there a trivial workaround? (what file to I smash?)
<didrocks> lamont: you can go to gnome-control-center -> keybindings -> launcher
<didrocks> you will see 2 "Launch a terminal"
<didrocks> one has to be set, not the other
<didrocks> (you have to try, they are both named the same)
<lamont> does it matter which?
<didrocks> lamont: yeah, only one is wired
<lamont> much better
<ahasenack> hi, can someone please sponsor this bug? It's critical for us: bug #1053057
<ubottu> Launchpad bug 1053057 in landscape-client (Ubuntu) "Client queues up lshw calls if talking to old server" [Undecided,New] https://launchpad.net/bugs/1053057
<SpamapS> ahasenack: I uploaded it to quantal-proposed yesterday... awaiting beta-freeze acceptance (or post-beta-thaw)
<ahasenack> SpamapS: thanks, who can I talk to about that?
<SpamapS> ahasenack: #ubuntu-release
<ahasenack> SpamapS: thanks
<cjwatson> pitti: What's up with the ARM test failures on https://launchpad.net/ubuntu/+source/glib2.0/2.33.14-1svn2 ?
<ahasenack> hi, can someone please nominate bug #1053057 for lucid, natty, oneiric and precise? I have debdiffs ready and will change the bug description to comply with sru rules
<ubottu> Launchpad bug 1053057 in Landscape Client "Client queues up lshw calls if talking to old server" [Critical,Fix committed] https://launchpad.net/bugs/1053057
<SpamapS> ahasenack: on it
<lucazade> hi all! Is bug #1053269 going to be solved or at least any idea why it happens?
<ubottu> Launchpad bug 1053269 in grub2 (Ubuntu) "black boot" [Undecided,Confirmed] https://launchpad.net/bugs/1053269
<cjwatson> lucazade: It might be related to a framebuffer handling bug that smb and I were talking about yesterday
<cjwatson> lucazade: I have an nvidia box I can dig out, so I'll take a look as soon as I can dig myself out from under everything else ...
<lucazade> cjwatson: is it a regression?
<cjwatson> Well, you said it was a regression in the bug description
<doko> tkamppeter, foomatic-db demoted
<cjwatson> So who am I to argue
<lucazade> cjwatson: if you need any test i'm here
<cjwatson> What it's a regression *in* is a different question
<lucazade> i've an optimus dell desktop to test it out
<doko> apw, ping on https://launchpad.net/bugs/1048824
<ubottu> Launchpad bug 1048824 in svn2cl (Ubuntu) "[MIR] svn2cl" [Medium,Incomplete]
<apw> doko, will look at it, thanks
<smb> cjwatson, lucazade If there is a second machine to ssh into the one with the black screen, then dmesg from that machine with the black screen would be helpful to find out whether framebuffers are replaced
<lucazade> smb: ok ... good idea.. i'll try to catch dmesg
<doko> bryceh, nivida-common shows up on the demotion list. is this wanted?
<lucazade> smb, cjwatson ... pasted my dmesg ... http://pastebin.com/VdDtBQqs  (ubuntu pastebin is broken atm)
<cjwatson> doko,bryceh: 'apt-cache show nvidia-common' says it's a transitional package
<doko> cjwatson, so I assume it's safe to demote
<cjwatson> should be
<cjwatson> lucazade: huh, you have the nvidia module loaded apparently (or did you file that bug from a different machine?), but that dmesg shows inteldrmfb
<cjwatson> but I have to go out for a bit ...
<smb> lucazade, I don't see a framebuffer switch from one kernel driver to the other (like I talked to cjwatson yesterday).
<smb> cjwatson, Might be a dual gfx machine
<cjwatson> smb: Yeah.  Any way you can think of to distinguish which of us owns this bug?
<lucazade> smb it is an optimus machine: intel + nvidia
<xnox> doko: if you demote to universe, how would main-only lts->lts upgrade happen? just fine?
<smb> cjwatson, I may be tempted to go for option 3 and ask someone else...
<xnox> doko: or is that not the package that people install to have nvidia?
<cjwatson> xnox: this is hardly the only problem in that category - in any case LTS->LTS upgrades generally have universe enabled
<cjwatson> So I wouldn't expect that to be a problem
<xnox> cjwatson: ok. thanks.
<cjwatson> It used to be a problem for cdromupgrade, but we've basically desupported that
<xnox> =)
<smb> cjwatson, The problem might be somewhere in the middle. I don't see failures to obtain resources like in the one I was looking at. Might just be a fail in switching gfx
<smb> lucazade, Any way, you should upload the dmsg file to the bug report as it is likely to get lost otherwise
<lucazade> smb: going to upload the dmesg to the bug report
<smb> cjwatson, lucazade The only other thing I noticed (but cannot really decide about its influence) is that from the dummy 80x24 console the system goes to inteldrmfb and later enables the discrete nvidia gfx...
<lucazade> smb, cjwatson.. if I disable the vt.handoff=7 feature at least I can see the VT.. is it possible that new grub rev is not patched against it?
<lucazade> smb, cjwatson .. I can try to blacklist nvidia module to see if it is related to this
<smb> lucazade, I guess it cannot hurt to gather that as an additional testing case... Not having really much experience with those dual gfx machines...
<tkamppeter> doko, pitti, hi
<cjwatson> lucazade: I was pretty careful to keep all those patches
<cjwatson> lucazade: in fact most of them are upstream.  Perhaps you could attach your /boot/grub/grub.cfg as well though
<lucazade> cjwatson http://pastebin.com/XstaeXXA
<lucazade> cjwatson: going to blacklist nvidia module... rebooting
<doko> tkamppeter, foomatic-db-compressed-ppds still recommends printer-driver-all
<lucazade> cjwatson: dmesg blacklisting nvidia_current http://pastebin.com/ZVSqxYk8  (same behaviour)
<cjwatson> lucazade: as far as I can see, all the necessary GRUB configuration is still in place
<cjwatson> lucazade: It's possible that something is wrong with video setup internally in GRUB, but at this point I would be rather inclined to suspect the kernel instead
<cjwatson> lucazade: You might try downgrading to a kernel version that previously worked to test this theory, or downgrading to GRUB 1.99; either ought to narrow it down
<lucazade> cjwatson... going to try an old kernel
<lucazade> cjwatson: reverted to -21 kernel (-22 is the new one) and it fixes the issue
<lucazade> cjwatson: so it is the kernel!
<lucazade> updated the bug report https://bugs.launchpad.net/linux/+bug/1053269  .. hope it is the correct project
<ubottu> Launchpad bug 1053269 in grub2 (Ubuntu) "black boot" [Undecided,Confirmed]
<micahg> could someone more familiar with objective-c binary dependencies take a look at bug 1051389?
<ubottu> Launchpad bug 1051389 in sope (Ubuntu) "Sync sope 1.3.16-1 (universe) from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/1051389
<cjwatson> lucazade: great, thanks
<doko> bryceh, tjaalton: libdri2 is scheduled for demotion. is this intended?
<tjaalton> doko: looks to be some linaro thing
<tjaalton> rsalveti: ^
<lucazade> cjwatson: will the bug be assigned to anyone or I should ping Tim Gardner?
<cjwatson> lucazade: smb already knows about it, so let that team worry about their own assignment processes
<lucazade> cjwatson: perfect.. tnx for the support!
<smb> cjwatson, Thanks so much. :)
<cjwatson> Oh, the bug is actually in the wrong place
<cjwatson> Let me fix that
<cjwatson> smb: can you delete the bogus linux upstream task from that bug?
<cjwatson> lucazade: you should always use packages in Ubuntu, not (upstream) projects, unless you know that the bug is reproducible with upstream code
<lucazade> cjwatson: ok... good to know
<smb> cjwatson, hm.. not sure
<tkamppeter> doko, I can demote the Recommends to a Suggests, but we need something which fits both Ubuntu and Debian.
<cjwatson> smb: do you have the minus sign in a red circle next to the upstream task?
<smb> cjwatson, Ah yea
<smb> cjwatson, gone
<cjwatson> ta
<doko> tkamppeter, well, is the recommendation correct for Ubuntu? but then we have to promote some packages
<tkamppeter> doko, no, Debian folks have added that.
<cjwatson> you can generate recommends/suggests dynamically using substvars
<doko> that would be an idea
<doko> cjwatson, would it be good to have an Inclusion list for the seeds that python3-% is seeded, if python-% already is?
<cjwatson> doko: Maybe for R.  Sounds likely to induce some confusion at this point
<doko> yeah, not now
<cjwatson> doko: I don't think germinate can do the particular logic you mention, though
<cjwatson> It can include python3-* if anything else in its source package is in main, but it's quite possible that there are sources in main with python-* in universe
<doko> and on second thought, we maybe want to demote the python2-% packages, so better seed these explicitly
<rsalveti> tjaalton: doko: hm, this library is needed for the PowerVR SGX driver
<rsalveti> for omap4
<doko> rsalveti, then some reference was lost this cycle
<rsalveti> the only package depending on it is the pvr-omap4 one, which is in restricted
<rsalveti> don't know if that is what caused this
<ahasenack> hi, can someone please sponsor and upload these sru packages to -proposed? https://bugs.launchpad.net/ubuntu/+source/landscape-client/+bug/1053057
<ubottu> Launchpad bug 1053057 in landscape-client (Ubuntu Precise) "Client queues up lshw calls if talking to old server" [Undecided,New]
<doko> cjwatson, is the libdri2 demotion a bug? still has references in the b-d's and the armhf binaries in restricted
<ogra_> uh, definitely a bug
<ogra_> the omap GLES driver that is in teh images needs it
<doko> I mean, a bug in germintate
<ogra_> well, dunno where a bug is here, just saying that demoting it is definitely worng :)
<cjwatson> doko: one moment
<didrocks> ogra_: waow, libreoffice on armhf?
<ogra_> didrocks, used to always have it in the past
<cjwatson> ogra_: what's the exact package name of that driver?
<ogra_> cjwatson, pvr-omap4
<didrocks> ogra_: oh, I didn't know, thought it was too slow fo the armhf image
<ogra_> didrocks, why would it ?
<ogra_> its not to slow for an atom
<ogra_> cortext-a9 is faster than most low end atoms :)
<ogra_> *cortex
<didrocks> ogra_: ah, you were talking about armel at the time
<didrocks> (just looked at the logs)
 * cjwatson looks very confused
<cjwatson> pvr-omap4 isn't in germinate output, but it isn't listed for demotion either
<ogra_> cjwatson, at pvr-omap4 or at the conversation above ?
<ogra_> :)
<ogra_> intresting, it should be restricted
<didrocks> ogra_: http://irclogs.ubuntu.com/2011/03/01/%23ubuntu-release.html#t15:58 ;)
<ogra_> could it be that it was promoted without seed update ?
<doko> cjwatson, it is listed for demotion on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<doko> ahh, you mean the driver
<cjwatson> doko: pvr-omap4 isn't
<cjwatson> ogra_: But then it should be listed for demotion
<ogra_> didrocks, pfft, thats sooo 2011
<cjwatson> It shouldn't be in this neither state
<didrocks> ogra_: I so stick to the past, you know :)
<ogra_> didrocks, we used to ship LibO before zoho ...
<cjwatson> So I'd like to debug that before we do anything to the seeds
<doko> ok
<ogra_> didrocks, it was just that the slow builds on arm were always delaying the images
<didrocks> ogra_: ok, was thinking it was a runtime issue, my bad :)
<cjwatson> It does indeed seem that there was never an MIR for pvr-omap4
<ogra_> didrocks, but that was pre-panda-buildd times ... wheer the buildds were only 10% as fast :)
<cjwatson> Unless it was split out from something else
<didrocks> heh
<ogra_> cjwatson, no, it wasnt
<cjwatson> But it's been there since precise now, so there's an argument that we should just grandfather it in now ...
<ogra_> bug 1042151
<ubottu> Launchpad bug 1042151 in libdri2 (Ubuntu Quantal) "MIR: libdri2 needs to be in main for pvr-omap4 (restricted) to build" [High,Fix released] https://launchpad.net/bugs/1042151
<ogra_> there was a mir for libdri2
<ogra_> bug 959924 is the only papertrail i find for pvr-omap4
<ubottu> Launchpad bug 959924 in Ubuntu Precise "[needs-packaging] pvr sgx driver and kernel module for Pandaboard" [Wishlist,Fix released] https://launchpad.net/bugs/959924
<ogra_> but that has no MIR attached or anything
<cjwatson> oh
<cjwatson> wait, what
<cjwatson>         if archive_source[pkg][1] == "restricted":
<cjwatson>             continue
<cjwatson> oh, great, it predates revision control of that file
<cjwatson> elmo: do you remember why component-mismatches (nÃ©e anastacia) ignores anything currently in restricted?
<elmo> *blink*
<elmo> cjwatson: no, sorry, I can't thin of any good reason to do that
<cjwatson> It might not be from when you maintained it - I just unfortunately can't tell
<elmo> think
<cjwatson> There was a non-trivial period between you running the archive and all that stuff going into bzr
<cjwatson> elmo: Unless ... there isn't revision control somewhere for Ubuntu's dak instance, is there?
<cjwatson> The only reason I can think of is that really it ought to know to say "to multiverse" etc. for stuff in restricted
<cjwatson> And vice versa
<elmo> cjwatson: sorry, I don't think so, I don't seem to have the bzr trees from the jackass era dak
<cjwatson> OK, never mind - thanks
<elmo> at least not locally, it may be in the DC *somewhere*
<cjwatson> Probably not worth it if it's not readily to hand
<cjwatson> (What naming scheme was jackass from, anyway?)
<cjwatson> Oh, penguins, duh
<elmo> so, it apparently dates back to a copy of anastacia from 2005
<elmo> which is so old it's in subversion
<cjwatson> It's possible that at one point nothing in restricted was seeded
<cjwatson> germinate's default set of components didn't include restricted until germinate 0.8 in February 2006
<cjwatson> So that would sort of make sense
<thebishop> hello hello
<thebishop> has any work been done (or would anyone be interested in) adding Gamepad support to Unity?
<xnox> thebishop: design is at #ubuntu-design, unless you are talking about writting a search lense to dash, than it's #ubuntu-app-devel i believe.
<infinity> bryceh: Around?
<infinity> bryceh: I'm going to remove the out-of-date intel-gpu-tools binaries on !x86, which is going to render xdiagnose uninstallable.  Care to move the intel-gpu-tools hard dep for xdiagnose to a recommends?  (I assume its use is guarded in some way, since not every computer has an intel GPU, but if it's not, that should be fixed too) :P
<hallyn> rsalveti: hey, in qemu-linaro hav eyou seen https://launchpadlibrarian.net/116773384/buildlog_ubuntu-quantal-powerpc.qemu-kvm_1.2.0%2Bnoroms-0ubuntu1_FAILEDTOBUILD.txt.gz ?
<rsalveti> hallyn: not yet, just finished my local package to be able to push, so just missing the test for powerpc
<hallyn> oh maybe i do that to myself
<rsalveti> infinity: btw, package not seeded, but we're in freeze, should I just push it or would it be better to wait beta 2?
<rsalveti> qemu-linaro I mean
<infinity> rsalveti: My approval was based on the assumption that you'd both be uploading, so please do.
<infinity> rsalveti: Though, it would be nice if it also builds...
 * infinity glances at hallyn.
<plars> didrocks: around still?
<rsalveti> infinity: great, yeah, need to sort this build for powerpc
<rsalveti> might be the same issue
<didrocks> plars: was about to leave, what's up?
<hallyn> infinity: builds everywhere ican test :)  non-upload would have caused spurious errors in all sorts of testers, so still think it was worth it
<plars> didrocks: I filed bug #1054034 from a test I had running, but then noticed right after there was a compiz update
<ubottu> Launchpad bug 1054034 in compiz (Ubuntu) "keyboard shortcuts not saved in precise->quantal upgrade" [Undecided,New] https://launchpad.net/bugs/1054034
<plars> anything in the update you think could have fixed it?
<didrocks> plars: right, as I told you the other day, the new unity stack partially fixed it
<didrocks> plars: we still have a dconf-writer bug, but most of the issue there is fixed
<plars> didrocks: right, but you mentioned some fixes coming.  Just checking to see if this should have been fixed already in those or if it's still expected by you to be broken
<didrocks> plars: no, this upload must fix it (but still with some known caveats)
<didrocks> plars: the caveats are: some times the migration is reverted to the default
<plars> didrocks: I don't think I'm getting the defaults... in fact I'm now getting two entries for launch a terminal
<plars> didrocks: ok, I'll retest with the one that came in this morning
<didrocks> plars: this is separate
<didrocks> plars: launch a terminal is an opened bug
<didrocks> plars: bug #1050796 FYI
<ubottu> Launchpad bug 1050796 in compiz (Ubuntu Quantal) "Double shortcuts conflict with gnome-control-center ones" [High,Triaged] https://launchpad.net/bugs/1050796
<didrocks> plars: needing a compiz fix, I set it to the release team tracking so that PS is looking at it (not trivial to change the binding)
<plars> didrocks: but also launch hud is getting set to disabled
<plars> which I don't think is the default
<didrocks> plars: ah, this is part of the issue that are fixed with the newer version
<plars> didrocks: right, so I'll check that. thanks!
<didrocks> yw :)
<hallyn> hm, interesting.  so this is fallout from the last merge with debian.
<infinity> hallyn: Merging from experimental git, or from sid?
<hallyn> infinity: from sid, early during quantal
<hallyn> i need to find a power box to play on
<Laney> davis.c.c
<Laney> seems borked :(
<cjwatson> doko: I'm still working on this component-mismatches bug, but it's rather involved.  I may not finish today.
<jtaylor> there are a bunch of uninstallable php packages
<jtaylor> is there an unfinished transition going on?
<jtaylor> SpamapS: why are -imap and -interbase dropped form php5?
<jtaylor> the argument in the changelog does not really apply as the universe ones are uninstallable and fail to build
<bryceh> infinity, will do.  Do we need a new intel-gpu-tools in quantal?
<infinity> bryceh: No, the one in quantal is correct (only builds on x86, as it should).
<infinity> bryceh: It's xdiagnose that's wrong, by depending on it. :P
<bryceh> ahh
<micahg> infinity: maybe arch specific depends?
<micahg> if it's really that important
<micahg> although that doesn't make too much sense now that I think about it :)
<infinity> Also a possibility.  But it still feels wrong to force it to be there on all systems, even if they don't have the GPU.
<bryceh> I  think recommends should be fine.  Did a quick review of the code and looks like nothing will break if it's not present
<infinity> bryceh: That would be lovely, if you just fix up the one that's currently in the queue and re-upload for me.
<bryceh> infinity, uploaded as 3.2
<infinity> bryceh: Cool, thanks.
<SpamapS> jtaylor: for imap, because c-client is unsupported upstream
<SpamapS> jtaylor: the changelog has lost information actually
<SpamapS> jtaylor: I am fairly certain that it was a conscious decision to avoid having it in main
<jtaylor> so what do we do with the broken ones in universe now?
<SpamapS> jtaylor: I believe I already commented on the bug that I'd sponsor any work to get php5-imap updated
<jtaylor> so if there is no patch remove?
<fginther> Can someone please help with sponsoring a patch? https://code.launchpad.net/~fginther/ubuntu/precise/evemu/transitional-1051044/+merge/125214
<fginther> I also have a debdiff attached to the bug: https://bugs.launchpad.net/ubuntu/+source/evemu/+bug/1051044
<ubottu> Launchpad bug 1051044 in evemu (Ubuntu) "Need transitional package to the renamed libevemu1" [Undecided,New]
<SpamapS> jtaylor: indeed. Perhaps removing it would help push a few people to migrate away from it ;)
<jtaylor> is it there an alternative?
<jtaylor> imap seems kind of important
<infinity> What's "broken" with php5-imap?
<jtaylor> fails to build. uninstallable
<infinity> It was always a no-brainer to just update it and keep it lockstep with php5...
<jtaylor> SpamapS: can you sponsor bug 1054249 please
<ubottu> Launchpad bug 1054249 in redland-bindings (Ubuntu) "rebuild against phpapi-20100525 in quantal" [Undecided,New] https://launchpad.net/bugs/1054249
<infinity> Yeah, imap and interbase both should be simple to update, it's just that no one has done so in ages. :/
<jtaylor> infinity: how is the procedure for that? extract it from php5 source?
<jtaylor> no documentation in the package
<infinity> jtaylor: Yeah.  I haven't done it for years (I was the one who originally split the sources), but it should be fairly evident from looking at the orig for each.
<infinity> You can blame me for the lack of docs, I suspect.
<jtaylor> I looked through php5 git, there is stuff in the imag orig that never appears in php5 git
<jtaylor> specifically the part that now fails
<infinity> Which is?
<jtaylor> some stuff in a HAVE_IMAP2005 define
<infinity> Other than that one patch we're apparently carrying, it should literally just be a cp -a of ext/imap.  If it's not, someone messed up.
<SpamapS> infinity: I can't find the justification for them both not being in main actually.. was that an accident?
<infinity> jtaylor: Yeah, that's a local patch.
<infinity> debian/patches/kolab.patch
<bryceh> infinity, try #2...
<infinity> SpamapS: No, it was intentional, to keep the libs out of main.
<jtaylor> oh
<infinity> SpamapS: php-imap was also my example package long ago to show people how to do out-of-tree module builds.
<SpamapS> infinity: but it wasn't documented anywhere I can find
<jtaylor> do we still need thaT?
<infinity> SpamapS: The split was documented waaaay back in php4, I suspect.
<infinity> SpamapS: It's been like this ever since hoary.
<bryceh> infinity, as 3.1 this time
<SpamapS> infinity: the split is in the changelogs.. Ubuntu keeping them split is not (they've since been re-united in Debian)
<infinity> SpamapS: Right, they were reuinted in Debian because of the lack of main/universe, and because I stopped maintaining it.
<infinity> SpamapS: The only reason they were split in Debian was to keep the packages in sync, and so php-imap could be an example.
<infinity> SpamapS: But the split in Ubuntu was purely for main/universe reasons.
<infinity> Anyhow, the bit that's failing, you can blame zul for...
<infinity> And if Debian's not carrying this "kolab" patch, nor is upstream after two years, it might be worth just dropping it.
<SpamapS> infinity: I guess what I'm looking for is where we nacked c-client and interbase libs for main...
<zul> infinity: that was before my time
<SpamapS> heh, I was just looking for the status of said kolab patch
<SpamapS> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456591
<ubottu> Debian bug 456591 in uw-imap "include kolab annotation patch" [Wishlist,Fixed]
<infinity> Err, what?
<SpamapS> thats in uw-imap
<infinity> zul: You're the one who added the patch, how could that be before your time? :P
<SpamapS> I believe the patch for upstream php was nacked tho
<infinity> SpamapS: There was no MIR process in 2005.
<zul> infinity: i thought you were talking about the imap split
<infinity> zul: No, the imap split was me. :P
<zul> infinity: but yeah i was asked to include that patch
<SpamapS> https://bugs.php.net/bug.php?id=43948 .. there's part of it, I think
<zul> infinity: iirc ScottK wanted that patch in
<jtaylor> ok interbase has no patches I'll just try the cp -a approach for that
<jtaylor> mcrypt still builds, but should we update it too?
<infinity> jtaylor: If it's actually changed, yeah.
<SpamapS> Looks like Kolab did the right thing and ditched the imap extension ;)
<infinity> jtaylor: Just do a quick diff of the current source and the packaged one.  No point doing an empty version bump for nothing.
<jtaylor> oh course I'm not that far yet
<infinity> jtaylor: (Or just blindly update, cause who cares)
<infinity> SpamapS: By which, you mean, dropping the kolab patch from php-imap would be a sane way forward?
<SpamapS> infinity: indeed
<infinity> SpamapS: Cool.  That's a 2-second fix that would be much better than talking about it. :)
<infinity> SpamapS: (Though, again, if php-imap has changed upstream, worth revving to the latest too, which makes it a 4-second fix)
<SpamapS> yeah we should do that too
<infinity> bryceh: Trailing , on your Recommends seems a bit sloppy. ;)
<infinity> bryceh: (I'm also not sure how dpkg parses that...)
<fginther> infinity, can you take a look as some more utouch related packages, or recommend someone who can?
<infinity> fginther: That would be my thing still, yeah.  Toss me a list in /msg and we can chat about them.
<jtaylor> mcrypts diff is not really significant
<jtaylor> -       {NULL, NULL, NULL}
<jtaylor> +       PHP_FE_END
<infinity> jtaylor: Well, if it touches the .c at all, I'd assume it's a bugfix. :P
<fginther> infinity, thanks
<jtaylor> though that might be worth it
<infinity> jtaylor: Most of the extensions are pretty insanely old and stable, so generally any change to them is either a bugfix or catching up with Zend's API tweaks.
<jtaylor> I'll just do it for that
<jtaylor> seems like a change that makes sense even if it is a noop now
<infinity> jtaylor: Oh, and <3 for the README.source additions.  That wasn't really a convention back when I did the splits, but totally still my fault for not documenting it.
<ScottK> infinity: We added the patch to php to get rid of an embedded code copy being shipped with kolab.
<infinity> jtaylor: (I guess it seemed "obvious" to me, which nothing ever really is)
<infinity> ScottK: And that's no longer required?
<ScottK> I'm not sure why people think that.  I don't know.
<ScottK> I would be quite surprised if it weren't though.
<infinity> ScottK: Oh, hrm.  Well, the other option is someone fixing the patch. :P
<ScottK> what's the issue?
<infinity> Dunno.  It's FTBFS, apparently, due to the patch.  I haven't looked at it.
<ScottK> Riddell: Could you have one of your Kolab buddies look into this ^^^
<r000t_bd> Who would I talk to about an idea I had that, while I didn't think was that great, 8 friends so far have told me to bring up to you guys
<r000t_bd> The general idea is when one runs apt-get install/upgrade, it broadcasts the list of packages it needs to the LAN broadcast address, to see if anybody else has what it needs. If so, a computer replies with the package(s) it has, and a high-speed LAN transfer (that also doesn't bug the mirrors) begins
<hallyn> i kinda like it
<r000t_bd> apt-p2p is SIMILAR, but it doesn't solve the issue my idea solves with massive corporate installs hogging bandwidth whenever an update is released
<r000t_bd> not to mention this could be enabled by default without the same concerns as doing the same for apt-p2p
<r000t_bd> Bad packages aren't an issue since they're digitally signed anywya
<hallyn> r000t_bd: could be a painful DOS though if not disabl-able
<hallyn> unlikely, yes
<Riddell> ScottK: what's that?
<infinity> r000t_bd: To be far, massive corporate installs should either run local mirrors or local proxies.
<infinity> s/far/fair/
<infinity> But it's still a cute idea, if it could be implemented securely and sanely.
<sarnold> r000t_bd: yeah, I kinda like that. but sooner or later _some_ system is going to have to ping the servers to see if updates are available..
<r000t_bd> sarnold, well yeah, initial updates have to come from the mirrors
<r000t_bd> which is why an updated package could be announced, "Hey, I have a newer version of BIND9, this version is x.x.x.x, who needs it?"
<r000t_bd> The issue with local mirrors or apt-cachers is, off the top of the head, roaming clients (a friend of mine has a company provided laptop that he docks at work and then takes with him) that wouldn't be able to get new/updated packages when not at work
<r000t_bd> and for MASSIVE installs, that server would get slammed
<sarnold> r000t_bd: announce is odd; it'd be too easy for a temporarily down host to miss the announcement. Polling from clients tends to be more reliable.
<r000t_bd> And it's not just about corporate users, consider maybe the house that has 9 computers but only a DSL connection
<r000t_bd> And I don't think there would be a way to NOT have to ask the mirrors for a package list
<r000t_bd> if the list comes from peers it can get very out of date
<infinity> r000t_bd: Most corporate sysadmins I know loathe excessive broadcast traffic and often even actively prevent it.
<sarnold> I did a caching web proxy once to try to address that problem for my multiple systems -- completely forgetting that between an x86_64 and an x86 system there was very little package overlap, surely not worth the hassle.
<infinity> r000t_bd: As for the local mirror/cache issue, I see that as a misconfiguration.  A corporate setup that transparently proxies for archive.ubuntu.com isn't tough, for instance.
<infinity> r000t_bd: There's no reason roaming needs to be hard for users.
<r000t_bd> Now have any of you guys heard of apt-p2p?
<infinity> r000t_bd: And there's also no real reason this needs to be apt's problem.
<sarnold> infinity: though its hard to see firefox _really_ benefitting from this to the same extent :)
<brendand> bryceh, did you ever think about putting lpltk in pypi?
<infinity> sarnold: Hrm?  I'm not sure how firefox relates...
<sarnold> infinity: ah. i thought you were going in the direction of generic http caching for all clients
<infinity> sarnold: Or are you just referring to the part where all port 80 traffic would now route through a transparent proxy (even if it's usually a no-op)?
<infinity> sarnold: Which again, to be fair, is a pretty common corporate setup. :P
<infinity> Of course, we also don't use dnssec, so one could just spoof the DNS for archive.ubuntu.com to point at an internal machine.
<sarnold> infinity: I'm guilty of inflicting that on users myself, when a 64K frame-relay link was the best affordable option....
<infinity> And other awful fun things.
<infinity> Because, again, a "large corporate environment" (or even a smallish one) that doesn't control its own DNS resolution is pretty rare.
<r000t_bd> infinity, what about people who've used "select best server" in Software Sources and thus directly connect to a different mirror?
<infinity> r000t_bd: People who don't use the corporate-prescribed setup (and are given root) tend to fall out of the realm of "stuff sysadmins should muck with" anyway, and you also can't guarantee they'd use your fancy p2p setup.
<infinity> r000t_bd: If you trust them enough to be root on their own machines, you trust them to break things differently from how you wanted them to use them.
<infinity> (You can also spoof for *.archive.ubuntu.com, it's not rocket surgery)
<jtaylor> Riddell: php-imap fails to build in quantal partly due to an old kolab patch
<arosales> iamfuzz: Hello, as we near beta2 for 12.10 I wanted to get your thoughts on https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-eucalyptus
<infinity> r000t_bd: Anyhow, I'm not trying to discourage you from writing something cool, I'm saying that I doubt you'll get others interested in writing it for you, as I see any number of solutions to the "large install base updating" problem that are much more pleasant than broadcast storms and a fragile/untested new apt method.
<infinity> r000t_bd: If you want to do it yourself as a fun project, go to town, cause, well, people working on fun new code are always welcome, whether it pans out or not.  Most of my "best" learning experiences were things no one but me used. :P
<r000t_bd> mkay
<r000t_bd> (reverting to smalltalk) Has anybody considered what happens when we hit release 17.04 and reach the end of the alphabet?
<Laney> cyrillic
<r000t_bd> AA, AB, AC, is an option... start with Aardvark
<infinity> If you can find an animal that starts with BB, I'll be impressed.
<r000t_bd> That's why you use AB instead of BB :p
<micahg> well, we fixed the only place in the distro where it makes a difference (backports), so we can just start with A again
<infinity> micahg: No, no, we need to start with W, H, and B again.
<infinity> And that probably ends that discussion. :P
<r000t_bd> What if we stop using animals?
<r000t_bd> Starting with 17.04, using minerals instead
<bryceh> brendand, pypi?  no I hadn't.  It's in the ppa now btw
<bryceh> infinity, aiui dpkg parses it ok, but I can upload without that if you'd like
<infinity> bryceh: Please do, it offends my sensibilities. ;)
<bryceh> infinity, there you go.
<infinity> bryceh: Many thanks.
<iamfuzz> arosales, hey there
<iamfuzz> arosales, we're just going to remain in the Partner repo for Quantal
<iamfuzz> arosales, we're in Sid now so should be in future releases by default
<infinity> H/win 197
<Laney> that's a lorra windows
<infinity> Laney: IRC is serious business.
<stgraber> I usually try to restart irssi when I reach 100 as it's sometimes good to make sure all the channels are in auto-join and the config isn't completely broken ;)
<stgraber> it so far it seems to nicely match our kernel release cycle
<Laney> I garbage collect quite aggressively, as I have a big ol' window list at the bottom of my irssi
<Laney> 197 would leave me with about 3 lines for conversation :P
<stgraber> I'm always suprised how easily I can keep a full window-number => channel name mapping in my head :)
<infinity> Laney: I do activity lists numerically at the bottom, and hilight lists in the title bar, but the activity list filters join/part cruft and such, so it's not unwieldly.
<r000t_bd> (they use irssi and not a GUI client combined with a znc)
<infinity> stgraber: And yeah, that creeps me out that I tend to know who/what a number is when it hilights.
<Laney> I get to do that with letters instead, thanks to the window list
<Laney> w = ubuntu-devel, 0 = ubuntu-release
<arosales> iamfuzz: good to hear about being in sid. Regarding the 2 work items in servercloud-q-eucalyptus were those complete, valid todo, or need postponing?
<arosales> iamfuzz: there were mainly around getting feedback
<iamfuzz> arosales, the first is complete, second is ongoing
<arosales> iamfuzz: ah good to hear, I'll update the blueprint accordingly.
<iamfuzz> arosales, many thanks
<arosales> iamfuzz: sure, np, and thanks for the update.
<Riddell> jtaylor: where is this?  php-imap package that hasn't been updated since oneiric?
<jtaylor> thats the problem
<jtaylor> we need to update it, but the patch needs fixing or dropping
<ScottK> Riddell: php5 ftbfs due to the patch we added for kolab, apparenlty.
<bdmurray> stgraber: do you know anything about welcome.jpg in the slideshow still being a pangolin?
<stgraber> bdmurray: nope, my guess is that we'll get yet another last minute slideshow, I'd actually be surprised if we ever get the slideshow in place by UIF ...
<stgraber> bdmurray: might be worth poking Dylan about it
<stgraber> I only take care of reviewing the stuff they land in the branch, making sure they have the required paperwork, update the translations and upload
<bdmurray> stgraber: okay, thanks
<cjwatson> doko: http://paste.ubuntu.com/1219512/
<cjwatson> doko: deployed - I suggest you may want to seed a bunch of those rather than move them to multiverse :-)
<cjwatson> Some arguably ought to be seeded by pattern to save effort later
#ubuntu-devel 2012-09-22
<rsalveti> hallyn: seems the problem is at the packaging side
<rsalveti> blobs_arch += bamboo.dts mpc8544ds.dts
<rsalveti> mpc8544ds.dts doesn't exist anymore at the qemu upstream
<rsalveti> seems it's not needed as it's generated at runtime (previous one was a very minimal one)
<hallyn> rsalveti: yep, kinda funny as before the last merge with debian that wasn't in there anyway.  still before i just remove that i'd like to test-build ona ppc box.
<fishor> hallo all, i need you help. i'm kernel developer and i use latest ubuntu 12.10. Mostly it works fine for me. I installed vanilla kernel to work on some hardware issue on Asus zenbook UX32A. For some reasons skype sound scratchy on vanilla kernel.
<fishor> Are there some special patches for pulseaudio in ubuntu kernel?
<fishor> i'm confused because: ubuntu kernel sounds fine, include skype. and vanilla kernel sounds fine too except skype
<cyphermox> fishor: you mean patches to the kernel for sound?
<fishor> cyphermox, yep
<fishor> or may be some extras for pulseaudio, for example some realtime patches
<cyphermox> fishor: I'm not super familiar with the kernel stuff, but I'd suggest looking at http://kernel.ubuntu.com/git?p=ubuntu%2Fubuntu-quantal.git&a=search&h=HEAD&st=commit&s=SAUCE (sauce patches) for quantal
<cyphermox> (or ask in #ubuntu-kernel)
<cyphermox> I suspect it's more a kernel thing than something in pulse though, if it works fine on the ubuntu kernel and scratchy on vanilla
<cyphermox> bbl, train near destination.
<fishor> cyphermox, thx! i'll ask -kernel
<hashem> What does it mean for a package to have a different source package? Why are they separate to begin with then? https://launchpad.net/ubuntu/quantal/i386/compiz-plugins-default on the bottom says "Source package âcompizâ package in Ubuntu"
<tumbleweed> hashem: one source package can build multiple binary packages
<tumbleweed> there are many reasons why its useful to break packages up into separate binary packages
<tumbleweed> and yes, the names of the source packages are sometimes not trivially guessable
<hashem> fair enough, thanks. Question 2: Is there a way to get debuild to install the required dependencies automatically?
<cjwatson> just use 'sudo apt-get build-dep'
<tumbleweed> or use sbuild / pbuilder to do your building in isolated chroots
<hashem> thanks cjwatson. I'm trying to fix a segfault in /usr/lib/compiz/libgrid.so, however, apt-get build-dep compiz reports, "The following packages have unmet dependencies: libnotify-dev : Depends: libnotify4 (= 0.7.5-1) but 0.7.5-1ppa1precise is to be installed   Depends: gir1.2-notify-0.7 (= 0.7.5-1) but 0.7.5-1ppa1precise is to be installed E: Build-dependencies for compiz could not be satisfied." I'm running the command "bzr buil
<hashem> ddeb".
<hashem> tumbleweed, I'm following this guide http://developer.ubuntu.com/packaging/html/udd-getting-the-source.html#branching , so I have downloaded right now, an orig.tar.gz file, and a directory that contains the unpacked source, cmake folder and debian folder.
<cjwatson> hashem: Using a chroot as tumbleweed suggested would isolate your builds from whatever random stuff happens to be going on on your system.
<cjwatson> I'm not going to debug your system right now :-)
<hashem> I'm very new to linux development. To me, libnotify4 version 0.7.5-1 looks like 0.7.5-1ppa1precise. I don't understand the difference or how to resolve the issue.
<penguin42> cjwatson: The 'bricks Samsung uefi' laptop bug from a few weeks ago; do you know if any one managed to find someone at Samsung to prod?   It was suggested it needs marking as security given that it could be used for intentional bricking if anyone figures out what causes it?
<cjwatson> The dependency is an exact one, so it doesn't matter if it "looks like" the same version, it isn't the same.
<cjwatson> penguin42: Sorry, I haven't had time to follow up.  I suggest that somebody who does have time goes ahead and does so.
<cjwatson> hashem: 'sudo apt-get -f install' might help clear things up a bit
<cjwatson> (without extra arguments)
<penguin42> cjwatson: I have neither the laptop or any contacts, does Canonical have any vendor contacts?
<cjwatson> Since your package database is apparently inconsistent right now
<cjwatson> penguin42: I have no idea; I am but a humble developer
<cjwatson> penguin42: I don't do vendor relations
<penguin42> cjwatson: OK, thanks
<cjwatson> (Somewhat deliberately)
<penguin42> yes, it's much safer!  Is there a team who does that should be subscribed to the bug?
<cjwatson> I don't know a suitable team to subscribe, and it's Saturday so I'm not going to look
<cjwatson> I'll add a to-do list item for Monday to have a look
<penguin42> cjwatson: That's fine, thanks
<hashem> I'm trying to set up pbuilder to build from the compiz.dev directory I got from bzr branch ubuntu:compiz. I ran sudo pbuilder create --debootstrapopts --variant=buildd, but when I run sudo pbuilder --debuild (which "builds a Debian package from the Debian source  directory.") there's no .deb file created
<jtaylor> hashem: its in /var/cache/pbuilder/result by default
<hashem> I have no dsc file, so I can't use sudo pbuilder build *.dsc
<hashem> jtaylor, there is nothing in that directory
<jtaylor> was the build successful?
<jtaylor> you can create a dsc with debuild -S
<hashem> Nothing in the output of pbuilder indicated it was building anything http://pastie.org/4781091 . When I ran debuild -S, it failed to start http://pastie.org/pastes/4781099/text
<jtaylor> lets move to #ubuntu-packaging
<hashem> ok
#ubuntu-devel 2012-09-23
<Sly> Talk about ridiculous. CTRL+ALT+T won't even open terminal after the last couple of upgrades I've done, and there are no error logs for why it may not have opened.
<Sly> It's amazing that a custom hotkey works, but a default hotkey doesn't.
<Sly> Oh well. Guess it's time to reformat to something that has some decent dev support.
<Sly> pz
<obounaim> #join #ubuntu
<doko> cjwatson: Source and binary movements to restricted
<doko>  -----------------------------------------
<doko>  o emacs-defaults
<Laney> why restricted?
<Laney> it should go to main
<Laney> doko: ^
<doko> just copied from component mismatches
<Laney> any idea?
<doko> I assume a glitch in supporting packages from restricted in yesterday's update
<Laney> why is it component mismatched at all?
<doko> debfx, qt4-x11 has an unused b-d on g++-4.6. please remove it
<xnox> what to do with sponsorship requests that are not appropriate for quantal, but are ok for Rancid Raccoon r-series?
<cjwatson> doko: Thanks, I'll debug that
<cjwatson> Obviously a bug :-)
<cjwatson> Ah, easy fix, done
#ubuntu-devel 2013-09-16
<dholbach> good morning
<dholbach> hey... can you guys please help with the sponsoring queue?
<dholbach> we're at 95 requests!
<Noskcaj> dholbach, I'm not sure if that's an achievement or a fail
<Noskcaj> bdrung, I've made the audacity branch, can you take a look? It should be in your emails
<dholbach> Noskcaj, a bit of both ;-)
<lifeless> asd
<lifeless> bah, sorry.
<rbasak> dholbach: how can I politely remove https://code.launchpad.net/~jackweirdy/vidalia/680192/+merge/178623 from the sponsorship queue?
<rbasak> (I'm not sure how MPs map into the queue)
<infinity> rbasak: Just reject the MP.
<rbasak> infinity: I don't see any obvious way to do that. Am I missing some permission somewhere?
<rbasak> I can only change status to Needs review, Merged, or Work in progress.
<infinity> Possibly.  The 'status' field is editable if you have the right permissions on the branch.
<infinity> I'll reject it for you.
<rbasak> Thanks
<dholbach> rbasak, yes, if in doubt, just ask in here and somebody will do it for you
<dholbach> I think it's TB members and LP admins
<rbasak> I see. Thanks!
<dholbach> I'm not too happy with the setup myself and don't know the reasons for it, but on the other hand, there's always somebody around
<dholbach> infinity, happy birthday! :)
<infinity> dholbach: Nope, core-dev was added to the group a while back.
<dholbach> ah, awesome!
<infinity> (So please, stop bugging TB for it)
<infinity> rbasak: ^
<rbasak> Thanks.
 * rbasak should do more core work and apply for core dev.
<infinity> Yes, you should.
<dholbach> yeehaw
<infinity> You're one of the few left on my "would gladly sponsor for core dev" short list.
<rbasak> Thanks :)
<Noskcaj> Should FFe syncs have the sponsors team unsubscribed till the FFe is granted?
<iulian> Noskcaj: Yes because it wouldn't make sense to have the sponsors subscribed if there's nothing to sponsor.
<Noskcaj> iulian, ok, thanks
<asac> anyone knows if https://lists.ubuntu.com/mailman/listinfo/ubuntu-patches was used at some point? it says HIGH VOLUME, but doesnt have an archive
<asac> or is archiving intentional disabled?
<cjwatson> asac: Yes, archiving is intentionally disabled, but mails still go out
<cjwatson> merge-o-matic sends mails there
<cjwatson> I know it still works because occasionally I get bounces :-)
<asac> cjwatson: ok... so its not an automatic debdiff service :)? had hoped for that
<asac> (for everyhting)
<asac> just mom
<cjwatson> You may be unaware of everything that MoM does ...
<cjwatson> It does more than just merges with respect to Debian
<asac> ok... dont need the details now
<cjwatson> The code predates me being involved in MoM, but I believe that it announces all changes in Ubuntu
<asac> interesting. i guess i might just try to subscribe :)
<cjwatson> Well, possibly not all; it probably won't mention syncs
<cjwatson> I tend to think that saucy-changes is a more useful list for this kind of thing, since you can check debdiffs for the tiny fraction that you actually care about
<ogra_> ++
<cjwatson> I think in the case of a merge from Debian, the patch on ubuntu-patches will only contain the new debdiff versus the base version in Debian
<cjwatson> But, ubuntu-patches basically is an automatic debdiff service, albeit probably a limited one in some ways
 * cjwatson tries to summon Monday morning brainpower to work on proposed-migration for the :any stuff
 * ogra_ could only offer some of his jetlag 
<Noskcaj> Is it worth converting debdiffs to branches if i lack the power to upload them?
<cjwatson> No
<cjwatson> Debdiffs are just as easy to apply
<Noskcaj> ok
<Noskcaj> Can someone please explain why http://reqorts.qa.ubuntu.com/reports links the oneric bug tracker?
<smartboyhw> dholbach, how do I tell in the sponsorship queue which packages can I sponsor? (It's nice to include that as a feature in the report)
<dholbach> smartboyhw, that'd be very hard to implement - right now it's a static page only
<smartboyhw> dholbach, OK
<smartboyhw> hmm, it's easy somehow
<pitti> Good morning
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur
 * mdeslaur hugs dholbach back
<nickguletskii> Hi, I would like to ask if there is a change of https://bugs.launchpad.net/ubuntu/+source/lm-sensors/+bug/987714 getting fixed in precise? This bug breaks multiarch support for no good reason (an empty file "is not in sync with other instances of the same package" somehow)
<ubottu> Ubuntu bug 987714 in lm-sensors (Ubuntu) "package libsensors4 1:3.3.1-2ubuntu1 failed to install/upgrade: conffile './etc/sensors.d/.placeholder' is not in sync with other instances of the same package" [Low,Triaged]
<nickguletskii> chance*
<cjwatson> nickguletskii: Hm, dpkg bug I think.  Somebody should confirm in a chroot environment whether quantal's dpkg behaves the same way; I suspect it doesn't.
<nickguletskii> cjwatson: It seems that the quantal version of libsensors4 doesn't have that file, so I can't replicate.
<nickguletskii> heh, weird, it does
<cjwatson> nickguletskii: You don't have to replicate with the quantal version of libsensors4
<cjwatson> You can probably just take a precise chroot and manually upgrade it to quantal's dpkg
<nickguletskii> cjwatson: My bad, it does have .placeholder in .install, it just doesn't exist in the filesystem
<nickguletskii> cjwatson: You are right, this is probably a dpkg bug...
<OrokuSaki> @hallyn Hi! I was wondering if you could help me out with lxc 1.0 sometime.. its not working for me.. I am using 0.9X instead.. when I run lxc-info -n android, I don't have a pid. Kernel is 2.6.35.. Does this perhaps have to do with /sys/fs/pstore? My kernel does not have pstore.. I may try to backport it
<udevbot> Error: "hallyn" is not a valid command.
<OrokuSaki> Of couse, I don't have fanotify or apparmor either
 * cjwatson tries a test upgrade
<cjwatson> (needs quantal's liblzma5 too)
<cjwatson> nickguletskii: Yep, quantal's dpkg is fine, so a backport *should* be possible; not trivial since the code was rearranged somewhat
<chrisccoulson> i've just rebooted my laptop, and it now only boots to a grub prompt.  anyone like to help me out here? :)
<cjwatson> chrisccoulson: https://www.gnu.org/software/grub/manual/grub.html#GRUB-only-offers-a-rescue-shell
<chrisccoulson> cjwatson, thanks
<cjwatson> chrisccoulson: BIOS or UEFI?
<nickguletskii> cjwatson: so it's very unlikely that it will happen?
<cjwatson> nickguletskii: I didn't say that :-)
<chrisccoulson> cjwatson, UEFI
<cjwatson> chrisccoulson: With or without secure boot?
<chrisccoulson> cjwatson, it's with secure boot
<cjwatson> chrisccoulson: Just a theory but might you perhaps have saucy-proposed enabled, upgraded grub2 last Wednesday, and didn't upgrade between then and rebooting?
<nickguletskii> cjwatson: I can't find a relevant bug (I can only find the .placeholder problem in libsensors4)... Should I ask in #ubuntu-bugs about filling out a bug report?
<cjwatson> nickguletskii: Er, you don't need a new bug - I reassigned this one to dpkg
<chrisccoulson> cjwatson, yeah, that's entirely possible
<cjwatson> chrisccoulson: *ritual mockery for having saucy-proposed enabled*
<chrisccoulson> heh
<cjwatson> chrisccoulson: "configfile /EFI/ubuntu/grub.cfg"
<cjwatson> then get back into a real system and upgrade to a grub version actually intended for human consumption
<cjwatson> and disable saucy-proposed :)
<nickguletskii> cjwatson: thank you very much :)
<chrisccoulson> cjwatson, aha, that looks better. Thanks!
 * chrisccoulson owes cjwatson a beer
<cjwatson> You can repay me by answering my question from last week :-)
<cjwatson> 11:41 <cjwatson> chrisccoulson: firefox-testsuite needs to be updated to depend on fonts-liberation, not ttf-liberation - I think I have commit access but which branch(es) do I need to commit to?
<nickguletskii> bye :)
<chrisccoulson> cjwatson, ah, i think i've committed that to trunk
<cjwatson> Oh good, thanks
<chrisccoulson> i was going to upload it when i do the firefox 24 upload later
<cjwatson> Yeah, no desperate rush, I just didn't want it to drift past release
<chrisccoulson> sure, no problem
<chrisccoulson> right, switching back to my proper machine now :)
<smoser> hm..
<smoser> $ sudo ifquery --list --allow auto
<smoser> [sudo] password for smoser:
<smoser> ifquery: failed to lock lockfile /run/network/.ifstate.lock: Bad file descriptor
<smoser> that does'nt look right. expecially since
<smoser>  /etc/network/if-up.d/upstart
<smoser> uses it.
<smoser> it seems /run/network/.ifstate.lock was created around the time my system booted.
<smoser> slangasek, ^ you have any explanation that make that just my system ?
<hallyn_> OrokuSaki: (replied to the pm)
<smoser> bug 1226067
<ubottu> bug 1226067 in ifupdown (Ubuntu) "ifquery fails with bad file descriptor" [Undecided,New] https://launchpad.net/bugs/1226067
<hallyn_> OrokuSaki: oh, looks like ppa version hasn't been built since i pushed the fix to git, lemme make sure
<hallyn_> no, it hasn't.  starting a build now
<OrokuSaki> Sweet! hallyn! thanks! =)
<slangasek> smoser: nothing specifically... if the lock file is hanging around, that seems like an 'ifup' call may have crashed?
<smoser> slangasek, maybe. reproduces in stock cloud iamge.
<smoser> slangasek, https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1226067
<ubottu> Ubuntu bug 1226067 in ifupdown (Ubuntu) "ifquery fails with bad file descriptor" [Medium,New]
<smoser> nothing really sticks out at me in the system.
<lamont> if saucy complains that gnome-control-center-unity is not part of ubuntu, is that me, or saucy?
<smoser> arges, ping.
<arges> smoser: hi
<smoser> please see bug 1160490
<arges> yes
<ubottu> bug 1160490 in ifupdown (Ubuntu Raring) "race condition updating statefile" [Medium,Fix committed] https://launchpad.net/bugs/1160490
<arges> smoser: ok i see it
<arges> smoser: as an experiment can you test 0.7.44 from debian unstable? and see if it has the same issue?
<gQuigs> I was wondering if all the desktop related lucid bugs on here: http://people.canonical.com/~ubuntu-archive/pending-sru.html could just be closed
<gQuigs>   for example: xserver-xorg-video-openchrome, gnome-power-manager and moon (moonlight)
<gQuigs> I was told I would need someone on the SRU team to get close them out
<alberts> mdeslaur: Hi! Can you look at fix for nautilus - https://code.launchpad.net/~albertsmuktupavels/nautilus/white-screen-fix/+merge/180231
 * mdeslaur looks
<smoser> arges, well, 0.7.44-0ubuntu2 *does* have it (saucy)
<smoser> i can quick try with 0.7.44 from debian though
<arges> smoser: actually n/m, looking at the usptream changes
<smoser> arges, k. fwiw, reproduce was just 'boot a cloud image'
<smoser> (also i see this on my laptop though)
<arges> smoser: yea setting it up now and debugging
<mdeslaur> alberts: sorry, I don't have enough nautilus knowledge to be able to understand the impact of that fix. Perhaps you could get someone from the desktop team to approve it?
<alberts> mdeslaur: how to do that?
<arges> smoser: found a patch that fixes it
<arges> http://anonscm.debian.org/hg/collab-maint/ifupdown/rev/fb3055c2c4f0
<arges> smoser: whats teh best way to approach this? create new debdiffs for the regression?
<smoser> for raring, i think you just upload a new package into -proposed.
<smoser> that has a new package version > propposed version
<alberts> mdeslaur: can you look also at this - https://code.launchpad.net/~albertsmuktupavels/ubuntu-themes/restore-space-between-applications-and-places-in-gnome-panel-raring/+merge/178242. It is simple fix which already is included in saucy, but I think it should be included in raring too.
<mdeslaur> alberts: for the nautilus issue, perhaps ask seb128 in #ubuntu-desktop about it?
<arges> smoser: ack. i'm on it
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<alberts> mdeslaur: ok
<gQuigs> how about SRUs from 11.10?  Can they just be closed? : see bug 853507
<ubottu> bug 853507 in pcmanfm (Ubuntu Oneiric) "[SRU]pcmanfm crashed with SIGSEGV in fm_nav_history_get_cur()" [Low,Incomplete] https://launchpad.net/bugs/853507
<smoser> arges, but i think first thing is fix in saucy. i dont think SRU team will move that to -updates as athe bug is right now.
<arges> smoser: will do saucy first
<slangasek> smoser, arges: if you want the SRU team to know not to copy the package to -updates, you'd better set the verification-failed tags...
<smoser> done
<arges> slangasek: smoser: so i found the fix for the regression. how should i handle this? submit a new debdiff with both patches (the one that fixes the race and the fix for teh regression?)
<slangasek> arges: submit an incremental patch against the packages currently in saucy + -proposed
<arges> slangasek: ok this is in bug 1226067
<ubottu> bug 1226067 in ifupdown (Ubuntu) "ifquery fails with bad file descriptor" [Medium,Confirmed] https://launchpad.net/bugs/1226067
<slangasek> yep
<arges> this might be a good testcase to add to ifupdown
<ari-tczew> ampelbein_: can we forward this one to Debian? or it's Ubuntu-specific? (https://launchpad.net/ubuntu/+source/synfig/0.64.0-1ubuntu2)
<ampelbein_> ari-tczew: As far as I can tell, debian doesn't have multiarched boost yet.
<ampelbein_> Or has it? I didn't check for some time.
<ari-tczew> ampelbein_: I don't know, as well.
<ampelbein_> ari-tczew: So, if Debian doesn't have it yet, the patch would be very wrong to send to debian.
<ari-tczew> sure
<arges> slangasek: ok. so bug 1226067 has the patches for P/Q/R as well (since they are affected.)
<ubottu> bug 1226067 in ifupdown (Ubuntu) "ifquery fails with bad file descriptor" [Medium,Confirmed] https://launchpad.net/bugs/1226067
<utlemming> anyone around to help debug 13.04 to 13.10 device permission issuses?
<utlemming> after upgrading from 13.04 to 13.10 I lost the ability to manage USB disks, use printers, audio, webcam and networking
<utlemming> pretty much discovered that 13.04 to 13.10 makes my laptop largely unusable
<utlemming> I was able to fix audio and webcam, but everything else is fubar'd
<utlemming> I am really thinking of reverting back to 13.04
<smoser> arges, i'll upload to saucy "right now" unless someone else is doing that.
<arges> smoser: cool., nobody else is sponsoring afaik
<dobey> pitti, jibel: hey. i uploaded an ubuntuone-credentials last week, and for some weird reason, the autopkgtest run failed, but i got no e-mail about it failing. and the failure makes no sense to me. :(
<dobey> has uscan or something gone weird recently? i just did a bzr merge-upstream on a branch, and ".bz2" has been appended to the version number
<Laney> dobey: isn't it the missing make check target?
<dobey> Laney: that's what the error says, but given the exact same tests ran fine previously, and that the tests require a built tree and everything, i find it hard to believe that is a valid error. did adt-run do something to change to a different working directory without an unbuilt tree, to run the tests, recently?
<dobey> and that the only change in that upload was to add a dep in debian/controlâ¦
<Laney>   * adt-run: Fail tests if they exit with nonzero if "allow-stderr"
<Laney>     restriction is set. Thanks Robie Basak! (LP: #1210503)
<ubottu> Launchpad bug 1210503 in autopkgtest (Ubuntu) ""allow-stderr" tests that produce stderr output always pass" [High,Fix released] https://launchpad.net/bugs/1210503
<Laney> probably that
<Laney> I guess it erroneously used to pass
<dobey> oh, ugh
<dobey> Laney: of course, that still doesn't explain why I was never notified about the failure when it did start happening. :)
<dobey> Laney: anyway, any idea about the ".bz2" being appended to the version when i do merge-upstream?
<Laney> No idea
<Laney> have a look at uscan --verbose --report {,--debug}
<dobey> well, that verifies that it's apparently uscan doing it :-/
#ubuntu-devel 2013-09-17
<OrokuSaki> echo echo echo
<dholbach> good morning
<Noskcaj> Has anyone got 30 seconds to review https://code.launchpad.net/~noskcaj/ubuntu/saucy/navit/liberation/+merge/185976 ?
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<Laney> Noskcaj: ok
<rbasak> Laney: I commented on bug 1121874 and removed ~ubuntu-sponsors. It's also my first patch pilot day today.
<ubottu> bug 1121874 in mysql-5.5 (Ubuntu Raring) "MySQL launch fails silently if < 4MB of disk space is available" [Medium,Triaged] https://launchpad.net/bugs/1121874
<rbasak> Laney: it'd be great if you're around to help me, actually. I'm MOTU and server-dev now.
<Laney> rbasak: how convenient
<Laney> :P
<rbasak> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: rbasak, Laney
<Laney> Let me know if you think stuff is ready and you can't upload it
<Laney> but feel free to concentrate on stuff you can if you like
<Laney> try to do older ones first though
<rbasak> How do you want to avoid duplicate work?
<rbasak> Many of the older ones scare me and I don't want to touch them :-/
<Laney> that's how they get to be old ones
<Laney> you can ask the appropriate person to take a look
<Laney> patch piloting doesn't have to mean uploading
<rbasak> I can clean some of these up a bit too - ones that are already done and just need to be checked and removed.
<Laney> like this
<Laney> mlankhorst: can you work with 4$ on pushing https://code.launchpad.net/~fourdollars/xorg-server/lp1212123/+merge/180060 ?
<Laney> apparently it's fixed in 13.04 onwards
<Laney> rbasak: I'm looking at red for now, you try orange and yellow if you like
<rbasak> Laney: OK. I'm just removing https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1207102 though as that's done.
<ubottu> Ubuntu bug 1207102 in maas (Ubuntu Precise) "Set PXE class lease expiration to 30 seconds" [Undecided,New]
<Laney> k, sounds good
<cjwatson> BenC: unless I'm going blind, your latest linux-ppc upload doesn't seem to have actually built the powerpc64-emb flavour
<cjwatson> BenC: so it'll probably get stuck in saucy-proposed since the new powerpc64-emb metapackages will be uninstallable
<BenC> cjwatson: That would beâ¦weird
<BenC> flavours="debian.ppc/control.d/vars.powerpc-e500 debian.ppc/control.d/vars.powerpc-e500mc debian.ppc/control.d/vars.powerpc-smp debian.ppc/control.d/vars.powerpc64-emb debian.ppc/control.d/vars.powerpc64-smp"
<cjwatson> The build log seems to confirm
<BenC> cjwatson: I'll follow up with another upload
<cjwatson> BenC: thanks
<Laney> rbasak: maybe you fancy https://code.launchpad.net/~med/ubuntu-seeds/sosreport/+merge/179485
<rbasak> Laney: sure. I'll look as soon as I'm done with https://code.launchpad.net/~edbaunton/ubuntu/saucy/r8168/fix-for-linux3.10/+merge/182485. I'll review but I think I'll need you to do the actual merge for me.
<Laney> k
<happyaron> Laney: is there any progress on setting up translation for ubuntu-wallpapers?
<cjwatson> infinity: You said a while back that you understood the scilab failures and it was a matter of rebuilding something.  I can't really work out what, from https://launchpad.net/ubuntu/+source/scilab/5.4.1-4/+build/4860867 - any hints?
<Laney> happyaron: not yet
<happyaron> ok
<Laney> happyaron: but if you want to help you can turn that patch into a merge proposal
<happyaron> Laney: ok
<happyaron> will see if I have time to work on that.
<Laney> should be quick
<rbasak> Laney: if I mark a bug Incomplete, will it disappear from the sponsors queue until someone changes the bug status again? Or should I unsubscribe ubuntu-sponsors temporarily?
<Laney> just changing the status should do it
<Laney> add a comment saying how to get it back
<Laney> actually, no, sorry it doesn't for Incomplete
<rbasak> OK
<rbasak> I'll just leave it in there after my comment then, and move on.
<Laney> feel free to unsubscribe
<rbasak> I've asked for clarification since I can't figure out/reproduce the original problem. It might be me, so I think it's unfair to drop him to the end of the queue again. But if he doesn't respond I think it'd be appropriate to unsubscribe sponsors as it isn't clear what he actually wants uploaded now.
<rbasak> Oh it was an MP, so I've marked it Work in progress. That probably drops it from the queue I guess.
<rbasak> smoser, utlemming: any objection to https://code.launchpad.net/~med/ubuntu-seeds/sosreport/+merge/179485 (seed sosreport in cloud images)? The only things I can think of to consider are installed size and python 2 requirement as mentioned by infinity in https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1206106/comments/9
<ubottu> Ubuntu bug 1206106 in sosreport (Ubuntu) "[MIR] sosreport" [High,Fix released]
<rbasak> It looks like it only drags in 1123k (~92k compressed) in a current saucy image.
<infinity> cjwatson: I believe it unwinds to being something related to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714730
<ubottu> Debian bug 714730 in gfortran "gfortran: binNMU is needed for all packages which contains Fortran90 .mod file when upgrading default version" [Important,Open]
<infinity> cjwatson: Possibly.  Untested theory so far.  I can look at it after I've participated in the miracle of flight this morning.
<cjwatson> infinity: Hm, OK, maybe I can try some analysis and no-change uploads
<rbasak> Laney: I reviewed bug 1217474 and the submitted debdiff is OK to upload with minor changes, but I can't do that. Could you review/upload, please? I'm not sure what testing you'd like to do yourself?
<ubottu> bug 1217474 in crash (Ubuntu) "basic autopkgtest for crash" [Medium,In progress] https://launchpad.net/bugs/1217474
<Laney> rbasak: OK, can you attach your changes too?
<Laney> also I guess update the forwarded bug with the new patch
<rbasak> Laney: ack. The VM that had my updated debdiff mysteriously died :-( but I'll recreate it. Meanwhile, please could you close out https://code.launchpad.net/~jderose/ubuntu/saucy/couchdb/1.4.0/+merge/182725? This has been uploaded already and is in the archive.
<Laney> sure
<rbasak> Actually just realised I can just mark it as Merged.
<Laney> k
<rbasak> Laney: OK I've attached crash_autopkgtest_v2.debdiff to bug 1217474
<ubottu> bug 1217474 in crash (Ubuntu) "basic autopkgtest for crash" [Medium,In progress] https://launchpad.net/bugs/1217474
<rbasak> Updated patch sent to Debian.
<Laney> ta
<rbasak> zul or adam_g: please could you review/upload the patch in bug 1130608? It's languishing in the sponsorship queue. Does this need an FFe?
<ubottu> bug 1130608 in horizon (Ubuntu) "[RFE] - Horizon - Make available openstack_s3 environments for juju" [Wishlist,In progress] https://launchpad.net/bugs/1130608
<rbasak> Laney: please could you reject https://code.launchpad.net/~noskcaj/ubuntu/saucy/imagemagick/lp1218248/+merge/183315? The issue was fixed by a security update, and I don't think it would be accurate to mark this branch as merged.
<Laney> rbasak: roger
<rbasak> mdeslaur: please could you unsubscribe bug 1221040 from ubuntu-security-sponsors as AIUI you've said that it needs no further action right now?
<ubottu> bug 1221040 in wordpress (Ubuntu Raring) "Sync wordpress 3.6.1 (universe) from Debian stable-security" [High,New] https://launchpad.net/bugs/1221040
<mdeslaur> rbasak: done
<rbasak> Thanks!
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: rbasak
 * dholbach hugs rbasak and Laney
<pitti> Good morning
 * ogra_ waves to the DixieChick^Wpitti
<smoser> shoot.
<lifeless> smoser: bang?
<smoser> archive admin (stgraber) i just uploaded ifupdown to p q and r for bug 1226067. but did not include -v to the genchanges.
<ubottu> bug 1226067 in ifupdown (Ubuntu Raring) "ifquery fails with bad file descriptor" [Medium,In progress] https://launchpad.net/bugs/1226067
<stgraber> smoser: do you want to re-upload?
<smoser> yeah. can you NACK?
<stgraber> yep
<lifeless> smoser: are you east coast based?
<smoser> lifeless, yeah. US/Eastern.
<lifeless> smoser: ah, so it's not unreasonably early for you right now ;)
<stgraber> smoser: done
<smoser> not at all.
<smoser> but one coudl argue it is unreasonably late for someone on your side of the world, lifeless
<lifeless> smoser: I'm in Seattle this week.
<lifeless> smoser: for http://lists.openstack.org/pipermail/openstack-dev/2013-July/011687.html
<smoser> neat, lifeless . so its not unreasonably late, but unreasonably early. and reasonably whacked up body clock.
<lifeless> smoser: zigactly!
<Laney> is there a bug where new autopkgtests aren't run by jenkins the first time?
<Laney> the first time the package is uploaded^
<happyaron> rbasak: mind have a look at bug #1226492?
<ubottu> bug 1226492 in UbuntuKylin "[FFE]upload fcitx-qimpanel into archive" [High,New] https://launchpad.net/bugs/1226492
 * happyaron or maybe a release team member...
<rbasak> happyaron: you need a release team member to ack the FFe first, before a sponsor can upload it.
<rbasak> happyaron: once (and if, I guess) it's acked, please subscribe ~ubuntu-sponsors to the bug
<bigon> chrisccoulson: hey, do you think you could upload mozjs17 into debian?
<bigon> I mean are you planning to also maintain this in debian?
<happyaron> rbasak: ok
<happyaron> rbasak: thanks
<marcoceppi> I'm having a weird issue with python packaging, can't seem to get past this
<marcoceppi> http://paste.ubuntu.com/6119081/
<marcoceppi> I found this bug, but it says it's been patched in the version of python-stdeb (0.6.0+20100620-2build1)
<marcoceppi> Not sure what's going on or how to move past it
<rbasak> marcoceppi: I've seen that before
<rbasak> marcoceppi: I think it's caused by an unclean upstream source, but I'm not sure.
<marcoceppi> rbasak: I am the upstream source
<marcoceppi> bug report: https://github.com/astraw/stdeb/pull/57
<rbasak> marcoceppi: did you create the "upstream tarball" with the right setup.py invocation, or are you just using your source tree?
<marcoceppi> rbasak: I used python setup.py sdist
<marcoceppi> then running against that tarbal
<rbasak> I guess it is a bug then.
<rbasak> I was only doing a hack for a PPA (and wasn't sure how the upstream source was created).
<marcoceppi> but according to that report it's patched in the version of python-stdeb that I have
<marcoceppi> hacks are welcome :)
<rbasak> My hack/workaround was to modify the upstream source to match what it wanted, which I think I found spat out somewhere.
<marcoceppi> rbasak: gotchya, I'll try that and press on
<rbasak> marcoceppi: note that I think what it produces works anyway. My memory is hazy though.
<rbasak> Oh. I think it works anyway once modified according to what it complained about.
<cr3> what's the name for the alternative to a "native" package, ie one where packaging is separate from the source?
<cr3> the debian mentors page says non-native, but I thought there was another name
<cjwatson> I would say non-native
<cr3> cjwatson: if it's good enough for you, it's good enough for me. thanks!
<roadmr> hello! can SRUs update translatable strings? (specifically the _Comment in a .desktop file)
<slangasek> roadmr: they can, but given that translators will generally not have a chance to catch up, it's contraindicated unless there's a very serious issue with the current string
<roadmr> slangasek: oh ok, that makes sense. Thanks!
<rbasak> cjwatson: could you add openldap to ~ubuntu-server-dev uploads please?
<cjwatson> rbasak: Done
<rbasak> Thanks!
<bdmurray> barry: can you shed some light on what the systemerror in this means? https://errors.ubuntu.com/problem/15bc0ab1791f275923e1d66575637a22e2b24b7d
<barry> bdmurray: it is almost definitely a buggy extension module.  these things happen when an exception occurs, something doesn't check it correctly, and it lingers until python itself checks the error.
<bdmurray> barry: so something with xml.dom or xml.dom.minidom in this case?
<barry> bdmurray: probably not.  the problem is these kinds of things are *very* hard to track down because the tracebacks have no connection to where the error actually is
<barry> bdmurray: you have to audit 3rd party extension modules, often by manual code inspection
<bdmurray> barry: so then it sounds like something we may want to prevent reporting?
<barry> bdmurray: hard to say.  it's a real bug *somewhere*.  it's just not obvious or easily determined where that is ;)
<rbasak> cjwatson: I got an openldap upload rejected, but the upload was for a precise SRU. Is there something that can be fixed there, or shall I just find a sponsor/someone else to upload?
<infinity> rbasak: What did the reject comment say?
<rbasak> "Signer is not permitted to upload to the component 'main'."
<infinity> rbasak: The mail does include a comment and who rej... Oh.
<infinity> rbasak: Well, there you go. :P
<rbasak> I get that I'm not permitted :)
<rbasak> I'm just not clear on exactly what I should do about that.
<infinity> rbasak: Right, sorry, I missed what you were driving at.  I take it that's a packageset you have access to in saucy?
<rbasak> infinity: cjwatson added openldap to the ~ubuntu-server-dev exception list for me earlier.
<infinity> rbasak: I'm sure someone can fix that.  But I can also sponsor it for you.
<rbasak> infinity: I'd appreciate that, thanks. I'll stick a debdiff in the bug.
<cjwatson> rbasak: Package sets are per-series.  You didn't say you wanted precise
<cjwatson> (But dinnertime)
<rbasak> cjwatson: ah, I didn't realise I needed to specify, thanks.
<infinity> rbasak: I can just steal it from the rejected queue.
<rbasak> infinity: it was openldap
<rbasak> infinity: https://bugs.launchpad.net/ubuntu/precise/+source/openldap/+bug/1216650 (the MP on that), except that I added dep3 headers. I've tested that it fixes the issue in the expected places.
<ubottu> Ubuntu bug 1216650 in openldap (Ubuntu Precise) "slapd crashed with SIGSEGV in lutil_str2bin() when using mdb" [Medium,In progress]
<rbasak> (and reviewed the patch)
<rbasak> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<infinity> rbasak: Reuploaded.
<rbasak> infinity: thanks!
<tarpman> rbasak: if I understand correctly, that bug can be triggered under other backends as well, but mdb makes it a lot more likely?
<rbasak> tarpman: it looks like that to me, yes.
<jtaylor> somethings wrong with adt again: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-skimage/ARCH=amd64,label=adt/6/
<jtaylor> input/output error during install
<pitti> that's from dpkg install; are you sure it's adt specific?
<pitti> hm, installs fine here; trying with run-adt-test -s skimage here
<pitti> (takes a while, crappy internet)
<pitti> Sep 17 19:02:11 autopkgtest kernel: [   87.041881] EXT4-fs error (device vda1): __ext4_new_inode:913: comm dpkg: failed to insert inode 263909: doubly allocated?
<pitti> jtaylor: ^ from that syslog
<pitti> that indeed seems to be a bug somewhere between kernel and qemu
<asac> wgrant: StevenK: check with fginther about a launchpad issue please when you are around
<pitti> adam_g: hey, how are you?
<adam_g> pitti, good, you?
<pitti> adam_g: quite fine, thanks!
<pitti> adam_g: not sure whether you saw the autopkgtest failure of python-troveclient?
<pitti> ah, it actually went to zul, I guess he sponsored
<adam_g> pitti, no i haven't. do you have the results url handy?
<pitti> and https://launchpad.net/~gandelman-a doesn't have an address
<pitti> adam_g: https://jenkins.qa.ubuntu.com/job/saucy-adt-python-troveclient/1
<pitti> adam_g: so, there is no debian/tests/
<pitti> adam_g: so either XS-Testsuite: needs to be dropped, or perhaps you forgot to bzr add them or so?
<adam_g> pitti, ah!
<adam_g> pitti, i actually did not package any originally, but perhaps this tells me i should :)
<pitti> adam_g: so, copy&paste bug in debian/control?
<adam_g> pitti, yup
<adam_g> pitti, what address is missing from https://launchpad.net/~gandelman-a ?
<pitti> adam_g: anyway, if you feel like it you could perhaps add a little smoketest; even a simple 'python -c "import trove"' already is quite useful
<adam_g> pitti, yeah, should be doable
<pitti> adam_g: I think jibel' scripts take email addresses from LP for the notifications
<adam_g> hmm. i've got 4 addresses registered there.
<pitti> adam_g: not public, though
<adam_g> ah
<pitti> jtaylor: other amd64 tests like firefox do the same now; could be a regression from today's kernel?
<pitti> apw: ^ we are getting several "failed to insert inode 263909: doubly allocated?" like errors on amd64 autopkgtests since today
<wgrant> fginther: You had a Launchpad issue?
#ubuntu-devel 2013-09-18
<fginther> wgrant, yes. any idea what might be causing the 401 Unauthorized error here: https://jenkins.qa.ubuntu.com/job/mir-saucy-armhf-ci/5/console
<fginther> wgrant, it's intermittent, the same exact job will pass if retried
<fginther> it's a relatively new issue, I don't recall seeing it prior to this week. Now they are fairly frequent
<wgrant> fginther: Nothing's changed on the Launchpad size
<wgrant> side
<wgrant> There are two rules when Launchpad checks OAuth timestamps:
<wgrant>  - The timestamp must be within 60 minutes of the current time.
<wgrant>  - The timestamp must be no more than 60 seconds older than the latest request from the same OAuth token.
<wgrant> In this case, the second criterion is failing.
<wgrant> You're making a request with a timestamp that's a minute older than some other request with the same token.
<wgrant> Perhaps the slave's system clock is incorrect.
<fginther> wgrant, let me check
<fginther> wgrant, it does appear to be 10 minutes behind
<wgrant> That'd do it.
<fginther> wgrant, thanks for the help
<wgrant> np
<dholbach> good morning
<apw> pitti, these started recently i assume, can you tell what kernel did not show these issues 'before'
<apw> pitti, as the recent kernel upload on the face of it does not have any ext4 changes at least
<apw> pitti, so perhaps what i need is an example of the test that is failing that i can try and run here
<zequence> Anyone available for a fairly simple upload (artwork update)? lp:ubuntustudio-menu
<Laney> zequence: I recommend that you file a bug and subscribe ubuntu-sponsors
<zequence> Laney: Right. Thanks
<doko> mwhudson, are you porting libgo to aarch64?
<doko> cjwatson, is Gerhard Fuchs still supposed to maintain packages.ubuntu.com?
<cjwatson> doko: Gerfried; but yes, I believe so
<pitti> Good morning
<Ursinha> good morning pitti
<pitti> apw: so far I know https://jenkins.qa.ubuntu.com/job/saucy-adt-firefox/150, https://jenkins.qa.ubuntu.com/job/saucy-adt-update-manager/93, https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-skimage/6/ARCH=amd64,label=adt/
<pitti> apw: it only seems to affect amd64, and their syslogs have all rather random messages like that
<pitti> apw: it seems to trigger with lots of I/O, like installing lots of dependencies with dpkg and all that
<pitti> apw: haven't examined in more detail yet (sorry, plumbers conf and all that jazz)
<apw> pitti, those were the only three i could find also, can we get one of them rerun, as i have run the skimage one 20 times without reproducing it
<apw> pitti, following the instructions in your wiki on the subject
<pitti> apw: these VMs run on precise, perhaps that's related?
<pitti> apw: yes, I'll try to re-run the three, at least to get some more patterns
<apw> pitti, sounds good
<pitti> running now
<apw> pitti, testing on a raring system indeed, so that might relate
<apw> pitti, that tends to imply it is not the payload kernel in this case of course ...
<pitti> apw: or that some of the assumptions it makes aren't valid any more on top of an old kernel or so?
<pitti> apw: u-manager failed again (link coming)
<apw> pitti, are we able to run these against older kernel easily, as they seem to have appeared so suddenly
<apw> pitti, and we prolly need to ask the host if it changed kernel recently as well
<apw> pitti, feel free to pass me on to whoever owns that box to ask
<pitti> apw: jibel and I do, but I'm afraid my day today is packed with plumber conf stuff
<pitti> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-update-manager/94/ARCH=amd64,label=adt/ is the new failure (look at syslog)
<pitti> apw: ah sorry, unrelated this time; it didn't even get that far, pykde got uninstallable
<pitti> so let's wait for the other two
<apw> pitti, ok
<pitti> apw: hah, skimage succeeded now; so what kind of sun rays hit us this time..
<apw> pitti, indeed, can we tell which host ran the previous ones (is it the same one, ie is there more than one)
<apw> pitti, i suspect some poking of the host is appropriate
<pitti> apw: yes, we can
<pitti> need to run now, sorry
<apw> pitti, np, that the reruns are working takes the pressure off
<cjwatson> infinity: I rebuilt some Fortran packages for gfortran 4.8, but I don't think that's the scilab problem after all - I think it's a missing build-dep or some other similar thing that was on the Debian maintainer's system when they built the package.  I filed http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=723644
<ubottu> Debian bug 723644 in scilab "scilab: FTBFS when building architecture-independent packages" [Serious,Open]
<cjwatson> infinity: If you can figure out https://launchpad.net/ubuntu/+source/mpich2/1.4.1-4.2ubuntu2/+build/5025697, that would be good.  I've tried it three times, and each time it's mysteriously SIGILLed somewhere in the middle of debhelper.
<cjwatson> infinity: Which would make a lot more sense to me if it were, you know, doing anything odd there.
<apw> cjwatson, there is a strong correlation between the explosions and collect2 in that log
<apw> cjwatson, whre you see the command and a real looking error rather than "in your output was" messages
<cjwatson> apw: Oh, you think it's dodgy output ordering?  Very odd for it to terminate at that particular point in debhelper though
<apw> cjwatson, yeah that last one could be real, there are a lot of collec2 make failures as well with sigill and sigsegv as well before we get that far
<cjwatson> I guess dh_installmime is the last thing in that particular cdbs make target
<cjwatson> So it could be make failing and not debhelper, but that's still WTF.  Why isn't everything else failing to build then?
<cjwatson> It's failed on three different builders
<apw> yeah, most odd indeed
<apw> did we get a new compiler by any chance recently
<cjwatson> Other things are working fine
<apw> makes no sense indeed
<cjwatson> Indeed there's a test rebuild fairly happily chunking through
<apw> i wonder if they are assertions failing, a c assert drops one of those doesn't it
<cjwatson> apw: That usually raises SIGABRT
<apw> bah not that then
 * apw woudl like to know if the buildd in question is producing any dmesg noise to go with it
<apw> alignement for instance
<bdrung> chrisccoulson: why did you bump the epoch in thunderbird?
<chrisccoulson> bdrung, because we already manually added one to the language pack binaries (carried over from when they came from a separate source), and it was either that or add extra hacks to manually add an epoch to the -dbgsym binary packages too
<bdrung> okay
<dobey> pitti, jibel: how do i see what triggered a certain autopkgtest run?
<dobey> bah, i guess rdepends autopkgtets breaking doesn't block packages after all :(
<Laney> which?
<dobey> Laney: or maybe the previous "exit with non-zero when allow-stderr" bug was the issue. but new squid3 and new python-oauthlib broke a couple of the u1 packages autopkgtests :(
<slangasek> dobey: which packages?
<dobey> slangasek: ubuntu-sso-client and ubuntuone-control-panel
<slangasek> ok.  python-ubuntu-sso-client certainly depends on python-oauthlib, which should be enough to make an ubuntu-sso-client adt failure block python-oauthlib migration.  However, the last update of python-oauthlib happened on Sep 3, and the ubuntu-sso-client build failures didn't start happening until Sep 10?
<slangasek> so which package actually caused the regression?
<dobey> slangasek: eh? it was synced to ubuntu on sept 9, and copied into the release pocket on the 10th
<slangasek> dobey: ah - sorry, I was trying to go by the changelog, which of course only shows the Debian upload date
<dobey> slangasek: but there was also a bug in adt-run that caused the tests to 'pass' even though they should have failed, which looks like it probably landed on the 10th, which is when the tests start failing
<slangasek> ah
<dobey> squid was updated on the 2nd, so it probably also slipped in due to the adt-run bug
<slangasek> ok
<dobey> :(
<ochosi> slangasek: sorry bout that
<Laney> yeah you got a passing run with the new oauthlib
<ochosi> slangasek: so the thing is that there seems to be a cross-flavors issue with logout taking ~8secs (even on fast machines)
<ochosi> slangasek: i noticed in xubuntu, then similar issues were reported/confirmed by ubuntu-gnome users, ubuntu users, lubuntu users
<ochosi> slangasek: as there was a switch to logind (and in our case, xfce4-session was patched to support logind), i was wondering whether sessions need more work for logind
<slangasek> ochosi: logind isn't meant to be in the critical path for session teardown.  When the hangs happen, what processes from the user session are still left running?
<ochosi> slangasek: it's a bit hard to say for me, tbh i wasn't entirely able to debug it (and Laney mentioned that this hasn't been debugged yet in ubuntu either)
<ochosi> slangasek: i checked xfce-session (as in ~/.cache/upstart/startxfce4) but there wasn't anything suspicious, i also checked lightdm's logs
<slangasek> debbugged in Ubuntu?  Has it been reproduced in Ubuntu?
<slangasek> ah, yes, you said
<ochosi> well i haven't *personally* reproduced it in ubuntu
<slangasek> are all of the affected flavors using upstart user sessions now?
<ochosi> but it was confirmed to me
<ochosi> i think so, but i can also say for xubuntu for sure
<slangasek> ochosi: so my first guess would be that some user upstart job is not shutting down cleanly when asked, leading to timeouts with the session teardown; it could be related to logind, though I don't see any particular reason why
<slangasek> debugging this probably involves either taking snapshots of the process state from outside the login session and seeing what's running when, or putting debug "echo"s in each of the upstart jobs
<ochosi> hm, i'm not sure i'm technically fit to take care of that
<ochosi> i mostly suggested logind, because i realized it was new and used by all flavors
<ochosi> (so it was more an idea than an informed conjecture)
<slangasek> ochosi: are there open bug reports about this?
<ochosi> slangasek: not yet, i wasn't sure what to report it against...
<slangasek> I'm not either ;)
<slangasek> but better to have it in launchpad than not
<ochosi> definitely
<ochosi> if you have a suggestion i'm happy to write a bugreport
<ochosi> it's also that i'm not sure what to report, as i haven't found anything relevant in the logs
<ochosi> :s
<ochosi> slangasek: so should i just report a generic bug..?
<slangasek> ochosi: report it against upstart for now
<ochosi> slangasek: ok, thanks, i'll paste the bug# as soon as i'm done
<ochosi> or i can subscribe you to it
<ochosi> slangasek: submitted the bug and subscribed, thanks so far!
<happyaron> who's patch pilot right now?
<rbasak> happyaron: there isn't one in right now. It's listed in the channel topic when there is.
<rbasak> happyaron: but if you have a question, go ahead and ask it.
<happyaron> rbasak: would like to find someone review/upload LP #1226492
<ubottu> Launchpad bug 1226492 in UbuntuKylin "[FFE]upload fcitx-qimpanel into archive" [High,New] https://launchpad.net/bugs/1226492
<shadeslayer> cjwatson: could you update the packageset?
<shadeslayer> I put mplayerthumbs in the Kubuntu supported seed
<alkisg> bdrung: hi, I'm using adblock-plus from https://launchpad.net/~mozillateam/+archive/xul-ext, but it needs updating now with thunderbird 24... thanks in any case!
<alkisg> apt-get dist-upgrade ==>
<alkisg> The following packages will be REMOVED:   xul-ext-adblock-plus
<alkisg> The following packages will be upgraded:    thunderbird thunderbird-gnome-support thunderbird-locale-el thunderbird-locale-en
<alkisg> (12.04)
<brainwash> file a bug report against the affected package
<dobey> xnox: ugh. the new python-paste you uploaded, is pretty well broken. its own unit tests don't even pass. and it breaks things that use it (like u1db)
<dobey> xnox: who wrote this patch to convert it to python3?!
<rbasak> dobey, xnox: ah, sounds like the same root cause as https://launchpadlibrarian.net/150553029/buildlog_ubuntu-saucy-i386.convoy_0.2.1%2Bbzr20-0ubuntu1_FAILEDTOBUILD.txt.gz
<dobey> rbasak: indeed. https://bugs.launchpad.net/ubuntu/+source/paste/+bug/1227291
<ubottu> Ubuntu bug 1227291 in paste (Ubuntu) "NameError: global name 'StringType' is not defined" [Critical,New]
<rbasak> StringType is not defined (a 2 to 3 thing) from inside /usr/lib/python2.7/dist-packages/paste/
<rbasak> RIght
<dobey> rbasak: looks like someone tried to make it work with py3 and failed horribly at it :(
<dobey> rbasak: i don't know if it's a 2to3 thing exactly, but the new version of the paste package has a few patches which remove the import of that and several other FooType names, and doesn't quite resolve the usage of them properly
<rbasak> dobey: I didn't mean 2to3 specifically, just a general issue when moving code between 2 and 3.
<dobey> i'm not sure that's why it was there
<dobey> if paste wasn't already supporting py3, then it was there for some other reason
<rbasak> It might be an attempt to make code work under both 2 and 3 gone wrong.
<dobey> rbasak: and anyway, fixing that one error by defining it in that file, onlyh results in other things breaking for another reason
<rbasak> Yeah I don't think that's the root cause
<dobey> rbasak: i don't think so. it's a pre-existing thing. the patches in the new package are an attempt to work under both 2 and 3 gone horribly wrong
<bjsnider> in instances where apt has two different repositories providing the same package, how does it pick which one to use?
<bjsnider> version string is exactly the same
<rbasak> bjsnider: see the output of "apt-cache policy <package>".
<rbasak> It scores them. If scores are the same, then it's non-deterministic I think.
<dobey> whee, and the new squid moved junk around again
<rbasak> You can alter the scores. Search for "apt pinning"
<tarpman> bjsnider: apt_preferences(5) says it'll pick the one listed earliest in sources.list
<bjsnider> rbasak, http://paste.ubuntu.com/6125062/
<bjsnider> tarpman, oh my god you're kidding me
<bjsnider> it's that trivial
<bjsnider> it really is that g comes before l
<rbasak> Ah. The APT preferences do not affect the choice of instance, only the choice of version.
<bjsnider> rbasak, multiarch turned this into a problem
<bjsnider> here's what this guy just described to me
<bjsnider> he's got the amd64 version of that lib installed. came from the libreoffice ppa
<bjsnider> he then adds the gnome3 ppa some time later. he asks for the multiarch lib
<bjsnider> apt picks the gnome3 ppa version for trivial reasons
<bjsnider> except the two changelogs are different
<bjsnider> can't overwrite, now his system is broken, can;t do updates and -f install doesn't fix it
<dobey> wtf can't people pick names that aren't used by other pieces of software, for things?
<bjsnider> would have been avoided had pat realized it's safer to pick the libreoffice ppa version because the amd64 lib is already there
<bjsnider> * apt
<rbasak> PPAs are like that. If users want to use multiple PPAs, their maintainers need to be careful to not collide packages.
<rbasak> Users can pin PPAs to a low priority to help with this to some extent, but that doesn't change their fundamental nature.
<bjsnider> yeah but i think apt needs to be smarter than this
<bjsnider> g comes before l is not good logic
<rbasak> So pin your PPAs as you wish to have them.
<tarpman> is there a reason why the gnome ppa copies the package instead of depending on the libreoffice one
<dobey> tarpman: cross-ppa dependencies is a huge pain to get right
<bjsnider> the two ppas have nothing to do with each other
<dobey> much easier to simply copy or build your own
<tarpman> dobey, ok
<rbasak> bjsnider: yes they do. They share the package namespace on the user's system.
<bjsnider> average users aren't going to know why these failures are happening or what to do about them
<dobey> average?
<rbasak> So PPA maintainers should get their work into a release or backports or whatever.
<dobey> majority of people probably aren't using either PPA, let along both
<dobey> and this problem is extremely rare in practice
<rbasak> It's fine to use PPAs to override small things, but for entire sets of packages, it's dangerous for exactly this reason.
<rbasak> I wouldn't recommend that an average user uses a PPA at all.
<dobey> and the issue in apt really has nothing to do with PPAs or ubuntu, directly
<rbasak> This is why we have releases.
<rbasak> Packages in a single release are engineered to work together.
<bjsnider> only use a ppa if you're na expert?
<bjsnider> how about only use linux if you're an expert too
<dobey> average users will by definition use a PPA if they install any "for purchase" apps from the software center, or use google hangouts
<rbasak> If you use a PPA, you immediately lose security updates from the security tesam.
<dobey> bjsnider: if you want to complain about apt's behavior, the place to do it is in a bug against apt upstream, not in inrc
<dobey> err irc
<rbasak> Only use a PPA if you trust the maintainer of the PPA to have engineered the PPA to work with all the other PPAs you have added.
<rbasak> (at least for average users)
<bjsnider> dobey, i just wanted expert opinion on the logic behind apt's decision-making in that case
<dobey> bjsnider: well this channel isn't for the development of apt. it's more about the development of ubuntu (ie, building the packages that go in the archive)
<rbasak> apt isn't smart enough to read the minds of PPA maintainers. It's designed to resolve things specified by package maintainers. If they haven't declared Conflicts, then it won't work. I don't see how it's a problem with apt.
<dobey> bjsnider: #debian or an apt/dpkg-specific channel would be a better place to ask that
<dobey> rbasak: it's a problem which apt deals with poorly
<rbasak> dobey: I think it's more fundamental to how packages work.
<dobey> rbasak: there are several things apt could do, which it doesn't, that would help. regardelss of the quality of the packages or repositories
<bjsnider> dobey, agreed
<bjsnider> g comes before l is not good enough
<dobey> rbasak: as in other situations, apt could simply ask what to do (ie, pick which one you want)
<rbasak> It is an error to show apt the same package and version from multiple sources that are not the same.
<rbasak> Perhaps apt should detect the checksum difference and flag that.
<rbasak> But whichever way, I don't think it can be expected to work.
<dobey> it doesn't have to work. it just needs to be graceful
<dobey> pretending to work and ending up with a broken system, is pretty bad
<bjsnider> it's just a failure of imagination going back many years i'm sure. the original designers couldn't envision the circumstances that exist today
<dobey> if we were still using the same version of apt that was shipped 10 years ago, i'd think we'd have far worse issues to deal with :)
<genii> Hello. Since -frecord-gcc-switches seems not to be used, how to find what compile options were used to build ?
<cjwatson> genii: simplest to look in the build log
<cjwatson> genii: or anything unusual will normally be in debian/rules
<cjwatson> genii: debian/rules is the entry point to the package's build system
<genii> OK, thanks
<cjwatson> shadeslayer: Done, I think, feel free to check
<shadeslayer> checking
<shadeslayer> cjwatson: well, Riddell already uploaded it, so I got a rejection message that it's already in the archive
<shadeslayer> I suppose I'll have to wait till next time now ;)
<cjwatson> what's your LP account name again?
<shadeslayer> rohangarg
<cjwatson> $ edit-acl -p rohangarg -S saucy -s mplayerthumbs check
<cjwatson> Rohan Garg (rohangarg) can upload mplayerthumbs to Saucy/Release
<shadeslayer> awesome
<shadeslayer> thanks :)
<cjwatson> (lp:ubuntu-archive-tools)
<shadeslayer> neat, will remember that
#ubuntu-devel 2013-09-19
<sarnold> smoser: lintian throws some warnings and errors on simplestreams, e.g. http://paste.ubuntu.com/6126373/
<smoser> sarnold, do do you have any idea what would do that ?
<smoser> i udnestand the man pages.
<smoser> but dont understand how 'python3:any' got in there.
<sarnold> smoser: not a clue on bad-provided-package-name python3:any -- is that ":any" supposed to be there?
<smoser> $ grep any debian/control || echo no
<smoser> no
<smoser> ?
<smoser> i'm sure its something 'ive done stupid. but i dont have a clue.
<sarnold> haha
<smoser> (which is probably why i'm 'so sure it was something that i've done stupid)
<sarnold> man, I just hoped you'd know right off the top of your head a typo somewhere, but .. that's really confusing.
<jbicha> python3:any is new but it's ok http://lists.debian.org/debian-python/2013/09/msg00044.html
<jbicha> I guess you need to report a lintian bug then
<xnox> dobey: rbasak if the python3 converted code leaked into the python2 package that indeed is bad (or vice versa)
<xnox> dobey: rbasak: i'll double check it. But if you say it broke u1, surely it should have been stuck in -proposed because of u1's auto-package-tests, right?!
<Noskcaj> Can someone hit "rebuild" for language-pack-as and mesa? one failed in chroot the other failed to upload
<infinity> Noskcaj: Done.
<Noskcaj> thanks
<dholbach> good morning
<smartboyhw> dholbach, many, many, thanks!!!!!!!!!!!!!
<rbasak> nnnnnnnnnn/sb end
<Noskcaj> smartboyhw, That was a bit over-the-top, can you explain
<smartboyhw> Noskcaj, for sponsoring ubuntustudio-look :)
<smartboyhw> Noskcaj, and I'm not saying it to you:P
<Noskcaj> smartboyhw, I'm allow to be interested. It looks like studio will have a good release for 13.10
<Noskcaj> Does anyone have a good pbuilderrc file for pbuilder-dist i can copy? it needs at least debian sid and ubuntu saucy support
<cjwatson> Grr, I'd hoped I'd never have to use a hardy chroot again
<bluesabre> dholbach: thanks for sponsoring several of xubuntu's pending packages
<bluesabre> would it be possible for you to take a look at https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1227402 as well?
<bluesabre> it updates each of our themes to their latest version which fixes some minor buglets and addresses some transitionary items
<ubottu> Ubuntu bug 1227402 in shimmer-themes (Ubuntu) "Please update shimmer-themes to 1.6.2" [Undecided,Confirmed]
<dholbach> bluesabre, I had a very brief look at it but couldn't quite figure out what to do with the debdiff or the branch
<bluesabre> ochosi, our artwork lead, would have additional details to the changes involved
<bluesabre> ah
<dholbach> in either case I couldn't produce a source package out of it
<bluesabre> I see
<dholbach> let me add a comment to the bug so whoever takes care of it can leave some pointers for either myself or another sponsor
<bluesabre> thanks a lot
<bluesabre> normally we'd have one of our devs with upload rights take care of it, but both are currently away and are likely to miss the UIF
<ochosi> dholbach: thanks for your uploads so far, it's really great for us because (what bluesabre just said)
<dholbach> ochosi, bluesabre: https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1227402
<ubottu> Ubuntu bug 1227402 in shimmer-themes (Ubuntu) "Please update shimmer-themes to 1.6.2" [Undecided,Incomplete]
<bluesabre> thanks dholbach
<dholbach> I know I could just sign the source package which is in the branch (why?), but I wanted to understand a bit better what I'm uploading there :-)
<bluesabre> fair enough.  We have one developer who has been the sole maintainer of that package.  We basically drop the latest git-tags of each theme into there and run debuild -S to produce the latest
<dholbach> ah no, hang on
<bluesabre> as to what he usually does then, its beyond me, but since he has direct upload, its probably known only to him
<dholbach> bluesabre, ochosi: I still don't know how it's put together, but I could rebuild the source package and can upload it - I just took the liberty of adding (LP: #1227402) to the changelog entry so the bug gets closed automatically
<ubottu> Launchpad bug 1227402 in shimmer-themes (Ubuntu) "Please update shimmer-themes to 1.6.2" [Undecided,Incomplete] https://launchpad.net/bugs/1227402
<dholbach> bluesabre, ochosi: maybe you can suggest adding a debian/README which describes how it's put together
<ochosi> dholbach: thanks a *lot* ! i can tell you this was a lot of work to put together (i mean the artwork stuff, but maybe also the complicated packaging, who knows ;)) and I'm happy to see it land before UIF
<bluesabre> dholbach: yes, we've already requested the usual developer to do so when he's around next
<dholbach> bluesabre, ochosi: uploaded
<ochosi>  \o/
<dholbach> rock on!
<bluesabre> dude, you rock!
<ochosi> +1
<dholbach> keep up the good work!
<ochosi> dholbach: a big thank-you from the xubuntu dev-community!
<davmor2> bluesabre: no dholbach doesn't rock, more trance/techno/dance/dubstep
<bluesabre> haha
<dholbach> I think what's happening here is that davmor2 is trying to sneak his own music wishlist in :-P
<bluesabre> probably makes the loco meetings more fun
<doko> glatzor online?
<pitti> Good morning
<davmor2> dholbach: No, just going for accuracy, I've heard you DJ it definitely isn't rock, it does however fall nicely into the other categories :D
<dholbach> I'm not quite sure about the categories, but yeah, Rock doesn't happen that often ;-)
<doko> pitti, apport-noui wants to demote. expected?
<pitti> doko: yes, we don't need that on the phone any more
<pitti> doko: and server guys certainly want to continue with -cli
<pitti> it was a bit of an evolutionary dead end; I should discuss with ev whether we'll still need it at all
<doko> ok, demoted
<doko> jamespage, your libunwind merge ftbfs on every architecture
<jamespage> doko, yeah - I know
<doko> good =)
<jamespage> doko, something odd about linking for the mini-debug-info stuff
<doko> urgh
<doko> anything more specific?
<jamespage> doko, I need to refresh my memory
<jamespage> that happened > 2 weeks ago
<jamespage> doko, the lzma linking was failing for one of the test binaries
<jamespage> I think I see that someone fixed upstream - I'll take another look
<doko> xnox, can I assign this one to you? bug #1227639
<ubottu> bug 1227639 in python-repoze.lru (Ubuntu Saucy) "[MIR] python-repoze.lru needed as a b-d for routes" [High,Incomplete] https://launchpad.net/bugs/1227639
<jamespage> doko, this is the build failure I see on i386
<jamespage> http://paste.ubuntu.com/6128253/
<jamespage> amd64 works OK
<doko> jamespage, looks like libunwind-coredump.so isn't linked with lzma
<doko> fails on the buildd on amd64 too
<jamespage> doko, oh - does it?
<dobey> xnox: paste doesn't work under python 3 either. the patches to make it "work" with 3 as well as 2 are broken. u1db dosen't have an autopkgtest yet, because i wasn't able to make it work right when i was trying to get it working, so i had to leave it out. i've recently discovered another way to do the tests for it though that might work, so i can try to get that in, but the package will of course be held in -proposed because pa
<jamespage> doko, ignore the failure for the one currently in proposed
<jamespage> the test failure is me not reading my own README.source
<doko> ahh, good =)
<speakman> Hi folks. I'm trying to build a package using pbuilder-dist, but it insists on running tests and since it's an x11 program it won't pass. How can I disable testing during pbuilder-dist build?
<JackYu> dholbash, hi
<rbasak> speakman: I don't know about pbuilder specifically, but in general you need to set or get it to set DEB_BUILD_OPTIONS=nocheck when running debian/rules. With sbuild you can just set the environment variable and it passes through.
<rbasak> (this assumes the packaging supports this standard)
<Laney> is there a trick to make debmirror download Contents?
<cjwatson> --getcontents
<Laney> I got that
<cjwatson> Not sure then
<speakman> rsajdok: thanks, but I can't find a way to pass the DEB_BUILD_OPTIONS envvar to the "pbuilder" environment. I'll just try to set it in the running environment and hope for it to come along.
<speakman> Looks like it worked! :)
<smoser> hey. i was looknig at germinate output, basically auditing build process of cloud images.
<smoser> https://bugs.launchpad.net/ubuntu/+bug/1224504
<ubottu> Ubuntu bug 1224504 in Ubuntu "cloud image package list differs from germinate output" [Medium,Confirmed]
<smoser> the build process installs 'ubuntu-minimal' explicitly.
<pitti> jibel: do you know why the new python3.3 wasn't held back by the failing apport test?
<smoser> is there any reason why we would do that? and if so, is there a reason I should'nt just add it to a seed ?  And if so, why would it not be part of all seeds ?
<pitti> jibel: someting changed in MIMEText which breaks the handling of encoding (I'm not yet sure whether apport did things wrong all the years or it's a bug in py3.3), but I thought such things were supposed to be kept in -proposed
<speakman> Where do I fetch the final .deb when pbuilder is done? It looks disappeard currently.
<jamespage> doko, OK - fix uploaded for libunwind
<cjwatson> smoser: Most of the packages you list there are installed conditionally and mustn't be seeded
<cjwatson> smoser: and if you try to add ubuntu-minimal to any other seed you will blow things up
<cjwatson> smoser: is any of this actually important? :-)
<cjwatson> smoser: You absolutely must not seed grub-pc.
<cjwatson> smoser: (because that's hardware-dependent)
<ogra> it might put some pressure up to get the armhf port ready :)
<cjwatson> ogra: I mean even within a single architecture.
<ogra> yeah
<smoser> cjwatson, i wont seed grub-pc. but couldn't i ?
<jibel> cjwatson, has python3-defaults been forced to -release ? The test result is "apport 2.12.2-0ubuntu1 FAIL apport 2.12.2-0ubuntu1 python3-defaults 3.3.2-14ubuntu1" but it wasn't held back
<cjwatson> smoser: efi, sure
<cjwatson> ly
<bjsnider> dobey, i reported a bug to debian yesterday on that apt issue and they argued themselves out of it being apt-s fault and closed it
<cjwatson> smoser: It's generally a fundamental mistake to assume that the BIOS variant is the only one
<smoser> none of it is really important, no. but i was just trying to understand why we would install 'ubuntu-minimal' and 'ubuntu-cloudimg^'
<cjwatson> jibel: No, I sorted out some associated bugs but I didn't force it
<cjwatson> smoser: It's usually a good idea to have the metapackages installed to aid upgrades
<cjwatson> smoser: You've kind of misunderstood seed structure inheritance though
<cjwatson> smoser: The cloud-image seed inherits from standard, yes, which means that germinate computes its expansion starting from the assumption that everything in standard and below is already installed
<pitti> jibel, cjwatson: oh, I guess it's because apport depends on python3, not on python3.3 directly
<cjwatson> smoser: But that doesn't translate into package dependencies
<pitti> jibel, cjwatson: so it's again a transitive dependency, which we don't yet do unfortunately
<speakman> How do I get the resulting .deb package after pbuilder is finished?
<speakman> I can't even find the resulting name anywhere on my disk.
<pitti> (especially because changes in python-defaults are much less prone to break other python stuff than changes in the actual python interpreters)
<cjwatson> smoser: We deliberately omit those dependencies because if we include them then somebody who wants to vary a single choice we've made in, say, ubuntu-minimal, then has to remove ubuntu-standard and ubuntu-desktop as well
<cjwatson> (or whatever)
<cjwatson> smoser: So you need to track the seed inheritance structure when installing the metapackages/tasks in images
<cjwatson> smoser: IOW you can't assume that installing a task higher in the structure will automatically pull in ubuntu-minimal - it won't
<pitti> jibel: ok, nevermind then; I guess we just need to switch to transitive checks at some point
<cjwatson> smoser: does that help?
<smoser> maybe. but now i'm more confused.
<smoser> so the change i made to structure
<speakman> ping cjwatson and rbasak, any ideas how to reach the created .deb package from pbuilder?
<cjwatson> speakman: I don't use pbuilder
<smoser> that does not indicate that cloud image is a strict superset of server ?
<speakman> cjwatson: ok :/
<cjwatson> smoser: Sure, but it doesn't translate into dependencies from any metapackage you generate from cloud-image
<cjwatson> smoser: Nor does it mean that, e.g., the server task implicitly includes standard
<cjwatson> it doesn't
<cjwatson> smoser: now, ubuntu-minimal is probably unnecessary for a different reason: it's included by debootstrap
<cjwatson> speakman: IIRC it's in something like /var/cache/pbuilder/result/ though
<cjwatson> speakman: sbuild is more helpful: puts results in the current directory
<smoser> i dont understand. what you mean by "the server task implicitly includes standard".
<doko> jibel, is there something wrong?
<smoser> my understanding was that it *explicitly* in STRUCTURE includes standard.
<JackYu> robert_ancell, hi
<cjwatson> smoser: That only affects how germinate expands the dependencies
<cjwatson> smoser: It intentionally doesn't translate into the Task fields in the archive
<robert_ancell> JackYu, hello
<cjwatson> smoser: If nothing else, I have no interest in bloating the Packages file with a gazillion Task fields for everything in minimal ...
<JackYu> robert_ancell, would you help to upload the fcitx-qimpanel at bug #1226492?
<ubottu> bug 1226492 in UbuntuKylin "[FFE]upload fcitx-qimpanel into archive" [High,New] https://launchpad.net/bugs/1226492
<smoser> cjwatson, so we *should* be explicitly installing server^ in the build process ?
<smoser> if in fact we want to say "its server + stuff"
<cjwatson> smoser: Yes
<robert_ancell> JackYu, that has nothing to do with me
<cjwatson> smoser: compare live-build/auto/config in livecd-rootfs
<JackYu> robert_ancell, oh, sorry. I saw you are the Pilot today:)
<cjwatson>         xubuntu)
<cjwatson>                 add_task install minimal standard xubuntu-desktop
<robert_ancell> JackYu, sorry, not available at the moment
<smoser> that seems repetitive. but OK.
<cjwatson> smoser: a bit, yes.  IIRC I tried the alternatives and they were worse.
<cjwatson> (for other reasons)
<smoser> ok then. do you have feelings on if i should put STRUCTURE back ?
<cjwatson> smoser: That depends on whether you want cloud-image to be dependency-expanded with respect to server
<cjwatson> I don't think my feelings come into it :)
<JackYu> robert_ancell, That's all right. Would you introduce someone available?
<cjwatson> smoser: That said, cloud-image looks substantively duplicated from server
<cjwatson> smoser: So it does look as though that STRUCTURE change might be a mistake
<cjwatson> smoser: Either that, or there's a load of stuff in cloud-image that should now be deleted because it's already in server
<cjwatson> smoser: Either way, you should indeed make the image build process line up with the seed structure
<speakman> cjwatson: sbuild..?
<cjwatson> smoser: And consider the future question of whether you might ever want something in the default server install but *not* in cloud images
<cjwatson> speakman: apt-cache show
<robert_ancell> JackYu, according to the bug you need an archive administrator which is someone from https://launchpad.net/~ubuntu-archive/+members#active
<smoser> alright. i'm gong to revert that change for now.
<robert_ancell> JackYu, like cjwatson :)
<cjwatson> speakman: and https://wiki.ubuntu.com/SimpleSbuild
<cjwatson> robert_ancell: he still needs a sponsor to upload it ...
<JackYu> robert_ancell, thank:)
<cjwatson> not like me
<cjwatson> I have a million things to do today
<speakman> cjwatson: thanks
<JackYu> cjwatson, robert_ancell, yes, I'm looking for a sponsor...
<robert_ancell> Laney, why does bug 1226492 need an archive admin?
<ubottu> bug 1226492 in UbuntuKylin "[FFE]upload fcitx-qimpanel into archive" [High,New] https://launchpad.net/bugs/1226492
<speakman> cjwatson: A quick one; can I build i386 binaries on an x86_64 platform with sbuild? That's why I'm using pbuilder atm.
<JackYu> I know cjwatson is very busy:)
<cjwatson> speakman: Yes, I do it all the time, you just need an i386 chroot
<cjwatson> xnox: Would you have time to run an update of app-install-data-ubuntu in preparation for final beta?  I notice you did some in raring
<xnox> cjwatson: correct. Yeap, I can do that now.
<speakman> cjwatson: thanks! :)
<pitti> doko: seems last py3.3 is missing a Replaces: ? http://paste.ubuntu.com/6128496/
<cjwatson> speakman: (and rest per that wiki page)
<pitti> doko: want a bug report for that?
<doko> pitti, hmm, it should have one ...
<pitti> doko: not for libpython3.3-stdlib, only for pyton3.3 and python3.3-minimal
<doko> pitti, ok :-/ are the autopkg tests succeeding?
<pitti> doko: for py3.3? yes, they got fixed; thanks!
<pitti> we don't test upgrades in britney, though, so above upgrade bug wasn't detected
<JackYu> pitti, hi, would please help to review the FFE  request at bug #1226492?
<ubottu> bug 1226492 in UbuntuKylin "[FFE]upload fcitx-qimpanel into archive" [High,New] https://launchpad.net/bugs/1226492
<pitti> JackYu: I'm not in the release team
<JackYu> pitti: you  are an archive administrator?
<pitti> JackYu: yes
<JackYu> pitti: Laney said this FFE needs an archive administrator agree:)
<pitti> for NEW review, I guess; can do next week, I'm at a conference this week
<doko> pitti, uploaded
<pitti> doko: danke sehr
<JackYu> pitti, this package would be installed in UbuntuKylin. we need upload this package first before upgrade our default-settings package:).
<speakman> sbuild doesn't like --jobs=13. At least it doesn't pass it to dpkg-buildpackage
<cjwatson> speakman: Are you sure?  Remember that packages have to take explicit care to honour that.
<speakman> cjwatson: I did work using pbuild and it's the same package.
<cjwatson>                        "j|jobs=i" => sub {
<cjwatson>                            push(@{$self->get_conf('DPKG_BUILDPACKAGE_USER_OPTIONS')},
<cjwatson>                                 '-j'.$_[1])
<cjwatson>                        },
<cjwatson> seems fairly straightforward, in sbuild
<cjwatson> speakman: What pbuilder invocation were you using to do this?
<cjwatson> Because AFAICS parallel-build support isn't built into pbuilder ...
<speakman> cjwatson: --debbuildopts
<cjwatson> Perhaps use "ps aux" while sbuild is running to see what the dpkg-buildpackage command line actually is
<speakman> /usr/bin/perl /usr/bin/dpkg-buildpackage -us -uc -mDaniel NystrÃ¶m <daniel@nystrom.st> -b -rfakeroot -j13
<speakman> HM...
<Riddell> ogra: do you know if the ubuntu desktop "Texas Instruments OMAP4 (Hard-Float) desktop image" images are working currently? I can't get today's daily to do anything
<ogra> Riddell, i have no clue
 * ogra hasnt touched a panda in ages
<speakman> cjwatson: http://pastebin.com/Cxpm42Ea
<speakman> cjwatson: that's my sbuildrc
<ogra> and i dont knw who is up to test them or something
<Riddell> ogra: do you know if anyone is looking out for it as part of beta 2?
<cjwatson> speakman: sbuild is fine based on that command
<ogra> nope
<Riddell> ogra: what hardware are the cool kids running these days?
<ogra> Riddell, either desktop or QA i would imagine
<speakman> cjwatson: I also have to make sure it doesn't run any tests (nocheck in DEB_BUILD_OPTIONS), how do I pass that to sbuild? Just setting the env var?
<cjwatson> since it's manifestly passing it through
<cjwatson> speakman: yep
<ogra> Riddell, ubuntu touch on nexus devices :)
<cjwatson> speakman: sbuild sanitises the environment but DEB_BUILD_OPTIONS is one of the ones it lets through
<speakman> cjwatson: Great!
* Maple__ changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Maple__> fasf
<Maple__> you know
<Maple__> this needs +t
<cjwatson> Maple__: it's deliberate since in practice it's not much of a problem
<Maple__> ...if you say so.
<cjwatson> Maple__: And you don't seem to have actually changed anything from my point of view, just set it to the previous value
<cjwatson> I do say so
<cjwatson> If it becomes a practical problem we'll revisit
<cjwatson> (If kicking offenders isn't sufficient)
<speakman> cjwatson: and finally - after one day of trying to "cross" compile for i386 I did get one .i386.deb five minutes before "deadline". :D
<speakman> cjwatson: thanks a lot for helping!
<cjwatson> you're welcome
<cjwatson> I still do almost all my Debian uploads as i386 despite my host system being amd64, so it's a familiar process
 * xnox started to do _multi and merge amd64&i386 uploads for some of my builds.
<pitti> xnox: is "_multi" something sbuild-ish, or just means "you build for multiple architectures and merge the .changes?
<cjwatson> pitti: Not sbuildish, just convention - dak doesn't actually care what the bit between _ and .changes is
<xnox> pitti: build for multiple architectures, then use mergechanges -f foo*.changes.
<cjwatson> pitti: mergechanges(1) produces _multi though
<pitti> cjwatson: oh, as in "part of the .changes filename", thanks
<xnox> pitti: mergechanges, defaults to _multi.changes suffix to not clobber up the rest (source, $arch) . changes.
<pitti> nice, I didn't know about mergechanges
<xnox> pitti: on #ubuntu-release  & in-person there were requests about langpacks refresh. Not sure if it's time to do them again yet, or not.
<pitti> xnox: we missed doing fresh -base ones for beta
<xnox> cause e.g. archive rebuild is in progress.
<xnox> pitti: =( ok.
<pitti> xnox: I guess the next sensible -bsae refresh one would be before final beta, and/or final
<pitti> xnox: but that's mostly about reducing image size
<xnox> ack.
<pitti> xnox: updates from LP are auto-uploaded twice a week
<dobey> xnox: still around?
<pitti> doko: "Jenkins Fixed - saucy-adt-python2.7" \o/ thanks!
<dholbach> doko, barry: who could take a look at https://code.launchpad.net/~mitya57/ubuntu/saucy/python-defaults/2.7.5-5ubuntu1/+merge/185620?
 * dobey wonders what to do about paste
<xnox> dobey: yeah, here.
<xnox> dobey: i think i fixed lint.py in debian now, what packages / where was paste failing for you?
<xnox> dobey: so waiting on lp mirror to pick it up to merge it.
<dobey> xnox: fixed it how?
<xnox> it did unbreak convoy at least.
<dobey> xnox: did you fix the package to run the unit tests at build time as well?
<dholbach> happyaron, is https://bugs.launchpad.net/ubuntu/+source/libchewing/+bug/1220224 something we still want to get into saucy?
<ubottu> Ubuntu bug 1220224 in libchewing (Ubuntu) "Sync libchewing 0.3.5-2 (main) from Debian unstable (main)" [Undecided,Incomplete]
<xnox> dobey: which one? paste's? that's failing from before i started to touch it, so no, i didn't enable it.
<dobey> xnox: it breaks u1db
<dobey> xnox: yes paste. there seem to be a lot more issues than simply the StringType issue
<xnox> dobey: let me test it know, just debuild would do? or do I need to run it?
<happyaron> dholbach: I think it's nice to have.
<dobey> xnox: debuild should be enough, it runs the tests during the build
<dholbach> happyaron, ok, it's still sitting in the sponsoring queue
<happyaron> good
<xnox> dobey: doing test-build against the updated paste now.
<dobey> xnox: can you link to the fix you applied to paste?
<xnox> dobey: build succesful.
<xnox> dobey: well it's in the debian svn / upload. I can link to it once launchpad imports the debian upload.....
<dobey> hmm
<dobey> xnox: ok, please ping me when it gets merged into saucy
<mterry> zul, can you subscribe the server team to blinker bugs?  (it needs to be in main for flask)
<zul> blinker bugs?
<zul> mterry:  doh...done :)
<xnox> dobey: ack.
<mterry> zul, thanks.  I already patched it to run tests.  Seems fine besides
<mterry> zul, bug 1227623 if you're curious
<zul> mterry:  coold thanks
<ubottu> bug 1227623 in blinker (Ubuntu Saucy) "[MIR] blinker required as b-d and as recommends for flask" [High,Fix committed] https://launchpad.net/bugs/1227623
<barry> dholbach: i will look
<dholbach> thanks
<barry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
<pitti> so what magic needs to happen to make the PS auto-uploader actually upload ubuntu-themes in the next 2 hours or so to meet the UIF?
<xnox> ev: fginther: ^
<fginther> pitti, are the necessary changes in trunk?
<xnox> fginther: yes.
<fginther> robru, can help then ^^
<robru> pitti, hi. i will kick off a release build of misc stack for you (this includes ubuntu-themes)
<fginther> robru, thanks
<robru> fginther, pitti: ok, it is done. you should see ubuntu-theme package upload soon.
<robru> pitti, although, I disagree with your changes to the version number... like all daily_release packages, it's built in split mode, which means orig.tar.gz is created by deleting debian/ dir.
<robru> pitti, so with daily_release'd stuff, you only have control over the part of the version number to the left of the '+' sign... the rest is automatically added by jenkins in order to identify when it was released.
<pitti> robru: oh, I see; well, I can back that out
<pitti> robru: but I was worried as there is no obvious way to build an orig for myself, nor any real "upstream"
<pitti> robru: but can we at least drop the 13.04+13.10 stuff?
<robru> pitti, I already fixed the changelog in trunk.
<pitti> robru: ok, thanks
<robru> pitti, the 13.10 bit has to stay, but if you want to change the '13.04' part to something else, go right ahead.
<robru> pitti, and if you 'bzr bd' in the branch, it will make orig.tar.gz for you
<pitti> robru: yes, basically just drop the 13.04+; that seems useless?
<pitti> robru: but oh well, it's already uploaded now according to the changelog, so nevermind
<robru> pitti, I agree, but there needs to be something there for jenkins to build off of. we should discuss with didrocks what makes a good version number.
<pitti> robru: thanks for getting it into the archive!
<pitti> robru: actually, no -- https://launchpad.net/ubuntu/+source/ubuntu-themes/13.04+13.10.20130919.2-0ubuntu1 doesn't seem to contain my changes?
<robru> pitti, hmmm, let me check
<pitti> ah no, that can't be that upload
<pitti> robru: that said the upload was from 4 hours ago
<pitti> so we need another one with xnox's and my changes
<robru> pitti, hmm, that's strange. it looks like it missed your commits. I'll try it again
<pitti> robru: no, xnox' and my commits presumably haven't even been there 4 hours ago
<robru> pitti, i think that timestamp is wrong, because the version number matches what just got uploaded
<robru> pitti, yeah, that's definitely the build I just kicked off, see here: http://10.97.0.1:8080/job/cu2d-misc-saucy-3.0publish/16/console most recent build in the system, and the version number matches. not sure why it says 4hrs ago, maybe one server has a bad clock somewhere/
<robru> also not sure why it didn't get your commit, but will try again
<pitti> robru: ah, so it hasn't actually been uploaded to saucy yet?
<pitti> robru: as https://launchpad.net/ubuntu/+source/ubuntu-themes/13.04+13.10.20130919.2-0ubuntu1 definitively doesn't have the latest changes
<robru> pitti, it made an upload but for some reason it didn't include your commit.
<pitti> robru: or the tree from xnox
<robru> pitti, this is an issue that has bit me a couple times recently, it's like the jenkins job is caching launchpad branches so it doesn't see new commits sometimes
<robru> pitti, hmmm, jenkins claims to have released revision 315, which would include xnox's work. are you sure it's missing?
<pitti> robru: the upload timestamp says "Thu, 19 Sep 2013 14:05:04 +0000" which roughly coincides with "4 hours ago", though
<pitti> robru: perhaps that was an auotmatic one?
<robru> pitti, no, automatic uploads are disabled, things are kind of a mess right now.
<pitti> robru: ah yes, so 315 has xnox' merges, but mine was 316
<pitti> latest one is 318
<robru> yeah, ok I'll run it again and hope for the best
<pitti> robru: thanks
<robru> pitti, you're welcome
<robru> pitti, hmmm, still doesn't seem to have found it. last time this happened to me it took ~12 hours before jenkins saw the latest commit
<robru> pitti, you might want to file your UIFe now, if necessary.
<infinity> smoser: Weren't you going to seed ubuntu-cloudimage-keyring somewhere to keep it in main?
<infinity> smoser: (Or have something depend on it)
<smoser> infinity, maas will depende on it.
<smoser> can i recommends it?
<infinity> smoser: Recommend would be fine.  Also, cloud-utils wants to move to universe too, is that meant to be?
<alberts> Hi! Can patch pilot look at this fix for raring - https://code.launchpad.net/~albertsmuktupavels/ubuntu-themes/restore-space-between-applications-and-places-in-gnome-panel-raring
<smoser> infinity, cloud-utils is in cloud-image seed.
<infinity> smoser: Is not.
<infinity> smoser: cloud-init and cloud-guest-utils are, but not cloud-utils.
<smoser> cloud-guest-utils is binary from cloud-utils.
<smoser> is that not enough?
<smoser> cloud-utils is now metapackage.
<infinity> smoser: Sure, it's a metapackage that depends on cloud-guest-utils and cloud-image-utils.  Is all of that supposed to be in main, or just cloud-guest-utils?
<infinity> smoser: If it should all be in main, you should seed the metapackage somewhere.
<infinity> smoser: Especially if this is required for smooth upgrades from precise.
<infinity> smoser: So, you seed cloud-guest-utils to cloud-image, I'd suggest that you might want cloud-utils in supported.
<smoser> cloud-guest-utils and cloud-image-utils should be in main.
<smoser> yeah. i'll add it in supported.
<infinity> Thanks.
<smoser> and maas will have the dependency on cloudimage-keyring sometime soon
<smoser> roaksoax, ^ can you add that ?
<smoser> for your next upload
<smoser> Depends: ubuntu-cloudimage-keyring
<roaksoax> smoser: for maas?
<smoser> yes
<roaksoax> smoser: what is that for?
<roaksoax> smoser: i mean, what tool?
<roaksoax> region/cluster?
<smoser> whatever downloads ephemeral images.
<alberts> barry: do you have time?
<barry> alberts: hi, what's up?
<alberts> barry: hi! I see you are patch pilot. can you look at this - https://code.launchpad.net/~albertsmuktupavels/ubuntu-themes/restore-space-between-applications-and-places-in-gnome-panel-raring/+merge/178242
<alberts> barry: and at this - https://code.launchpad.net/~albertsmuktupavels/indicator-applet/fix-for-1215337/+merge/185623
<pitti> robru: ouch; is it using the http:// addresses by any chance? they usually lag behind a few minutes
<barry> alberts: i'll take a look
<pitti> robru: I modified bug 1079639 for an UIFe
<ubottu> bug 1079639 in ubuntu-themes (Ubuntu) "UIFE: Icons for error alerts are hokey" [Undecided,Fix committed] https://launchpad.net/bugs/1079639
<robru> pitti, some empirical study has shown that the lag between when a commit lands in trunk, and when jenkins is able to push a release, is more than 4hrs, but less than 7hrs (assuming it's consistent; i haven't tested enough to be able to see if it's random or not)
<robru> pitti, it looks like your commit is 2hrs old, so I expect I'll be able to get a release out within 5hrs
<infinity> smoser: Did you want me to just do that supported seed change for you?
<infinity> smoser: (I'm trying to get some noise out of component-mismatches while I clean it up)
<barry> alberts: i must confess that i am not really qualified to review these branches :/
<smoser> i did it.
<smoser> didn't i?
<smoser> gah.
<smoser> now i did it.
<alberts> barry: who can do it?
<barry> alberts: someone from the desktop team would probably be better
<alberts> barry: ok. thanks!
<barry> alberts: not sure who's still online though ;) mterry perhaps?
<mterry> barry, hi
<mterry> barry, I'm on unity8 team these days  :)
<mterry> of course I can still help
<barry> mterry: ah.  i just looked at ~ubuntu-desktop ;)
<mterry> barry, what am I helping with?
<barry> mterry: alberts has some branches ^^ that need review.  i'll be happy to sponsor them if you can review and approve them
<barry> mterry: https://code.launchpad.net/~albertsmuktupavels/ubuntu-themes/restore-space-between-applications-and-places-in-gnome-panel-raring/+merge/178242
<barry> mterry: https://code.launchpad.net/~albertsmuktupavels/indicator-applet/fix-for-1215337/+merge/185623
<infinity> smoser: Thanks.
<mterry> barry, alberts: looking, commented on first one
<Noskcaj> how do i run debuild through pbuilder-dist?
<barry> @pilotout
<udevbot> Error: "pilotout" is not a valid command.
<barry> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<alberts> mterry: replied on first one
<alberts> mterry: replied to second too
<mterry> barry, first MR you linked to is approved
<mterry> barry, second just needs some testing, but code seems fine
<pitti> robru: wow, that seems like a weird delay, given our 4 hour landing cycle :)
<pitti> robru: thanks
<jtaylor> can one opt out of this phased updates thing? i.e. get everything immediately?
<robru> pitti, yes, this delay only started in the last couple weeks. also, 4-hour landing cycle has been disabled for several weeks
<robru> because everything is broken and horrible
<cjwatson> jtaylor: http://www.murraytwins.com/blog/?p=127
<jtaylor> thx
<cjwatson> jtaylor: referenced from https://lists.ubuntu.com/archives/ubuntu-devel/2013-August/037563.html
<jtaylor> do you know since when support for it is in update-manager?
<cjwatson> I added it in January
<cjwatson> I think it got SRUed back, not sure
<cjwatson> of course you can use apt-get and that always ignores phasing
<jtaylor> hm k, I'm asking because my update manager seems to behave differently since a few weeks
<jtaylor> on 13.04, it pops up multiple times each time giving me a small chunk of updates
<cjwatson> hopefully bdmurray can investigate, he's the king of phased updates :)
<jtaylor> but I'm not sure if I may be imaging it, as I usually update via apt-get, so I'll first check if opting out changes anything
<infinity> tjaalton: You need an MIR for glamor-egl, it looks like.
<tjaalton> infinity: yes
<infinity> tjaalton: Please file one? :)
<tjaalton> on it :)
<infinity> tjaalton: Is this all new code, or something split from mesa or some such?
<tjaalton> infinity: it's a new library
<bdmurray> jtaylor: could you elaborate on pops up multiple times each time?
<jtaylor> it pops up offers me a couple updates, I apply, close update manager
<jtaylor> it pops up right again with more
<bdmurray> Your /var/log/apt/history.log file might be helpful.
<jtaylor> bdmurray: I had this today: http://paste.ubuntu.com/6130220/
<jtaylor> though it seems to be one regular and one security updates
<jtaylor> is it intentional they are split in two?
<bdmurray> apt and curl are undergoing phasing at the moment
<bdmurray> so its possible the first time you weren't selected to install them and later you were
<jtaylor> I had this two split several times in the last few weeks
<bdmurray> oh, and I guess that would make more sense if they were further apart
<jtaylor> really close to each other
<robru> pitti, so a build from r318 has been dispatched, but it seems to be going very slowly. I see it in the PPA but it doesn't look like it's made it into distro yet.
<bdmurray> okay, I'll have a look thanks
<robru> pitti, https://launchpad.net/~ubuntu-unity/+archive/daily-build/+packages?field.name_filter=ubuntu-themes&field.status_filter=published&field.series_filter= keep and eye on that i guess
<jtaylor> this time there were 10 minutes because it was waiting on an ack of listchanges
<jtaylor> yesterday I had itpop up ~ minute after it was done with the first set
<jtaylor> (on a different machine)
<jtaylor> I'll check the logs tomorrow, but I think it might have also been security and regular updates
<infinity> robru: "Very slowly?"  It took 13 minutes to build, so there's only another 11 minutes of delay there so far.
<pitti> robru: trÃ¨s bien, merci
<robru> infinity, well, usually the misc stack runs quite quickly i thought, just a few minutes? seems like it's been running for 30 minutes now, i'm not sure that that's normal
<pitti> robru: I think it'll get held in -proposed due to the freeze that cjwatson announced, but I sent that UIFe about it
<robru> yeah
<infinity> robru: PPA publication times vary a bit.  But still, I wouldn't call this "very slow" was all I was driving at.  It was only uploaded 24m ago.
<robru> infinity, I was referring to this: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/All/job/cu2d-misc-saucy/ which started 35 minutes ago, seems uncharacteristically slow to me
<tjaalton> infinity: btw, if you still want to meet and talk about the backport stack implementation & future, me and mlankhorst are both at lpc
<infinity> Hrm.  Shame Andy isn't.
<infinity> But still might be nice to have a chat.
<infinity> I'm pretty convinced that what we're doing isn't the best we can do, by a long stretch, but sorting out what would be better could take some beer and a large whiteboard.
<tjaalton> the lobby bar has napkins ;)
<infinity> Heh.
<robru> pitti, ok. it looks like it is done and I'm just publishing it now.
<robru> should be in -proposed shortly (before it was just in that PPA)
<tjaalton> infinity: mir filed as bug 1227919
<ubottu> bug 1227919 in glamor-egl (Ubuntu) "[MIR] glamor-egl" [Undecided,New] https://launchpad.net/bugs/1227919
<infinity> tjaalton: Thanks.
<infinity> mterry: If you've got a tiny bit of time, could you have a look at the above?
<mterry> infinity, is it time sensitive?  I can do now, but would slightly prefer to do tomorrow
<infinity> mterry: Seems to be a new rdep of xorg-ati, but I'm sure it can wait a day, just not a month. ;)
<mterry> infinity, done  :)
<infinity> mterry: Might need a light security audit too.
<infinity> mdeslaur: ^
<mterry> infinity, ick, yeah, will assign to security now then, that can take a bit sometimes
<mdeslaur> infinity: thanks
<mdeslaur> sarnold: ^ one more for your list
 * mterry hugs sarnold for his audits
 * sarnold <3  :D
<infinity> sarnold: Doesn't look like it'll be a long audit, but I figure a library that will be linked into an X driver and running ring 0 might need a look-see.
<sarnold> infinity: oh, nice, drivers can go one of two directions.. :)
#ubuntu-devel 2013-09-20
<saiarcot895> Is it possible to get a FFe for the addition of an Apport package hook?
<TheMuso> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<TheMuso> saiarcot895: You would have to file a bug to find out.
<saiarcot895> TheMuso: will do
<venux> Alright.  So I'm trying to develop a theme for it, right, and I want the background color to be a specific shade of blue, and I can't find out how to set that in the mytheme.awn-theme file.  I've checked other themes and they use some sort of 16 digit hexidecimal color code.  In web design, I've only ever heard of and used 6 digit hex color codes, so I'm not too sure how to generate a 16 digit color
<venux> the above is in regards to avant window navigator themes btw
<venux> was wondering if anyone here has had experience with awn themes?
<sarnold> sixteen digits of hex is eight bytes of color data; that'd be 16 bits of color data per RGB and probably opacity... zounds. that's a lot of color. :)
<sarnold> maybe it's sixteen bits per cymk? you know, just in case you want to interact via an offset printing press? :)
<venux> ty, i thought it had something to do with the opacity as well... welll... ill figure out how to generate some of them...  trial and error i guess.
<xnox> dobey: https://launchpad.net/ubuntu/+source/paste/1.7.5.1-6ubuntu1 in saucy-proposed now
<TheMuso> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.10 Beta 1 released | Archive: Open, FF | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> good morning
<sladen> guten morgen
<happyaron> dholbach: I pushed the change according to Jack_Yu's comment
<dholbach> happyaron, I'll take a look in a bit
<happyaron> thx
<dholbach> happyaron, what about the libchewing bug in the sponsoring queue?
<dholbach> should it be uploaded? is it too late?
<happyaron> dholbach: it can be uploaded, but all package depends on it may need a rebuild. I think no API change but no ABI guarantee.
<dholbach> hum
<dholbach> how did they resolve it in Debian?
<happyaron> dholbach: I think it was coordinated that updates to other packages were happen right after libchewing's update.
<happyaron> but we missed that point in Ubuntu
<dholbach> so I'd be happy to sponsor it, if it's something we want
<dholbach> but I'm not quite sure what to do :)
<happyaron> is it difficult to do things like binNMU?
<happyaron> dholbach: maybe I can do some testing this eve, and give feedback then
<dholbach> cool
<happyaron> actually I'm on a national holiday, but all right, :)
<dholbach> enjoy your day off!
<dholbach> happyaron, d/copyright would need to be updated according to the source file changes - some files' headers also still seem to say "version 2"
<happyaron> dholbach: I think those gpl-2+ files are already marked in d/copyright
<dholbach> sorry, my bad
<dholbach> let me double check everything
<happyaron> :)
<dholbach> you're right
<dholbach> happyaron, I'll add the bug number to the changelog entry
<dholbach> apart from that ready to go
<dholbach> uploaded
<happyaron> thanks
<dholbach> anytime
<pitti> Good morning
<ogra> slomo, could you take a peek at https://bugs.launchpad.net/ubuntu/+source/gst-plugins-bad1.0/+bug/1224665 and leave a comment if you find the time ?
<ubottu> Ubuntu bug 1224665 in gst-plugins-bad1.0 (Ubuntu) "[FFe] Android media support over hybris for gst-plugins-bad1.0" [Undecided,New]
<dobey> how long between a whoopsie crash report being submitted, and it appearing on errors.ubuntu.com?
<xnox> doko: Can you pull this patch into debian & ubuntu ? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850#c9
<ubottu> gcc.gnu.org bug 57850 in c++ "[4.8/4.9 Regression] Option -fdump-translation-unit not working" [Normal,Resolved: worksforme]
<xnox> it fixes abi-compliance checker on debian/ubuntu
<dobey> pitti, jibel: do you know how i can get a local adt run of a test using the qemu vm stuff, to not delete the temporary directory where the real tree is built for tests that have a build-needed restriction, when i pass -k?
<xnox> into 4.8
<dobey> or anyone else maybe? ^^
<pitti> dobey: no, not really; but what you perhaps could do is to ssh in after you start your test, and then SIGSTOP adt at a convenient point, or cp -r the temp test tree someplace else?
<pitti> dobey: or you circumvent adt-run completely and just build your tree there and run debian/tests/whatever directly
<dobey> pitti: how do you make debuild not cleanup after the build?
<dobey> although local won't really help
<cjwatson> debuild never cleans up after the build
<cjwatson> other tools around it might ...
<pitti> dobey: dpkg-buildpackage/debuild don't do that "copy entire tree to $TMPDIR" stuff, that's adt-run
<cjwatson> well, not unless you use -tc
<pitti> dobey: dpkg-buildpackage -us -uc -b && sudo debian/tests/whatever should do what you want
<dobey> problem is that dh_install is failing in the vm during the build started by adt-run
<pitti> dobey: or even just "fakeroot debian/rules build" to skip the dh_* bits
<dobey> pitti: yeah, that won't help because it's not where things are breaking :(
<pitti> dobey: oh, you mean the package build is breaking, not the tests?
<dobey> yes
<dobey> well, the package builds fine locally and with pbuilder (and in a PPA or in the archives)
<pitti> dobey: I bet that this is reproducible with "fakeroot debian/rules build"
<pitti> dobey: there's often packages which make assumptions about dpkg-buildpackage's environment (such as various $DEB_*)
<pitti> dobey: but adt-run doesn't use dpkg-buildpackage, it just calls debian/rules build
<pitti> arguably that's Debian policy, but then again I'm rather convinced that this shold be obsoleted
<pitti> fixing lots of packages for these corner cases is just tedious
<dobey> dh_install: libu1db1 missing files (usr/lib/*/libu1db.so.1*), aborting
<pitti> dobey: yep, I bet the package behaves differently because debian/rules expects $DEB_HOST_MULTIARCH but doesn't set it by itself
<pitti> DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
<pitti> dobey: ^ try adding that to the top
<dobey> huh. i wonder why other packages that do the same thing aren't failing. or is DEB_HOST_MULTIARCH always set to something in the jenkins adt instances?
<pitti> dobey: no, but dpkg-buildpackage sets it
<pitti> dobey: other packages did fail in adt-run for the same reason
<dobey> pitti: the jenkins adt-run uses dpkg-buildpackage instaed of fakeroot debian/rules build?
<pitti> dobey: no, the other way around (and nothing to do with jenkins, that's just adt-run)
<pitti> most people check with dpkg-buildpackage only (and frankly I think that shold be the one and only interface), but adt-run directly calls debian/rules build as I said
<pitti> so in adt-run, your debian/rules won't have $DEB_HOST_MULTIARCH set
<pitti> which causes the library to not get configured/installed for multiarch
<dobey> pitti: i mean, there is another package which has pretty much the exact same rules file using $DEB_HOST_MULTIARCH, and the autopkgtests are passing just fine for it when it builds the tree. it doesn't fail with the missing library file
<dobey> pitti: so i don't understand why it doesn't also fail
<pitti> dobey: well, that depends on the package..
<dobey> anyway, adding the bit to the rules file does fix it
<dobey> pitti: thanks
<pitti> yw
<dobey> pitti, jibel: just uploaded a u1db that includes autopkgtest config that wasn't there before, if there's anything you need to poke to enable it. thanks
<pitti> dobey: no, should be automatic; thanks
<doko> xnox, waiting until the arm64 build is done
<xnox> doko: ok.
<xnox> doko: i'd love for that patch to make it into saucy =)
<slomo_> ogra: if this is proposed for upstream integration, sure
<xnox> wgrant: doko: can you please retry https://launchpad.net/ubuntu/+archive/test-rebuild-20130917/+build/4986109 it should be fine now, with fixed paste.
<pitti> xnox, wgrant: ^ retried
<xnox> pitti: thanks! didn't know you have access =)
<pitti> (sounds like sleep time for both of them)
<pitti> "Start 2013-09-22"
<pitti> xnox: how eager are you to verify? i. e. is that fine, or shall I bump score?
<xnox> pitti: i know it's fine, verified locally. I just don't want people to see it on ftbfs-rebuild list and try to investigate, that's all.
<pitti> ah, good point
<pitti> xnox: will build in 8 mins now
<xnox> cool.
<smoser> hey...
<smoser> could a archive admin help me out please?
<smoser> https://launchpad.net/ubuntu/saucy/+queue?queue_state=0&queue_text=uvtool
<smoser> thats for FFE bug 1218508
<ubottu> bug 1218508 in Ubuntu "FFE 13.10: uvtool lxc and kvm tools" [Undecided,Confirmed] https://launchpad.net/bugs/1218508
#ubuntu-devel 2013-09-21
<highvoltage> oh 4chan. http://www.indiegogo.com/project/preview/692587e7
<u-k-i-t> Morning all. Could some sponsor / help through a virtualbox fix into saucy via this syc request please. bug 1228569.
<ubottu> bug 1228569 in virtualbox (Ubuntu) "Sync virtualbox 4.2.16-dfsg-3 (multiverse) from Debian unstable (contrib)" [Undecided,New] https://launchpad.net/bugs/1228569
<u-k-i-t> Fixes bug 1220724.
<ubottu> bug 1220724 in virtualbox (Ubuntu) "vm will not launch if network is set to bridge" [Undecided,Confirmed] https://launchpad.net/bugs/1220724
<Ampelbein> u-k-i-t: I guess someone already did that: https://launchpad.net/ubuntu/+source/virtualbox/4.2.16-dfsg-3
<Ampelbein> Only a few minutes before your request ;-)
<u-k-i-t> Better done twice than not at all. ;-)
<u-k-i-t> I deal with the other request etc. in a moment.
<ari-tczew> jdstrand, doko: will be bug 1196958 processed in saucy?
<ubottu> bug 1196958 in libmnl (Ubuntu) "[MIR] libmnl (b-d of libnetfilter-conntrack)" [Undecided,In progress] https://launchpad.net/bugs/1196958
#ubuntu-devel 2013-09-22
<psusi> so gparted released a minor release fixing several bugs and I just uploaded it to debian unstable... should/could it be synced to saucy before the freeze on Monday?
<Noskcaj> psusi, It's possible, file a sync bug as soon as the package is available in debian and link all fixed bugs
<Noskcaj> it will need an FF
<Noskcaj> *FFe
<psusi> Noskcaj, will it need an FFE seeing as how it is a bugfix only release?  no new features?
<Noskcaj> psusi, At this time, yes.
<Noskcaj> ANd if not, do it just to be safe, since i doubt anyone will look till monday
<smartboyhw> psusi, we are very close to Beta 2 Freeze
<smartboyhw> And rarely people upload stuff on Sundays.
<psusi> ok... I'll probably let it go then since none of them are a big deal or fix bugs currently filed in ubuntu
<valavanisalex> Hi, Inkscape ships some extension scripts that are written in python and I'm not sure how to distribute them properly.  I was under the impression that dh_python2 is used for installing python modules for use by external applications rather than for installing internal components of an application.  Can anyone point me to a similar package with a well-written rules file?
<valavanisalex> At the moment, Debian is throwing up a tonne of Lintian errors because of this [1] so I don't want to merge their latest package until I can sort out the python scripts [1] http://packages.qa.debian.org/i/inkscape.html
<love> can anyone point me to a nice tutorial about making a deb package for a LXDE window theme?
<love> I know some of the basics...  I will need a theme_name.install, but I am not sure what my rules file should look like...  I'll be using pbuilder most likely, unless there is an easier solution...
<love> well... this has been very un-helpful
#ubuntu-devel 2014-09-15
<mwhudson> hm
<mwhudson> for the purposes of super evil hacking, is it possible to convince dpkg that a package is installed?
<mwhudson> sudo vim /var/lib/dpkg/status seems to be suitably evil
<pitti> Good morning
<mlankhor1t> mwhudson: you can create a fake package with http://eric.lubow.org/2010/system-administration/creating-dummy-packages-on-debian/
<apachelogger> if I use bzr merge on two packaging branches will that use dpkg-mergechangelogs internally?
<mwhudson> mlankhorst: ah heh, i guessed that that was possible but not that it had been packaged up like that
<mlankhorst> :-)
<zbenjamin> zyga: hey, about your bug https://bugs.launchpad.net/qtcreator-plugin-ubuntu/+bug/1355286
<ubottu> Launchpad bug 1355286 in phablet-tools (Ubuntu) "phablet-shell conflicts with how SDK sets up ssh keys" [Undecided,New]
<zbenjamin> zyga: couldn't you make phablet-shell add the key to the authorized_keys instead of replacing it?
<zbenjamin> zyga: that file is perfectly fine with containing multiple files
<zbenjamin> zyga: multiple keys i mean
<zyga> zbenjamin: hey
<zbenjamin> heys
<zyga> zbenjamin: I'm not the upstream of phablet-tools, ask ogra about it
<zyga> zbenjamin: I think it's doable
<zbenjamin> ogra_: ^^^^
<zyga> zbenjamin: but ogra "rules" that place so he has to make the call
<zyga> zbenjamin: I just reported that having found the issue so that you both can talk and figure it out :)
<zbenjamin> zyga: ;)
<ogra_> zbenjamin, phablet-shell is  robru's baby ... i agree th key handling is pretty subooptimal
<ogra_> zbenjamin, assign it to me, i'll add some checks and make sure the key is only appended
<zbenjamin> ogra_: awesome!
<zyga> ogra_: \o/
 * ogra_ was annoyed by this plenty of times before 
<zyga> and I'll mirror that in python-phablet
<zyga> ogra_: are you going to the devices sprint?
<ogra_> dunno how my next sprint is called :)
<ogra_> i'm soing to one in 6 weeks or so
<zbenjamin> ogra_: the one in washington
<zyga> ogra_: yeah, the one
<ogra_> (if i get my ass up and finally book it at least :P )
<zyga> ogra_: let's find an hour there to talk about a python API and how we could bless one
<zyga> ogra_: meh, you don't have to be in a hotel lobby now :P
<zbenjamin> ogra_: you should get going on that, flights are rare ;) > 200 people will be there from us
 * zyga got on a train to madrid to do the visa process again
<ogra_> zbenjamin, sure ... deadline is 19th though
 * zbenjamin nees to update his ESTA
<zyga> and now scrambles to get someone to hlep with the invitation letter
<davmor2> ogra_: dude book it already we'll have the entire landing team there in one place rather than just some of us :)
<ogra_> davmor2, no worries ... :)
<zbenjamin> ogra_: i cannot assign the bug to you for phablet-tools: https://bugs.launchpad.net/qtcreator-plugin-ubuntu/+bug/1355286
<ubottu> Launchpad bug 1355286 in phablet-tools (Ubuntu) "phablet-shell conflicts with how SDK sets up ssh keys" [Undecided,New]
<ogra_> done
<zbenjamin> thx :)
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<cjwatson> Urgh, "sudo service dbus restart" was a mistake
<ogra_> lol
<ogra_> only on desktops though
<infinity> cjwatson: Mistake, adventure, potayto, potahto.
<Laney> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<tkamppeter> pitti, I have a problem with pk.install_packages() and as it seems that you have helped me somehow with it in the beginning (http://people.canonical.com/~pitti/scripts/install-printerdriver-gi.py) I want to ask you for help again.
<sergio-br2> Hi
<sergio-br2> i'm trying to compile a package in utopic, in launchpad, with gcc 4.8
<sergio-br2> but it's trying to use a parameter from gcc 4.9 there
<sergio-br2> -fstack-protector-strong
<sergio-br2> is this a bug in debhelper ?
<sergio-br2> https://launchpadlibrarian.net/184914518/buildlog_ubuntu-utopic-amd64.dinothawr_1.0%2Br379~6~ubuntu14.10.1_FAILEDTOBUILD.txt.gz
<sergio-br2> x86_64-linux-gnu-g++-4.8: error: unrecognized command line option '-fstack-protector-strong'
<rbasak> sergio-br2: I don't know if that should be treated as a bug or not, but look at dpkg-buildflags(1) for details on overriding this.
<sergio-br2> ok
<sergio-br2> do i need to add only DEB_CFLAGS_MAINT_SET="-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
<sergio-br2> to debian/rules?
<cjwatson> sergio-br2: the defaults are suitable for the current default compiler.  It isn't a bug if you need to override them when using an older compiler.
<cjwatson> sergio-br2: I'd suggest instead:
<cjwatson> export DEB_CFLAGS_MAINT_STRIP := -fstack-protector-strong
<cjwatson> export DEB_CFLAGS_MAINT_APPEND := -fstack-protector
<sergio-br2> ok
<mlankhorst> afaict from the manual, isn't -fstack-protector-strong implicitly added?
<mlankhorst> same for -fstack-protector for gcc < 4.9
<cjwatson> It's clearly being explicitly added here
<sergio-br2> what's the difference between gcc 4.8 from trusty and from utopic?
<cjwatson> (by dpkg-buildflags)
<mlankhorst> yeah
<cjwatson> But DEB_CFLAGS_MAINT_* let you control this
<cjwatson> Actually it would be DEB_CXXFLAGS_MAINT_* here, since this is g++
<cjwatson> sergio-br2: difference> err, usual ongoing development?  check the changelogs for details
<sergio-br2> k
<shadeslayer> stgraber: poke
<shadeslayer> stgraber: how can I make a Arch container on Ubuntu?
<shadeslayer> because using lxc-create with the archlinux template, I  get : /usr/share/lxc/templates/lxc-archlinux: line 53: pacman: command not found
<Laney> sbeattie: can you remember bug #1266492 well enough to write the SRU information in the description for e-d-s?
<ubottu> bug 1266492 in evolution-data-server (Ubuntu Trusty) "ld:i386 crashes with -static -fPIE -pie" [Critical,Confirmed] https://launchpad.net/bugs/1266492
<stgraber> shadeslayer: at the moment I don't think you can... the proper solution there would be to have archlinux added to the download template so you could download pre-built images
<shadeslayer> stgraber: there's a bootstrap image here https://mirrors.kernel.org/archlinux/iso/2014.09.03/archlinux-bootstrap-2014.09.03-x86_64.tar.gz
<tkamppeter> pitti, around?
<pitti> tkamppeter: sporadically; not feeling very well today
<popey> Did we remove oem installer from the live cd these days? I don't see it in the F4 menu in 14.10 i386 iso...
<cjwatson> Should still be there.
<popey> its not in the F4 menu and i cant raise it with oem-config/enable=true
<popey> unless I'm doing it wrong, which is plausible
<cjwatson> Sounds like a bug, maybe on ubuntu-cdimage.  The code looks OK.  Can't test right now as mid-upgrade.
<popey> want me to file a bug?
<cjwatson> Sure
<popey> k
<cjwatson> Worst case I realise I'm misremembering and close it again
<tkamppeter> pitti, did you see my initial message?
<pitti> tkamppeter: I did, yes, but there's no question; also, it's been years since I did anything with packagekit, so it's probably best if you post a question to -devel@?
<tkamppeter> pitti, will do so.
<smoser> how does net-device-added get invoked ?
<smoser> ah. upstart-udev-bridge.
<pale3_> is it possible to have two package.init files in package/debian/ rules dir?
<pale3_> I am wondering how do I then add two init scripts from one package (because package have two binaries)?
<pale3_> I am talking about package firehol, which now consist of two binaries (firehol,fireqos). both of them needs init script for startup.
<blkperl> slangasek: increasing the values of maxkeys and maxbytes in addtion to the root_* ones seems to have worked for now.
<slangasek> blkperl: hmm, alright
<cjwatson> pale3_: If you mean that there are firehol and fireqos binary packages, then you can indeed have debian/firehol.init and debian/fireqos.init.  If you mean that you have firehol and fireqos executables within a single firehol binary package, then you can have debian/firehol.firehol.init and debian/firehol.fireqos.init and use the --name option to dh_installinit.  See the dh_installinit(1) manual page.
<cjwatson> pale3_: (Similarly for Upstart jobs *.upstart and systemd units *.service.)
<pale3_> cjwatson: your second statements is correct, thats indeed my situation. thx for helping me, I'll go and read dh_installinit
<slangasek> hallyn: hi, is bug #1369785 something that you would be willing to help with?
<ubottu> bug 1369785 in qemu (Ubuntu) "kvm modules not autoloaded on ppc64el" [Undecided,New] https://launchpad.net/bugs/1369785
#ubuntu-devel 2014-09-16
<Mirv> if a core-dev around, there'd be a trio of simple debian/ changes to ack for CI Train at https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/
<Mirv> for signon-plugin-oauth2, the new account-plugin-google comes from account-plugins in the same landing
<Mirv> also, ubuntu-app-launch getting cgmanager and newer upstart dependencies: https://ci-train.ubuntu.com/job/ubuntu-landing-013-2-publish/3/artifact/packaging_changes_ubuntu-app-launch_0.4+14.10.20140915.3-0ubuntu1.diff
<pitti> Good morning
<pitti> infinity: hey, happy birthday!
<dholbach> good morning
<ion> that
<cjwatson> mardy: Could you get https://code.launchpad.net/~cjwatson/signon-ui/pre-0.17-upgrades/+merge/234788 or equivalent into utopic reasonably quickly?  This bug rather disastrously broke my trusty-to-utopic upgrade yesterday (it happened that enough packages were unconfigured that "dpkg --configure -a" gave up, so proceeding required a lot of manual operations; I was able to recover, but most users wouldn't).
<pale3> hi, I'm building package wiich has /usr/share/doc/package/html dir with bunch of html,css stuff. I suppose that this isn't required for creating deb pakacge. I there way to prevent installation of this dir
<pale3> also one more question, as upstream package versions is 2.0.0.rc.1, what versins shuld I use. Could anyone suggest appropriate notation
<pale3> /versins/version
<Laney> oops
<Laney> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mardy> cjwatson: looks good, thanks! I'll try to get it into utopic
<cjwatson> mardy: lovely, thanks
<cjwatson> pale3: why not just remove it in debian/rules after calling dh_auto_install or similar?
<cjwatson> pale3: something like 2.0.0~rc1-1 (where the trailing -1 etc. is the packaging revision) would be usual
<pale3> cjwatson: I dind't tested, will this work if i add rm -rf /usr/share/doc/package/html in override_dh_auto?
<pale3> cjwatson: thx for versioning suggestion
<pale3> i mean override_dh_auto_install
<cjwatson> pale3: not /usr/share/doc/package/html!  Remember that that's your system's directory ...
<cjwatson> pale3: you want debian/package/usr/share/doc/package/html
<pale3> I figgured that I need more work dir, build failes
<pale3> cjwatson: thx
<shadeslayer> stgraber: ping
<shadeslayer> stgraber: lxc question, how do I make a container that I can use with the download template?
<ogra_> cjwatson, could we get tcpdump into rtm for debugging purposes ?
<cjwatson> ogra_: Sure, copied.  Are you intending to put it on any images?  If so please seed it ...
<ogra_> no, just for sergiusens to debug some connectivity stuff
<ogra_> we dont need it seeded
<shadeslayer> anyone else who's a lxc expert and can advise on how to create downloadable lxc rootfs's?
<sergiusens> cjwatson: ogra_ thanks
<hallyn> slangasek: of course.  but note that the autoloading for x86 is actually done by the kernel package nawadays.
<stgraber> shadeslayer: hey
<shadeslayer> stgraber: hi ho, see my question :)
<stgraber> shadeslayer: so basically if you want to make your own image, what you need is .tar.xz compressed version of a rootfs where all hostnames have been replaced by LXC_NAME.
<shadeslayer> I see
<stgraber> shadeslayer: then you need to create a second tarball called meta.tar.xz which contains the following files: build_id (image version string), config (the basic container config), create-message (message displayed post-create, expiry (UNIX EPOCH for cache expiry) and templates (list of files that contain LXC_NAME and need to be sent through sed)
<stgraber> shadeslayer: those files are the ones you usually see in /var/cache/lxc/download/...
<stgraber> shadeslayer: if you care about unprivileged containers, some of those files will have to be different in that case. You can create a <filename>-user file which will override the main one. e.g. config-user will let you ship a different configuration for unprivileged containers
<shadeslayer> oh my, seems a fair amount of work that has no scripts to do it?
 * shadeslayer started looking into docker
<stgraber> shadeslayer: you can do a local test run by making say /var/cache/lxc/download/test/test/amd64/default, unpacking meta.tar.xz in there and placing rootfs.tar.xz. Then call lxc-create -t download -n blah -- -d test -r test -a amd64
<stgraber> shadeslayer: right, we have scripts upstream to generate the public images but I'm not sure how re-usable those would be
<stgraber> shadeslayer: if all you care about is shipping containers between machines, your best bet is a big tarball of /var/lib/lxc/<container> and shipping that between hosts for now (we're working on a better workflow and better tooling but that's still at the design stage)
<shadeslayer> I see
<shadeslayer> stgraber: the thing is, I want to run a arch lxc container on a ubuntu host
<shadeslayer> and that is currently impossibru
<shadeslayer> because ubuntu doesn't have pacman
<shadeslayer> which is what the lxc template uses to bootstrap things
<stgraber> ok, so for a one off kind of thing, I'd create an arch VM, install LXC, create a container in there, make a tarball out of it and copy that to an Ubuntu host, call it tpl-arch or something like that and then use lxc-clone to make copies of it
<stgraber> a clean solution would be to do the same first steps but then update github.com/lxc/lxc-ci to know about pacman and archlinux, get an initial i386 and amd64 arch container loaded on the CI infrastructure and then use that to bootstrap the creation of daily arch containers on images.linuxcontainers.org
<stgraber> we've already done that exact same thing with opensuse (same problem, their package manager wasn't available on Ubuntu)
<shadeslayer> hmm
<rbasak> infinity: ping, re: mysql
<rbasak> infinity: also, some light reading: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007040.html
<slangasek> hallyn: sure; and we'd like the autoloading done by the kernel on ppc64el, but no idea when that will get done :)
<hallyn> slangasek: so i guess the solution is to move qemu-system-x86.qemu-kvm.upstart to qemu-system-common.qemu-kvm.upstart, and have it check the host arch
<hallyn> probably best if we can coordinate with the sysvinit script (i.e. debian)
<hallyn> slangasek: would you want this for utopic?
<mitya57> ScottK: pyqt5 failed to migrate because of a typo in d/tests/control,
<mitya57> can you please upload http://paste.ubuntu.com/8358366/plain/ when you have time?
<mitya57> (Or should I just put it into the queue?)
<dobey> anyone know how to twiddle BIOS settings via /dev/nvram? or update the BIOS?
<dobey> (update it via /dev/nvram that is)
<Guest11861> dd if=/dev/nvram of=/path/to/nvram_name_here.bin   ???
<Guest11861> dd if=/dev/nvram of=/path/to/nvram_name_here.bin.old   to save it to a file
<slangasek> hallyn: eh, currently in utopic the script appears to be called /etc/init.d/qemu-system-x86; I think it's sensible to have a separate script per arch
<Guest11861> dd if=/path/to/new_nvram.bin of=/dev/nvram to write to it?
<slangasek> hallyn: otherwise you have to go renaming conffiles which is annoying
<slangasek> hallyn: and yes, it would be good to have this for utopic :)
<Guest11861> dobey :
<dobey> Guest11861: i know how to use dd. that doesn't tell me how to do what i need to do exactly though :)
<dobey> Guest11861: i need info on the deeper technical bits of it
<Guest11861> dobey : define twiddle?
<dobey> Guest11861: find a specific setting and change it to a valid value
<hallyn> slangasek: that's the init script, but the upstart script is called qemu-kvm (for legacy reasons)
<Guest11861> dobey : do you have the memory map? And a hex editor? Or are you looking for an api?
<dobey> no i don't have the memory map
<dobey> i guess if i did i probably wouldn't be asking, but eh :)
<dobey> what i have is a motherboard where i can't see the bios setup screen when i enter it on boot, and no way to upgrade the bios outside of the bios, becuase i don't have windows
<Guest11861> throw coreboot onto it?
<dobey> and i'm trying to find some way to resolve it or at least fix my video memory allocation, because the default 256MB setting isn't cutting it
<dobey> i'd like to avoid breaking my machine in the process though
<dobey> anyway, need to get food
<slangasek> hallyn: right; see latest bug followup
<hallyn> k
<hallyn> slangasek: it's not true though
<hallyn> we only ship the upstart job
<slangasek> hallyn: then you have not cleaned up the init script on upgrade
<hallyn> ?
<hallyn> you're saying a fresh install now installs both?  (but i installed htis laptop from utopic a month ago)
<slangasek> hallyn: I'm saying that I have it on my system, and it belongs to the package
<slangasek> the fact that it's not on a fresh install (and the fact that it's listed as an 'obsolete' conffile) confirms that it's not in the current package
<hallyn> slangasek: probably from a bug prior to 2.0.0+dfsg-2ubuntu2
<slangasek> but the fact that it's still on my system means that the current packaging is buggy and failed to remove it on upgrade
<hallyn> slangasek: so yes, the reason i haven't renamed qemu-kvm.conf is bc i'm not sure how to do it reliably in terms of packaging
<hallyn> i'd be fine with renaming it to qemu-system-x86.conf
<hallyn> (though that's ugly :)
<slangasek> well, you could even have qemu-kvm.conf shipped by qemu-system-x86:{amd64,i386} and by qemu-system-ppc:ppc64el, and not by other archs
<slangasek> since you wouldn't be installing native versions of those qemu-system-* packages at the same time, the file would just be owned by different packages on each arch
<slangasek> not sure if that's more or less sensible than renaming the conffile
<hallyn> would that hae to be done through debian/rules then, or can that be done through debian/qemu-system-x86.install?
<hallyn> slangasek: so should postinst remove /etc/init.d/qemu-system-x86 (on ubuntu)?
<slangasek> hallyn: you should use dpkg-maintscript-helper rm_conffile
<hallyn> ok, thx, will post a debdiff before doing anything (first finishing up with libvirt)
<slangasek> kees, pitti: TB meeting?
<pitti> slangasek: argh, yes, joined
<hallyn> mdeslaur: hey.  so virt-install shipping from virt-manager introduces 2 new regressions in qrt's test-libvirt.py.  just curious if you've looked at those yet and already knew how to fix them
<hallyn> (one is bc virt-install changed the filename it creates from .img to .qcow 2 :( )
<mdeslaur> hallyn: no, sorry, haven't looked at it at all
<hallyn> mdeslaur: ok, thanks, just didn't want to be wasting time.  ttyl
<mdeslaur> hallyn: cool, thanks
<mdeslaur> hallyn: I wasn't expecting a virt-manager upload to break the libvirt test script, so I don't even think I tried it
<dobey> oh well, guess i'll have to live without games on pc for a while
<hallyn> mdeslaur: heh.  yeah.  ($&%% virt-install.
<doko> jamespage,  did the golang packagers stop shipping .a files at all?
<jamespage> doko, did they ever?
<doko> I thought so, for their first packages ...
<shadeslayer> stgraber: got a moment?
<stgraber> shadeslayer: in a meeting, should be free in about an hour if you're still around?
<shadeslayer> stgraber: works for me, mind putting this to download http://curl.io/get/mhrxqen2/901e295b9b2cd6cc2ee135d83f2147475d68a2db  :P
<shadeslayer> so that we can start right away :)_
<shadeslayer> ( its the arch lxc container I'm working on )
<stgraber> shadeslayer: ok, I'm sort of around for the next 50min
<shadeslayer> stgraber: right, so if you have that container downloaded, you want to rename it to : manjaro.tar.gz
<shadeslayer> and untar it
<shadeslayer> and a config option needs editing in the config file so that it picks up lxcbr0 instead of br0
<stgraber> ok
<stgraber> so how was that container produced?
<shadeslayer> stgraber: via a manjaro ( a arch derivative ) VM
<stgraber> ok, on which you installed lxc and created a regular arch container?
<shadeslayer> yes
<shadeslayer> ( FWIW the error I get on ubuntu when starting the container is : Failed to mount cgroup at /sys/fs/cgroup/systemd: Permission denied )
<shadeslayer> oh oh
<shadeslayer> running it as a unconfined container makes it work
<shadeslayer> though I'm not exactly happy with that
<stgraber> systemd in unpriv containers tends to fail pretty badly usually
<shadeslayer> oh lol, it also modifies my volume xD
<shadeslayer> stgraber: I see, well, networking is still broken
<shadeslayer> but atleast it starts, hurray
<stgraber> shadeslayer: lxc.aa_profile=unconfined will make it start mostly fine but with the usual downsides that this is terribly unsafe
<shadeslayer> stgraber: got a better idea on how to make it work?
<stgraber> patch systemd to be less stupid? :)
<shadeslayer> :p
<stgraber> systemd attemps to mount /sys/fs/cgroup/systemd whether it's already there or not and fails badly if it can't
<shadeslayer> something that does not involve me throwing my life into systemd and taking up drinking copious amounts of alcohol
<stgraber> allowing a container to mount cgroupfs in that way is a very bad thing because the container can then bypass any limit set on it
<shadeslayer> I see
<stgraber> well, you can run it with lxc.aa_profile=unconfined and then just never run anything you don't trust in there, assuming you trust those arch binaries to begin with
<shadeslayer> heh, this is going to grow into a build system :p
<hallyn> mdeslaur: all right i think those are fixed.  /win 26
<mdeslaur> hallyn: great
<hallyn> though my re-pull didn't show my pushes... hm
<hallyn> that's annoying
<hallyn> that's better
<doko> mlankhorst, new try to build mesa with 3.5?
<desrt> can someone help me with installing an ubuntu image on a 2012 n7?
<desrt> i know this is unsupported, but really i just want a way to test arm builds of some stuff from time to time by sshing to it
<desrt> otherwise, what am i meant to do with this wonderful piece of otherwise-useful canonical-owned hardware?
<desrt> (it was working before with a very old OS version on it and i made the mistake of attempting to reflash the newer stuff -- now it's a shiny brick)
<slangasek> infinity: commit #6188 on the glibc packaging svn - has this been tested at all as part of a bootstrap build?  Because the 'ifneq ($(filter stage1,$(DEB_BUILD_PROFILES)),)' check in debian/rules.d/build.mk seems to be the exact opposite of what the cross-toolchain packages are patching this to do
<infinity> slangasek: The cross toolchain packages need adjusting (and maybe glibc in response, etc) to these changes being made, that's on my short list.
<hallyn> slangasek: arges: do you know the name of the kvm kernel module on ppc64le?
<slangasek> hallyn: kvm-hv
<hallyn> thx
<hallyn> and output of uname -m?
<hallyn> slangasek: ^ i'll assume it's precisely "ppc64le" ?
<slangasek> hallyn: hum, I can't readily check at the moment, the porter box is down and the other machines I have access to at the moment are hosts running in BE mode
<slangasek> smoser: ^^ can you confirm the correct uname -m on ppc64el?
<smoser> slangasek, looking
<smoser> $ echo "dpkg=$(dpkg --print-architecture) uname_m=$(uname -m)"
<smoser> dpkg=ppc64el uname_m=ppc64le
<smoser> slangasek, ^
<hallyn> smoser: thx
<infinity> slangasek: THe porter is down?
<infinity> slangasek: Fixed.
<slangasek> infinity: ah, you fixeded it?  yay
<bdmurray> pitti: Could you have a look at bug 1370230?
<ubottu> bug 1370230 in Apport "apport-retrace has become slower" [Undecided,New] https://launchpad.net/bugs/1370230
<infinity> slangasek: ppc64el looked like it had been halted when someone meant to reboot.  powerpc was down too, due to a kernel bug.  I need to see if I can get more traces on that and escalate to benh/antonb.
<slangasek> mmk
<infinity> It's a bit of a blocker for shutting down our old precise ppc buildds, since the gcc testsuite (at least) can reliably crash the trusty kernel every time. :(
<mlankhorst> doko: try x-staging
<mlankhorst> doko: I won't try with 10.1 any more, it kept regressing
<mlankhorst> erm 10.2
<hallyn> slangasek: http://paste.ubuntu.com/8360612/  at least removes the bad old sysvinit file;  it seems like it *should* install the right upstart file on ppc64le
<hallyn> (built fine in ppa and tested from there)
<infinity> hallyn: Except that it was removing the init script that was a mistake.  Both should exist (but be named the same).
<infinity> hallyn: Highly recommend renaming that to /etc/init.d/qemu-kvm in both Debian and Ubuntu and mv_conffileing it, not rm_conffile.
<hallyn> infinity: why should both exist?  i thought not too long ago that was not in vogue
<hallyn> infinity: but i don't think i can convince mjt to rename it to qemu-kvm
<infinity> hallyn: Our "remove all init scripts" fervor was misguided. :P
<hallyn> drat
<infinity> hallyn: And we went about adding them all back recently, along with an upstart hack that ignores the init script if a same-named upstart job exists.
<infinity> hallyn: This allows smaller (or no) deltas with Debian, and a smoother transition to other init systems.
<hallyn> infinity: ok, but so in slangasek's case we would have to detect tha tthe files are different, and remove his sysvinit version
<hallyn> oh, i gues not
<hallyn> i'm being silly
<hallyn> ok, lemme ping mjt.  i think i can make a good case
<infinity> hallyn: So, either the init script needs to be renamed, or reintroduce it and rename the upstart job.
<infinity> hallyn: But I think renamiing the init script is sane, since it's clear what it does (enables kvm for qemu) and you've just made it not arch-specific.
<hallyn> right, arch-specific will start to suck soon
<infinity> hallyn: For ease of maintenance, I might suggest merging the scripts with branching for different arches, to cut down on duplicate code.
<hallyn> yeah i was thinking they'd be more different when i started out
<infinity> hallyn: But that's your call.
<hallyn> infinity: so then should it just move to qemu-system-common for ease,
<hallyn> (then it can just be called qemu-system-common.qemu-kvm.upstart/init/default, instead of renaming something to qemu-system-$arch.qemu-kvm.upstart)
<hallyn> course i'm getting a bit sick of moving files between packages
<cjwatson> Oh!  I think I just had a brainwave about fixing all the zillion man-db error reports / bugs I get when it's triggered and debconf doesn't work ...
<cjwatson> Or at least arranging for some other package to be the victim :-)
<infinity> As long as it's not one of my packages, I fully support this.
<cjwatson> Dunno.  It'd probably be whichever one next tries to use debconf
<infinity> That could be one of my packages. :P
<cjwatson> Or maybe it's only broken during triggers for some reason, but anyway, my immediate motivation is "stop reporting errors against man-db" :-P
<cjwatson> Maybe they'll end up somewhere where the failure is comprehensible.
<cjwatson> And of course it might just be that using debconf in a trigger is unsafe because it runs at points when the relevant perl frontend module is unavailable.
<infinity> cjwatson: That would be a fundamental flaw in the whole design, then, since postinsts tend to invoke debconf, and triggers invoke postinsts...
<cjwatson> infinity: postinst configure is a superset of postinst triggered, but not the other way around.  So it can be handled.
<cjwatson> infinity: http://paste.debian.net/121373/ is what I'm playing with at the moment.
<infinity> cjwatson: To be fair, that fix is correct even without triggers being involved.
<infinity> cjwatson: deconf-is-not-a-registry and all that.
<infinity> (Though, a bit more malleable when it's influencing maintscript behaviour rather than package runtime, I guess)
<cjwatson> infinity: It's actually backwards from debconf-is-not-a-registry.
<cjwatson> Because it's caching information from debconf in the filesystem, rather than the other way round.  But in this case debconf is the agreed interface, so.
<infinity> cjwatson: Hrm, fair point.  Why didn't you just do it as a conffile/semaphore originally, with debconf reading/setting it?
<cjwatson> Well, that's what I'm doing now :)
<cjwatson> It didn't occur to me that using debconf in this way would be a problem, and then I had a mental block on the proper fix that didn't involve changing the interface.
#ubuntu-devel 2014-09-17
<slangasek> hallyn: any reason that your debdiff is calling dpkg-maintscript-helper directly, instead of using debian/qemu-system-x86.maintscript?
<hallyn> slangasek: yes.  ignorance
<slangasek> ;)
<hallyn> so that will expand into all the preinst/postinst/potsrms as needed?  neat
<hallyn> the package.maintscript is not descirbed in dpkg-maintscript-helper manpage
<slangasek> hallyn: yeah, it's part of debhelper's support for dpkg-maintscript-helper, rather than part of the dpkg interface itself
<slangasek> hallyn: documented in dh_installdeb(1)
<cjwatson> Though as a result of a conversation at DebConf there's now a bug requesting a cross-reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759754
<ubottu> Debian bug 759754 in dpkg "dpkg-maintscript-helper: please document debian/package.maintscript support in dh_installdeb" [Wishlist,Open]
<hallyn> oh cool, thanks
<hallyn> infinity: hm.  qemu's debian/rules just does "        dh_installinit -pqemu-system-x86 --no-restart-on-upgrade --error-handler=true --name=qemu-kvm
<hallyn> i.e. it's not doing --upstart-only
<hallyn> but ther eis no compatiability script being created.
<infinity> hallyn: COmpat scripts don't happen anymore.
<infinity> hallyn: And because --name doesn't match the init script, only the upstart job is copied.
<infinity> hallyn: For other reasons (upstart not running it twice), they should have the same name anyway, and if they did, it would magically DTRT.
<hallyn> ok, so i'm plannin to rename the sysvinit script, but fo rmy education,
<hallyn> if the package name was the upstart job name, then it would create the upstart job?  no you say no more compat scripts
<blkperl> slangasek: sigh... still seeing failures my earlier optimism was wrong
<blkperl> slangasek: maybe you were right and its a different issue
<hallyn> ok.  np.  we'll use the sysvinit script anyway.  thanks.
<infinity> hallyn: If the package name and the init script name and the upstart job name were all meant to be the same, then you'd skip --name
<infinity> hallyn: If the package is mismatched (which is fine), then the upstart job and init script should match each other and you need --name
<hallyn> why no more compat scripts?
<infinity> hallyn: Because compat scripts are entirely incompatible with other init systems?
<hallyn> oh, yeah, that
<hallyn> makes sense
<hallyn> thanks
<pitti> bdmurray: yeah, that was quite expected, as before it barely installed anything new (for a well-filled sandbox)
<pitti> bdmurray: I replied to the bug with an initial idea which I think should boost the performance quite a bit
<pitti> bdmurray: I think ATM we don't have really useful numbers to measure the slowdown though (I think we should compare times with cache but empty sandbox, see bug)
<pitti> Good morning
<ScottK> mitya57: I can't get the pastebin to load.
<Unit193> Finally loads for me now.
<pitti> slangasek: still awake? do you know the recommended way to check whether upstart is running? I don't see a socket in /run (checking for such is simple and fast)
<pitti> context: bug 1370329; I'm trying to teach systemd's reboot etc. to fall back to something that works under upstart
<ubottu> bug 1370329 in systemd (Ubuntu) "systemd's reboot/shutdown programs don't work under upstart" [Medium,Triaged] https://launchpad.net/bugs/1370329
<pitti> "telinit 0/6" works fine, but I'd rather guard that with a check if we are actually running upstart
<mitya57> ScottK: how about without /plain? http://paste.ubuntu.com/8358366/
<ScottK> mitya57: Works.  Thanks.
<mitya57> Thanks to you. Btw I'm really impressed by how quickly ftpmasters processed -2 in Debian.
<mbiebl> pitti: couldn't upstart provide /dev/initctl, then it should just work(tm)
<ScottK> mitya57: Thanks for your contribution to Ubuntu.
<pitti> mbiebl: I don't know how much effort that would be; I'm currently working on a fallback to connect to the upstart socket
<ScottK> (uploaded)
<dholbach> good morning
<infinity> pitti: Our usual check is to parse $(initctl version)
<infinity> pitti: (see the libc6 postinst, etc)
<pitti> infinity: yeah, I was wondering if there was something a bit less expensive
<infinity> pitti: If there was, I'd be using it. :/
<pitti> infinity: I think checking if one can connect to unix:abstract=/com/ubuntu/upstart is fine?
<pitti> it's unfortunately an abstract socket, not an unix socket
<infinity> pitti: That assumes dbus?
<infinity> Perfectly viable to have upstart booting your system but no dbus running (or even installed).
<pitti> well, that's upstart's private d-bus socket (not the system dbus one)
<pitti> AFAICS that's upstart's one and only way to talk to it aside from the system bus
<pitti> i. e. it's "the" upstart socket
<pitti> unless I missed anything (I grepped upstart for other connections this morning)
<mlankhorst> weird, is anyone else having problems with youtube on precise?
<mlankhorst> chromium browser works, firefox fails
<pitti> mbiebl, jodh, slangasek: fugly, but at least works: http://paste.ubuntu.com/8363393/
<pitti> I checked telinit's implementation, and it's much more than just one or two d-bus calls, so this calls telinit instead of reimplementing it
<pitti> mbiebl: do you want this in master (i. e. for Debian) too, or aren't you concerned much about booting upstart in Debian?
<mlankhorst> oh nm, looks like an extension issue
<ypwong> cjwatson, hi, ubuntu kylin team is considering to remove wubi.exe from the image, is it possible?
<cjwatson> ypwong: sure, file a bug on ubuntu-cdimage and I can take care of it
<ypwong> cjwatson, thanks! will do.
<caribou> cjwatson: FYI, I just SRUed a fix for bug #1073108 on grub2
<ubottu> bug 1073108 in grub2 (Ubuntu Precise) "grub-pc fails to boot (system resets after GRUB prompt) on degraded RAID" [Medium,In progress] https://launchpad.net/bugs/1073108
<caribou> cjwatson: in case you want to have a look. This is why I pinged you a few days back but I found the fix
<cjwatson> caribou: ah, sure, that makes sense
<cjwatson> caribou: you need sponsorship for that?
<caribou> cjwatson: yes
<caribou> cjwatson: the fix is already in Trusty & Utopic. I'm doing the SRU for Precise
<cjwatson> Yeah
<cjwatson> I remember it
<cjwatson> caribou: sponsored, thanks.  will need another SRU team member to review
<caribou> cjwatson: thank you ! the SRU team is subscribed as well
<flexiondotorg> slangasek, Was just discussing the following with popey - https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1343841
<ubottu> Launchpad bug 1343841 in plymouth (Ubuntu) "boot animation did not appear" [Undecided,Incomplete]
<flexiondotorg> slangasek, popey Suggested I bring it to you attention.
<flexiondotorg> The boot logo is displayed when booting the live media but the installed system doesn't display anything during the boot.
<flexiondotorg> slangasek, This can be reproduced with Ubuntu daily-live, is there anything useful I can run to add to the bug report?
<smoser> can i get an archive admin to NACK the trusty-proposed upload for cloud-init please ?
<smoser> stgraber, ?
<stgraber> smoser: always happy to reject uploads :)
<stgraber> smoser: there you go
<smoser> thanks stgraber
<shadeslayer> stgraber: is there a way to allow lxc to mount procfs?
<stgraber> shadeslayer: turn off apparmor or use a custom apparmor profile allowing mounting proc
<shadeslayer> hmm
<stgraber> shadeslayer: the main reason why we deny mount of proc is that apparmor can only filter access based on paths, so if you can mount procfs somewhere else, then the new mount won't have any protection and you can easily use that to escape the container.
<stgraber> shadeslayer: note that this isn't a problem with unprivileged containers, so if running unprivileged, lxc.aa_profile=unconfined is actually safe
<shadeslayer> I see
<rbasak> infinity: ping (again)
<caribou> stgraber: have you heard of any issue with debian sid container recently ?
<stgraber> caribou: yeah, there are a few issues apparently, one is the apt config, I think we've got a pull request for that. The other may be related to systemd assuming it's been switched to it.
<caribou> stgraber: yeah, looks like systemd is there for something : http://pastebin.ubuntu.com/8365367/
<bdmurray> pitti: the apport-retrace options I used included --sandbox-dir and -C
<pitti> bdmurray: good mornhing
<pitti> bdmurray: right; I was wondering about a comparison with empty sandbox-dir; as with a filled (but old) one we'd compare "broken" against "correct", so not that useful for optimization
<pitti> bdmurray: I have an idea how to speed it up, I was just wondering how to measure it
<bdmurray> pitti: got it
<slangasek> flexiondotorg: the apport information from the person who submitted it shows a system with only VESA in /proc/fb, which does not give the full graphical boot splash experience; but that's in VirtualBox, so is also not relevant to the original submitter's claim that it's broken on an HP laptop
<slangasek> flexiondotorg: so there is still not anything actionable here for plymouth
<slangasek> flexiondotorg: if you can reproduce this problem on real hardware, that's interesting to have apport data for
<flexiondotorg> slangasek, I can reproduce. What do you need.
<slangasek> flexiondotorg: well, I think you should file a new bug against plymouth with 'ubuntu-bug plymouth'
<slangasek> (because your problem may be different than the original submitter's)
<flexiondotorg> slangasek, Also there are several bug reports that look related.
<flexiondotorg> * [LP #1343841](https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1343841)
<flexiondotorg>     * [LP #1356513](https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1356513)
<flexiondotorg>     * [LP #1368414](https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1368414)
<ubottu> Launchpad bug 1343841 in plymouth (Ubuntu) "boot animation did not appear" [Undecided,Incomplete]
<ubottu> Launchpad bug 1356513 in plymouth (Ubuntu) "plymouth 0.9.0 can not use framebuffer for terminal: none" [Undecided,Confirmed]
<ubottu> Launchpad bug 1368414 in plymouth (Ubuntu) "plymouth bug-no splash screen" [Undecided,New]
<slangasek> pitti: why open a dbus connection to the abstract socket, instead of just connect() ?  The latter should suffice for confirming upstart is running
<flexiondotorg> slangasek, When I run up Ubuntu daily-live on real hardware what apport incantations do you want me to invoke?
<slangasek> flexiondotorg: 'ubuntu-bug plymouth'
<flexiondotorg> slangasek, Once I have created a bug. I have other people experiencing the same issue on possibly different hardware. How should they then submit their apport feedback to my bug report?
<slangasek> flexiondotorg: they should file their own bugs, *not* pile on to the same bug report
<flexiondotorg> slangasek, Perfect. Thanks.
<slangasek> flexiondotorg: however, now that I'm thinking about it, I'm not sure we fixed it yet so that the plymouth apport hook is back in the right place
<slangasek> flexiondotorg: so give me a minute to look at this
<pitti> slangasek: ah, if upstart won't get confused by that, that's certainly simpler
<pitti> slangasek: I do something similar in postgres, and the server then always complains about an aborted connection
<flexiondotorg> slangasek, Sure thing. Ping me when you want me file a bug.
<slangasek> pitti: upstart may complain as a low-severity warning, but so what :)
<pitti> slangasek: *nod*
<flexiondotorg> slangasek, Are you aware full disk encryption is broken in 14.10 because Plymouth won't accept the passphrase?
<slangasek> flexiondotorg: no, I'm not aware of that, because I am using it every time I reboot
<flexiondotorg> OK, I'll re-do my test install and file a bug.
<smoser> hey. i'd like to declare names for network interfaces.  i have only mac address.
<smoser>   /etc/udev/rules.d/70-persistent-net.rules says i can edit it if i change only the name
<smoser> but i would not be able to render something exactly like that as i do not have all the necessary ATTR
<smoser> so my question is where can/should i write a udev rule like:
<smoser>  SUBSYSTEM=="net", "ACTION=="add", DRIVERS="?*", ATTR{address}=="$MAC_ADDRESS", NAME="eth0"
<smoser> such that /lib/udev/write_net_rules would not overwrite it
<pitti> smoser: write_net_rules won't touch the file if it already exists
<pitti> smoser: so either just write your adjustments there, or make it an empty file and put your's into a different one (not sure why you'd want this, but it's an option)
<pitti> smoser: ah sorry, I probably misremember that, so ignore this
<pitti> I haven't actually seen it updating an existing file, but I don't see where in the code this would be enforced; presumably if you hotplug a new interface it would get added there
<flexiondotorg> slangasek, I've just tested full disk encryption and you are quite correct it does indeed work.
<smoser> pitti, right. if it doenst update the file on hotplug, then it only serves for interfaces available the first time it ever arn
<slangasek> flexiondotorg: ok.  So I've just uploaded plymouth 0.9.0-0ubuntu4, which reintroduces the apport hook; if you can upgrade to that version of plymouth and then run 'ubuntu-bug plymouth', that's what will get us the needed info
<flexiondotorg> slangasek, Sure.
<doko> cjwatson, is it ok to remove the ps3 packages in the seeds?
<cjwatson> doko: yeah probably
<cjwatson> jamespage: would you mind merging kombu?  needed for new celery version I synced into -proposed, which in turn is needed to fix a build failure
<doko> done
<jamespage> cjwatson, yes ok
<cjwatson> ta
<cjwatson> sbeattie: could you merge hardening-wrapper?  it would fix a build failure
<cjwatson> (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752717)
<ubottu> Debian bug 752717 in src:hardening-wrapper "hardening-wrapper: disable standard hardening flags for test suite" [Serious,Fixed]
<sbeattie> cjwatson: yeah, thanks.
<smoser> cjwatson, you still around ?
<smoser> utlemming and i are getting bothered on bug 1336855 . and admittedly it is a painful issue.
<ubottu> bug 1336855 in cloud-init (Ubuntu Utopic) "[SRU] non-interactive grub updates for 12.04 break on AWS" [Critical,Confirmed] https://launchpad.net/bugs/1336855
<cjwatson> smoser: just go ahead with your workaround and assume I'll sort it out later if it breaks something I care about
<cjwatson> I have no time for anything else at the moment
<smoser> ok. i would *love* to have it sorted correctly in grub.
<smoser> but "need fix now".
<smoser> thanks
<flexiondotorg> slangasek, I've just installed Ubuntu daily-live from today.
<flexiondotorg> slangasek, First boot, got the Unity greeter and switch to tty2 and did apt-get update/upgrade which pulled in the new plymouth build you created plus some Qt5 stuff.
<flexiondotorg> Switched back to Unity greeter and rebooted. Still no boot logo in Plymouth but the bigger issue is that now there is no Unity greeter at all.
<flexiondotorg> slangasek, Do you still want me to riase the plymouth bug given this other change?
<slangasek> flexiondotorg: well, that's interesting
<slangasek> flexiondotorg: so you get no graphical login screen at all?
<flexiondotorg> Just restarted lightdm and Unity greter has loaded.
<slangasek> ah
<slangasek> so if you have that working, I'd say it's ok to file a plymouth bug
<flexiondotorg> Want me to login first or switch to a vt and file the bug?
<flexiondotorg> slangasek, Do you also want a photo of the "no boot logo" screen for Plymouth?
<flexiondotorg> I've rebooted and this time Unity greeter has loaded without issue.
<slangasek> flexiondotorg: probably easiest to file the bug from a GUI login.  Photo - will the photo show anything interesting? :)
<flexiondotorg> slangasek, Photo would be of my cruty old Thinkpad T43p with a blakc screen ð
<slangasek> yeah, I know what black looks like
<slangasek> no need for a photo ;)
<flexiondotorg> What about the nice purple border? Can you image that too? ð
<flexiondotorg> s/image/imagine/
<cjwatson> that part is a grub bug that I've been meaning to get round to fixing
<cjwatson> but I can see it here so don't need details
<flexiondotorg> Yeah, I saw the GRUB bug.
<cjwatson> slightly busy with ... everything else
<flexiondotorg> slangasek, https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1370707
<ubottu> Launchpad bug 1370707 in plymouth (Ubuntu) "Plymouth does not display the graphical boot splash" [Undecided,New]
<flexiondotorg> Do you want me to subscribe any groups to that report?
<slangasek> flexiondotorg: cheers - that should give me a starting point
<flexiondotorg> slangasek, You're welcome.
#ubuntu-devel 2014-09-18
<pitti> Good morning
<dholbach> good morning
<Mirv> I wonder if others are getting the graphical apt icon from time to time claiming KeyError "The cache has no package named 'ubuntu-emulator-runtime'" and if there's something that would need fixing. I think the package was this i386 only package?
<Mirv> sometimes I don't have it, but I remember having it already a month ago or so
<Mirv> right, from the 'android' source
<rbasak> mvo_: have you seen bug 1341320? There's also http://askubuntu.com/questions/496199/hwe-support-status-does-not-tell-me-how-to-upgrade-to-12-04-5 which I think is the same thing.
<ubottu> bug 1341320 in update-manager (Ubuntu) "empty apt-get install command suggested by hwe-support-status" [Undecided,Confirmed] https://launchpad.net/bugs/1341320
<mvo_> rbasak: no, haven't see it, thanks for the notificiation
<rharper> hallyn: I rebuilt qemu with the debdiff for the mknod kvm stuff -- it didn't build qemu-keymap -- so my upgrade of packages is failing ... what am I missing?
<hallyn> rharper: i'm probably pushing to archive soon.  but, qemu-keymap is obsoleted
<hallyn> it'll get removed when you upgrade
<rharper> hrm, ok, maybe I'll just uninstall it
<rharper> just trying to confirm that the upstart job does create the node file inside a container
<hallyn> the packaging should mamke it uninstall
<rharper> it didn't
<hallyn> pkg is built at ppa:serge-hallyn/virt
<hallyn> you can jsut add that and dist-upgrade
<rharper> ok, lemme give that a try then
<hallyn> ok then i'll wait for your report before pushing to utopic
<rharper> hallyn: is that utopic only or should trusty versions be in there?  I added and updated, but I don't see a qemu 2.1 via showpkg for qemu-system-x86
<hallyn> rharper: utopic only
<hallyn> i don't think we can sru that to trusty
<hallyn> it's tiny, but stlil a feature
<rharper> urg
<rharper> that's fair
<rharper> hallyn: lemme try on utopic then
<aliljet> hi!  I was wondering if there's an up to date ubuntu-recommender repo?
<slangasek> doko: fwiw I'm giving back freetype for ppc64el, this doesn't look like a freetype bug there's no error output from the compiler
<barry> doko: webob retry succeeded
<doko> barry, good, can you look at the other python-* ftbfs too?
<barry> doko: yep, it's one of my background tasks
 * barry likes test suites that take 20m to run
<doko> slangasek, freetype, looks like an issue with -fPIC only ... libtool sends this output happily to /dev/null
<doko> afk
<slangasek> doko: what an absurd thing for libtool to do!
<Mirv> compiz would like to have core-dev ack for the dependency changes https://ci-train.ubuntu.com/job/ubuntu-landing-016-2-publish/8/artifact/packaging_changes_compiz_1%3A0.9.12+14.10.20140918-0ubuntu1.diff
<flexiondotorg> slangasek, Me again. We been testing full disk encryption using Ubuntu 14.10 daily with mixed results.
<camako> pitti, ping! Will you be releasing a new version of umockdev? We (in the mir team) are looking forward to the O_TMPFILE fix...
<flexiondotorg> slangasek, I can reliably reproduce installing a fresh 14.10 daily with full disk encryption enabled and then on first boot Plymouth will display just a black screen.
<flexiondotorg> If I switch to vt1 and back to vt7 I see the Plymough graphical theme and pass phrase entry but Plymouth will not accept my pass phrase.
<flexiondotorg> This is using hardware with open source radeon driver.
<flexiondotorg> However, doing the same on hardware with Intel integrated chipset, everything works fine.
<slangasek> flexiondotorg: ok, useful info; I'm not sure if I have a radeon system here to test on but I'll try to figure that out
<flexiondotorg> What we have also discovered is if we disable vt_handoff. Everything appears to work correctly.
<flexiondotorg> slangasek, Have tested that theory extensively but so far a busted system can be made to work.
<flexiondotorg> s/Have/Have not/
<doko> slangasek, freetype is an include issue ... /home/doko/tmp/freetype-2.5.2/freetype-2.5.2/include/freetype.h:33:28: fatal error: ftconfig.h: No such file or directory
<doko>  #include FT_CONFIG_CONFIG_H
<doko>                             ^
<doko> -I ./builds/unix is on the command line, but it should be -I ../builds/unix
<Chipaca> in 14.04.1 a package has MultiArch: foreign, and i can depend on it on an i386 package and install it on amd64 and everything works
<Chipaca> in 14.10 it has no MultiArch, and I can't
<Chipaca> is that a bug?
<jtaylor> which package?
<flexiondotorg> slangasek, Back from my run if you have any questions regarding Plymouth.
<flexiondotorg> Or rather the testing we've been doing.
<smoser> cjwatson, do yo uhave  aminute ?
<smoser> i'm trying to figure out what d-i does in install on ppc64el that i'm not doing
<smoser> i'm prety sure its doing something to get /boot/grub/grub or /boot/grub/powerpc-ieee1275/core.elf onto /dev/sdb1 (the EFI system partition)
<smoser> but it is moderately different
<smoser> heres what the installed d-i system looks like : http://paste.ubuntu.com/8374462/
<slangasek> flexiondotorg: mostly it's down to me laying hands on a radeon machine, I think
<flexiondotorg> I'd send you one of mine but as I unerstand we are separated by some many thousands of miles ð
<zul> barry: ping https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1367907 is there we can do anything about this?
<ubottu> Launchpad bug 1367907 in python3.4 (Ubuntu) "Segfault in gc with cyclic trash" [Undecided,New]
<flexiondotorg> slangasek, Just used todays image and no need to vt switch but I still can't get Plymouth to accept the pass phrase.
<slangasek> flexiondotorg: I'm reasonably certain that there are radeon machines closer to hand, yes
<flexiondotorg> slangasek, I've asked a couple of the other guys to join us here to explain what they have doscovered using virtualisation platforms such as Vbox and QEMU.
<flexiondotorg> Not sure if they will take the bait and join though.
<slangasek> flexiondotorg: results in virtualized environments don't tell us why it's not working on radeon; VMs have different video drivers, and have been mostly-broken for a while with most of the VM video options
<flexiondotorg> slangasek, Fair enough. But in some virtualised environment it works and others it doesn't. I thought it might be an easier way to gather some test data?
<slangasek> flexiondotorg: well, that would be useful data to have, but it still wouldn't help us for radeon
<flexiondotorg> slangasek, Agreed. But I don't think this problem is specific to radeon.
<flexiondotorg> The following bug reports maybe relevant.
<flexiondotorg> https://bugs.freedesktop.org/show_bug.cgi?id=80553
<flexiondotorg> https://bugs.gentoo.org/show_bug.cgi?id=517572
<ubottu> Freedesktop bug 80553 in general "plymouthd exists prematurely so boot splash doesn't work with 0.9.0" [Normal,Assigned]
<ubottu> bugs.gentoo.org bug 517572 in Core system "sys-boot/plymouth-0.9.0 does not shows splash screen" [Normal,Unconfirmed]
<infirit> flexiondotorg, not sure how much you told so let me know what you need me to elaborate on
<mwhudson> sigh
<mwhudson> i need someone to sit me down and explain to me what the modules/abi checking in the kernel build process is all about
<mwhudson> in terms that i won't forget again
<flexiondotorg> infirit, Basically can you tell slangasek what virtualised environment can be used to demonstrate the problem and those that work fine.
<flexiondotorg> infirit, I explained the on real hardware radeon open source driver do not allow Plymouth the accept the decryption pass phrase where as Intel drivers do.
<infirit> virtualbox 4.3.14 does it for me
<flexiondotorg> Sadly, I don't have an Nvidia system I can test on.
<flexiondotorg> infirit, Virtualbox does what, work or not work?
<flexiondotorg> I know, I know the answer but slangasek doesn't ð
<infirit> But also qemu 2.1.1 in virt-manager/libvirt
<infirit> flexiondotorg, slangasek none of those work for me once installed.
<infirit> I have not tried vmware
<infirit> Only when removing the handover it works in these 2
<infirit> But hat may just be working around another problem
<barry> slangasek: can you retry python-concurrent.futures: https://launchpad.net/ubuntu/+archive/test-rebuild-20140914/+build/6375254
<slangasek> barry: retried
<barry> thanks
<Chipaca> jtaylor: realpath
<jtaylor> ?
<Chipaca> <jtaylor> 20:45:50> which package?
<jtaylor> oh thats the one that got absorbed into coreutils right?
<jtaylor> might be a bug due to the change
<jtaylor> oh its one big package, thats probably why
<Chipaca> jtaylor: what does that mean?
<Chipaca> oh, in U it's in coreutils?
<Chipaca> so it's a bug in the dummy transitional package i guess
<jtaylor> though coreutils is M-A: foreign so it should work
<jtaylor> maybe, the transitional is not m-a
<Chipaca> exactly, and that breaks it
<Chipaca> hm, can i depend on coreutils >x.y.z | realpath ?
<jtaylor> I think so
<Chipaca> worked in U, let's see on T
<jtaylor> filing a bug should not harm either
<Chipaca> yup
<jtaylor> assuming m-a works for transitionals
 * Chipaca files
<Chipaca> https://bugs.launchpad.net/ubuntu/+source/realpath/+bug/1371303
<ubottu> Launchpad bug 1371303 in realpath (Ubuntu) "missing MultiArch breaks multiarch packages that depend on realpath" [Undecided,New]
<jtaylor> hm it should be filed against coreutils that contains the transitional
<Chipaca> now to see if it'll work in 12.04 too :)
<Chipaca> jtaylor: thanks for reassigning it
<Noskcaj> Could someone please look at bug 1371309
<ubottu> bug 1371309 in ubuntu-gnome-meta (Ubuntu) "Add numix-gtk-theme to ubuntu-gnome seed" [Undecided,New] https://launchpad.net/bugs/1371309
<Noskcaj> cjwatson, You did the most recent change to the seed, is bug bug 1371309 alright?
<ubottu> bug 1371309 in ubuntu-gnome-meta (Ubuntu) "Add numix-gtk-theme to ubuntu-gnome seed" [Undecided,New] https://launchpad.net/bugs/1371309
<doko> rbasak, jamespage: why is mysql built sequentially?
<smoser> well, cjwatson if you come around. this is d-i install: http://paste.ubuntu.com/8375494/ . and this is curtin install: http://paste.ubuntu.com/8375494/
<smoser> bah. d-i : http://paste.ubuntu.com/8374462/
<slangasek> doko: so for the record, it's not libtool that's suppressing the output, freetype is invoking libtool with >/dev/null 2>&1 and I can't figure out where in the build system this is happening <grr>
<slangasek> doko: also, I am skeptical of this "include issue"; why would freetype have regressed in its ability to find its own headers, and why would it have regressed only on ppc64el?
<doko> it is libtool
<doko> or the generated Makefile, once building with, and then without -fPIC
<slangasek> doko: freetype's build system is crazy and I can find no generated Makefile like you describe - which file are you seeing this in?
<doko> slangasek, no, it is libtool itself calling the compiler twice, once without -fPIC, and then with it
<slangasek> doko: ah; so it's libtool redirecting gcc's output?
<slangasek> do you know how to override that?
<infinity> smoser: At a glance, I'm not actually seeing a problem with the difference between those two pastes.  I assume that the curtin one doesn't boot, however?
<doko>       # Allow error messages only from the first compilation.
<doko>       if test "$suppress_opt" = yes; then
<doko>         suppress_output=' >/dev/null 2>&1'
<doko>       fi
<slangasek> hmm, -no-suppress apparently
<slangasek> doko: yeah, just got there, thanks
<slangasek> this is of course not documented in libtool --help
<doko> slangasek, libtool -no-suppress
<slangasek> apparently not
<slangasek> needs to go after the --mode argument
<slangasek> doko: ok; this is what I get for output now, doesn't say anything about an include problem? http://paste.ubuntu.com/8375838/
<doko> hmm
<infinity> slangasek: That's an -O3 problem.
<doko> does this go away with -O2?
<slangasek> probably ;)
<infinity> slangasek: Or, rather, a sketchy code being optimised to oblivion with -O3.
<slangasek> I just wanted to confirm that this wasn't the include problem you were seeing
<slangasek> I'll chase it down from here
#ubuntu-devel 2014-09-19
<infinity> pitti: Hrm.  Check out the sbcl failure in utopic-proposed.  pkgstrip vomits with a "find : permission denied"... Bug in pkg* for not ignoring that, or bug in sbcl for producing non-readable/traversable files/directories during build, or both?
<infinity> pitti: (Testing the obvious fix for sbcl and will submit that to Debian regardless, but wondering if we should also consider this a pkgbinarymangler failure and fix that)
<pitti> camako: oh, sure, can do!
<pitti> Good morning (or so)
<pitti> infinity: yes, in general I think we should fix this stuff in pkgbinarymangler too, to avoid rather pointless package deltas
<pitti> camako: I wasn't aware that you guys are waiting on this, so thanks for the ping
<pitti> camako: released upstream 0.8.7 and uploaded to sid; I'll sync it in a few hours once it got imported into LP
<happyaron> attente_: it's released yesterday, I'm working on it atm
<KjetilK> I'm one of the upstream devs of librdf-trine-perl, and I've just committed some rather extensive performance enhancements in the package. These are the only changes since the last version, which is already in utopic
<KjetilK> we would normally not be releasing a new version with just a single changeset, but if it could make it into Utopic, we might do it anyway
<KjetilK> so, I was wondering if it is worth releasing and pestering the Debian dev about it, or if it is too late anyway?
<infinity> KjetilK: We're (way) past feature freeze, so unless you can make a good case for why it's absolutely necessary for utopic, it probably wouldn't make it anyway.
<KjetilK> infinity, yeah, I figured
<infinity> KjetilK: But releasing and getting it into Debian for jessie (and we'll pull it into 15.04) still isn't a bad plan.
<KjetilK> yeah, the DD usually packages our releases in a week or two
<infinity> KjetilK: Right, well the jessie freeze is imminent, so if you needed motivation, go with that.  If you can be bothered to spend the time trying to convince people like me that it's a safe and sane update for Ubuntu to pull in, we can talk after it's in Debian.
<KjetilK> basically, my argument wouldn't be that it is absolutely necessary, but rather "not a huge number of users, if we've screwed up, it is unlikely to negatively impact many, but the gains are likely large for the few who use it"
<KjetilK> ok, we'll follow the normal cycle, then
<KjetilK> infinity, BTW, how imminent is jessie freeze, last I read was early November?
<infinity> KjetilK: "Not many users" is, to me, actually an argument against updating, not for.
<infinity> KjetilK: On the one hand, not many users would benefit and, on the other, very few people will be testing it to find bugs in time to fix them before release.
<KjetilK> yeah, I can see that, fewer eyeballs
 * KjetilK nods
<infinity> KjetilK: As for the imminence of jessie freeze, I keep forgetting the exact date, and have just been treating it as "very soon" to push myself to get the things in that I need to. :P
<KjetilK> hehe, good :-)
<KjetilK> infinity, BTW, since you're a DD, I just noticed https://packages.debian.org/sid/noip2
<KjetilK> which doesn't have a maintainer, but I find no WNPP bug on it, and the package is uptodate with upstream and appears sane...
<KjetilK> Perhaps someone has orphaned it without telling anybody?
<infinity> KjetilK: That's cruft.  It's been removed from sid, note that it only exists on m68k on debports.
 * KjetilK nods
<infinity> KjetilK: https://packages.qa.debian.org/n/no-ip.html
<infinity> KjetilK: Removed over 2 years ago.
<KjetilK> infinity, yeah, but that's a different package, isn't it?
<infinity> KjetilK: No, that was the source that produced the noip2 binary.
<KjetilK> ah, ok
<KjetilK> that's probably the reason why I didn't find it on on QA myself :-)
<dholbach> good morning
<tvoss> pitti`, guten Morgen :)
<tvoss> dholbach, ping
<dholbach> tvoss, pong
<jibel> jodh, Hey, wrt. my 2 machines that hang on reboot/shutdown I enabled debug mode and filed bug 1371469
<ubottu> bug 1371469 in upstart (Ubuntu) "system hangs on shutdown/reboot" [Undecided,New] https://launchpad.net/bugs/1371469
<jibel> jodh, this is 100% reproducible but not immediately after boot
<ypwong> cjwatson, isolinux/lang no longer works in utopic, bug 1330416, could you help to take a look?
<ubottu> bug 1330416 in Ubuntu Kylin "In Ubuntu Kylin, default langauge in Ubiquity language chooser is not Simplified Chinese, isolinux/lang not honoured" [Critical,Confirmed] https://launchpad.net/bugs/1330416
<jodh> jibel: thanks. can you attach a log showing the shutdown? I've got a few questions but will add those to the bug...
<jibel> jodh, which log? I attached syslog, is there any other?
<jodh> jibel: you didn't actually attach the file.
<jibel> jodh, oops, sorry
<jibel> jodh, done. interestingly I cannot attach it uncompressed
<brendand> cjwatson, sorry to bug you again about software-properties - i keep getting told by different people that the issue around setting 14.09 as the series isn't resolvable or something like that
<brendand> cjwatson, but obviously you told me differently, so i'm just checking on the truth of the matter
<brendand> cjwatson, there's some proposed hacks to our tools that should be rejected if add-apt-repository is actually going to work in RTM
<cjwatson> smoser: that's just a matter of making sure /boot/efi is mounted in advance and then running grub-install, I think
<cjwatson> smoser: maybe you forgot the mount of the ESP?
<cjwatson> Noskcaj: I do lots of ad-hoc seed maintenance but that sort of thing is a matter for the ubuntu-gnome team; I don't tend to get involved
<cjwatson> ypwong: ok, added to this morning's amusingly long queue :-/
<cjwatson> brendand: I said roughly "I'm working on it" and that's still true.  I intend to make add-apt-repository work
<cjwatson> brendand: I think if you keep asking different people then you'll inevitably get people guessing :)
<cjwatson> brendand: it certainly can be made to work without having to do the controversial base-files change
<brendand> cjwatson, i'm not asking them for the fun of it :)
<brendand> cjwatson, it just came up because robru is trying to land a change to phablet-tools that hacks around add-apt-repository completely
<shadeslayer> does anyone know if schroot has space restrictions?
<brendand> cjwatson, he's getting his information from cyphermox
<cjwatson> brendand: well you have the answer now
<ypwong> cjwatson, thanks for the help, tried to trace down the root cause as much as I can but does not know enough of gfxboot-theme to go further
<cjwatson> ypwong: I may well not have time to look today; we'll see
<ypwong> ok
<caribou> When we do major modifications to code (scripts, programs, etc), is it required to update the copyright statements ?
<cjwatson> recommended
<caribou> cjwatson: I'm thinking of the makedumpfile script that you reviewed yesterday
<smoser> cjwatson, i tried to show that in the paste.  the d-i installed system does not have a /boot/efi.
<cjwatson> smoser: this is my best guess sorry
<smoser> the contents of /dev/sda1 is /boot/grub/grub (or at least very similar)
<smoser> its not a filesystem
<cjwatson> hang on, you are confusing me by talking about an EFI System Partition
<cjwatson> this is ppc64el right?
<cjwatson> what has EFI got to do with anything?
<smoser> did you look at those pastes ?
<cjwatson> only briefly, I had like five people pinging me about urgent things this morning
<smoser> understandable
<smoser> http://paste.ubuntu.com/8375494/
<smoser> that is information about what d-i set up.
<cjwatson> you know if you stopped using sgdisk you would be less confused.
<cjwatson> I'm not interested in sgdisk output - show me what parted says :)
<smoser> you're confusing sgdisk with sfdisk.
<cjwatson> ah you did, further down
<smoser> i did show you what parted said
<cjwatson> so ... why were you talking about an EFI system partition?
<cjwatson> I'm very confused, there should be no such thing
<smoser> because thats the gpt partition type of the /dev/sda
<smoser> /dev/sda is gpt partitioned
<smoser> and /dev/sda1 is of type C12A7328-F81F-11D2-BA4B-00A0C93EC93B
<cjwatson> yeah, but that doesn't mean it has to have an ESP
<cjwatson> hmm, that's thoroughly bizarre
<smoser> agreed.
<cjwatson> it should be a PReP partition
<smoser> i thought it was just doing PReP too
<smoser> so i just tried pretending as if it had
<smoser> but telling grub to install to it says: not a PReP partition
<smoser> if you do that.
<smoser> for further confusion... i remembered that the thing that is doing the loading is petitboot
<smoser> kexec based loader.
<cjwatson> do you have a partman log from d-i?
<smoser> so i suspect that it is actually mounting partitions and lookoing. because the menu you see in power-nv (no virt) is not a grub menu
<smoser> i can probably manage to get you one. but i dont have one at the moment and the system is not being friendly to me.
<cjwatson> while I understand that you're using d-i as the reference case that works here, this is not how I set up d-i to work
<cjwatson> util/grub-install.c:          grub_util_error ("%s", _("the chosen partition is not a PReP partition"));
<cjwatson> that message?
<cjwatson> maybe compare the GUID in the source with the one on disk
<cjwatson>           const grub_gpt_part_type_t template = {
<cjwatson>             grub_cpu_to_le32_compile_time (0x9e1a2d38),
<cjwatson>             grub_cpu_to_le16_compile_time (0xc612),
<cjwatson>             grub_cpu_to_le16_compile_time (0x4316),
<cjwatson>             { 0xaa, 0x26, 0x8b, 0x49, 0x52, 0x1e, 0x5a, 0x8b }
<cjwatson>           };
<cjwatson> and I guess there could be some bug in the comparison there
<cjwatson> the d-i recipe for ppc64el in partman-auto is:
<cjwatson> 8 1 1 prep
<cjwatson>         $primary{ }
<cjwatson>         $bootable{ }
<cjwatson>         method{ prep } .
<smoser> cjwatson, ok. i have no idea how its booting.
<cjwatson> which should turn into SET_FLAGS prep for parted_server
<smoser> but i do have an idea as to why it might be different then you expected.
<smoser> maas is feeding some preseed and that could be doing it.
<smoser> infinity, do you have any idea how boot works on power nv ?
<smoser> i'm thikning grub isn't actually involved.
<cjwatson> oh and more importantly the prep filesystem
<smoser> what is "prep filesystem" ?
<smoser> how does one create that
<cjwatson> oh just a virtual thing that causes parted to slam in the right guid
<cjwatson> not a real filesystem
<cjwatson> more a partition type than a filesystem, sorry for confusing term
<smoser> ok. you can go back to other more pressing things.
<cjwatson> it would be helpful to see the maas preseeding
<smoser> let me see if i can dig that up
<cjwatson> since we should really get that right ...
<smoser> http://paste.ubuntu.com/8379633/
<smoser> but fwiw, it *is* right :)
<smoser> it works.
<cjwatson> having an EFI System Partition on a system that is not EFI is not right
<cjwatson> it may work by virtue of being ignored
<cjwatson> but it is a wart we should clean up
<cjwatson> especially if it causes people to ask me really confusing questions :-)
<cjwatson> ok, none of that preseeding should influence that, so I'd still like to see the partman log when you get a chance
<smoser> where do i collect that ?
<cjwatson> it's /var/log/installer/partman on an installed system
<smoser> thanks.
<cjwatson> when I was paying close attention to this, the partitioning was GPT { PReP; <rest of Ubuntu> }
<cjwatson> now since then we have done a major parted upgrade
<cjwatson> so it *could* be that something went crazy there
<cjwatson> but I think you should be patterning things after how it's meant to work :)  (and while I appreciate wanting to pattern things after something that *does* work, this did work in the past)
<cjwatson> smoser: right, just dug up the relevant bits of parted - it is actually a flag, "set <partition-number> prep on" in the parted CLI should do it for instance
<cjwatson> or ped_partition_set_flag (part, PED_PARTITION_PREP, 1);
<smoser> cjwatson, so you think it is getting set on the efi system partition ?
<cjwatson> I think it's erroneously not getting set
<cjwatson> and that the boot flag is getting set instead, which is mapped onto "please be an EFI System Partition"
<cjwatson> these sorts of not-a-real-filesystem things are mostly done using flags in libparted
<cjwatson> or real-filesystem-but-special-semantics
<smoser> right. thats what i had thoguth
<smoser> and i had other curtin that suc cessfully put a prep partition on
<smoser> (at least something identified as prep)
<smoser> but then system didnt boot
<cjwatson> and it booted with that?
<cjwatson> oh
<cjwatson> um
<cjwatson> well, let's get d-i in the right shape again and then model on that?
<smoser> cjwatson, also remember that there are 2 cases here.
<smoser> one power-nv and one powerkvm.
<cjwatson> right, I'm not hugely familiar with the differences
<smoser> that makes 2 of us
<smoser> :)
<cjwatson> powerkvm is roughly equivalent to running qemu-system-ppc64?
<cjwatson> with slof
<smoser> well, it *is* running qemu-system-ppc64
<cjwatson> right, so that's what I tested with in the past
<smoser> right. and that reads prep for sure.
<cjwatson> power-nv I confess total ignorance of
<caribou> -/5
<smoser> right. that just means "bare metal" where ubuntu would be the hypervisor
<cjwatson> but we ought to have the same partition/boot layout on both, right?
<smoser> and the thing that loads that is 'petitboot'.
<cjwatson> chaining to grub?
<smoser> remember the conversation with anton about petitboot reading grub ?
<cjwatson> no :)
<smoser> oh no? you were on that... they talked abou it. i think that is what is happening.
<cjwatson> unless you mean the one really really early on
<smoser> i *think* petitboot (which is a linux kernel + busybox) somehow finds things to boot.
<smoser> and shows you a menu
<smoser> and it labels them suspiciously similar to the way grub would.
<smoser> but you're most certainly not interacting with grub
<cjwatson> so, for prep, the general idea is that the prep partition is basically just a zoned-off chunk of disk, and a GRUB core image is basically dded into it
<cjwatson> any other boot loader that wants to chain to it should be looking up the prep partition by guid and then chaining it in the obvious naÃ¯ve way
<cjwatson> I'm assuming that it is expecting the chained loader to be 32-bit BE
<smoser> that explaination of prep seems to fit with what i've seen. so i wasn't completely off.
<cjwatson> if we're now creating an ESP by accident, then it's possible that powerkvm is now broken
<cjwatson> or maybe slof handles that
<cjwatson> I don't see anything in my copy of slof/fs/packages/disk-label.fs that would though
<camako> pitti, thanks for the quick action... much appreciated!
<infinity> smoser: Booting natively completely ignores that partition and just scans all mountable Linuxish partitions for grub and yaboot configs and mashes them together in petitboot.
<infinity> smoser: So, the PReP thing only matters for VMs, but we use it everywhere for consistency, and portability of disk images, and to not drive us batty.
<infinity> smoser: Oh, and the PReP thing also matter of booting natively as a PowerVM partition.
<smoser> thats what i thought.
<smoser> so i'm not sure why petitboot doesn't like my curtin based install
<smoser> but the new firmware delivered a much nicer petitboot with 'rescan devices' which is crazy useful.
<smoser> :)
<infinity> Shiny.
<cjwatson> smoser: oh so maybe you need to be diffing /boot/grub/grub.cfg and that kind of thing then?
<smoser> cjwatson, yeah.
<cjwatson> hadn't occurred to me that power-nv would do that!
<smoser> well i told you!
<smoser> what i suspected
<smoser> but its still kind of yucky.
<smoser> mostly confirmed that they're parsing grub config
<smoser> which as seen here could be buggy. its also possible that now my curtin changes would work (solved by my firmware upgrade)
<smoser> right now i'm doing a d-i based maas install
<smoser> and will get cjwatson the requested parted log.
<cjwatson> I guess I missed that, sorry
<cjwatson> I think I thought you mean "mounting partitions and looking <for a grub core image to chainload>", not "mounting partitions and looking <for grub configuration to parse>"
<smoser> ok. so i'll get that system installed into d-i
<smoser> and then i'll get cjwatson and infinity access to it.
<smoser> cjwatson can feel free to ignore that.
<smoser> and infinity should dist-upgrade it to utopic
<smoser> where in theory we have magic pixies and kvm support
<smoser> cjwatson, d-i install of utopic
<smoser> hardware-summary: http://paste.ubuntu.com/8380127/
<smoser> lsb-release: http://paste.ubuntu.com/8380128/
<smoser> partman: http://paste.ubuntu.com/8380129/
<smoser> status: http://paste.ubuntu.com/8380130/
<smoser> syslog: http://paste.ubuntu.com/8380131/
<cjwatson> hmm, the boot flag is already in place
<cjwatson> I wonder if that matters
<cjwatson> and whether it would behave differently on a blank disk
<Daryl_> Hello peeps
<smoser> infinity, https://bugs.launchpad.net/ubuntu/+source/powerpc-ibm-utils/+bug/1371624
<ubottu> Launchpad bug 1371624 in powerpc-ibm-utils (Ubuntu) "update_flash is /bin/sh but contains bash" [Undecided,New]
<rbasak> pitti: is postgresql-server-dev-all expected to stay in main for >utopic?
<rbasak> Wondering where to build-dep on that or a specific version (for bacula)
<pitti> rbasak: I wouldn't see it, if anything needs it it's fine in main
<pitti> rbasak: usually it's a build-dep of server-side extensions
<pitti> but we have pretty much all of them in universe
<pitti> rbasak: bacula? I thought this was a db client, not an extension
<rbasak> No idea why it build depends on that, but it does.
<rbasak> It FTBFS right now because it depends on postgresql-server-dev-9.3
<rbasak> pitti: so I'm wondering whether to change it to postgresql-server-dev-all, or to -9.4.
<pitti> rbasak: ideally it should work with libpq-dev only
<pitti> rbasak: if it needs some extra server-side include file for poking in internals, then I think -dev-all should be ok
<om26er_> jamespage, Hi! Can you please review/comment on https://code.launchpad.net/~om26er/ubuntu-test-cases/fix_minimal_image_size_test/+merge/235298 ?
<pitti> rbasak: (I mean within the realm of already being deep in hack territory :) )
<mapreri> pitti: what do you think about syncing scribus now? I uploaded 1.4.4 to sid (should go to testing at the next britney run) and I'd like utopic shipping it. I'm not sure if a FFE is needed, though...
<pitti> mapreri: it's two microreleases; most projects only fix bugs in microreleases
<pitti> mapreri: so a quick review of the changelog is in order (and testing a build on utopic, of course), but it's probably okay
<mapreri> pitti: yes, the most of the changes are bugfixes and really little changes. http://sources.debian.net/src/scribus/1.4.4%2Bdfsg1-1/ChangeLog/
<mapreri> pitti: do you prefer me upload it to a ppa before syncing?
<mapreri> (I guess it builds fine, though :P)
<pitti> mapreri: yes, indeed
<pitti> mapreri: if you sbuild it locally, that's good enough
<infinity> smoser: Yeah, I have a Debian bug for that, fixing in the next upload.
<mapreri> pitti: to be honest, I never tried to build it in a utopic chroot, only in sid...
<pitti> mapreri: I'll give it a spin here, and sync if it works
<mapreri> pitti: great, thanks
<quadrispro> have a nice we all
<quadrispro> ciao!
<mhall119> cjwatson: ok, I'm here now :-P
<mhall119> cjwatson: so if we created a new click database, how could we install development packages to it without conflicting with installing regular packages from the store?
<cjwatson> mhall119: so I'd say stacking a test database on top temporarily would be the best answer, except that that currently requires root
<cjwatson> (just to create the test db)
<cjwatson> actually let me just check that assumptio n
<mhall119> cjwatson: could we create this when the user enabled developer mode and just leave it in place? or would that conflict with installing packages from the store?
<cjwatson> mhall119: I'm thinking something more transient than that
<mhall119> zbenjamin_: ^^ this is related to our discussion earlier
<cjwatson> mhall119: as in something controlled by an environment variable, so it would be confined to just the process context of the SDK, and could be a temporary directory
<mhall119> even better
<cjwatson> mhall119: so right now this isn't exposed in the CLI, although the library interface allows it - look at click/commands/*.py and notice that there's a db_dir=None param passed to db.read()
<cjwatson> oh actually
<cjwatson> click install --root=<some directory>
<cjwatson> that stacks a directory on top
<mhall119> zbenjamin_: do we currently use click install of pkcon install-local?
<mhall119> cjwatson: if we did that would it replace $HOME/.local/share/applications/<appid>.desktop?
<cjwatson> I don't know, this is a few too many questions to fire at me all at once
<cjwatson> probably
<mhall119> I suppose I should put this all into a doc
<cjwatson> this might not be perfect right now but I think it is the correct direction
<cjwatson> I imagine you use pkcon install-local right now, which has the effect of running click install as root so that it can ensure that the app can't write to its own code
<cjwatson> you probably do want to keep that part of it so that app authors can test in a properly confined environment
<cjwatson> that said the packagekit-based interface is not long for this world; I'm writing a new native click d-bus interface
<cjwatson> basically because packagekit upstream is killing plugins, see http://blog.tenstral.net/2014/09/listaller-back-to-the-future.html
<mhall119> cjwatson: zbenjamin_: I'm adding these bits to the bottom of https://docs.google.com/a/canonical.com/document/d/1i5KRNoc-UXYxT3xFDl9YKETwaa0I2yIUG33Oi_pyeYc/edit
<cjwatson> mhall119: it might work for the SDK to just set $HOME
<cjwatson> to a temporary dir
<mhall119> possibly, not sure what side-effects that might have on the app's runtime
<cjwatson> mhall119: right; but I think in general the SDK should be giving developers a clean test environment?
<mhall119> I can see arguments for both ways
<cjwatson> I think if you go with the approach that they don't get a clean test environment, you will find it extremely difficult to satisfy the requirement of not conflicting with installing packages from the store
<mhall119> yeah, I suppose the developer can come up with a way to pre-populate test data if they need it
<zbenjamin> mhall119: cjwatson: right now we use pkcon to install the packages.
<zbenjamin> mhall119: cjwatson: i would like to not need root privs for that, because the only way would be to somehow echo it into the commandline which kind of is ugly
<ogra_> zbenjamin, not necessarily
<zbenjamin> ogra_: that means?
<zbenjamin> ogra_: using a dbus interface?
<ogra_> adb shell "echo -e '#\x21/bin/sh\necho $PASSWORD' >/tmp/askpass.sh"
<ogra_> adb shell chmod +x /tmp/askpass.sh
<ogra_> adb shell SUDO_ASKPASS=/tmp/askpass.sh sudo -A <command>
<zbenjamin> ogra_: this is not ugly? ;)
<ogra_> i admit you still need to echo the PW once that way
<ogra_> but better than adb shell "echo $PASSWORD|sudo -S <command>"
<zbenjamin> ogra_: i would prefer to not echo the password around, for a real phone user its not just any password
<ogra_> which yoou would need to do for every command
<ogra_> will a real phone user use developer mode at all ?
<ogra_> my mom wouldnt
<zbenjamin> ogra_: of course
<ogra_> (she wouldnt even know what it meaans)
<zbenjamin> ogra_: of course not ;), but a developer using and developing for the phone would
<ogra_> you could indeed dump a dbus interface in place
<ogra_> but that means poking more security holes (even though they are small)
<zbenjamin> yeah thats a problem :/
<zbenjamin> ogra_: i want transaction support in click ;)
<zbenjamin> ogra_: click rollback
<ogra_> hah
<zbenjamin> ogra_: its kind of sad that there is no API that can elevate a process to higher rights in linux when you know the password, then i could just open a communication channel that is encrypted to send the password
<ogra_> zbenjamin, lets discuss that at the sprint
<zbenjamin> ogra_: ok!
<ogra_> dev mode as is is an awful hacked android dev mode, i think we can really do better
<zbenjamin> ogra_: yeah :)
<ogra_> (with the right amount of time and planning involved)
<mhall119> zbenjamin: what would you need root for?
<zbenjamin> mhall119: click install needs root, and cjwatson suggested to create a temporary click db what would need root as well
<mhall119> zbenjamin: he also said he's adding a d-bus interface to click so as to replace packagekit
<mhall119> which I assume means we can run something as the normal user and have click install it as root
<mhall119> just as pkcon install-local does today
<mhall119> because we're going to have to support that for store installed apps too
<ogra_> you will still need a way to elevate privs, authenticate or some such
<ogra_> (or a key as zbenjamin said above)
<mhall119> why?
<zbenjamin> mhall119: yep, that also means to make the upstart jobs aware of the temporary database
<ogra_> mhall119, because you dont want everyone to be able to do stuff with root privs on your device ?
<mhall119> zbenjamin: why couldn't that just be something passed over dbus?
<mhall119> ogra_: we want them to install packages
<ogra_> right
<mhall119> which they can today
<mhall119> without root privileges
<ogra_> yes, but if the desire is to do that with higher privs in the future
<ogra_> which is how i understand the above
<mhall119> I don't think we'llneed higher privs
<zbenjamin> mhall119: could be , but the app still should be started confined and i would like to use a stable API/service for that so we do not break on every change. We had that before and it burned us badly
<mhall119> zbenjamin: that's the goal, the only difference from the SDK's perspective would be that it tells the install command to install to /tmp/sdk-dev/ or something like that
<zbenjamin> mhall119: yeah and start it of course
<mhall119> yes that too
<zbenjamin> mhall119: plus we need signals that tell me about the state of the app (at least started/stopped and exit code )
<mhall119> zbenjamin: do we already have that?
<zbenjamin> mhall119: yes upstart does that
<mhall119> then it should be the same with cjwatson's replacement
<zbenjamin> mhall119: you want to look at libupstart i think
 * mhall119 doubts that he really wants to :)
<zbenjamin> ok probably not ;)
<mhall119> zbenjamin: you call upstart-app-launch or something like that right?
<mhall119> I assume it uses envvars liek $HOME or $XDG_* to find the app to start
<zbenjamin> mhall119: its ubuntu-app-launch now, and i use the backend library directly, not the frontend
<zbenjamin> mhall119: uh tedg would be the right guy to ask that, it should be upstart jobs
<mhall119> zbenjamin: I still assume there's a way to tell it where to look for apps
<mhall119> ok, we'll find out from ted
<mhall119> lucking all of this is code that we're writing, so the only real obstacle is developer time
<mhall119> unfortunately the only real obstacle is developer time :(
<zbenjamin> :/
<zbenjamin> mhall119: only thing i'm concerned about is that with a change like that we would break compatiblity to older phone images.
<zbenjamin> mhall119: we have no way of asking the phone if it has features like that, so the script can adapt
<zbenjamin> i hardly doubt we can use the same commands for both ways of installing a app, except only setting a env var would change the behaviour of all used commands
<tedg> mhall119, I'm confused, what are you trying to do?
<mhall119> tedg: we want to install a click package somewhere other than where the store installs and run the app from there
<tedg> mhall119, Why?
<mhall119> tedg: the case is app development, running an app project from the SDK currently installs it normally, which conflicts if you already have the app isntalled
<mhall119> so I can't have the stable version of my app on my phone *and* test the development version on my phone
<tedg> mhall119, Clicks are all per-user, so wouldn't it make more sense to just have it be another user account?
<tedg> So I could have my stable account and my dev account.
<tedg> Or I could install the dev in my stable account right before shipping.
<mhall119> tedg: and could we run it on the stable account session in Unity?
<tedg> I'm confused. You'd be two users. You log in as one, or the other, or switch between them.
<tedg> Just like all Ubuntu systems.
<mhall119> tedg: we don't have multi-user on the phone, but even if we did I don't think that's a very developer friendly solution
<mhall119> tedg: click allows (or will allow) the SDK to install the dev click package in a separate space, we would just need to launch it under confinement from that place
<tedg> mhall119, We do have multi user, we just don't have UI for switching users. That's a solvable problem.
<mhall119> tedg: they're all solvable problems, it's just a matter of which one is easiest/most appropriate to solve for this
<tedg> mhall119, I don't understand why a) you wouldn't change the name (i.e. so it'd show up with two icons in the apps scope) or b) you wouldn't change the version, so that you could detect which you're running.
<tedg> Both of those options work today.
<mhall119> tedg: the appid is used in multiple places, which makes it more complicated to change especially for scopes where it's in the source and binary filenames
<mhall119> even if you change the version number you have to uninstall the currently installed one before you can run the dev one
<tedg> mhall119, That's not true. It's all ref counted. Each user on the system can have different versions of the app.
<mhall119> each user can, yes
<tedg> So you don't have to remove the old one.
<mhall119> but I currently can only use one user
<tedg> You just have to say "this is the version I want"
<mhall119> so here's my use case, I have uReadIt 1.0 installed on my phone. It works, I use it every day. But now I'm starting on 2.0, it won't be ready for months. I want to be able to test 2.0 on my phone while I develop it, but still be able to use 1.0 on the same phone until 2.0 is finished and in the store
<tedg> So you want to have two apps installed. uReadIt 1.0 and uReadIt 2.0
<mhall119> I really don't care if uReadIt 2.0 is installed, I just want to be able to run it on my phone from the SDK
<mhall119> under proper confinement
<tedg> To run under proper confinement it needs to be installed.
<tedg> So you want to have two apps installed.
<mhall119> yes, one permanently and one temporarily
<tedg> And so why can't they have different appids?
<tedg> com.ubuntu.developer.mhall119 and com.ubuntu.developer.mhall119.test
<tedg> Or package names.
<mhall119> with a QML app I have to change it in the manifest and in the MainView QML code
<mhall119> for scopes I need to change it in the manifest, in the .ini file, and (somehow) in the resulting binary .so file
<mhall119> for C++ apps or plugins I might need to change it other places
<tedg> My argument would be that we should fix that. It should be set in one place, the manifest.
<tedg> For instance Unity Actions gets it from teh APP_ID environment variable.
<mhall119> it needs to be in the QML app to tell (I guess) Unity what app the window belongs to
<mhall119> it also seems to be used by content-hub to identify the app
<tedg> Sure when it creates the Mir connection.
<tedg> Yup, but that's just for content hub to match to the manifest.
<mhall119> I'd imagine Online Accounts also wants it from the QML
<mhall119> or maybe it uses the manifest files only
<tedg> No, I think it gets it from the apparmor profile it's running under.
<tedg> Checks the dbus connection.
<mhall119> at any rate, I'd rather not make the developer change their app name just to run it
<mhall119> unless it can be done automatically and transparently
<tedg> I think it should be done automatically and transparently. I'd rather make QtCreator complex and our phone simple.
<tedg> It's easier to upgrade QtCreator :-)
<tedg> Because complexity leads to bugs.
<mhall119> tedg: but, if we can properly install it as a click package of the same name, just in a different location, why wouldn't that work with ubuntu-app-launch and confinement?
<tedg> mhall119, If it has the same name, which do we run?
<mhall119> tedg: how do you decide currently?
<tedg> What happens if you run both at the same time?
<mhall119> how would you?
<tedg> The App IDs are guaranteed unique.
<tedg> We assume that everywhere.
<mhall119> tedg: unique per app, not unique per install
<tedg> There is only one of each appid in the session.
<mhall119> tedg: you can have pre-installed clicks in /usr/share/click/preinstalled and store-installed updates in /opt/click.ubuntu.com/ can't you?
<tedg> We have hashtables and db tables that use it as a primary key.
<tedg> Correct, but only one of those is the running one for the current user.
<tedg> So there's one version of each package for the current user.
<tedg> Whether the system has one or a thousand.
<mhall119> tedg: so could we temporarily make the current user look in /tmp/click/ first, then /opt/click.ubuntu.com/ then /usr/share/click/preinstalled ?
<tedg> Or you could just install the click, and then remove it when done.
<tedg> It'd be the same effect.
<mhall119> tedg: install current+1, then uninstall only that version and it will still have current?
<tedg> There can be only one of that package name. So if you install uReadIt 2 with the same package name as uReadIt 1, the 1 doesn't exist.
<tedg> Yes
<mhall119> it'll exist in /usr/share/click/preinstalled still though won't it?
<mhall119> or is that only because it's installed there as root?
<tedg> Preinstalled, yes, always. For the ones in /opt it'd be refcounted.
<mhall119> so if I have 1.0 installed as phablet from the store, and I install 2.0 as phablet from the SDK, it'll remove 1.0
<tedg> So if there's only one user it could be dropped and uninstalled. But, we could make a dummy user to keep a ref.
<mhall119> tedg: is there no way we can add another click database to /tmp/click/ and let the user session know about it?
<tedg> There is not no way, it's software. There's no reason to do that.
<mhall119> cjwatson, if I understand him correctly, says we can make click install to /tmp/click by passing it an additional argument
<tedg> Besides the fact that cjwatson is always correct, he's correct in this case too. That doesn't make it a good idea.
<mhall119> it sounds better than having to implement multi-user UI and making me switch accounts whenever I want to hack on my app
<tedg> I'm not saying you have to do that, though I do like that from the developer experience perspective.
<tedg> All you have to do is install the app you want to test, and uninstall it when you're done.
<mhall119> and switch accounts
<tedg> Nope, you'll have the new version as soon as you install the new version.
<mhall119> so I can install 2.0 as phabletdev and run 2.0 as phablet?
<tedg> No
<tedg> Each user has different versions
<mhall119> then I have to switch accounts, no?
<tedg> You'll have to install 2.0 as phablet.
<tedg> If you want different accounts with different versions, you'll have to run as the account that has the version you want.
<mhall119> and install 1.0 as phabletdev?
<tedg> If you want.
<mhall119> if I don't 1.0 will be removed, no?
<tedg> Sure, but you never need to log into that account. I think there are other ways to keep references, but I'm not as sure there.
<tedg> We just need to keep a reference.
<mhall119> and then if I install uReadIt 2.0 as phablet, and then uninstall 2.0 as phablet, I will revert back to having 1.0 as phablet, or will I know long have uReadIt as phablet?
<mhall119> s/know/no/
<tedg> Well, technically if you run "uninstall" you won't have version. But you can "install 1.0" and you'll switch to 1.0. 2.0 will loose refs, and then be removed.
<mhall119> so the SDK would need to remember the previous installed version and re-install that
<tedg> So the real answer is, yes you can go back to 1.0
<tedg> Yes
<tedg> It can discover it as well.
<mhall119> how?
<tedg> Anything that is not confined can get a list of versions on teh system.
<tedg> I'll have to look up the command, but click provides it.
<mhall119> but on actual multi-user systems it would need to know the last version that user had
<tedg> Sure, if there was a chance of there being more than one installed.
<tedg> I guess there could also be a preinstalled and an upgraded version as well.
<mhall119> tedg: can you add your recommendation to the bottom of https://docs.google.com/a/canonical.com/document/d/1i5KRNoc-UXYxT3xFDl9YKETwaa0I2yIUG33Oi_pyeYc/edit so we don't lose it please?
<mhall119> it seems we're going to need to go through different options in detail
<tedg> mhall119, No rights :-)
<mhall119> tedg: refresh and you should now
<tedg> mhall119, Updated
<mhall119> thanks tedg
<dobey> infinity: around?
 * dobey needs a debdiff sponsored
<dobey> slangasek: or if you could sponsor. i've attached a debdiff to https://bugs.launchpad.net/ubuntu/+source/libjsoncpp/+bug/1368420 which i need to get into utopic. thanks.
<ubottu> Launchpad bug 1368420 in libjsoncpp (Ubuntu) "Prices shown incorrectly in some locales" [Critical,In progress]
<Noskcaj> The package bowtie is currently FTBFS on !amd64. debian (and upstream) has dropped building on those arches. Should we sync the change that stops attempting builds on the failed arches?
<cjwatson> zbenjamin: to be clear I'm not suggesting that you should need root privileges; I think you misunderstood me
<cjwatson> tedg: yes, right now if you install a new version of an app the old one will immediately be vulnerable to GC; but we could indeed suppress that somehow
<cjwatson> tedg: the other bit is that as soon as you install a new test version of an app it would be the thing that shows up in your desktop in general as the current version.  perhaps a good approach would be to have subusers
<cjwatson> tedg: so you could have click package versions owned by cjwatson:sdk
<cjwatson> with whatever separator
<cjwatson> tedg: then those could have different semantics wrt hooks and such
<slangasek> dobey: what's the upstream status of this libjsoncpp patch?
<dobey> slangasek: not upstreamed yet (i'd just finished preparing it).
#ubuntu-devel 2014-09-20
<slangasek> dobey: ok.  Are you taking care of that?
<slangasek> dobey: (a simple "yes" here will be enough for me to push the button on sponsoring the upload ;)
<dobey> slangasek: yes
<slangasek> dobey: ok, uploaded
<dobey> slangasek: thanks!
<dupondje> some question. There is some bug in firefox/flashplugin caused by a missing apparmor rule
<dupondje> file a bug on flashplugin or firefox for that?
<dupondje> (flashplayer does not work in firefox because it doesn't have access to /etc/ssl/openssl.cnf)
<debfx> dupondje: firefox since it ships the apparmor profile
<zbenjamin> cjwatson: good :) since we switched to adb as phablet root is always a bit problematic :)
<israel> Hey everyone!  I have a question about Bash and chroot... not sure if this is the right place or not... but here goes
<israel> how do I use a bash function as the command for chroot?
<israel> i.e. myfunction(){apt-get install programs}
<israel> sudo chroot chrootdir myfunction
<israel> why doesn't sudo chroot chrootdir "$( myfunction )" work?
<mlankhorst> because it isn't run in the chroot
<blkperl> slangasek: I think I figured out my nfs issues, idmap is not looking up expired keys sporadically...
<slangasek> fun
<blkperl> err whats the difference between id_legacy and id_resolv
<slangasek> I don't know
<slangasek> :)
<blkperl> slangasek: so the only thing that works is nfsidmap -c , I don't think the key limit in /proc/user-keys is the issue which is what all the bug tickets focus on
<blkperl> and running nfsidmap -c on a 1 minute cron is not a viable workaround :(
<blkperl> slangasek: looks like theres a debian bug too https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758870
<ubottu> Debian bug 758870 in src:linux "nfs-common: nfs v4: uid/gid lookup fails for some of the users" [Important,Open]
#ubuntu-devel 2014-09-21
<ramsudharsan> I guess I have come to the right place
<ramsudharsan> Is this development forum?
<ramsudharsan> I need some answers regarding Kernel
<gcl5_cp> ubuntu 14.4 come without MIME type to png images
<gcl5_cp> Change(open with in File Proterties) doesn't work
<gcl5_cp> Change(open with in File Proterties) do nothing
<t0by> Hi - I'm sorry, but is it a bug or a feature that a window with Gdk.WindowTypeHint.DIALOG still has the minimize button in Ubuntu 14.04?
#ubuntu-devel 2015-09-14
<dobey> isn't there some magic variable to set to add extra options to ./configure with dh?
<seyeongkim> There is mini.iso update schedule on the web? eg http://bugs.launchpad.net/bugs/1461620 can be integrated to mini.iso ?
<ubottu> Launchpad bug 1461620 in linux (Ubuntu Trusty) "NUMA task migration race condition due to stop task not being checked when balancing happens" [Medium,Fix committed]
<seyeongkim> or netboot
<smartass> hi, where can I find the policy for LTS releases? https://wiki.ubuntu.com/LTS seems more like promises than a real policy
<smartass> btw, I was told to ask this question here after aksing in #ubuntu
<pitti> Good morning
<cjwatson> dobey: dh doesn't do magic variables.  You would write an override_dh_auto_configure rule to add configure options.
<dholbach> good morning
<didrocks> hey dholbach, thanks for your email last week! :)
<dholbach> salut didrocks
<tjaalton> doko: so llvm 3.7 still fails to build on i386, guess I'll switch the new mesa default back to 3.6 so that it can be uploaded
<jamespage> doko, I had a query from ceph upstream about how they might reduce the size of their debug packages with dwz (as they do for centos/rhel/fedora)
<jamespage> doko, do we have an equiv for Ubuntu/Debian?
<doko> tjaalton, I'm not going to pull in the third llvm version into main. if you want to do that please get rid off 3.5 first
<doko> jamespage, not on my radar. I'll look at using compression by default with binutils 2.26
<doko> jamespage, any feedback on my dovecot question?
<jamespage> doko, dovecot?
 * jamespage reads backscroll
<doko> jamespage, I was looking at the dovecot merge, neglected for the 18 months ... debian dropped the ssl cert support between 2.2.13-5 and 2.2.13-8. do you have any suggestion how to handle that in ubuntu?
<jamespage> doko, blimey - let me take a peek
<jamespage> doko, personally I'd +1 following debian's removal of that stuff
<jamespage> upgrades should remain intact, new installs don't get self-signed certs
<jamespage> doko, whilst we're chatting ;)
<jamespage> doko, the "Multi-Arch: same" updates for the jerasure and gf-complete libs - does that just apply to the actualy library package (i.e. not the -dev package)
<doko> jamespage, -dev too. I didn't see anything that would fail with this
<jamespage> doko, I think jerasure is probably OK for that - but I just added some binaries to -dev for gf-complete to support unit testing in reverse-depends
<doko> jamespage, ohh, maybe split these out into a tools or bin package?
 * jamespage ponders that
<doko> ok, still looking at the snakeoil handling in dovecot
<rbasak> infinity: your comment in https://bugs.launchpad.net/ubuntu/+bug/1487538/comments/2 is contrary to https://wiki.ubuntu.com/FreezeExceptionProcess#FeatureFreeze_for_new_packages which I think is the source of my previous confusion. Please can you clarify? Can I update "FeatureFreeze for new packages" in the wiki, effectively replacing it with your comment?
<ubottu> Launchpad bug 1487538 in Ubuntu "Add dpdk to wily universe" [Wishlist,New]
<doko> jamespage, but that was not a "must have". just wondering if this could be done
<jamespage> doko, actually a tools package makes alot of sense
<jamespage> doko, I can do that now
<jamespage> its a NEW handle - are you OK with that?
<doko> sure
<tjaalton> doko: right, let's do that in w+1 then
<jamespage> doko, I'll just get a +1 from the debian maintainer on that approach and then I'll do the work
<jamespage> doko, I've also been chatting with the new upstream for jerasure and gf-complete (Loic - works for redhat ex inktank/ceph)
<jamespage> doko, although they have tagged some new releases, its not that well thought out yet re versioning etc... so I'd prefer not to bump versions this cycle, and work with them on getting that resolved
<doko> sure, I'm just checking. and reading that things were not maintained upstream raised an eye ;)
<jamespage> doko, upstream has a new owner :-)
<jamespage> doko, I'll repoint all the docs to the new location, and we'll work with them to move forwards next cycle
<jamespage> doko, the functional diff between what we have and what's upstream is 0
<sandero12> ciao
<sandero12> !lista
<ubottu> sandero12: No warez here! This is not a file sharing channel (or network); read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â». If you're looking for a channel, see Â« /msg ubottu !alis Â».
<infinity> rbasak: Yeah, so, 8 years ago, we didn't have a formal release team (or many of the machinery we do now), and MOTU was directly making any call on the archive outside main.  I'm not sure why they made this one, and I've never noticed it was documented. :P
<infinity> rbasak: But as long as a package isn't meant to be installed by default (by any flavour, not just Ubuntu, obviously), then it's not a feature change.  That's just straight up logical.  An argument can still be made for really late inclusion being stupid because you might have an immature package in the archive that's harder to fix post-release, but that falls under "don't be an idiot", not "we need arbitrary rules to restrict you", I'd think.
<rbasak> infinity: yeah that's all reasonable. I'm just asking that we update the wiki because this point has caused confusion a number of times now I think.
<infinity> rbasak: I'm all for updating the wiki.  We seem to have a habit of documenting ancient history and underdocumenting current practice. :P
<cjwatson> I think the original MOTU call here was because there was a habit of shoving lots of new packages in at the last minute and not fixing them to, like, build and stuff.  But p-m may have helped here.
<juliank> mvo: infinity: I was wondering about getting the final python-apt 1.0 release into wily. The changes are rather small, and it would fix problems with other unrelated packages that would complain about the current version number (which is not PEP440 compliant, there's actually also an vivid upload planned for that), and some other crazy stuff [like you stuff two Version objects for different packages with the same version number in a set,
<juliank> and only one of them is kept]
<juliank> It can also be synced again now, as the increases gcc 5 deps are gone, as the transition is practically done for it in Debian.
<infinity> juliank: I was actually going to merge it a while ago, but mvo's l10n mess confused me a tad, so I was going to leave it to him (I'm not sure if his delta is intentional or build system buggery).
<juliank> infinity: You must be talking about something else [APT?]. I'm talking about python-apt, which I uploaded 1.0 final yesterday
<juliank> OK, not yesterday, two days ago
<juliank> (uploaded to Debian)
<juliank> infinity: Or do you mean the vivid thing?
<infinity> juliank: Err, oh.  Yeah.  I read that as 'apt', not 'python-apt'.  I'm not awake yet. ;)
<infinity> juliank: So, yeah, python-apt could have just been synced if apt was merged (because of the build-dep bump), that's the only reason we have a delta.  If you dropped the build-dep again (as the changelog claims), I have no issues with just syncing it, I think.
<juliank> infinity: Yeah, the build-dep was dropped, which was interesting, because it was actually mostly a side-effect of mvo not having committed that change to the repo :)
<mvo> infinity: thats build system aritfacts most likely, fortunately we worked on fixing this
<mvo> I will claim it was intentional
<infinity> mvo: So, 'diff debian ubuntu | filterdiff -x '*/*/*.po' | patch' would be a reasonable way to merge?
<juliank> mvo: The thing with APT translation is, the order in which strings are extracted from files depends on the specific file system.
<juliank> Because we auto-generate the file list from a glob pattern and did not sort it
<juliank> Yes, exclude the po diff
<mvo> thats fixed in git, right
<infinity> mvo: Kay.  Because of the ordering issue mentioned, it was really hard to see if the delta was breakage or intentional imports of LP translations (for instance).
<infinity> mvo: If our package just has the same translations as Debian, but in a different order, I'm happy to do that merge, since I'm TIL (and the merge will conflict with my last upload).
<juliank> Was the C++ ABI transition done in Ubuntu too?
 * juliank is not entirely up to date
<infinity> juliank: Before Debian, yes.
<juliank> Ah, OK
<infinity> juliank: (Which was super fun, as we renamed a lot of libraries Debian chose not to rename, and then has to un-rename them)
<juliank> :(
<mvo> infinity: yeah, just do it (or use the git ubuntu/master branch)
<infinity> mvo: Give me commit to that repository and I'll do it in git, but I had planned to just be old-fashioned and let you commit the result. :P
<mvo> infinity: :) fair enough
<gQuigs> hi, I've got this pending review - https://code.launchpad.net/~bryanquigley/ubuntu-seeds/ubuntukylin.wily   -  I did the same thing for Ubuntu
<infinity> gQuigs: Lemme update my local seeds and have a look.
<gQuigs> gst0.10 removal, just cleaning up some old branches and realized this one never made it through
<gQuigs> infinity: thanks!
<infinity> gQuigs: Yeah, the delta looks reasonable, I'm just updating ALL the seeds here so I can grep and see if more flavours need the same love.
<infinity> (huge pet peeve when someone fixed a bug in one seed and says "eh, I guess the flavours will figure it out on their own without being told")
<gQuigs> just fyi, gst0.10 is still needed on phone/KDE - unless a new QT lands
<infinity> gQuigs: Check.
<infinity> gQuigs: So, all GTKish flavours can/should drop 0.10?
<gQuigs> I told Gnome
<gQuigs> nope, Mate still had a dependency too
<gQuigs> and Studio and Edubuntu aren't close (I did go through them all a month ago)
<infinity> gQuigs: Oh, kay, fair enough.
<infinity> gQuigs: Do you have a handle on what needs to be done to clean the mess for everyone for 16.04?  Seems like dropped 0.10 from the LTS supported set would be a nice win.  For 15.10, I'm less concerned.
<infinity> s/dropped/dropping/
<gQuigs> mostly, here are my raw notes - http://pastebin.ubuntu.com/12409537/
<infinity> pitti: Still around?
<gQuigs> basically QT and WxWidgets are the two biggest blockers
<infinity> pitti: http://autopkgtest.ubuntu.com/packages/n/nvidia-graphics-drivers-304/wily/amd64/ <-- two tmpfails in a row seems not entirely ideal.
<infinity> ERROR: Quota exceeded for instances: Requested 1, but already used 10 of 10 instances (HTTP 413) (Request-ID: req-f7f823d2-9327-48a6-8e03-dabb85fc28dc)
<infinity> pitti: Can we not queue those up somehow, rather than failing?
<infinity> gQuigs: Iz merged.
 * infinity updates the meta to match.
<gQuigs> thanks!
<gQuigs> while in the zone :)  - https://code.launchpad.net/~bryanquigley/ubuntu-seeds/ubuntu.wily/+merge/270981
<gQuigs> 'doh, figured I forgot about kylin for this one ^
<gQuigs> now complete - https://code.launchpad.net/~bryanquigley/ubuntu-seeds/ubuntukylin-xul.wily/+merge/270991
<hallyn> slangase`: i'm afraid i don't know what to make of bug 1493590
<ubottu> bug 1493590 in shadow (Ubuntu) "package login 1:4.1.5.1-1.1ubuntu4.1 failed to install/upgrade: package login is not ready for configuration cannot configure (current status `half-installed')" [Undecided,Incomplete] https://launchpad.net/bugs/1493590
<sarnold> what's this thing in the AptOrdering.txt attachment?  NULL: ConfigurePending
<flexiondotorg> Evening
<flexiondotorg> cyphermox, infinity Is there any chance you could do some sponsoring for me please?
<cyphermox> flexiondotorg: sure, shoot.
<flexiondotorg> cyphermox, Cheers, I'll prepare a list ;-)
<cyphermox> flexiondotorg: just a reminder though, if you have things that ship new features there should be a feature freeze exception for them
<flexiondotorg> Bug fixes and some UI changes.
<flexiondotorg> And translation strings.
<cyphermox> we're also in UI freeze
<flexiondotorg> cyphermox, I filed these before that came into effect.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1493034
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1493065
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-welcome/+bug/1493274
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/mate-desktop-environment/+bug/1493771
<ubottu> Launchpad bug 1493034 in ubuntu-mate-settings (Ubuntu) "ubuntu-mate-settings 15.10.2 bugfix release [debdiff attached]" [Undecided,New]
<ubottu> Launchpad bug 1493065 in ubuntu-mate-artwork (Ubuntu) "ubuntu-mate-artwork 15.10.3 new release [debdiff attached]" [Undecided,New]
<ubottu> Launchpad bug 1493274 in ubuntu-mate-welcome (Ubuntu) "ubuntu-mate-welcome 1.0.3.2 update [debdiff attached]" [Undecided,New]
<ubottu> Launchpad bug 1493771 in mate-desktop-environment (Ubuntu) "Sync mate-desktop-environment 1.10.0+1 (universe) from Debian unstable (main)" [Undecided,New]
<slangasek> hallyn: it's a bug at least two steps removed from the shadow package; ignorable / closable as invalid
<slangasek> there's not going to be enough information there to ever debug it
<cyphermox> flexiondotorg: https://wiki.ubuntu.com/FreezeExceptionProcess#UserInterfaceFreeze_Exceptions, but I'll comment on the specific bugs as I review
<flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu/+source/mate-sensors-applet/+bug/1492557
<ubottu> Launchpad bug 1492557 in mate-sensors-applet (Ubuntu) "Sync mate-sensors-applet 1.10.4-1 (universe) from Debian unstable (main)" [Undecided,New]
<flexiondotorg> cyphermox, https://bugs.launchpad.net/ubuntu/+source/mate-netspeed/+bug/1492558
<ubottu> Launchpad bug 1492558 in mate-netspeed (Ubuntu) "Sync mate-netspeed 1.10.2+dfsg1-1 (universe) from Debian unstable (main)" [Undecided,New]
<hallyn> slangasek: but how do we tell him to work around?  i expected dpkg-configure to do it
<slangasek> hallyn: the dpkg --configure failed because the error message was spurious and the login package is *not* currently half-installed
<hallyn> ah!  ok, thanks :)
<slangasek> hallyn: he got the error pop-up after restart only because something deferred the crash reporting
<hallyn> ok, thx
<sarnold> I'm not seeing the ubuntu diff for pulseaudio at https://patches.ubuntu.com/p/ -- with version numbers like 1:4.0-0ubuntu11.1 I figured for sure we'd have a delta.. https://launchpad.net/ubuntu/+source/pulseaudio
<mdeslaur> sarnold: the 0 in 0ubuntu pretty much means we're not tracking debian for that package
<mdeslaur> sarnold: so no delta from debian
<sarnold> mdeslaur: ahhh
<sarnold> I think I know what's going on and then I find out that I really only understand our tiny little corner of the world :)
<mdeslaur> hehehe
<infinity> sarnold: Or, to expand on what mdeslaur said, even if we are tracking debian/* to stay in sync packaging-wise, the -0ubuntuN version means we've been skipping ahead on upstream versions, so the full debdiff is usually a many megabyte useless mess.
<sarnold> Unit193: congratulations :)
<Unit193> sarnold: Thanks!
<Unit193> Now, coffee time.
<sarnold> \o/
<infinity> Unit193: And added to ~xubuntu-uploaders ... You should be good to go.
<Unit193> Thanks, infinity!  Did you get my other ping a few days ago, btw?
<infinity> Unit193: If you never got a response, I'm going to go with "no".
<infinity> Unit193: Because the alternative is "I intentionally ignored you", which seems less nice.
<Unit193> Hah. :D
<Unit193> https://code.launchpad.net/~unit193/ubuntu-cdimage/xubuntu-core/+merge/268167 pinged with that, and the other two MRs in there.
<infinity> Unit193: Oh, right.  This.  I suppose it's too late to revisit the "maybe you should call it something other than core, so you don't have users confused by your product not at all relating to the thing the Canonical media machine is telling them about"?
<infinity> Unit193: I won't block it based on that (though I do need to find time, or another sucker to review it all), but it seems like it would be in your best interest to call it Xubuntu Minimal or Xubuntu Lite or something catchy that isn't Core.
<infinity> (But, we also overload "core" so much, I'd be amazed if any user wasn't already confused)
<Unit193> Yeeeeah, kind of already had started before all that broke, would be hard to reverse it all now but I do agree xubuntu-minimal would be much nicer.
<Unit193> bluesabre, ochosi: â
<infinity> Unit193: Well, it's not like you'd need to fix seeds and metas and such, except at a leasurely pace, but once you have a product with a name, names are hard to change. :)
<Unit193> The meta/task wouldn't be so bad if the ubuntu-upgrader tool hadn't already been patched, and we'd gotten some use for 'xubuntu-core' already. :3
<infinity> Unit193: Totally up to you guys, though.  If Core is a settled thing and you're happier with the weird name confusion than with trying to change it, I'm cool with that.
<Unit193> infinity: I see the problem with changing in having to patch everything, and calling it Minimal but having the task/meta be -core.  I poked the others at any rate.
<infinity> Unit193: Metas are easy enough to change, you just make the old one depend on the new one.  Tasks might be more problematic.  EIther way, just get me an answer, and we'll move ahead with the reviews.
<infinity> Unit193: To recap, "Ubuntu Core" is a minimal rootf, "Snappy Ubuntu Core" is the thing everyone and their dog write blog posts about, and the "core" packageset is the intersection of all flavours.  So, one more Core probably doesn't make it much worse than it already is. :P
<infinity> Unit193: It just means your users might think it's Snappy-based.
<Unit193> Yep, already had that one with a blog post on xubuntu.org...
<infinity> Unit193: I'm partial to the kitsch of "Xubuntu Lite", personally.  Sort of fits the theme of xfce in general.
<infinity> Unit193: For the CD product, that is.  The tasks/metas can really be named anything, and who cares.
<roaksoax> q/win 19
<Unit193> infinity: Core it is.
<infinity> Unit193: Mmkay.
#ubuntu-devel 2015-09-15
<pitti> Good morning
<pitti> infinity: the machinery already auto-retries three times (with 5 mins waiting in between), so this is a consistent failure
<Unit193> pitti: Howdy.  So do you also speak Klingon?
<pitti> infinity: cleaning up now, apparently some hung VM which is eating quota
<pitti> infinity: queues are notoriously long right now due to lcy01 being down
<pitti> Unit193: Qapla' !
<pitti> Unit193: nuQneH?
<Unit193> I do not, no.
<pitti> Unit193: "nuQneH" is the usual greeting -- it's literally "what do you want?" (Klingons don't have anything more polite)
<Unit193> Aha!  I see.  Nice!  I saw you on LP with it listed, wondered.
<pitti> infinity: ah! I see the bug how this could happen ("Multiple server matches found for 'adt-wily-amd64-nvidia-graphics-drivers-304-20150914-155306', use an ID to be more specific")
<pitti> infinity: filed as bug 1495788 in case you care
<ubottu> bug 1495788 in autopkgtest (Ubuntu) "nova: use UUIDs instead of instance names" [High,In progress] https://launchpad.net/bugs/1495788
<dholbach> good morning
<Mirv> chrisccoulson: can you check bug #1482219 - upstream has released a new version and gotten it signed, and unaware what more they could do
<ubottu> bug 1482219 in mozvoikko (Ubuntu) "xul-ext-mozvoikko isn't signed (cannot be loaded on Mozilla Firefox 41.0a2)" [High,Confirmed] https://launchpad.net/bugs/1482219
<Mirv> chrisccoulson: mailing list message http://lists.puimula.org/pipermail/libvoikko/2015-September/000820.html (feel free to reply)
<Mirv> since Firefox release is next week, it's a bit in a hurry now because the new mozvoikko would need to be distributed for LTS users too
<Mirv> or it simply stops working
<doko> jamespage, ceilometer, glance, heat are still dep-wait. for the latter two I can't find any packages
<jamespage> doko, nope - they are pending acceptance into Debian exp first - they are in the queue tho
<jamespage> for ceilometer I need to raise the MIR for jsonpath-rw-ext - on my list for today
<jamespage> castellan and magnumclient still pending
 * pitti watches the trusty bcmwl test install lts-vivid kernel
<pitti> preparing the instance now takes achingly long -- but oh well, we have infinite capacity to run in parallel, don't we :)
<pitti> err sorry, ECHAN
<pitti> apw: ^ that was for you
<apw> heh
<pitti> Riddell: just FYI (in lieu of email notifications), new packagekit is stuck, apparently aptdaemon needs some porting
<Riddell> mm yes
<Riddell> mvo: any input on that? ^^
<Riddell> for some reason it works on arm and powerpc but not on i386 and amd64.  failures are usually the other way around
<ogra_> Riddell, just drop these deprecated arches then ;)
<Laney> looks like it failed everywhere to me
<Riddell> Laney: where are you looking? the aptdaemon line here says only on those two arches http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#packagekit
<Laney> Riddell: oh, I went http://autopkgtest.ubuntu.com/packages/a/aptdaemon/
<Laney> ^to
<Laney> I wonder why those say pass
<Riddell> mm right they all fail, but at least it's all the same failure
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs Laney
<Laney> nobody tell him that I just sneakily moved my patch pilot shift from now to tomorrow :-)
 * Laney hugs dholbach back
<dholbach> Laney, I really never meant the schedule to nail people to a certain date or time :)
<Laney> yeah I know, I don't usually mind moving it
<flexiondotorg> cyphermox, Thanks for your help yesterday.
<flexiondotorg> cyphermox, I'd like to make a small change to the network manager packaging. Which repo should I grab to submit a merge proposal to just the 'debian/' folder?
<cyphermox> lp:~network-manager/network-manager/ubuntu
<flexiondotorg> cyphermox, Thanks.
<cyphermox> lemme know, there may have to be some patching too
<flexiondotorg> cyphermox, Actually, it is network-manager-applet I need to change.
<Odd_Bloke> infinity: cjwatson: Once we have built an image on Launchpad, we pull it down, unpack it, and then 'purge linux-* grub-*' and create a tarball from that.
<flexiondotorg> Only debian/control.
<Odd_Bloke> infinity: cjwatson: I've been playing around with doing it in a hook by copying the chroot and modifying that, but I'm hitting problems with uninstalling kernels inside the chroot (because it tries to update MBR etc.).
<pitti> bdmurray: hmm, didn't we use to have test results (or at least failures) on http://people.canonical.com/~ubuntu-archive/pending-sru.html?
<Odd_Bloke> infinity: cjwatson: Is there a more live-build-y way I could do this, or shall I try doing what we do at the moment (with mounting the image and modifying it as a properly mounted partition)?
<cjwatson> Odd_Bloke: If you're just going to purge kernels and boot loaders, I'm not sure why you're going to the effort of installing them in the image in the first place?
<Odd_Bloke> cjwatson: We ship both the image (with kernel and boot loaders) and the tarball (without).
<bdmurray> pitti: Yes we did
<cyphermox> flexiondotorg: then lp:~network-manager/network-manager-applet/ubuntu although it looks like it's missing revision -0ubuntu7
<cjwatson> Odd_Bloke: Can you make use of lb_binary_rootfs, perhaps, which I believe is called before the kernel and boot loader are installed?
<hallyn> is there a known bug about dhclient (run by hand) in wiliy not updating the nameserver list?  is /etc/resolv.conf.d/tail supposed to be a symlink to nonexistent 'original' file?
<hallyn> (had to add 8.8.8.8 to /etc/resolv.conf myself)
<pitti> bdmurray: was that taken down deliberately, or did some change in britney break this?
<pitti> bdmurray: are you parsing the html for that, or the yaml? (the latter seems much easier)
<bdmurray> pitti: nothing has changed with sru-report afaik, the yaml
<bdmurray> pitti: https://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/sru-report#L614
<infinity> Odd_Bloke: Yeah, you could be building both the image and the tarball as artifacts of your live-build process.
<infinity> Odd_Bloke: Sure, it doubles the size of the LP bits, but also, it means your bits are all in one place, which is lovely.
<seb128> Riddell, hey, did you notice that your packagekit update breaks aptdaemon (I guess https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/1494891 is due to the new version) and is blocked in proposed due to that?
<ubottu> Error: malone bug 1494891 not found
<seb128> https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/1494891
<bdmurray> pitti: 'reason' seems to be empty in most of the entries in the yaml file for vivid
<pitti> bdmurray: indeed; it's there for wily, but not for stables
<bdmurray> pitti: it used to be there though...
<pitti> bdmurray: yeah; thanks for the pointer, I'll file a britney bug for it and pile it on my list
<pitti> bug 1496020
<ubottu> bug 1496020 in Auto Package Testing "[britney] reason: field is empty for stable reports" [Undecided,New] https://launchpad.net/bugs/1496020
<Riddell> seb128: yep, most annoying this aptdaemon, I'm trying to recreate the issue and see if I can fix it
<seb128> Riddell, the autopkgtest are failing so that should be fairly easy to reproduce
<seb128> also if that the lp bug I pointed it's probably some obvious issue, attributes that got removed
<Odd_Bloke> cjwatson: linux-image and grub are installed in to the chroot.
<pitti> seb128: isn't that an API break?
<seb128> pitti, I guess it is
<cjwatson> Odd_Bloke: Perhaps you can arrange to install them in one of the lb_binary stages instead?  Or is that too difficult due to dependencies?
<pitti> (wrt. "needs full transition", FFE, examination of what is affected, etc.)
<seb128> pitti, yeah, it should probably require a ffe, quite some things changed in packagekit
<seb128> even if that version is not the one dropping support for plugins yet
<seb128> Riddell, ^
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<pitti> mdeslaur, infinity, stgraber, slangasek, kees: TB meeting reminder in 30 mins -- perhaps you can have a look at my SRU policy proposals before?
<mdeslaur> pitti: ack
<tedg> pitti: Is there a way to make dbusmock use a direct dbus connection instead of a bus?
<pitti> tedg: what is a "direct" connection? to a private bus?
<pitti> tedg: dbusmock is essentially just syntactic sugar around dbus-python; you can put the mocks on any bus, not just the system or session one
<tedg> pitti: Hmm, okay. And basically set the connection in init.
<pitti> tedg: unless you use DBusTestCase's convenience functions to start a private sytsem/session bus, it's the caller's responsibility to create the bus connection, yes
<pitti> tedg: if your test suite is python, then I still think it's much easier to use .start_session_bus() instead of bothering with the setup of your own
<pitti> but if your test suite is !python, you have to anyway
<tedg> pitti: Trying to test with a private connection instead of a full bus. The full bus case I know works, but it seems the private connection case is broken. Well, I don't know, but I don't have coverage on it currently, so it is suspect.
<tedg> pitti: The test suite is C++ using libdbustest to start the bus, which is easy enough. But this is a bit different.
<pitti> tedg: a private connection still needs to go to a full bus; it just won't be the "well-known" system/session/user one, but other than that it's just another bus? or what do you mean?
<tedg> pitti: No, without a dbus-daemon, so no Hello.
<dobey> tedg: you mean the p2p socket connection, versus the shared dbus connection?
<tedg> Yes
<pitti> tedg: ah -- that's the bit I'm not aware of (peer to peer)
<tedg> Wish cgmanager was just on the system bus. But, eh, drop this code when we move to systemd for the session.
<pitti> infinity, stgraber, kees: TB o'clock
<infinity> pitti: Already there.
<bdmurray> Laney: Do you know if the ubuntu-sponsoring code is pulled automatically?
<Laney> bdmurray: I sure didn't do anything to make it get pulled
<Laney> so it seems so :)
<bdmurray> Laney: did you think about using any of the teams in the package to team mapping?
<Laney> bdmurray: remind me of the link quickly?
<Laney> the short answer is no, because the set information was already there
<Laney> and it would have been more work to fetch package subscribers or the map itself
<Laney> sounds like a good idea though
<bdmurray> Laney: I'm suggesting reviewing the teams in it to add to the list of teams. It's output is here: http://people.canonical.com/~ubuntu-archive/package-team-mapping.json
<Laney> bdmurray: those don't really map neatly to packagesets in the main
<Laney> It would probably be nice as a data source though
<Laney> I mean "to uploading teams"
<tdaitx> bdmurray, dh-exec FTBFS in core because bats is in universe instead of main, I need an owning team, doko suggested to subscribe foundations and said you should be able to do it
<tdaitx> bdmurray, https://bugs.launchpad.net/ubuntu/+source/bats/+bug/1496050
<ubottu> Launchpad bug 1496050 in bats (Ubuntu) "[MIR] bats" [Undecided,New]
<bdmurray> tdaitx: done
<slangasek> bdmurray: should one of the team-subscribing scripts be added to ubuntu-qa-tools or somewhere?
<tdaitx> bdmurray, thanks =)
<doko> finally, firefox and thunderbird migrated to -release after five months
<ogra_> gut ding will weile haben ;)
<hallyn> slangasek: hey - i had pushed 0.39-2 cgmanager to mentors, but it seems to be gone.  did you sponsor it?  (I don't see it in the archive)
<hallyn> or did i err somewhere.  i can re-push
<slangasek> hallyn: I did not sponsor it; I also can't figure out mentors' web UI for the life of me, I assume that it's just broken beyond repair and wait for sponsorees to tell me where to download stuff
<hallyn> slangasek: ok, lemme repush and post the .dsc url :)
<hallyn> slangasek: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.39-2.dsc
<hallyn> should fix all the lintian warnings (and do nothing more)
<slangasek> hallyn: if cgm-release-agent is a kernel callback, there's only one of them for the system; why install it in a multiarch directory?
<slangasek> hallyn: ah I see, you were misled by debhelper's own default behavior for libexecdir, which was a terrible failure on my part
<slangasek> hallyn: I see you added a lintian override for xs-testsuite; nack on this - either the field should be renamed from xs-testsuite to testsuite as the lintian message suggests, or it should be left un-overridden for future tracking.  And for the cgmanager-utils conflicts, I don't see any reason that Breaks would not suffice, can you explain?
#ubuntu-devel 2015-09-16
<hallyn> slangasek: so do you have another suggestion?  shoudl it just go into /lib/cgmanager/cgm-release-agent?
<hallyn> slangasek: cgmanager-utils conflicts: i tested it;  with breaks it simply refuses to upgrade the packages;  with conflicts it removes the old cgmangaer-utils and installs the new package
<hallyn> now it's possible that i should just remove the version - cgmanager-utils no longer is needed at all - uh, no longer exists
<tdaitx> doko, it seems squid FTBFS in wily-proposed due to the libecap2 -> libecap3 change, squid <= 3.4 requires ecap 0.2 or 0.3 (ie. libecap2-dev) - only squid 3.5+ can use ecap 1.0 (ie. libecap3-dev)...
<tdaitx> doko, I am trying to build, got an error due to a "logical-not-parentheses" warning, fixed it with a patch, then I am seeing lots of netinet/in.h and linux/in.h conflicts - ie. conflicts between libc6-dev and linux-libc-dev headers, any idea?
<tdaitx> ... trying to build with libecap2 ...
<hallyn> slangasek: reagarding the xs-testsuite, if i make it 'Testsuite' the dpkg in trusty will DTRT?  (I haven't found anything explaining the difference)
<slangasek> hallyn: dpkg in trusty will complain that it's an unknown field, but we're talking about a ppa so it doesn't matter
<slangasek> hallyn: how did you test that it refused to upgrade the packages?  I'm pretty sure your test was wrong
<slangasek> hallyn: oh and yes, if cgmanager-utils no longer exists it should be an *un*versioned conflicts, not a versioned breaks
<hallyn> slangasek: i install cgmanage ron trusty, then installed the 0.39-1 package there with dpkg -i, it refused.
<infinity> Unversioned Conflicts/Replaces, if the goal is to smoothly punt it off the system.
<hallyn> stgraber: ^ what exactly do you want in debian/control?  can you put it into the 'unstable' branch at https://github.com/lxc/cgmanager-pkg-ubuntu ?
<hallyn> ok, will make that an unversioned C/R now
<infinity> And raw dpkg won't do that right, you need apt or another frontend.
<hallyn> bah.  why?
<infinity> Because reasons.
<hallyn> ok, but if it'll break for people trying to do it manuallywith dpkg that's still bad no?
<infinity> dpkg will just tell you that you can't install something with something else that conflicts.  C/R paired is a hint to higher level frontends (like apt) to DTRT.
<hallyn> but if we can all agree on unversoined C/R then that works for me :)
<hallyn> oh, i see
<hallyn> thanks
<infinity> No, it's fine if complex upgrades like that can't be done with dpkg without first removing package A.
<infinity> But it should be smooth with apt/aptitude/dselect/update-manager/etc, which C/R will make sure of.
 * hallyn looks back up to see what else he needs to remember he messed up
<hallyn> ok, so i think there's only the cgm-release-agent location left to worry about
<hallyn> stgraber: ^ nm, we'll just leave the lintian warning for now and leave xs-testsuite as is
<TJ-> Anyone familiar with ecryptfs-utils source-code around?
<slangasek> hallyn: dpkg --auto-remove probably would've done the right thing for the Breaks case anyway
<slangasek> hallyn: sorry, --auto-deconfigure
<pitti> Good morning
<tyhicks> TJ-: I'm on the way to bed but I'll see how much help I can provide in the span of a few minutes :)
<TJ-> tyhicks: simple question this time I promise!
<tyhicks> good :)
<TJ-> tyhicks: I'm hacking on the ecryptfs-utils code to fix 'our' issue... but stumped as to where the source is included the linux/keyctl.h or defining KEY_SPEC_USER_KEYRING - can find its usages but no sign of where it is defined!
<TJ-> tyhicks: I grep-ed but couldn't see it, but it has to be there: http://paste.ubuntu.com/12424557/
<tyhicks> TJ-: the kernel defines it, which is why keyctl.h is in /usr/include/linux, and libkeyutils-dev also defines it in /usr/include/keyutils.h
<tyhicks> TJ-: ecryptfs-utils uses the definitions from libkeyutils-dev
<TJ-> tyhicks: I am planning on adding some intelligence so the code can pick the correct keyring to use, and allow the user to override the choice on the command-line
<TJ-> tyhicks: Ahhhh! of course. I think I'm a bit too tired. Thank you.
<tyhicks> TJ-: the intelligence part sounds good but I'm not a fan of the command line option
<TJ-> tyhicks: I did "apt-cache showsrc ..." but totally missed "libkeyutils-dev"
<tyhicks> TJ-: the kernel keyring, and all of the subkeyring belonging to a process, is too much complexity to expose to users
<tyhicks> s/subkeyring/subkeyrings/
<TJ-> tyhicks: I agree, but the 'intelligence' may not always be able to figure out the correct keyring
<TJ-> tyhicks: I was planning on only exposing it to ecryptfs_insert_wrapped_passphrase_into_keyring
<tyhicks> TJ-: actually, I think ecryptfs-utils may be using the wrong keyring
<tyhicks> TJ-: I wonder what would happen if ecryptfs_add_auth_tok_to_keyring() inserted the key into the KEY_SPEC_SESSION_KEYRING
<TJ-> tyhicks: I've been thinking that. It should be session not user
<tyhicks> TJ-: or possibly the KEY_SPEC_USER_SESSION_KEYRING
<tyhicks> TJ-: I think changing the keyring is the first approach we should take instead of trying to add intelligence about which keyring to use
<TJ-> tyhicks: but I've also been looking at what the various tools do with keyrings. default, and pam_init, are both supposed to link the session and user keyrings. The problem with just 'user' is when using 'sudo' it doesn't attach to the user session, or the non-sudo user
<TJ-> tyhicks: I'm aiming to set up enviroments with each scenario and then test various changes, starting with swapping user -> session, and working on up
<tyhicks> TJ-: ok, big thanks for the help on this
<TJ-> tyhicks: you're welcome. It's get another security feature that interests me. This may help me in thinking about implementing a systemd-cryptsetup LUKS key-file AskPass extension
<TJ-> s/get/yet/
<tyhicks> interesting
<tyhicks> ok, I've got to run now
<tyhicks> talk to you later
<TJ-> tyhicks: thanks
<pitti> wgrant: do you happen to have an estimate about when lcy01 comes back?
<wgrant> pitti: I'd hope this week, but some issues have been hit.
<wgrant> It is coming together, though.
<pitti> wgrant: thanks
<pitti> doko, infinity: can you please have a look at http://bazaar.launchpad.net/~ubuntu-release/britney/britney2-ubuntu/revision/496 -- does this make sense to you? anything else which we should trigger?
<pitti> originally I only wanted to make this temporary as we are currently so low on capacity, but I think it actually makes sense permanently
<dholbach> good morning
<dholbach> happy birthday infinity!
<pitti> ooh!
<pitti> infinity: happy birthday, man!
<pitti> doko, infinity: this is resulting in http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#gcc-5
<pitti> doko, infinity: (note that binutils and linux weren't triggered before)
<seb128> mvo_, hey, do you know if bug #1496291 is likely to be an apt or dpkg issue?
<ubottu> bug 1496291 in software-center (Ubuntu) "package:software-center:13.10-0ubuntu8:triggers looping, abandoned" [Undecided,New] https://launchpad.net/bugs/1496291
<seb128> s-c didn't change in wily afaik
<mvo_> seb128: dpkg or s-c itself, apt does not really deal with triggers
<seb128> dpkg I guess
<mvo_> seb128: I guess we need to find the cycle and break it, is there some helpful information maybe from dpkg?
<seb128> lubuntu-software-center has similar issue and didn't change either since vivid
<seb128> no, those e.u.c reports are useles s:-/
<seb128> https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1495077
<ubottu> Launchpad bug 1495077 in software-center (Ubuntu) "package software-center 13.10-0ubuntu9 failed to install/upgrade: triggers looping, abandoned" [Undecided,Confirmed]
<seb128> might have, it's an apport report with logs
<seb128> or https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/1495309
<ubottu> Launchpad bug 1495309 in software-center (Ubuntu) "package software-center 13.10-0ubuntu9 failed to install/upgrade: gatilhos em "loop", abandonado" [Undecided,New]
<seb128> dbus has similar report
<seb128> e.g bug #1496296
<ubottu> bug 1496296 in dbus (Ubuntu) "package:dbus:1.10.0-1ubuntu1:triggers looping, abandoned" [Undecided,New] https://launchpad.net/bugs/1496296
<seb128> so maybe it's due to it?
<seb128> Laney, ^ did you see anything like that?
<Laney> we made the dbus one interest-noawait
<Laney> but that was before 1.10
<seb128> https://errors.ubuntu.com/problem/17ccb3737169df5ac7c589255576b7abbe898229 has 1.10 reports
<Laney> where's a proper log?
<seb128> Laney, https://launchpad.net/ubuntu/+source/dbus/+bugs?orderby=-id&start=0 the upgrade reports
<seb128> I guess
<seb128> at least they have apport/dpkg logs
<Laney>  chain of packages whose triggers are or may be responsible:
<Laney>   lubuntu-software-center -> libc-bin
<Laney>  la cadena de paquetes cuyos disparadores son o pueden ser responsables:
<Laney>   lubuntu-software-center -> libc-bin
<Laney> OK, infinity probably fixed software-center on Friday
<Laney> lubuntu-s-c should have the same treatment I think
 * Laney JFDI
<rbasak> infinity or stgraber: can we speak about DPDK packaging please? I'm still not happy about the current state of packaging and would like your opinion.
<seb128> Laney, thanks for figuring out the details
<seb128> mvo_, ^ btw, seems like s-c got fixed
<Laney> don't know why these get attributed to dbus though
<mvo_> seb128: lovely
<mvo_> seb128: infinity is a hero
<seb128> :-)
<doko> pitti, that gcc list looks lovely ;)
 * doko starts renaming all my packages to gcc-* 
<doko> mvo_, could you have a look at http://autopkgtest.ubuntu.com/packages/a/aptdaemon/wily/amd64/ ?
<pitti> doko: lol
<jamespage> doko, hey - buildbot is blocking transition of sqlalchemy to the release pocket due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794300
<ubottu> Debian bug 794300 in buildbot "buildbot: FTBFS on unstable and needs rebuild for sqlalchemy transition" [Serious,Open]
<jamespage> doko, any ideas? its not been touched for eons in Debian
<mvo_> doko: I suspsect the new packagekit broke it
<doko> jamespage, no, I'll ping the maintainer. I really didn't want to get involved with that one, therefore I asked the guy to take it over
<jamespage> doko, ack - thankyou
<jamespage> (I saw you as an Uploader - hence the ping)
<doko> there's a new beta
<doko> jamespage, there's a new 0.8.x release, didn't check yet. but the test failures don't look like sqlalchemy related. I think ScottK is wrong
<doko> ohh, ScottK left ubuntu ...
<jamespage> doko, I also think they are not related to sqlalchemy
<jamespage> doko, I'll poke at it
<doko> barry, https://launchpad.net/ubuntu/+source/pyke/1.1.1-5build1/+build/7911076 is ply fallout
<jamespage> doko, well that makes no difference
<tjaalton> a question about Provides: a package depends on libfoo1 (>=1), and another incarnation of the library libfoo1-too Provides libfoo1.. there's no way to fulfil the dep with libfoo1-too?
<cjwatson> versioned Provides are a thing now, but you'll be trailblazing a little bit
<tjaalton> not on trusty though
<tjaalton> ?
<cjwatson> dpkg 1.17.11, which postdates trusty
<cjwatson> so the short answer is no
<tjaalton> right
<tjaalton> sigh
<cjwatson> best you can do is probably to make your shlibs generate alternate deps
<tjaalton> that would need rebuilds?
<cjwatson> yep
<cjwatson> or hack the revdeps manually
<tjaalton> ok
<seb128> doko, is bug #1456323 still valid?
<ubottu> bug 1456323 in openjdk-9 (Ubuntu) "openjdk-9 is a very early build, keep it in proposed" [Undecided,New] https://launchpad.net/bugs/1456323
<tjaalton> this is the mess with libosmesa6.. providing a renamed backport solves nothing (does solve -dev package installability though)
<tjaalton> oh well
<didrocks> tjaalton: btw, just confirming that I have no more crash at all with the xorg fixes, thanks again :)
<tjaalton> didrocks: ok good
<doko> seb128, yes, released is planned for second half of 2016
<tjaalton> hm, maybe osmesa needs it's own build target again, so that it doesn't need to depend on libglapi. then the stock version would work just like it did on precise
<seb128> dpm, pitti, do you have any idea why evolution-3.16 and evolution-data-server-3.16 mo files are not included in wily langpacks?
<seb128> hum, https://translations.launchpad.net/ubuntu/wily/+source/evolution/+pots/evolution/+admin has 3.12 naming
<seb128> I guess that's not good
 * seb128 fixes that
<seb128> unsure that's enough to have it included though
<seb128> dpm, wgrant, https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server has 2 templates, that's wrong right? can we delete the second one?
<rbasak> infinity or stgraber: can we speak about DPDK packaging please? I'm still not happy about the current state of packaging and would like your opinion.
<doko> pitti, update_excuses.html doesn't seem to pick up the autopkg test status, still showing the binutils and linux tests as running
<pitti> doko: yes, I know; still > 500 tests to run through (backlog from gcc-5), due to half of scalingstack being kaputt
<stgraber> rbasak: I guess though I have close to no background on this, maybe infinity knows more?
<infinity> rbasak: I'm not awake enough yet to go looking and having opinions.
<rbasak> stgraber: thanks. Maybe best to leave it with infinity then?
<rbasak> infinity: can we catch up later? We'd like to upload this week if possible, so I'd like to have your opinion today if I can get it please.
<stgraber> rbasak: sure, if infinity has more of a clue as to what's happening or should happen with DPDK then that'd likely save time
<stgraber> rbasak: also, you pinging me just reminded me of those two NEW reviews you asked for a while back, sorry, kinda dropped the ball with travel, will finish the review now
<stgraber> rbasak: from what I remember, the packaging looked great and I just need to look at the licensing
<rbasak> stgraber: yeah that makes sense. I think we have too many cooks with DPDK as it is :-/
<rbasak> stgraber: (kimchi/ginger) thanks!
<cjwatson> pitti: lcy01 is back up for buildds, FYI, and I think ChrisS is fixing the non-buildd stuff next.
<pitti> cjwatson: ah, good to hear!
<hallyn> slangasek: ok when i get some time today i'll move cgm-release-agent to /usr/lib/cgmanager/ .  Then that should hopefully get it ready
<slangasek> hallyn: /usr/lib/cgmanager or /lib/cgmanager? The latter seems more correct :)
<slangasek> hallyn: but it's also not something I'm going to stand on - this is the least of the packaging issues IMHO
<stgraber> rbasak: I'm happy with ginger, for kimchi, you're missing a debian/copyright entry for ui/pages/help/gen-index.py which is LGPLv2.1+ and not Apache2 as debian/copyright declares
<rbasak> stgraber: OK, thanks. Is that the only issue for kimchi?
<stgraber> rbasak: yep, the rest of debian/copyright appears valid
<rbasak> stgraber: OK I'll arrange a re-upload, thanks.
<stgraber> rbasak: alright, rejecting kimchi then
<rbasak> ack
<stgraber> rbasak: I'll keep ginger in the queue until I have the new kimchi since it depends on it
<rbasak> ack, thanks
<hallyn> slangasek: sorry yeah that's what i meant
<hallyn> it has to be /lib bc cgmanager can start very early
<tkamppeter> hi, I have a problem with bug 1449875. I could fix it by adding a dependency to Ghostscript but the new dependency recommends tons of unneeded packages. Do all these get installed then, too?
<ubottu> bug 1449875 in ghostscript (Ubuntu) "ghostscript fails on some EPS files" [Undecided,Confirmed] https://launchpad.net/bugs/1449875
<doko> pitti, could you have a look at https://launchpad.net/ubuntu/+source/debmake-doc/1.0-1/+build/7523212 ?  could that be a binary mangler issue ?
<jono> dpm, all set?
<dpm> jono, yep
<jono> dpm, ring ring
<jono> dpm, can you call me?
<dpm> jono, yep
<jono> dpm, weird
<jono> it is calling on my phone
<arges> doko: bug 1490352 for binutils-arm64-cross, was this supposed to change Build-Depends field? or be a no-change rebuild? the diff is just changelog.
<ubottu> bug 1490352 in binutils-arm64-cross (Ubuntu Trusty) "please backport aarch64 -Bsymbolic-functions fix to trusty" [Undecided,New] https://launchpad.net/bugs/1490352
<jono> but not my computer
<jono> one second, dpm
<doko> arges, oh, let me fix this
<arges> doko: ok i'll reject the current upload.
<doko> arges, reuploaded
<arges> doko: ok thanks, i'll review that
<bdmurray> Laney: I tried to add foundations-bugs, a team which is subscribed to bugs about packages, to sponsors-page.py (in TEAMS) but nothing is showing up. Should that team actually go in SPONSOR_TEAMS?
<Laney> bdmurray: It looks at subscribers to individual bug reports
<Laney> there is no knowledge of package subscribers
<Laney> (IIRC)
<bdmurray> ah, that would explain things
<Laney> what would you want it to show?
<Laney> I guess items it already knows about which are on packages that this team is subscribed to
<bdmurray> bugs where foundations-bugs is a structural subscriber (I think that would work) and has patch or has linked branch
<Laney> It's just show me all open bugs that <teams> are subscribed to currently
<Laney> I'm not trying to change the sponsoring process from "subscribe ubuntu-sponsors" in general
<bdmurray> Right, then structural subscriber and bug subscriber is ubuntu-sponsors would do that.
<Laney> That would probably be useful for you
<Laney> Maybe easier to consume the package-team-mapping though
<mterry> @pilot on
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<mterry> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
<hallyn> slangasek: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.39-2.dsc
<doko> seb128, Laney: gdk-pixbuf ftbfs,  leading to broken openjdk on architectures where it built
<doko> meh, why sync a package which alreads ftbfs in debian ...
<robert_ancell> doko, is anyone looking at the gdk-pixbuf issue?
<hallyn> xnox: netcf never got promoted from experimental to unstable.  is that supposed to happen automaticlaly at some point?  at this point it'll fail due to newer libnl3, but i'm trying to figure out which debian pockets i need to push updates for.
<hallyn> i.e. should i push one for both unstable and experimental?
<xnox> hallyn: nothing ever gets promoted from experimental to unstable.
<doko> robert_ancell, see #ubuntu-desktop, I mentioned it there too
<hallyn> (i also should do a new version, which i'll send to unstable at some point)
<xnox> hallyn: one has to manually upload into unstable.
<doko> but I don't know if anybody is looking
<xnox> hallyn: by default, one should upload just into unstable
<hallyn> xnox: ok.  (i really need to go for DM )
<hallyn> xnox: so if i push to unstable will the experimental version get obosleted?  i assume not,
<xnox> hallyn: unstable is kind of like ~ devel-proposed, there is automatic migration from unstable into testing, kind of like proposed migration from devel-proposed -> devel.
<hallyn> so i guess i'll push the current fix based on experimental, to unstable.  then send a new release to experimental
<xnox> hallyn: and currently devel[-proposed] are aliases for wily[-proposed]
<xnox> hallyn: why?
<hallyn> xnox: why which?
<xnox> hallyn: nobody uses experimental.
<hallyn> heh.  i just figured *someone* out there is using it,
<hallyn> but ok, i'll ignore it then and just go for unstable.
<hallyn> that's what i was wondering :)
<hallyn> thanks
<xnox> hallyn: think of experimental, like a PPA, but simply only one, shared with all DDs
<hallyn> can i ask you to sponsor the fix?
<xnox> hallyn: yeah experimental == PPA in debian world.
<xnox> hallyn: yes.
<hallyn> great, thx
<xnox> hallyn: dput to mentors.debian.net and give me url, i'll review, comment and maybe sponsor.
<hallyn> perfect.  thx.
 * hallyn notes pull-debian-source in wily seems broken
<cjwatson> hallyn: Debian ftpmasters occasionally remove packages from experimental that have newer versions in unstable
<cjwatson> you don't need to ask for that or do anything special to cause it to happen
<cjwatson> the only manual action needed is if you actually want to keep a different version in experimental
<hallyn> cjwatson: ok, that won' thappen for a week or two - i'll fix the current version in unstalbe first, then do an upload of a new release
<hallyn> gotcha, thx
<hjd> hallyn: re: pull-debian-source, bug 1453330?
<ubottu> bug 1453330 in ubuntu-dev-tools (Ubuntu) "pull-{lp,debian}-source not getting source for binary because DDE is dead" [High,Triaged] https://launchpad.net/bugs/1453330
<hallyn> hjd: yeah that looks like it
<hallyn> xnox: http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.3-4.2.dsc   (running out for lunch, biab)
<xnox> hallyn: please fix all warnings -> http://mentors.debian.net/package/netcf
<xnox> hallyn: since you are maintainer use 0.2.3-5 version; not nmu.
<tkamppeter> hi, I have a problem with bug 1449875. I could fix it by adding a dependency to Ghostscript but the new dependency recommends tons of unneeded packages. Do all these get installed then, too?
<ubottu> bug 1449875 in ghostscript (Ubuntu) "ghostscript fails on some EPS files" [Undecided,Confirmed] https://launchpad.net/bugs/1449875
<asac> anyone konws if there is a way to globally set time format for console?
<hallyn> xnox: for some of the warnings (like ancient standards version) i was going to fix that with the new 0.2.8 release.  this was meant as an emergency fix for the FTBFS
<sarnold> asac: perhaps locale's LC_TIME -- but anything that does strftime itself is unlikely to get it right..
<hallyn> huh, so -1 means nmu.  this is new to me
<asac> yeah
<asac> thanks sarnold
<asac> thats what i thought too, just wanted to check
<hallyn> xnox: (will ping when i re-upload)
<xnox> hallyn: no, XXX-Y[.Z] -> XXX is upstream, -Y is debian maintainer/uploader, optional [.Z] is the nmus
<xnox> hallyn: so maintainer does 1.0-1, 1.0-2, then two nmu happen at 1.0-2.1, 1.0-2.2, and then maintainer does 1.0-3 etc.
<xnox> hallyn: essentially it's a historical convention.
<hallyn> xnox: yeah that's what i meant, sorry
<hallyn> i'm trying to figure out the watchfile.  given that netcf has the 1:
<hallyn> oh uscan seems to ignore that, ok
<mterry> Laney, do you know why gdk-pixbuf is ftbfs in proposed?
<mterry> Laney, looks like some cve test failures
<mterry> Laney, when I try to reproduce locally on my desktop, my computer freezes(!)
<Laney> mterry: someone synced that?
<Laney> https://buildd.debian.org/status/package.php?p=gdk-pixbuf&suite=unstable <- could have predicted this :)
<Laney> https://bugzilla.gnome.org/show_bug.cgi?id=754387
<ubottu> Gnome bug 754387 in general "test-suite failure: ERROR: cve-2015-4491 - missing test plan" [Normal,Reopened]
<Laney> I don't know how to fix it yet
<mterry> Laney, heh
<Laney> or, well, I didn't try those ideas in a package yet and upstream didn't say anything
<mterry> Laney, we could skip the test...  or just remove it from proposed
<Laney> skipping a test for a CVE sounds bad
<Laney> doko already removed it anyway
<Laney> so no bother
<doko> mterry, looks that you actually like perl MIRs ... or else you would have demoted the recommends to a suggest in xdg-utils ;p
<mterry> doko, oh no, what did I do?  :)
<mterry> Laney, eh, skipping a broken test is ok  :)  But sounds good
<mterry> doko, you removed gdk-pixbuf from proposed?
<doko> mterry, yes
<doko> mterry, just the binaries, not the source
<mterry> doko, ah great, thanks!
<hallyn> xnox: http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.3-5.dsc    can you please confirm that at line 8 in debian/copyright, that 'permissive' is what the rest of that license text describes?
<hallyn> cause 'permissive' is mentioned but not defined in the debian doc about license files
<xnox> hallyn: one doesn't need a tag, if one includes text.
<xnox> so
<xnox> Files: *
<xnox> License:
<xnox>  <full text>
<xnox> or so i remember
<hallyn> xnox: that's what it was doing, but lintian now complains
<hallyn> so i spent 20 mins looking for a 'custom' tag i could add but didn't find that
<xnox> hallyn: it's ok, i would take it with a broken licence tag, if the license is correct.
<xnox> hallyn: but it is late now, for me. will look into it tomorrow.
<hallyn> xnox: ok, thanks
<hallyn> i'll go ahead and start on 1.2.8 then based on merging that and the 1.2.6 in experimental
<mterry> @pilot off
<udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
<mterry> @pilot ou
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mterry> @pilot out
<slangasek> hallyn: -2 uploaded
<hallyn> awesome, thx
#ubuntu-devel 2015-09-17
<pitti> Good morning
<Mirv> is anyone else seeing "/usr/bin/ld.gold: --push-state: unknown option" like bzoltan is? https://launchpadlibrarian.net/218108553/buildlog_ubuntu-wily-amd64.ubuntu-ui-toolkit_1.3.1639%2B15.10.20150916.2-0ubuntu1_BUILDING.txt.gz
<Mirv> that's not familiar to me at lesat
<TJ-> Mirv: yeah; it's an option in ld but not the older ld.gold. Makes it easy to save/restore flags for files
<dholbach> good morning
<Mirv> TJ-: right, it's just that bzoltan hasn't changed anything in the project being built and wondering what could have changed to cause that error on what's essentially a no-change rebuild
<Mirv> bzoltan: right, you haven't changed anything packaging related that would do toolchain changes?
<bzoltan> Mirv:  no, nothing is changed
<smb> pitti, morning. A question just out of curiosity and since I randomly happened to look. In britney when is a test marked as "in progress"? I randomly was looking at a package and that had amd64 and i386 as in progress over hours and in fact i386 is still. While the actual runtime of the test (as for amd64) is just a couple of minutes
<pitti> smb: yeah, sorry about that -- queues have been achingly long/slow for several days now, due to the continued downtime of half of scalingstack
<smb> pitti, ah ok. explains a lot. so basically sent off and then died in some way
<pitti> smb: i. e. "in progress" both means "running" (8 tests at a time per arch), and "queued" (still ~ 240 items)
<pitti> smb: well, not died, there's just a long line
<pitti> smb: the queues aren't currently exposed on a web UI; that's on the TODO list, after I'm done with teaching britney enough about the intricacies of kernel tests :) (working with apw on that one)
<smb> pitti, ok. I just cannot make a relation between the previous runtimes and any delta between changing into running now and its end. Which I was just wondering.
<pitti> smb: right, that's entirely dominated by the test request queue lengths
<pitti> smb: yesterday evening we had 600 queued tests, now 240, but of course every package upload triggers new ones :)
<smb> pitti, ok, thanks. :) At least I don't have to worry about me having done something that locked the testing up... well half of that worry was gone after amd64 completed at least. :)
<pitti> smb: I was told that scalingstack lcy01 comes back this week, then we are back to the "normal" under-powered mode :)
<smb> pitti, Lovely. :D
<TJ-> Mirv: gc++-5 (5.2.1-17ubuntu4)  has had recent changes for PR c++/65913 which add 'push-state'
<Mirv> TJ-: thanks, that's exactly what I was thinking about, a toolchain change
<Mirv> hmm, doko is not online though
<TJ-> Mirv: an amazingly invasive sude-effect :)
<TJ-> s/sude/side/
<Mirv> bzoltan: ^ not-your-fault-can't-do-anything-before-doko-is-online. probably.
<bzoltan> Mirv:  OK, the UITK landing is blocked for now than.
<TJ-> Mirv: bzoltan: the issue could be in qtbase-opensource-src-5.4.2+dfsg (qmake) which does "mkspecs/common/gcc-base-unix.conf:19:QMAKE_LFLAGS_USE_GOLD   = -fuse-ld=gold" irrespective of libraries being linked.
<caribou> what is the process to produce the mini.iso that we provide in the archives
<Mirv> TJ-: ouch. it seems this hasn't hit Debian yet so they don't have anything for that yet. thanks for the find! I'm filing a bug.
<Mirv> bzoltan: depending on schedule needs, you might want to consider vivid-overlay only landing this time and sync up for the next landing after this
<Mirv> since it's gcc/qtbase, this might take a little while
<caribou> Laney: how can we get a fix into a package in -backports ?
<bzoltan> Mirv:  OK, thanks
<Laney> caribou: re-backport it from the place it came from with the fix included
<caribou> Laney: well, the place it came from works, so a patch needs to be added to the package to backport
<caribou> Laney: haproxy1.5 uses start-stop-daemon --pid which is only available in Wily
<Mirv> filed bug #1496743
<ubottu> bug 1496743 in qtbase-opensource-src (Ubuntu) "/usr/bin/ld.gold: --push-state: unknown option" [Undecided,New] https://launchpad.net/bugs/1496743
<Laney> caribou: then whoever said this backport works needs to be spanked
<caribou> Laney: well it works, it simply doesn't terminate (LP: #1494141)
<ubottu> Launchpad bug 1494141 in haproxy (Ubuntu) "HAProxy 1.5 init script does not terminate processes" [Medium,In progress] https://launchpad.net/bugs/1494141
<Laney> caribou: file bug against backports with a patch
<caribou> Laney: ok, will do. thanks
<ginggs> Hi all. How reliable is http://qa.ubuntuwire.com/ftbfs/ ?  Package deal.ii FTBFS on all archs in Debian since June, but this page only shows the ppc failure, where it has never built.
<ginggs> I tried a no-change rebuild of deal.ii 8.1.0-4 on the PPA builders this morning, and it failed.
<Laney> It's not trying to rebuild stuff but reporting the state of the archive as it is now
<ginggs> I'm about to sync 8.1.0-5, but I'm just curious as to why it didn't show up on  http://qa.ubuntuwire.com/ftbfs/
<ginggs> Laney, thanks
<Laney> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<Laney> jamespage: hey, https://bugs.launchpad.net/oslo.log/+bug/1385295 is in the sponsor queue - should something happen with it?
<ubottu> Launchpad bug 1385295 in python-oslo.log (Ubuntu) "use_syslog=True does not log to syslog via /dev/log anymore" [High,In progress]
<jamespage> Laney, let me loot
<jamespage> k
<Laney> thanks!
<seb128> dpm, pitti, hey, saw my langpack/evolution/wily question yesterday?
<pitti> seb128: I did, but I thought you approved the -3.16 templates already?
<seb128> pitti, right, but do we need to do anything for those to be included in the langpack?
<seb128> the templates were approved for a while, I did fix some of the target details on the template page yesterday though
<seb128> unsure if that was the issue
<seb128> pitti, also https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server
<seb128> that has 2 templates and seems buggy
<seb128> but I don't know how to delete the second one
<pitti> seb128: shoudl be fine -- it's in http://people.canonical.com/~dpm/data/ubuntu-l10n/ubuntu_wily_potemplate-stats.json
<seb128> https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server/+pots/evolution-data-server/+edit seems wrong
<seb128> translations domain: evolution-data-server-3.12
<seb128> but I can't fix it/change to 3.16 since that's already used by the buggy other template
<pitti> wgrant: ^ halp?
<wgrant> seb128, pitti: Can you explain the situation?
<wgrant> I don't understand how the second template came about.
<wgrant> But if it was from an import, then won't further uploads just import into that?
<seb128> wgrant, unsure how we ended up in that situation, evolution rename its template every cycle
<seb128> evolution-3.xy
<seb128> same for eds
<seb128> but that seems buggy if you look at https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server
<seb128> the first template points to the 3.12 domain which is outdated
<wgrant> Right.
<seb128> and the second one has no translation
<wgrant> But fixing this is rather difficult.
<seb128> and none is in the langpacks
<seb128> can you delete the second one?
<seb128> the 3.16 one
<seb128> https://translations.launchpad.net/ubuntu/wily/+source/evolution has only one
<seb128> I guess somebody (could be me) did some wrong clicking when approving the eds 3.16 one
<wgrant> I don't think it's possible to delete an entire template.
<seb128> hum
<wgrant> What have you done in the past?
<wgrant> You must have manually approved the new pot and its pos into the existing template.
<seb128> accepting the new template
<seb128> right, that
<seb128> like evo
<seb128> https://translations.launchpad.net/ubuntu/wily/+source/evolution/+pots/evolution/+edit
<seb128> "evolution" template, domain "evolution-3.16"
<seb128> I guess somebody accepted the new eds one as "eds-3.16" instead of "eds"
<wgrant> Right.
<ginggs> tjaalton: any chance of LP: #1412441 still happening for wily?
<ubottu> Launchpad bug 1412441 in libclc (Ubuntu) "[MIR] libclc" [Wishlist,Confirmed] https://launchpad.net/bugs/1412441
<wgrant> So I think what needs to happen is that the -3.16 POTemplate and its POFiles need to have their paths adjusted to something that doesn't match reality, so future uploads won't autoimport into the bad template.
<wgrant> Then we can deactivate the bad template, and perform a fresh upload to update the right template.
<seb128> wgrant, k, thanks
<tjaalton> ginggs: dunno
<tjaalton> it's being updated in debian
<seb128> wgrant, pitti, done, https://translations.launchpad.net/ubuntu/wily/+source/evolution-data-server ... first points to 3.16
<seb128> do we need anything to have the .mo included in the next langpack now?
<wgrant> I'm surprised it's not there already.
<wgrant> There's no reason it wouldn't be.
<seb128> wgrant, I guess that part is more for pitti?
<seb128> or is the export coming from launchpad?
<seb128> note that evo/eds has their "domain" set to "-3.12" until yesterday
<seb128> so maybe that confused things
<xclaesse> mardy, is it known bug that evolution can't connect to google account anymore and UOA won't let you renew you auth token?
<xclaesse> mardy, I have to delete and re-create my google account like once a month
<smb> rbasak, Did you succeed in getting infinity to give feedback on dpdk (and feedback from upstream about abi version 0)?
<ginggs> tjaalton: yes, i saw your name in the changelog :)
<mardy> xclaesse: well, I'd say it's unexpected, google gives us a refresh token which AFAIK has long validity time
<mardy> xclaesse: do you happen to have "signond" lines in your syslog?
<xclaesse> mardy, hm, empathy can't connect neither... wondering if the problem is that uoa never actually give the token to the app
<xclaesse> a quick look at gabble logs and it seems to never receive a token to try connecting
<xclaesse> Sep 17 09:28:07 xclaesse-X230 signond[1715]: QObject::disconnect: Unexpected null parameter
<xclaesse> mardy, ^
<mardy> xclaesse: try this: echo "LoggingLevel=2" > ~/.config/signond.conf
<mardy> xclaesse: then delete the account and re-create it
<mardy> xclaesse: (kill signond, if it's running)
<mardy> xclaesse: and paste the syslog somewhere, but obscure the AccessToken and RefreshToken
<xclaesse> mardy, restarted my session and now it works
<xclaesse> mardy, with empathy-auth-client logs, I can confirm that what's going on is that UOA doesn't give the token
<xclaesse> signond probably deadlocked or something
<xclaesse> I have no idea how to reproduce, it just happens randomly like once a month
<mardy> xclaesse: what's the lifetime of the AccessToken (ExpiresIn field)?
<mardy> xclaesse: also, did you get a RefreshToken, or is that empty?
<xclaesse> oh I see that:
<xclaesse> Sep 17 09:43:14 xclaesse-X230 signond[1715]: message repeated 2 times: [ ../../../../src/signond/signonsessioncore.cpp 369 startProcess Error occurred while getting data from credentials database.]
<xclaesse> Sep 17 09:43:14 xclaesse-X230 signond[1715]: Challenge produces CRASH!
<xclaesse> mardy, I see no mention to AccessToken in syslog
<xclaesse> great now spamassassin is going to take 100% CPU for hours while evolution re-fetch all my emails
<mardy> xclaesse: weird, never saw that. Could you please paste the full logs somewhere?
<Odd_Bloke> infinity: cjwatson: So we take the ext4 filesystem that live-build creates, and we create tarballs etc. from it. One thing we need is a disk image with a single partition that is the ext4 filesystem. I've tried using kpartx (which is what we currently do), but things weren't appearing in /dev/mapper.
<Odd_Bloke> infinity: cjwatson: I've been trying to replicate lb_binary_hdd but been running in to all sorts of problems using live-build's losetup stuff.
<Odd_Bloke> Do you have any thoughts as to the best way of achieving this, or why kpartx might not be putting stuff in /dev/mapper?
<Odd_Bloke> It's particularly weird that it isn't happening because it _reports_ stuff has been mapped, it just isn't there.
<cjwatson> Odd_Bloke: Is this in a Launchpad build context?  The whole thing runs in a chroot, I don't know if that matters
<Odd_Bloke> cjwatson: It is in a LP build context, yeah.
<cjwatson> Odd_Bloke: If you give me an existing build then I can possibly feed it to my local setup and see if I can reproduce it there (though it will likely be tomorrow at this point rather than today)
<cjwatson> Odd_Bloke: unrelatedly, do you know anyone who could get https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/inline-release/+merge/271107 merged for me?
<Odd_Bloke> cjwatson: Sure, I'll feed one using kpartx through (I'm going to try a `udevadm settle` as well, to see if that changes anything) and point you at it.
<Odd_Bloke> cjwatson: Someone in ~charmers needs to pull the trigger; I'm bugging them about another merge ATM so I'll bug about both at the same time. :)
<cjwatson> thanks :)
<cjwatson> udevadm settle might not hurt indeed, I'm not sure if losetup et al make sure to wait for async rules
<Laney> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<seb128> Laney, good piloting round, nice to see some of the changes reviewed/uploaded ;-)
<dpm> seb128, sorry, I was in calls/preparing for calls yesterday. You cannot delete templates in LP, the invalid templates can be "moved out of the way", but it is a bit cumbersome
 * dpm looks for the documentation on doing that
<tdaitx> slangasek, should I: 1) add linux-libc-dev and libc6-dev to the bug I have open for squid3 FTBFS, 2) create new bug and add both packages to it, or 3) create a new bug for each?
<rbasak> infinity: ping
<dpm> seb128, it's under "Moving templates out of the way" -> https://wiki.ubuntu.com/UbuntuTranslationsCoordinators/Actions/LpTemplateAdministration
<seb128> dpm, thanks, can you do that for me? ;-) I close the tabs since and I think I workarounded it by renaming templates
<dpm> seb128, sure. I might have to leave it until tomorrow morning, but happy to
<seb128> dpm, thanks
<infinity> tdaitx: New tasks on the same bug is fine.  I have a 2.22 building in one of my PPAs right now, do you have reason to believe it's fixed upstream?
<infinity> tdaitx: PS: bug number?
<infinity> rbasak: *grunt*
<tdaitx> infinity, I have seem some updates to netinet/in.h in glibc, but it is not clear if it is fixed, I did build glibc 2.22 yesterday but I couldn't get the ppa to use it for the squid3 build (didn't look much into it)
<tdaitx> infinity, I believe I would need to bootstrap and rebuild a lot of stuff to get it to use a new glibc, right?
<infinity> tdaitx: Just having glibc in a PPA and then building squid in same PPA will do the trick.  I can just copy squid3 into mine when glibc is done.
<tdaitx> infinity, weird, that didn't work for me, I wonder why...
<infinity> tdaitx: Which PPA?
<tdaitx> infinity, https://launchpad.net/~tdaitx/+archive/ubuntu/testing
<tdaitx> infinity, for some reason squid3 build still fetches 2.21 instead of 2.22
<infinity> tdaitx: You probably just jumped the gun, retrying those builds. :P
<rbasak> infinity: otp atm, but mumble when I'm done please? Within half an hour I imagine.
<rbasak> (about dpdk as you can probably guess)
<infinity> rbasak: I have an interview in 50m, if we can clear up your call before then, sure.
<rbasak> infinity: OK, thanks.
<rbasak> Almost done here I thin.
<rbasak> think
<tdaitx> infinity, well, I did wait for the glibc build to be done and retried later... how much time should I wait usually?
<cjwatson> tdaitx: until the +packages page for that archive shows a green tick beside glibc; usually order of 10-15 minutes
<cjwatson> there's a publication step in there which takes a while because there are a gazillion PPAs
<tdaitx> cjwatson, hmm, ok, I _think_ the green tick was there, but I am not sure... if the build succeeds I will have my answer
<infinity> Well, even if it fails, you'll have your answer in the logs about which libc6-dev it used. :P
<tdaitx> heh, sure, my bad, that's what I meant =)
<tdaitx> I was being over optimistic...
<infinity> Erm.  Wat.
<infinity> Yeah, it didn't upgrade.  I wonder what voodoo is at work here.
<tdaitx> yeah, yesterday I assumed it was because whatever dependency is fetching libc6-dev is asking for a specific version of it and then I would need to rebuild from scratch with the new glibc
<tdaitx> but as I said I didn't look much into that
<infinity> Oh, or you just didn't update the package correctly. ;)
<infinity> Mine will work.
<infinity> You created a libc6 that's uninstallible.
<infinity> (Though, in general, good job on the patch rebasing and such)
<tdaitx> hmm, that bad uh?
<tdaitx> =)
<tdaitx> infinity, where did I go wrong?
<tdaitx> I mean on the glibc, not in general =P
<infinity> Oh, wait, mine won't work because it's intentionally FTBFS.  Perhaps I should fix that.
<infinity> tdaitx: At the very least, you didn't upate symbols.wildcards, and hilariously managed to create a libc6_2.22 that depends on libc6 (<< 2.22)
<tdaitx> ouch
<infinity> Although, now I'm monumentally puzzled as to why your build passes the elf/tst-protected1* tests and mine doesn't.  Whee.
<infinity> Oh, I wonder if I "fixed" that in an Ubuntu-specific patch, and my build is pure Debian.
 * infinity will quickly merge all that and test again.
<infinity> (massive jazz hands flailing around "fixed")
<rbasak> infinity: done. Still avialable?
<infinity> rbasak: Give me 3m, and I'll meet you on teh mumblez.
<rbasak> ack
<infinity> tdaitx: Toss that squid/glibc bug at me and I'll investigate when my 2.22 is done and fix it upstream if it's not fixed.
<tdaitx> infinity, LP: #1496223
<ubottu> Launchpad bug 1496223 in squid3 (Ubuntu) "squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch" [Undecided,New] https://launchpad.net/bugs/1496223
<infinity> tdaitx: .
<infinity> Ta...
<rbasak> infinity: https://launchpad.net/~smb/+archive/ubuntu/dpdk/+packages
<infinity>  0x000000000000000e (SONAME)             Library soname: [libdpdk.so.0]
<tdaitx> infinity, grab this patch for squid3: LP: #1496924 (will fix the build-dep and the error on warning during the build)
<ubottu> Launchpad bug 1496924 in squid3 (Ubuntu) "squid3 FTBFS due to bad libecap3 dependency and logical-not-parentheses warning" [Undecided,New] https://launchpad.net/bugs/1496924
<rbasak> infinity: https://gcc.gnu.org/wiki/FunctionMultiVersioning
<slangasek> tdaitx: to answer your earlier question, it's all a single bug so multiple bug tasks for the related packages is preferred
<slangasek> tdaitx: (but not worth fussing over)
<tdaitx> slangasek, I have moved the current patch to LP: #1496924, with that fix applied the build fails due to header mismatch LP: #1496223
<ubottu> Launchpad bug 1496924 in squid3 (Ubuntu) "squid3 FTBFS due to bad libecap3 dependency and logical-not-parentheses warning" [Undecided,New] https://launchpad.net/bugs/1496924
<ubottu> Launchpad bug 1496223 in squid3 (Ubuntu) "squid3 FTBFS due to linux-libc-dev and libc6-dev headers mismatch" [Undecided,New] https://launchpad.net/bugs/1496223
<Odd_Bloke> cjwatson: That charm merge has happened (as you will no doubt be aware once you check your email :p) and I'm building a package which should produce a build which you can play with.
<tkamppeter> hi, I have a problem with bug 1449875. I could fix it by adding a dependency to Ghostscript but the new dependency recommends tons of unneeded packages. Do all these get installed then, too?
<ubottu> bug 1449875 in ghostscript (Ubuntu) "ghostscript fails on some EPS files" [Undecided,Confirmed] https://launchpad.net/bugs/1449875
<Odd_Bloke> cjwatson: Right, got that build: https://launchpad.net/~daniel-thewatkins/+livefs/ubuntu/wily/cpc/+build/38142
<Odd_Bloke> cjwatson: The problem is where we echo "/dev/mapper/loop0p1 is not a block device"; we would expect that to be a block device.  I have taken out the 'udevadm settle', because it didn't make any difference.
<bdmurray> dannf: Could you add some SRU info to bug 1472650?
<ubottu> bug 1472650 in gccgo-5 (Ubuntu Vivid) "[arm64] gccgo runtime crashes with CONFIG_ARM64_PGTABLE_LEVELS=4" [Undecided,In progress] https://launchpad.net/bugs/1472650
<dannf> bdmurray: oh, sure - my bad
<dannf> bdmurray: done
<tdaitx> infinity, what ppa are you building glibc 2.22? I would like to check the diff to see exactly what I missed
<infinity> tdaitx: You could check the commit on the tip of http://anonscm.debian.org/viewvc/pkg-glibc/glibc-package/branches/glibc-2.22/
<infinity> tdaitx: Though, while it's interestingly educational, it might be a slight waste of time having two people do the same thing in paralle. ;)
<tdaitx> infinity, don't worry, it is educational for me, I'm not going to work on that =)
<tdaitx> I only did it yesterday because I wanted to check if it would solve the ftbfs, I was not willing to waste too many hours on it anyway (that why I didn't look too deep into why squid was not fetching the update I created)
<infinity> tdaitx: There would have been a lot of places where you missed 's/2.21/2.22/' since we only just fixed that in Debian to mostly use GLIBC_VERSION and substitute all over.
<infinity> tdaitx: And then a few places that still have to be handled manually, which you'll see in that commit.
<dobey> does anyone know of a way to process debian/copyright files in a meaningful way, to only be shown the copyright/license info relevant to the actual libfoo.so binaries in packages, rather than having to manually correlate binaries to source code paths?
<slangasek> it used to be that there was a place on the desktop where one could adjust font preferences (basically, fontconfig settings).  I can't seem to find that in unity anymore; does anyone know if this still exists somewhere in the UI? (Debian bug #798805)
<ubottu> Debian bug 798805 in libfreetype6 "libfreetype6 2.6-1 makes Cantarell blurry (CFF?)" [Important,Open] http://bugs.debian.org/798805
<hallyn> pitti: hey, just noticed that systemd in debian sid doesn't work in containers.  the previous version (same as in wily) does work.  assuem it's a regression in journald
<hallyn> ("regressioN" from lxc pov anyway)
<hallyn> haven't looked at debdiff
<dobey> slangasek: i think it went away when gnome got rid of it upstream, a long while ago. the settings can be tweaked in dconf-editor though (i know, not a good UI for that). maybe ubuntu-tweak or one of those things has some UI for it
<slangasek> dobey: right, turns out unity-tweak-tool does it
#ubuntu-devel 2015-09-18
<samthewildone> watching gremlins 2
<Unit193> infinity: So, I'm presuming that even poking you about transitioning openbox from proposeod to release isn't going to happen, due to it being a major upgrade?  (Reason it hasn't transitioned, openbox-kde-session depends on a package that no longer exists, but this is a current problem with the package already in release.)
<infinity> Unit193: So, fix the bug?
<Unit193> Sure kde-workspace-bin â plasma-workspace would do it, but it'd still be an upgrade from 3.5.2 to 3.6.1 after FF, which at this point since it's seeded in Lubuntu I'm presuming is the problem.
<infinity> Unit193: Not a problem.  Uploads to proposed need to beat FF, we're a bit more slack on when they migrate. :P
<Unit193> Ahaha.  Nice. :P
<infinity> Unit193: Anyhow, the only "problem" with the migration is the installability issue.  Fix that, and it'll be happy.
<pitti> Good morning
<pitti> hallyn: sounds like debian bug 798778?
<ubottu> Debian bug 798778 in systemd "systemd 226's init.scope breaks docker.io 1.7.1~dfsg1-1." [Important,Open] http://bugs.debian.org/798778
<Unit193> Howdy, pitti.
<infinity> Unit193: For bonus points, do some grep-dctrl on universe/Packages.gz and see if anything else depends on kde-workspace-bin?  If someone ripped it out when it still had rdeps, that's broken. :/
<pitti> hallyn: that's certainly the kind of change which could break LXC as well
<Unit193> infinity: Only declarative-plasmoids and startactive as far as deps, there's a couple recommends, but meh.
<infinity> Unit193: Yeah, don't care about recommends/suggests, but the other broken deps should be sorted too. :/
 * infinity goes to look at who's to blame for that.
 * Unit193 pretends he did *not* comment at all. >_>
<infinity> Bah.  Riddell removed it in vivid.  This has been broken a while.
<infinity> Riddell: Psst, you might not want to remove binaries when things still depend on them.
<Unit193> :D
<hallyn> pitti: hm, i don't think so
<pitti> infinity: hm, do you happen to know why gccgo-5 builds all of gcc-5's libraries? that smells bad
<pitti> like, you'd use the library depending on which one of gcc-5 or gccgo-5 happens to be higher
<infinity> pitti: In wily?
<pitti> infinity: and vivid too
<infinity> pitti: Only in vivid.
<pitti> infinity: I noticed another heap of test requests in http://people.canonical.com/~ubuntu-archive/proposed-migration/vivid/update_excuses.html which are totally in vain
<infinity> pitti: Which doesn't have gcc-5.
<pitti> infinity: wily too
<infinity> pitti: gccgo-5 doesn't exist in wily.
<pitti> infinity: but still, it's wrong in vivid too?
<infinity> No, it's right in both.
<infinity> gccgo-5 in vivid, gcc-5 in wily.
<infinity> There's no overlap.
<pitti> hm, how does apt-cache showsrc show it then
<infinity> --only-source
<infinity> showsrc will do binary->source mapping by default.
<pitti> oh! go apt
<pitti> infinity: thanks
<sarnold> why do we still ship the old python-juju? https://bugs.launchpad.net/ubuntu/+source/juju/+bug/1426549
<ubottu> Launchpad bug 1426549 in juju (Ubuntu) "drop pyjuju from vivid and newer" [Undecided,New]
<infinity> sarnold: No idea.  I know they both coexisted for a long time because $reasons, but I doubt those reasons are valid anymore.
<infinity> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1200878 was why it was reintroduced.
<ubottu> Launchpad bug 1200878 in juju (Ubuntu) "Upgrade breaks existing pyjuju deployment" [High,Fix released]
<sarnold> infinity: it seems unlikely to me that someone would intentionally want the old python juju in wily; if they really needed it, trusty is still there...
<infinity> sarnold: Based on the comments on the bug, I'm inclined to agree.
<infinity> sarnold: FWIW, no one saw that bug because I suspect the juju team blindly ignores all pyjuju bugs, and you didn't subscribe ubuntu-archive for us to just do the deed.
<sarnold> infinity: ah, thanks for the tip.
<pitti> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti
<sarnold> infinity: thans
<sarnold> thanks
<pitti> cyphermox: are you still working on bug 1492425, or want me to sponsor it?
<ubottu> bug 1492425 in multipath-tools (Ubuntu) "multipath-tools: wily: the quilt patch handle_spaces_in_rev_attr.patch is misapplied" [High,Triaged] https://launchpad.net/bugs/1492425
<smb> pitti, how does one recover from testbed failures (http://autopkgtest.ubuntu.com/packages/i/iscsitarget/) ?
<pitti> smb: it's fallout from the per-kernel testing I'm currently working on
<pitti> smb: I'm handling it, don't worry
<smb> pitti, ok, thanks
<thopre01> Hi there, which channel should I join to talk to PPA build admins?
<thopre01> We (ARM) are providing a PPA for arm-none-eabi toolchain and would like to build it for ARM
<thopre01> However it takes quite some time to build there
<cjwatson> thopre01: #launchpad
<cjwatson> thopre01: but I can answer you here
<cjwatson> thopre01: we have arm64 hardware in progress for an openstack cloud which will be providing virtualised arm (32-bit and 64-bit) builders
<cjwatson> thopre01: at the moment, the only option available is qemu-user-static on x86, which is (a) unreliable and (b) slow; can't do anything about that for the present, but hopefully the openstack-based solution is no more than a month or two away now
<lotuspsychje> someone knows wich package hold the generic firmwares of a wifi card?
<lotuspsychje> i have this card rt2800pci and on offline method it doesn get picked up
<lotuspsychje> but on cable it gets the generic firmware of it and works flawless
<lotuspsychje> so i was wondering if theres a way to backup generic firmwares to usb somehow?
<lotuspsychje> to install it offline
<thopre01> cjwatson: Ok thanks
<thopre01> We'll wait then
<jamespage> pitti, hey - I just commented on the qemu bit of bug 1495895
<ubottu> bug 1495895 in qemu (Ubuntu) "Unable to attach rados block device to instances" [High,Confirmed] https://launchpad.net/bugs/1495895
<jamespage> I think we do need the dependency otherwise upgrades will likely explode for quite a few cloud deployments :-)
<pitti> jamespage: you are worried about people doing dist-upgrade --no-install-recommends? (sounds like a YAFIYGI case to me..)
<jamespage> pitti, yes I am worried about that - apparently disabling Recommends install is something that alot of cloud operations like todo
<rbasak> smb: I think we're unblocked on my concerns for DPDK upload, so I'm happy for it to be uploaded to universe now. arges: as you reviewed already, please could you sponsor?
<pitti> jamespage: hmkay; do we really need the dep on both -common and -utils?
<jamespage> pitti, not sure - I'll checking with rharper when he starts
<rbasak> smb, arges: oh, my notes from my chat with infinity. If we're depending on libdpdk0 as the ABI isn't well defined we should have a strict versioned dependency instead of just generally on "libdpdk0". And the symbols file should be arranged to fail the build if the symbols change (I think we have that already?)
<pitti> and I figure changing the package description is overzealous (breaking translations and permanent delta, etc.)
<pitti> jamespage: but okay, if you want a strict Depends: I can sponsor that
<rbasak> Actually the strict versioned dependency on libdpdk0 should be on ovs I think. jamespage ^
<rbasak> (as it's consuming it)
<jamespage> pitti, I'm happy to sponsor - just wanted you to know why we need it
<pitti> jamespage: ah, ok
<smb> rbasak, cool. Hm, the symbols file is there at least. I believe that will cause the failure. The stricter dependency I would have to add
<rbasak> smb: actually the stricter dependency is on jamespage's end I think.
<smb> rbasak, ok... not sure how struct the aut generated ones are for other binaries produced
<jamespage> rbasak, well that will be driven in the normal way by shlib:Depends so it will generate libdpdk0
<smb> migth be already strict
<rbasak> jamespage: yes but the point is that it should be strictly versioned to the version of the libdpdk0 package, since a libdpdk0 package update might change the ABI.
<tkamppeter> hi, I have a problem with bug 1449875. I could fix it by adding a dependency to Ghostscript but the new dependency recommends tons of unneeded packages. Do all these get installed then, too?
<ubottu> bug 1449875 in ghostscript (Ubuntu) "ghostscript fails on some EPS files" [Undecided,Confirmed] https://launchpad.net/bugs/1449875
<Mirv> chrisccoulson: any chance to look at the bug #1482219? if Firefox 41 is released next week, all users including LTS users will lose the spell-checking. if you know what needs to be done, you could inform the upstream about what they still need to do.
<ubottu> bug 1482219 in mozvoikko (Ubuntu) "xul-ext-mozvoikko isn't signed (cannot be loaded on Mozilla Firefox 41.0a2)" [High,Confirmed] https://launchpad.net/bugs/1482219
<Mirv> chrisccoulson: I see the signed .xpi file has "META-INF" compared to the normal upstream tarball. maybe that can be used by the packaging, or how was the ubufox fixed?
<Mirv> chrisccoulson: it seems I figured it out, although I may not know what I'm doing.
<Mirv> chrisccoulson: if you're there, are you available for sponsoring https://code.launchpad.net/~timo-jyrinki/ubuntu/wily/mozvoikko/new_upstream_signed_release/+merge/271643 + for vivid, trusty and precise?
<Mirv> it's a main package
<Mirv> (and I'm only a MOTU)
<Mirv> ok, as chrisccoulson is not here, if any other core-dev can, please check the sponsoring queue and/or bug #1482219 MP:s. PPA builds available from the latest commits, and I've tested 14.04 LTS and 15.10.
<ubottu> bug 1482219 in mozvoikko (Ubuntu) "[SRU] xul-ext-mozvoikko isn't signed (cannot be loaded on Mozilla Firefox 41.0a2)" [High,Confirmed] https://launchpad.net/bugs/1482219
<Mirv> the problem here is that new Firefox comes next week already and SRU:s will take at least 7 days. only ubufox has been fixed to not break when the new Firefox comes.
<Mirv> the sponsoring queue does not show it but there's the precise branch too
<pitti> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Unit193> infinity: Also, https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/5397648/+listing-archive-extra - http://paste.openstack.org/show/3qkwEuusUcN7Yjqohn78/ :P
<hallyn> xnox: did you have any comments on http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.3-4.2.dsc ?
<xnox> hallyn: http://mentors.debian.net/package/netcf is better url.
<xnox> hallyn: still wrong version, should be 0.2.3-5
<hallyn> wtf?  i changed that
<xnox> you are maintainer now, right?
<hallyn> oh, i used the wrong link :)
<xnox> i see that there -5 upload as well
<xnox> horum.
<xnox> http://mentors.debian.net/package/netcf
<hallyn> thought i'd deleted that other one
<hallyn> and now i've deleted the whole thing
<xnox> hallyn: never mind, the -5 one looks great.
<xnox> hallyn: horum. well, reupload -5 again please =)
 * hallyn re-dputs
<xnox> hallyn: it was lovely for the whole 3 seonds
<hallyn> should take about 30s to show up
<hallyn> ... or longer
<hallyn> xnox: well while mentors chews on it, http://people.canonical.com/~serge/netcf_0.2.3-5.dsc  (but that doesn't give you lintian output :( )
<hallyn> xnox: https://mentors.debian.net/package/netcf is back up
<chrisccoulson> Mirv, has mozvoikko had a preliminary review by the AMO team, or a full review? Normally, addons only require a preliminary review to be loaded in Firefox, but side-loaded addons (those not installed via the addon manager) require the more thorough full review
<chrisccoulson> tbh, it would be better if this addon was just hosted on AMO like most other addons. The only reasons this one remained in the archive when we dropped all of the other Firefox extensions were that it wasn't hosted on AMO, and contained a binary component
<chrisccoulson> The latter doesn't apply now (the addon is all JS)
<infinity> tdaitx: https://launchpad.net/~adconrad/+archive/ubuntu/ppa/+build/7918795
<infinity> tdaitx: So, no, glibc 2.22 doesn't fix squid's sadness.
<tdaitx> infinity, I was afraid of that =/
<infinity> tdaitx: Might be fixed in git by jsm already.
<chrisccoulson> Mirv, so, that mozvoikko hasn't been through a full review and Firefox refuses to load it here when installed via the package manager
<infinity> tdaitx: If you were curious about the merge, for educational purposes, it's in ppa:adconrad/ppa
<tdaitx> infinity, sweet, thanks =)
<Mirv> chrisccoulson: ok. but how would it be part of Ubuntu's default language support if it'd not be in the archives?
<Mirv> until that's possible, there's a reason to keep it in archives since otherwise the majority of normal users would simply notice no spell-checking available
<Mirv> as extensions are not really familiar to most of average users
<Mirv> chrisccoulson: thanks for the preliminary/full review information, I'll rely that to the upstream so that they can see what they can do about it
<Mirv> chrisccoulson: if you have the correct PPA with Firefox to use for testing, please tell. I used 41.0~b9 from firefox-next and I got a warning about the new mozvoikko (and for some reason ubufox too) in the extensions dialog, but it still loaded and worked. on Firefox 40 using the packaged mozvoikko as well from the voikkotest2 PPA, I did have no warning anymore so that combination was puzzling me. proba
<Mirv> bly just the wrong Firefox test version to use.
<sarnold> Mirv: firefox 40 didn't have the signed requirements... chrisccoulson put some details in 1482219
<Mirv> sarnold: I know it didn't require, but the warning 40 already showed went away with this new version with signing included
<Mirv> so that's why I was puzzled when comparing to the 41 (or 42 dev edition locally unpacked). but it may be I'm using a wrong Firefox test version here, not something that will be distributed to the users.
<Mirv> chris certainly knows the best, so I believe the full review here would be the way to go to have an archive version that continues to work after next week's Firefox release
<samthewildone> lol
#ubuntu-devel 2015-09-19
<lotuspsychje> is there a reason why linux-firmware packages doesnt get installed by default (offline)?
<infinity> pitti: glibc upload for you, should be a good test of the current state of autopkgtest. :P
<infinity> pitti: Is the world backed up horribly?
<infinity> pitti: Looking for ghostscript to migrate, and none of its triggered tests seem to have run.
<infinity> pitti: s/none/very few/
#ubuntu-devel 2015-09-20
<StevenK> .win 21
<hjd> The package in wily-proposed seems to have built fine, but is still pending publication for amd64 https://launchpad.net/ubuntu/+source/fet. Any guesses as to why?
#ubuntu-devel 2016-09-19
<xnox> Mirv, i believe anybody with any upload rights can retrigger any autopkgtests
<xnox> so like majority of people
<tsimonq2> oh nice
<xnox> ScottK, can I become Ubuntu Backports team member? I need to upload & approve a few things that should live in backports long-term. Primary looking at backporting security uploads, to existing backports; as well as monitoring/approving/uploading things like btrfs-tools, tinc VPN, and othrs.
<xnox> could you bless me? and I shall follow https://wiki.ubuntu.com/UbuntuBackports as best as I can.
<tsimonq2> xnox: while you're here, what gets uploaded to backports?
<tsimonq2> I don't know what does lol
<xnox> tsimonq2, read wiki...
 * tsimonq2 facepalms at himself
<tsimonq2> sorry, long day
<tsimonq2> have a nice evening xnox
<xnox> no problems =) and i should go to bed.
<tsimonq2> o/ xnox
<ScottK> xnox: I'm not active with ubuntu-backports management anymore.  IIRC micahg is who you want.
<Mirv> xnox: I know
<Mirv> pitti: is there some sort of auto-retry nowadays in autopkgtest? I'm just wondering how the akonadi s390x tests seem to be "always" running when I check them, and they did seem to do so during the weekend too while they finally finished/Passed between Sat-Sun night
<micahg> xnox: let's chat some time, we can probably work something out ;)
<cpaelzer> good morning
<Mirv> mardy would like an archive admin to (pre)binNEW review the package account-plugin-mcloud from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+sourcepub/6844940/+listing-archive-extra
<pitti> Mirv: no, akonadi on s390x "just" breaks the testbed and thus causes an endless stream of auto-retries; I'll look into it
<pitti> tsimonq2: the script is really just a prototype; if you want to use it for real, rather ask robru -- he has a much better one, tweaked for PPAs (bileto silos) and with much better caching
<Mirv> ok
<Saviq> RAOF, yeah, Mirv did it - thanks guys!
<pitti> Mirv: done, qt should land in the next britney run
<Mirv> pitti: thank you
<cpaelzer> pitti: hi apw and I wondered if you could share a thought on constructing adt-run parms in a way that the tests would run against a kernel from ppa:canonical-kernel-team/ubuntu/unstable?
<cpaelzer> pitti: apw already send you a pm, but it might be better to do a three+whoever wants discussion here
<pitti> hey cpaelzer
<pitti> cpaelzer: do you just want to test this locally, or does it need to be on the infra?
<pitti> cpaelzer: locally it's easiest to just start a VM, install that kernel, and run autopkgtest with --null in that VM against that DKMS package
<pitti> err "-- null"
<pitti> cpaelzer: you can also install the kernel from the PPA via --setup-commands, but that's a bit complicated; any existing log against a kernel PPA shows the command line
<pitti> cpaelzer: e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-canonical-kernel-team-unstable/yakkety/amd64/a/acpi-call/20160918_090545@/log.gz
<cpaelzer> wow you write fast or these messages got batched somwhere :-)
<cpaelzer> I'd have liked to test locally
<pitti> got batched apparently :) (looks normal at my end)
<apw> yeah timestamps look like quick but not magical typing speed here :)
<cpaelzer> thanks pitti I'll try for the setup commands first and let you know, falling back to a null driver in case of too much issues
<cpaelzer> apw: pitti: adt-run [12:07:55]: testbed running kernel: Linux 4.8.0-11-generic
<cpaelzer> thanks pitti
<pitti> cpaelzer: cool :)
<cpaelzer> this is the cmdline that works for my dpdk test
<cpaelzer> just in case anybody needs something similar soon
<cpaelzer> adt-run --shell --debug --apt-upgrade --setup-commands 'apt-key adv --keyserver keyserver.ubuntu.com --recv-key 110E21D8B0E2A1F0243AF6820856F197B892ACEA' --setup-commands 'REL=$(sed -rn "/^(deb|deb-src) .*(ubuntu.com|ftpmaster)/ { s/^[^ ]+ +(\[.*\] *)?[^ ]* +([^ -]+) +.*$/\2/p; q }" /etc/apt/sources.list); echo "deb http://ppa.launchpad.net/canonical-kernel-team/unstable/ubuntu $REL main" > /etc/apt/sources.list.d/autopkgtest-
<cpaelzer> canonical-kernel-team-unstable.list; echo "deb-src http://ppa.launchpad.net/canonical-kernel-team/unstable/ubuntu $REL main" >> /etc/apt/sources.list.d/autopkgtest-canonical-kernel-team-unstable.list; ' --setup-commands 'apt-get update; apt-get install -y linux-image-generic linux-headers-generic' --binary *16.07-0ubuntu3*.deb --no-built-binaries --source dpdk_16.07-0ubuntu3.dsc --- adt-virt-qemu --cpus 4 --ram-size=2048 ~/work/
<cpaelzer> adt-yakkety-amd64-cloud.img
<cpaelzer> derived from the logs you linked pitti
<jamespage> pitti, is (more) of an ubuntu veteran than I am - do you know if its possible to generate merge reports between ubuntu and debian experimental?
<jamespage> I don't appear to have that in my knowledge set
<jamespage> hmm used to be able todo it using bzr branches
<jamespage> maybe I need to use nacc and rbasak package import thingumy
<pitti> jamespage: neither have I, I'm afraid; I guess one coudl configure MoM to do that, but I don't think we actually have that
<pitti> jamespage: but I've never actually used the auto-merges, they are almost always cluttered
<jamespage> pitti, where is the source for MoM?
<pitti> jamespage: IMHO it's much easier to grab the ubuntu diff and apply it to the exp package
<jamespage> yeah you're probably right
<pitti> jamespage: (and clean up the obsolete bits before, as usually)
<jamespage> I'll do what
<jamespage> that
<jamespage> golly can't type today
<pitti> jamespage: you know patches.u.c.?
<jamespage> pitti, yes
<jamespage> pitti, hey - can we drop the upload of python-pymysql I just did to yakkety? its still in proposed, and will create a whole load of headache for openstack packages
<jamespage> my mistake - got overzealous with taking new point releases from debian
<jamespage> https://launchpad.net/ubuntu/+source/python-pymysql/0.7.9-1ubuntu1
<jamespage> 0.7.6 is just fine
<pitti> jamespage: https://launchpad.net/ubuntu/+source/python-pymysql/+publishinghistory
<pitti> jamespage: sorry, it got published to -release half an hour ago
<jamespage> pitti, I think its still in proposed no?
<jamespage> Pending rather than published?
<pitti> jamespage: so it now needs to be uploaded as 0.7.9+really0.7.6 or so (or fix stuff to get along with 0.7.9)
<jamespage> yah published to proposed 2 mins about
<pitti> jamespage: no, it's published
<pitti> also, can't really stop "pending" any more
<jamespage> pitti, so we can't drop things from yakkety-proposed?
<pitti> jamespage: we can
<jamespage> Yakkety	proposed	2 minutes ago	main	misc
<pitti> but it's in yakkety-release already
<pitti> jamespage: oh, sorry, I mis-read
<pitti> jamespage: sure, I'll remove it
<jamespage> pitti, thankyou!
<pitti> done
<GunnarHj> pitti: Hi Martin, I can't find ubuntu-docs (or any other -docs package) at https://translations.launchpad.net/ubuntu/yakkety/+translations . Same thing in xenial. What has happened?
<seb128> GunnarHj, https://translations.launchpad.net/ubuntu/yakkety/+source/<name> seems to work?
<GunnarHj> seb128: Indeed. But the translators typically use the overview pages to find untranslated strings, and currently they don't see the -docs packages that way.
<seb128> tthat might be more of a launchpad question
<seb128> or maybe dpm knows
<GunnarHj> dpm_: ^ ?
<GunnarHj> seb128: Is there a quick access to someone at LP?
<seb128> #ubuntu-launchpad
<seb128> no, sorry
<seb128> #launchpad
<GunnarHj> seb128: Ok, thank, will try that. I may also post to the ubuntu-translators list to call their attention to it.
<seb128> GunnarHj, yw
<dpm_> seb128, GunnarHj, this sounds to me as if the .pot files for the docs packages did either not get uploaded or not approved
<GunnarHj> dpm_: They were both uploaded and approved, and taken into account in the latest language-pack-gnome-xx-base packages.
<seb128> dpm_, the source is translatable just fine
<seb128> dpm_, it's just not listed on the view GunnarHj asked about
<seb128> in the list
<seb128> dpm_, he got a reply on #launchpad
<GunnarHj> seb128, dpm: Mystery resolved. wgrant pointed out that the pages list the template names, not the package names, which in this case is ubuntu-help.
<seb128> yeah, I read that
<seb128> good then, no bug ;-)
<GunnarHj> seb128: Right. :)
<GunnarHj> seb128: Only in my head. :(
 * Laney offers GunnarHj some bug spray to help deal with that
<GunnarHj> Laney: Haha. I may need a dozen of those. :)
<dpm> seb128, GunnarHj, cool
<sforshee> pitti: I have a machine that after upgrading to yakkety sometimes hangs on boot then drops to maintenance mode. When this happens the journal shows that <disk>.device/start jobs are timing out, which I think is becuase udev isn't adding the systemd tag to devices. Any ideas why this would happen?
<semiosis> Odd_Bloke: are you around?  can you update livecd-rootfs on the cloud images build servers?
<semiosis> Odd_Bloke: the last build from the 14th doesn't have the resolv.conf fix from livecd-rootfs 2.408.4
<semiosis> or if not Odd_Bloke, anyone else?
<semiosis> this is regarding bug 1621393
<ubottu> bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393
<smoser> pitti, around ?
<smoser> i actually do not understand https://bugs.launchpad.net/ubuntu/+source/walinuxagent/+bug/1624596 completely.
<ubottu> Launchpad bug 1624596 in walinuxagent (Ubuntu) "ephemeral-disk-warning.service causes ordering cycle on multi-user.target" [Medium,Triaged]
<smoser> https://git.launchpad.net/~usd-import-team/ubuntu/+source/walinuxagent/tree/debian/ephemeral-disk-warning.service?h=ubuntu/yakkety is the ephemeral-disk-warning.service .
<smoser> it seems to me that having 'WantedBy' of multi-user.target implies Before
<smoser> is that true?
<pitti> smoser: yes, normally Requires= and Wants= implies Before=, since that's almost always what you want
<pitti> smoser: i. e. you define a target, define its dependencies, and usually you want the target to get active only after all your deps are started
<pitti> smoser: so if you want a dep to start after your target, you need an explicit After=
<smoser> yeah, and that makes sense. but since it is not strictly wrong, it should have decided that there was an ordering issue and dropped it.
<pitti> see man systemd.tareget, "Automatic Dependencies"; you can turn that off with DefaultDependencies=no if you don't care about the order, but I guess it's better to be explicit about it
<smoser> pitti, so do you agree with my suggested fix there ?
<pitti> smoser: looking
<pitti> smoser: structurally that will avoid the dep loop indeed; you would know better if it's semantically right, i. e. cloud-final does not need to run for ephemeral-disk-warning.service to work (but by the name I suppose it doesn't)
<pitti> adding an actual Description= might be nice, while you are at it?
<smoser> i'll submit merge proposal upstream for both
<smoser> i'm not actually sure *why* they had that after.
<pitti> cheers
<pitti> smoser: if it's just checking hardware and spit out some warning, that wouldn't need any particular ordering at all, does it?
<smoser> pitti, well, cloud-init is going to format that disk
<gpiccoli> pitti: ping
<pitti> hello gpiccoli
<gpiccoli> Hi pitti, how are you doing?
<gpiccoli> Sorry to bother you!
<gpiccoli> If you have some time, wanna discuss quickly LP 1615021 =)
<ubottu> Error: Could not gather data from Launchpad for bug #1615021 (https://launchpad.net/bugs/1615021). The error has been logged
<pitti> gpiccoli: aah, so it wasn't really hanging, the installer just showed up on the serial console when you expected it on VT1 (or vice versa)?
<gpiccoli> yeah pitti hehehe
<gpiccoli> It showed on tty1 (I guess) whereas I was expecting in hvc0 !
<gpiccoli> Wanna thank you for all the help and effort on this
<pitti> gpiccoli: TBH I don't actually know how the kernel (or maybe d-i) interpret console= and what the "primary" console is
<gpiccoli> Also, I have some questions pitti
<gpiccoli> One of the questions is exactly about this lol
<pitti> my gut feeling is that the installer doesn't care and just uses teh "current" console /dev/tty or /dev/console
<gpiccoli> I did a little digging on initramfs, and seems bterm is used to start the debian-installer menu
<pitti> but I'm not sure if it actually interprets the command line by itself, or whether the linux kernel has some semantics of "last/first console= is the primary one" or so
<gpiccoli> And it takes one of these consoles as env variable
<pitti> I notice that at least in VMs I do see the kernel and boot messages on *all* consoles though
<pitti> cyphermox, cjwatson: do you happen to know if d-i interprets console= kernel cmdline args to find out what the "primary" one should be?
<gpiccoli> yes, the console kernel param is used to show the kernel messages on multiple console
<pitti> cyphermox, cjwatson: or do they just use /dev/console or don't care at all and just use whatever the kernel presents as /dev/tty?
<gpiccoli> But I guess the last one is used to show debian isntaller
<gpiccoli> Let's see the opinion of cyphermox  and cjwatson
<pitti> gpiccoli: nice finding with "any command line customization works", what a red herring!
<pitti> gpiccoli: i. e. you always removed the default console= and just put in hvc0?
<cjwatson> If it cares it'll be in rootskel (for the installer itself) and finish-install (for setup of the installed system)
<cjwatson> Those are fairly small components so you can poke around there
<pitti> cjwatson: thanks; indeed both have tons of hits on egrep -r 'console|cmdline|tty'
<cjwatson> There's some logic in rootskel that appears to prefer the last console on the command line
<cjwatson> I haven't looked around exhaustively
<pitti> â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦â¦# Locate the last enabled console present on the command line
<pitti> rootskel-1.115ubuntu1/src/sbin/reopen-console-linux
<pitti> and defaulting to /dev/console if no console= is given at all
<pitti> gpiccoli: posted to the bug for posterity
<gpiccoli> pitti, very nice, thanks a lot!
<pitti> gpiccoli: so all good now?
<gpiccoli> since the default is /dev/console, that explain a lot!
<gpiccoli> Well, it ends the bug I guess, but I have a more is_this_feature_interesting question now
<pitti> gpiccoli: though I still don't know how the kernel determines what /dev/console should point to (both with and in absence of console= arguments)
<gpiccoli> (not sure either, will investigate, since it's curious =)  )
<gpiccoli> I noticed some installers in other distros makes use of the following strategy
<cyphermox> pitti: gpiccoli: as I recall we do read the setting
<gpiccoli> They open a terminal multiplexer (as screen or tmux) in base console (/dev/console hehehe) and attach to it in all other consoles
<gpiccoli> So, the installer is visible in every terminal, and we have a bonus of being able to open a console along the installer too
<gpiccoli> since terminal multiplexers have the "window" feature!
<gpiccoli> Would this be a good/accepted addition to Ubuntu installer?
<gpiccoli> Do you think it's interesting?
<pitti> gpiccoli: https://www.kernel.org/doc/Documentation/serial-console.txt
<pitti> this seems to agree that the last console= is what /dev/console will "point" to (but kernel messages still go to all of them)
<cyphermox> yes
<cyphermox> last one wins
<gpiccoli> ouch, this is really interesting to know! THanks folks
<cyphermox> pitti: is there a bug I should watch or are you working on it already?
<gpiccoli> What about the multiplexer cyphermox, cjwatson and pitti, seems interesting/feasible to you?
<cjwatson> I'm no longer involved in this, please untag me
<pitti> gpiccoli: sounds interesting indeed, although not exactly simple; for example, different consoles can (and will) have different geometries, term capabilities (color codes/fonts etc.)
<cjwatson> But I do recall it coming up recently on debian-boot@
<gpiccoli> cjwatson, unatagged! Sorry =/
<cjwatson> So I'd suggest looking through recent list archives there
<pitti> gpiccoli: so I think just a naÃ¯ve implementation will look awful in a lot of cases
<gpiccoli> Yeah pitti, you're right! It would need to "base" on the simpler console hehehe
<cjwatson> Some stuff on https://lists.debian.org/debian-boot/2016/08/threads.html
<cyphermox> I remember there was some old command you could poke to set /dev/console or otherwise get console messages on the current tty (or remove them from there, as it was most often the case)
<cyphermox> but maybe it's just old memories from Slowlaris days
<gpiccoli> Very nice cjwatson, thank you!
<gpiccoli> cyphermox, hahaha . I guess the best it to set hvc0 as console
<gpiccoli> Or set nothing, which works for us
<cyphermox> yeah
<gpiccoli> Great, thanks very much for your help!
<bdmurray> tseliot: Should bug 1619306 be verification-done?
<ubottu> bug 1619306 in ubuntu-drivers-common (Ubuntu Xenial) "SRU request: Include the 367 driver in Ubuntu 16.04" [High,Fix committed] https://launchpad.net/bugs/1619306
<tseliot> bdmurray: yes, as it was verified. I changed it to the wrong status, I suppose
<doko> apw: is there a reason to build linux 4.8 with gcc 5? I mean, gcc-6 was released way before linux 4.8
<seb128> doko, hey, could you check if there is still anything missing in https://bugs.launchpad.net/ubuntu/+source/libphonenumber/+bug/1618178 ? it looks like the previous comments got addressed
<ubottu> Launchpad bug 1618178 in libphonenumber (Ubuntu) "[MIR] libphonenumber" [Undecided,New]
<doko> seb128: still on my list, but it still doesn't show up on http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<seb128> why would it?
<seb128> we have not seeded unity8-desktop-session yet
<seb128> since some of the MIRs are not acked yet
<seb128> it would be backward to add the depends before getting the MIR
<doko> ahh, it's part of unity ...
<seb128> yes...
<robru> pitti: tsimonq2: https://git.launchpad.net/bileto/tree/britney/fetch-indexes
<nacc> infinity: quick q, re: dpkg-dev. It seems like with the move in debian to use (1.18.8) to replace the changelog program parsers with perl modules, some changelogs that were previously parseable now lead to parse errors. Is there any guarantee that shouldn't have happened? It seems correct for it to be a parse error now, but it is also a change in behavior.
<nacc> infinity: i can also take my question to debian, just saw you had the last upload and figured i'd check if you knew
<infinity> nacc: I'd file a bug with Debian including the specific changelog entries.  Though, if they're obviously syntactically incorrect, I'd be more inclined to say it was a bug that they parsed before. :P
<infinity> nacc: There's certainly no harm in fixing old changelog entries.
<nacc> infinity: yeah, that's kind of my approach, but it seems like at least at one point in debian's history, bad changelogs were more frequent than now. Makes for a headache for importing :)
<nacc> infinity: thanks for the tips
<nacc> if i had to guess, it's almost certainly fixed in current publishes, it's just historical publishes that have unparseable entries
<infinity> nacc: What, specifically, isn't working that used to?
<infinity> nacc: dpkg-parsechangelog giving up when it encounters a broken entry?
<infinity> nacc: (ie: dpkg can't parse its own changelog before 1.2.13)
<nacc> infinity: so, e.g., srcpkg:at 3.1.10.1 (first version published in debian available in lp publishing history) has a changelog tail that looks like: http://paste.ubuntu.com/23203956/. With 16.04's `dpkg-parsechangelog -l- --format rfc822 -SVersion --all` spat some warnings, but still returned the list of published versions. In 16.10 it errors out and doesn't output any versions.
<infinity> nacc: Indeed, it stops parsing at "Old Changelog:"
<infinity> For good reasons.
<nacc> yeah, i'm not saying it's wrong, per se, to change behavior. I was just surprised :)
<infinity> http://paste.ubuntu.com/23203975/
<nacc> interesting
<infinity> nacc: Anyhow, I'm not sure I see that as a bug or a feature, but you'd be better of discussing it with guillem.
<nacc> infinity: yep, i'll do that, thanks!
<nacc> infinity: for context, this is a git-importer for launchpad publishing history of source packages. So in theory, when i'm importing 3.1.10.1, e.g., as published in lp, I only have access to 3.1.10.1's source. But it looks like it's a bound range with bad entries, so possible for me to fix (with a new feature i just finsihed implementing :)
<infinity> nacc: Ahh, but when importing 3.1.10.1, you shouldn't care about versions before it, I would assume.
<infinity> nacc: And getting just the top entry should still work, no?
<nacc> infinity: yeah, that's true -- but the code in quesiton is generic and looks at the entire history to see where our next common ancestor is between the changelog's entries and the published history for that distro/series/pocket
 * infinity goes to hunt down an animal to lunch on.
<semiosis> is anyone around who can help update livecd-rootfs on the cloud images build servers and kick off a new build of xenial?  Odd_Bloke has done this in the past but I haven't been able to reach him for a few days.  this is regarding bug 1621393
<ubottu> bug 1621393 in cloud-images "xenial64 image (20160907.1.0) has a broken (empty) /etc/resolv.conf" [Undecided,New] https://launchpad.net/bugs/1621393
<infinity> semiosis: Do cloud image builds use a PPA for livecd-rootfs?  If so, that needs updating to match the SRU.
<nacc> rbasak: but in better news, i can confirm our apt workaround is actually quite nice. as i was apply the same logic to 'at' and it basically just worked :)
<semiosis> infinity: i seem to remember Odd_Bloke saying something about a PPA, yes
<infinity> semiosis: Right, that's what needs updating, then.  The builders themselves are ephemeral.  But the archvie they get livecd-rootfs from is likely not the primary archive. :/
<infinity> (Which is a bug in the cloud setup, but not my bug...)
<infinity> semiosis: So, you might be stuck poking Odd_Bloke repeatedly.
<semiosis> infinity: then that's what i'll do.  thanks.
<doko> tumbleweed, Laney: promoted. please could you fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822148 too?
<ubottu> Debian bug 822148 in src:snowball "snowball: memory leaks in libstemmer" [Important,Open]
<nacc> rbasak: do you have a good method for me to verify that my pygit2 converison has resulted in the same repository (including all history) for all the existing imports? i'm not sure if there is a good command to force a comparison of all objects in two repositories?
<tumbleweed> doko: upgrading to the new github snowball is a fairly large job, that I've been putting off for months
<tumbleweed> don't expect it in the next days
<doko> ahh, ok. qa.ubuntuwire.org is more pressing ;)
<tumbleweed> doko: on tho other side, cherry picking those PRs might be easy enough
<tsimonq2> thank you robru
<robru> tsimonq2: you're welcome!
<jderose> infinity: so Laszlo Ersek kindly chimed on https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1624096 - apparently it's a problem with shim, which upstream has fixed as of git commit 7052e7530755
<ubottu> Launchpad bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [Undecided,Confirmed]
<infinity> slangasek: ^
<infinity> slangasek: You <3 shim.
<slangasek> jderose: how did this break "after August 25th"?  the most recent change to shim-signed in yakkety was on August 8
<jderose> i <3 shim, you <3 shim, everybody <3's shim :P
<slangasek> and turning around a fix for shim-signed is not quick
<slangasek> oh, why are the edk2 binaries still in multiverse?
<slangasek> <fixy-fixy>
<jderose> slangasek: not totally sure... all i know is that the last timestamp i have for the last golden image i made for yakkety (using a xenial host) was August 25th, so the bug was introduced around there (+/- a week or so)
<slangasek> jderose: so, can you double-check what shim-signed version is in that one?
<slangasek> "When fallback.efi is not present, the should_use_fallback error path attempts to close a file that has already been closed"
<jderose> slangasek: yeah, give me a sec. i can figure out what version is in my exported tarbal, but that dosen't necessarily tell me what version was in the iso i installed from as sometimes i'll update the same qemu vm (from the same dev iso) for a week or so before a fresh remastering.
<slangasek> jderose: did you somehow have fallback.efi previously?
<jderose> slangasek: as i don't know what "fallback.efi" is, i'm not sure. i don't expect it's something i could have introduced anyway :P
<slangasek> you could have ;)
<jderose> sure sure. but could i have done it accidentally, without knowing? :P
<slangasek> dunno
<slangasek> there is a bug about that though, if I can find it
<slangasek> cyphermox: do you remember where the bug report about fallback.efi support is?
<slangasek> ah, LP: #1366546
<ubottu> Launchpad bug 1366546 in shim (Ubuntu) "Ubuntu doesn't provide \EFI\BOOT\BOOTX64.EFI for UEFI systems" [Undecided,Triaged] https://launchpad.net/bugs/1366546
<slangasek> so, we could work around your bug, more quickly than round-tripping to Microsoft, by adding fallback.efi to the disk
<jderose> slangasek: so it's an ISO mastering issue then?
<jderose> slangasek: hmm, so i working from home today and don't have easy access to the August 25th golden image tarbal i made... but i can figure it out tomorrow when i'm in the office. do you need to know this still?
<slangasek> jderose: probably not; for now we can assume that your Aug 25 image happened to have an out-of-date shim-signed package, and focus on the workaround wrt fallback.efi
<jderose> slangasek: okay, gotcha. please let me know if there's anything i can do to get you helpful information
<doko> wgrant, tumbleweed: what can we do about the ftbfs reports for the test rebuilds? end of this week I'd like to post about the test rebuild including links to the build failures
<tumbleweed> doko: I can do a run against a test archive. What's it called?
<doko> tumbleweed:  https://launchpad.net/ubuntu/+archive/test-rebuild-20160916 and https://launchpad.net/ubuntu/+archive/test-rebuild-20160916-linaro
<mizu_> Hi can anyone here help me set up lxr so that i can index the linux kernel
<sladen> mizu_: if you just want to view the result; something like  http://lxr.free-electrons.com/source/kernel/printk/printk.c  maybe useful
<mizu_> sladen: Hey! thanks for the reply. I'm required to have my own copy of the kernel on lxr.
<mizu_> It's for a class.
<mizu_> sladen: I was trying to follow the User manual for LXR. but i'm getting lost along the way. my poor english is making it a bit difficult.
<sladen> mizu_: well, people can help, but not do your homework for you :0
<sladen> :)
<sladen> mizu_: perhaps you could share how far you got.  And where you have gotten stuck?
<mizu_> sladen: Okay give me a few moments to write what i've done. sorry if it will be hard to understand
<mizu_> sladen: Also thank you!
<mizu_> So i downloaded the kernel from kernel.org and unzipped it in the /home/source/kernel directory. As it tells me to do in the User Manual. Then after installing all the required software for lxr like the swishe ctag etc. I went into the lxr folder and ran the configure-lxr.pl script. as it tells me in the manual. And i went with all the default options. This created my lxr.conf file. I then set up mysql, with root password. I than
<mizu_> And I am getting a nothing to index error
<mizu_> I am a bit lost in where the kernel comes into this setup
<nacc> mizu_: i'm guessing beteween your first and second descriptino, you got cutoff. It ended with "I than"
<mizu_> nacc: Oh sorry about that. I said I than ran the ./genxref script. and got a nothing to index error
<mizu_> the user manual says to do. ./genxred --url=http://localhost/lxr --tree=tree --version=v2
<nacc> genxref, right?
<mizu_> sorry that should be  genxref
<mizu_> yes
<nacc> mizu_: how are you storing your trees? FILES/cvs/git/subversion/bitkeeper
<mizu_> nacc: Files
<nacc> mizu_: ok, what is your exact genxref invocation?
<mizu_> nacc: sorry my english is not the best by invocation you mean what command do i put in when i run genxref?
<sladen> mizu_: yes, we need to know (a) what exactly you are typing  (b) what exact error message is then showing
<sladen> mizu_: it is probably best if you paste your terminal input/output here:  http://paste.ubuntu.com/
<nacc> mizu_: yeah, you said ran the ./genxref script, please pastebin the exact in/output
<mizu_> since i'm following the user manual, i just put in what they had which was. "./genxref --url=http://localhost/lxr --tree=tree --version=v2"
<mizu_> okay one sec sorry
<mizu_> paste.ubuntu.com/23204818
<nacc> mizu_: i think you are taking their guide too literally
<nacc> version you pass is the version you want to index
<nacc> and tree is the name of a tree to index
<mizu_> is the tree the directory to the linux kernel? also does the kernel need to be compiled first?
<nacc> given taht you're indexing the linux kernel, i'm assuming  it wouldn't be 'v2'
<nacc> mizu_: no, it's not necessary to compile the kernel, this is a source index
<nacc> mizu_: you probably don't need to pass --tree at all, afaict
<nacc> mizu_: if you pass a url
<mizu_> but then how would it knw to index the kernel?
<nacc> mizu_: the url (http://localhost/lxr) references a path on your system, afaict -- that's what you configured
<mizu_> hm, i am a bit confused. I think i will start from scratch and set up the conf file again
<mizu_> nacc: It would be best to use mutiple-tree configuration yes? I need to index both kernel and grub.
<nacc> mizu_: i have no idea :)
<sladen> mizu_: looking at eg.  http://oss.segetech.com/integra/lxr.conf
<sladen> mizu_: I can see "6) Copy this file as /usr/local/lxr/lxr.conf and adjust as needed - baseurl, virtroot, sourceroot, sourcerootname, cvswebprefix"
<sladen> mizu_: have you configured anything like this?
<sladen> mizu_: eg. how is genxref being told where to find the source to index?
<mizu_> sladen: when you run the config script its supposed to set it up i believe, but the script gives me different questions from the manual so its a bit confusing. one sec. I will retry the config script, which createes the conf file they are editing in that link.
<sladen> mizu_: can you pastebin the lxr.conf file?
<sladen> mizu_: the important config setting appears to be "sourceroot"
<sladen> mizu_: and then the 'versions' are just sub-directories inside that
<mizu_> sladen: yup! one sec redoing the script tht creates the file
<mizu_> sladen: sorry, this script is acting weird for some reason
<mizu_> sladen: really sorry about that. script was being weird. pastebin.com/ENNMhCb2
#ubuntu-devel 2016-09-20
<tumbleweed> doko: oops, I forgot to do it early, but I've got those FTBFS reports now
<tumbleweed> earlier
<pitti> Good morning
<sladen> Herbst has arrived
<pitti> massively -- non-stop rain since Friday evening here, depressing :(
<rbasak> nacc: a tree compare of refs/{heads,tags} maybe?
<rbasak> I'm not sure there's any easier way.
<cpaelzer> good morning
<tjaalton> http://qa.ubuntuwire.org/rdepends/ doesn't seem to work
<tjaalton> the whole site is down, so reverse-depends doesn't work. is there an alternative?
<handsome_feng> hi, Good morning everyone! I have a new package to be upload to archive,and I have file a bug in launchpad. Does anyone know who can help me? In the Topic I can't find who is the Patch Pilot. :(
<ricotz> chrisccoulson, hi, could you retry https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/ppa/+build/10930941
<pitti> ricotz, chrisccoulson: done ^
<ricotz> pitti, thanks!
<pitti> ricotz: interesting that I can even see that PPA..
<ricotz> pitti, huh, why?
<pitti> well, aren't security updates meant to be kept private until publication?
<ricotz> pitti, ah, I see, in this case I hope it stays that way otherwise it would take even longer to get them ;)
<ricotz> while yakkety builds are usually still missing :\
<pitti> this only applies to yet undisclosed vulns; for preparing new releases which are already published upstream it's totally fine and correct of course
<ricotz> pitti, ack, the referenced USN-3076-1 is still hidden on http://www.ubuntu.com/usn/
<Odd_Bloke> semiosis: I've been at a conference over the weekend, apologies for being AWOL. ;)  I'll look at updating livecd-rootfs now.
<Odd_Bloke> semiosis: Done; the next xenial Vagrant box should be built with the new livecd-rootfs.
<smb> xnox, since you have been looking at that old thing in the past, maybe you could help to sponsor the change I proposed in bug 1611277 in Yakkety. Depending on how you think about it. IMO it feels rather wrong to ignore removable devices and even if the scan then hits a cd it should not go too wrong as reading should have no usable meta-data
<ubottu> bug 1611277 in dmraid (Ubuntu) "Kernel Shipped With Ubuntu 16.04.1 Cannot Recognize fakeRaid" [Medium,Confirmed] https://launchpad.net/bugs/1611277
<xnox> that bug is long....
<xnox> smb, i like your patch, and i think it should go in everywhere, including debian.
<smb> xnox, probably yes. don't think there is anything maintained upstream anymore. Though apparently some people still use the thing
<xnox> some have no choice =(
<smb> yeah, likely :/
<smb> xnox, so at least for me I have no upload rights for this neither in Debian nor Ubuntu
<xnox> oh.
<xnox> smb, i'll sponsor that everywhere then.
<smb> xnox, thanks a lot. might help me a little step on my path to world-dom... I mean core-dev >:-)
<mdeslaur> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
 * dholbach hugs mdeslaur 
 * mdeslaur hugs dholbach 
<semiosis> Odd_Bloke: thank you very much
<willcooke> hey alecu, dobey, semiosis
<willcooke> err, sorry semiosis
<willcooke> didnt mean you
<willcooke> mean seb128
<seb128> hey :-)
<willcooke> dobey, I think we touched on this in the HO, but just wanted to make sure that the deps on sdk libs are addressed via your branches?
<dobey> willcooke: yes, one of my branches changes it to "snapd | ubuntu-sdk-libs,"
<willcooke> dobey, super, thanks!
<willcooke> seb128, ^ good news
 * dobey has way too many branches for too many things, at the moment
<seb128> great
<powersj> rbasak, re: oversized ISO, what should our next steps be?
<rbasak> powersj: I guess we need to decide how we should get the size down. That might be by reverting the ghostscript upload that bumped the size, or by dropping the print-server task from the ISO, or something else.
<rbasak> I don't know what the implications would be in reverting the ghostscript upload. Perhaps start a conversation with Gunnar, perhaps in a new bug against ghostscript?
<powersj> ok I can do that
<rbasak> Also, it's probably worth checking to see if the print-server task really doesn't appear in the installer, and if so we should have a bug against that too.
<powersj> dropping the print-server task, while not unusable due to the tasksel bug, does seem a bit of a bigger task/impact
<powersj> ah I filed one for that already
<powersj> bug 1624519
<ubottu> bug 1624519 in tasksel (Ubuntu) "print-server task dropped" [Undecided,New] https://launchpad.net/bugs/1624519
<rbasak> powersj: yeah, I would prefer to leave it alone.
<powersj> rbasak, one other topic, ISO testing - we should schedule something soon right?
<rbasak> powersj: ah yes, good shout
<nacc> rbasak: yeah, there is git-diff-tree, but for some reason the ubuntu package doesn't put that in the normal bin path?
<juliank> nacc: git subcommands do not belong into $PATH - git diff-tree works fine, but it's fairly lowlevel so it's not advertised by the bash completion, for example.
<nacc> juliank: ah maybe that's what i missed, thanks!
<mdeslaur> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<nacc> juliank: kept hitting tab (as it's a git recipe on their wiki for comparing two local repos) and wasn't seeing it, but found it in the package. Thanks again for the clarification :)
<juliank> nacc: Thing with diff-tree is that it works on tree objects - a lot of people probably don't even know those exist.
<Unit193> slangasek: Seen the conclusion in LP 1624096?
<ubottu> Launchpad bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [Undecided,Confirmed] https://launchpad.net/bugs/1624096
<nacc> juliank: ack :)
<slangasek> Unit193: I had discussed it with jderose here yesterday.  But I'm planning to work around it, which we can do a lot more quickly than we can land a new signed shim
<Unit193> Ah sorry I didn't see it.  Thanks for the info.
<mdeslaur> crud, the reverse-depends tool doesn't work anymore because it looks like qa.ubuntuwire.org went away
<Laney> mdeslaur: http://ubuntuqa.tblwd.org/
<nacc> i believe there is a failover service available
<nacc> :)
 * pitti uses it once to finally get that into my bash history
<mdeslaur> Laney: awesome, thanks!
* Laney changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | reverse-depends/seeded-in-ubuntu broken? http://ub
<Laney> fail
<pitti> $ reverse-depends -u http://ubuntuqa.tblwd.org/ src:udisks2
<pitti> <head><title>404 Not Found</title></head>
<Laney> pitti didn't follow the instructions :)
<pitti> oh, that is an actual human-readable page, sorry :)
<pitti> thanks!
* Laney changed the topic of #ubuntu-devel to: Xenial (16.04.1) Released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | reverse-depends/seeded-in-ubuntu broken? http://ubuntuqa.tblwd.org/ | Patch Pilots:
<juliank> I find the translation import queue a bit hard to read (it shows no imported ones, at least)? Did we get some of the new APT translation templates imported? I specifically worked things into the build system so they can be imported by launchpad (obj-*/po/{apt,libapt-pkg5.0,libapt-inst2.0,apt-utils}.pot) - would be a shame if they were not used
<juliank> This only started fairly recently with the CMake switch in 1.3~rc1, all the older builds (those building in build/) will fail to be imported
<juliank> The first I see is "obj-arm-linux-gnueabihf/po/apt.pot in apt in Ubuntu Yakkety" somewhere after #75, uploaded on 2016-08-12, and "Needs Review"
<juliank> The templates currently in use must be years old
<nacc> jgrimm: fyi, 277 commits between the yakkety openipmi upstream release and the latest upstream release :/
<jgrimm> nacc,  bug fixes, cosmetic, features, ?
<nacc> jgrimm: reading through them now
<jgrimm> nacc, cool
<nacc> "More massive restructure getting ready for the serial code."
<nacc> definitely lots of bugfixes too
<nacc> cpaelzer_: i see that you 'declined for yakkety', LP: #1585121. Can you help me understand what that means? ... was it nominated for yakkety at some point and then cancelled?
<ubottu> Launchpad bug 1585121 in awstats (Ubuntu Xenial) "awstats produces regex warnings in version 7.4 with Perl 5.22 on Ubuntu 16.04 LTS" [High,In progress] https://launchpad.net/bugs/1585121
<jgrimm> nacc, that's what it looks like
<jgrimm> anything else we want to discuss?  jamespage is likely ready to wrap things up..
<jgrimm> oh oopps. wrong channel. apologies.
<cpaelzer_> hmm
<nacc> if so i can approve that cancel to clean up the message, at least
<cpaelzer_> nacc: yeah when doing triage with josh and robie
<nacc> cpaelzer_: ok, so i'm good to cancel the yakkety nomination?
<cpaelzer_> nacc: it was found that the change should already be in yakkey
<cpaelzer_> nacc: thats why I declined, and if you agree cancel your nomination (or wherever it came from)
<cpaelzer_> It just was a chance for me to first time ack/nack nominations
<cpaelzer_> and this case provided both at once
<nacc> yep
<powersj> nacc, yeah sorry my bad
<nacc> ok, it should be fixed now
<nacc> cpaelzer_: i think also, LP: #1576698 can be in progress, at least for xenial?
<ubottu> Launchpad bug 1576698 in ntp (Ubuntu Xenial) "ntpdate-debian not working" [Medium,Triaged] https://launchpad.net/bugs/1576698
<jgrimm> nacc, can you approve nomination in 1534882?
<nacc> jgrimm: done
<jgrimm> nacc, thanks!
<nacc> jgrimm: np!
<nacc> jgrimm: re: openipmi, it's definitely not just bugfixes
<nacc>  184 files changed, 36011 insertions(+), 10237 deletions(-)
<nacc> rbasak: ok, let's say both y-proposed and y are present a repository. Should 'ubuntu/devel' point to y, if y is a proper descendant of y-proposed? meaning it's already been copied forward and y is current? Technically tree-wise y-proposed and y are identical in this case. I guess we'd want to work on y-proposed, though, as we'd expect the next publisehd version to show up there. I think I answered my
<nacc> own question by asking it :)
<ginggs> doko, what do you think about openmpi2 for yakkety?
<nacc> rbasak: smoser: pushed the apt/at fixes and the ubuntu/devel change to master
<smoser> import apt ?
<nacc> smoser: if you want to update and try to re-import apt to see if it works for you, that'd be great
<nacc> smoser: or i can
<smoser> i can.
<nacc> cool
<smoser> that one takes a while
<nacc> i'm updating the snap right now :)
<nacc> yeah, it's a lot of churn :)
<smoser> nacc, http://paste.ubuntu.com/23208016/
<smoser> $ git clone git+ssh://smoser@git.launchpad.net/~usd-import-team/ubuntu/+source/apt
<smoser> Cloning into 'apt'...
<smoser> fatal: remote error: Repository '~usd-import-team/ubuntu/+source/apt' not found.
<nacc> smoser: argh, i forgot to fix that! -- it's a bug i need to figure out how to deal with
<nacc> workaroud for now, is to use --no-push
<nacc> and then push manually from the git repository to that remote
<nacc> sorry, totally blanked on that
<nacc> it's because their internal parser, iirc, doesn't recognize git+ssh (i think)
<smoser> so my fix for git:// wasn't completely useless, eh ?
<smoser> :)
<nacc> smoser: heh
<nacc> smoser: actually, do you mind if i do the import, so i can test this?
<smoser> sure
<nacc> smoser: i'll ping you when it's done
<smoser> nacc, https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/306254
<smoser> oh wait. i geuss we can probably drop the python3-git now, right ?
<nacc> smoser: yeah, make it python3-pygit2
<nacc> and drop python3-git altogether
<smoser> done
<nacc> thanks, i'll pull that once i've got this tested -- it seems like this should work, basically i'm using git:// for fetch and git+ssh:// for push
<nacc> i think the parser will understand that (and if it doesn't, it's a bug in pygit2)
 * smoser adds --force
<rbasak> nacc: yeah. I guess if it was yakkety-proposed, then we could upload and push, then the import would end up pointing to it automatically. So that would be cleanest.
<nacc> rbasak: yep, that's my thinking, thanks
<jderose> slangasek: so following up on our conversation yesterday about fallback.efi... so you're saying a potential solution is just to have /usr/lib/shim/fallback.efi.signed from `shim` copied over to /EFI/BOOT/fallback.efi on the ISO?
<smb> xnox, grrr... (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827315)
<ubottu> Debian bug 827315 in src:sbuild "sbuild: Does not work with gnupg 2.x installed in the chroot" [Important,Fixed]
 * smb is trying to sbuild a yakkety package on trusty
<slangasek> jderose: correct
<slangasek> jderose: since the double free only happens on an error path when that file does not exist, making that file exist should work around the bug
<teward> smb: funny story: I've been trying to as well, and it's still busted, I heard there's no timeline for that getting fixed anywhere in the past (I got very annoyed at that bug last week)
<teward> (in Trusty)
<sarnold> smb: I've heard yakkety's sbuild on xenial works, no idea about trusty though
<smb> teward, yeah, reading through that debian bug it seems the "fix" is to backport sbuild...
<teward> sarnold: it doesn't work on pre-Xenial, because of changes to sbuild and the gnupg 2.x switchover
<sarnold> teward: ah. bummer :/
<smb> sarnold, hm, maybe someone picked a fix there but not back to t
<teward> sarnold: that said, I tried straight backport of Yakkety -> Trusty
<teward> and it does absolutley nothing
<jderose> slangasek: so is this a change that needs to be made in shim, or in the ISO mastering tools?
<sarnold> that seems like quite a large gap to jump
<teward> but it's a big issue, yes.
<slangasek> jderose: shim-signed and/or grub2 (since grub-install is what handles all the other UEFI bits)
<slangasek> cjwatson, cyphermox: ^^
<cyphermox> yes
<cyphermox> is the issue "just" that something crashes when fallback isn't there? because fallback.efi just by itself won't do anything very useful
<slangasek> cyphermox: the actuall question is, should this go in shim-signed, or be in grub-installer :)
<slangasek> sorry, grub-install
<cyphermox> grub-install
<cyphermox> (just like the other shim bits -- MokManager, etc.)
<jderose> cyphermox: yes, on yakkety currently, things go haywire when trying to boot the ISO in UEFI mode with QEMU - https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1624096
<slangasek> ok
<ubottu> Launchpad bug 1624096 in shim (Ubuntu) "yakkety: backport (or rebase to) fix eliminating a double-close in shim" [Undecided,Confirmed]
<slangasek> cyphermox: I believe you once expressed a contrary opinion in LP: #1366546, so wanted to check
<ubottu> Launchpad bug 1366546 in shim (Ubuntu) "Ubuntu doesn't provide \EFI\BOOT\BOOTX64.EFI for UEFI systems" [Undecided,Triaged] https://launchpad.net/bugs/1366546
<cyphermox> slangasek: I was wrong
<cyphermox> err, on the ISO though, I'm not sure what the benefit would be to have fallback.efi except to paper over the bug in shim
<slangasek> hmm good question
<cyphermox> that said, I'm happy to add fallback in general, I've been bugging you about it periodically for a while :)
<slangasek> the purpose of fallback.efi is to recover your boot config if it goes missing from nvram
<cyphermox> yep
<cyphermox> oh
<slangasek> if someone inserts a bootable CD, would we like it to magically do this for you, or not? :)
<cyphermox> yeah, I suppose that for the magic "recover my system" feature it might be good
<cyphermox> so we'd want to ship fallback on the CD, but not boot.csv
<cyphermox> but we'd want to ship a boot.csv in our directory, otherwise that won't work
<slangasek> if this doesn't violate principle of least surprise for the CD to magically do this
<slangasek> right
<slangasek> eventually we need to add boot.csv
<slangasek> but if it's correct to install fallback.efi, we could start doing that sooner rather than later even if the full thing isn't implemented
<cyphermox> it seems fine
<cyphermox> and implementing the rest is not complicated work, it just takes a bit of time to get things right
<cyphermox> I did test it out here before
<Unit193> jderose: Still here?
<jderose> Unit193: yup :)
<cyphermox> jderose: slangasek: updated the bug, I'll start hacking at those
<jderose> cyphermox: awesome, thanks! i can help test, test, test as soon as there's an ISO :)
<jderose> cyphermox: so as a quick crude test, i edited the latest yakkety daily desktop ISO, adding /BOOT/EFI/fallback.efi, and then tried installing from it with QEMU + OVMF. things aren't blowing up anymore, but it's also not bringing up the ubuntu installer pre-boot menu. it tries to PXE boot, then falls back to Shell>
<cyphermox> ok
<cyphermox> well presumably it was blowing up because it tried to go to fallback in the first place, that shouldn't be happening if there are other options to boot from
<cyphermox> (and one of them should be "hey there's a grubx64.efi"
<slangasek> cyphermox: so, perhaps fallback.efi is meant not to be there on removable media and this isn't fixable without a signing round-trip
<cyphermox> possibly
<cyphermox> that means I really need to go to read some shim code now
<slangasek> (I don't remember the semantics of fallback.efi, it's been a long time since I talked to mjg59 about this)
<cyphermox>               /* Do not print the error here - this is an acceptable case
<cyphermox>                  * for removable media, where we genuinely don't want
<cyphermox>                  * fallback.efi to exist.
<jderose> slangasek: so assuming the only workable fix is a signing round trip, do you think that can happen in time for 16.10?
<cyphermox> well, fallback might make sense on removable media for the reason we brought up earlier
<slangasek> jderose: it's possible, yes, but would be tight
<slangasek> cyphermox: it might "make sense" but the code may still not be designed that way
<cyphermox> right
<cyphermox> it is not
<jderose> slangasek: how much beer does System76 need to send you? :P
<jderose> slangasek: cyphermox: so does it seem to both of you that the newer shim in yakkety is the root cause of this problem, or might there be other changes in yakkety that are at play also?
<slangasek> jderose: that seems to be the only cause
<jderose> slangasek: so you'd expect that with a xenial guest, OVMF would try to load fallback.efi (which wouldn't kaboom because of the older shim package), then OVMF would "discover" whatever it needs to load to start the installer?
<slangasek> jderose: OVMF doesn't try to load fallback.efi, it only loads bootx64.efi
<slangasek> which is shim
<jderose> slangasek: ah, gotcha... so shim itself is what then calls fallback.efi?
<slangasek> yes
<jderose> slangasek: perhaps a dumb question, but why does shim run fallback.efi instead of just booting the installer?
<slangasek> jderose: because shim is a monolithic binary which has to do the right thing with no other information, and one of the things it has to do is load fallback.efi when it's present
<jderose> slangasek: okay, thanks. it's slowly starting to make more sense to me :)
<bdmurray> juliank: Could you have a look at bug 1592817?
<ubottu> bug 1592817 in python-apt (Ubuntu) "gdebi-gtk crashed with ValueError in update_interface(): could not convert string to float: '0,0000'" [High,Triaged] https://launchpad.net/bugs/1592817
<nacc> smoser: fyi, fixed the bug(s), i think. running the import now in the bg
<xnox> smb, you need a bit newer sbuild and no host keys setup.
<xnox> smb, use lxd container
<xnox> or lxc given that it's trusty
<xnox> i guess i should upload backports for sbuild
<xnox> micahg, so i really really need ~ubuntu-backports powers =)
<sarnold> or an SRU?
<Unit193> xnox: Ooooh, do my pbuilder request too!
<xnox> sarnold, i can break one or the other.
<xnox> sarnold, actually trusty apt should be new enough, to handle no host keys as done by new enough sbuild.
 * xnox ponders if i can do magic with debootstrap profiles too somehow.
<xnox> Unit193, shrug no. I want to remove pbuilder & cowbuilder from the archive. official builds are done using sbuild and there is no reason not to use $ mk-sbuild <sid|yakkety|xenial>; sbuild -A -d <sid|yakkety|xenial> for years now.
<Unit193> 1592205! (Maybe 1562358 too)  Erm, eww no.
<bdmurray> xnox: Could you have a look at bug 1623383?
<ubottu> bug 1623383 in udev (Ubuntu) "Some restarts fail due to missing base devices" [Critical,Confirmed] https://launchpad.net/bugs/1623383
<juliank> Hmm, https://wiki.ubuntu.com/Releases says yakkety will be supported until February but down the page says "Regular releases are supported for 9 months."
 * juliank is confused
<juliank> That seems like a copy/paste error from a non-LTS .04 release?
<sarnold> I wonder if that came from the 'vivid' line, which has had some kind of crazy half-zombie half
<stgraber> it's certainly supposed to be 9 months
 * juliank calculated with 9 months in his APT stable branch planning 
<juliank> It will be interesting to see if we come up with 1.4 apt series for the Debian stretch and next year's Ubuntu releases, or if we end up with one APT series covering 3 Ubuntu releases...
<tsimonq2> nice catch
<tsimonq2> look better now?
<juliank> tsimonq2: yeah
<juliank> Here's one thing I can guarantee: 17.04 will ship the same APT release series as stretch. 17.10 is tricky - If we got a lot of new stuff during the Debian freeze, we can do a release cycle in there, but I'd probably prefer to just move that to 18.04
<stgraber> xnox: hmm, so "gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 0xBA
<stgraber> xnox: hmm, so "gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 0xBAEFF88C22F6E216" seems to hang most of the time with gnupg2
<stgraber> xnox: that's the cause of all those adt failures for LXC, any idea what's going on?
<tumbleweed> you sure you aren't hitting a broken keyserver in the pool?
<stgraber> xnox: on the exact same network, running the same with gpg1 works immediately so it's clearly a gnupg2/dirmngr thing
<juliank> BTW: If someone wants to contribute huge features to apt for the next series, please do so in the next 1.5 months. APT is basically freezing for big stuff in 2 months. Smaller features freeze in 3 months.
<stgraber> tumbleweed: good question and that actually just pointed me at the answer, dirmngr is completely screwed up in ipv6 mode
<stgraber> tumbleweed: it just plain fails if you pass hkp://[ipv6] as the keyserver and if you pass a DNS record which does happen to have IPv6 addresses on an IPv6 enabled machine, it will go crazy doing weird DNS queries for a while, eventually run out of IPv6 addresses to fail and finally succeeds over IPv4
<stgraber> obviously that assumes you have IPv4 connectivity at all, which I don't
<juliank> stgraber: Oh, while I see that: you can use the encrypted keyserver: hkps://hkps.pool.sks-keyservers.net
<stgraber> as for adt, that's failing because unlike gpgv1, it's not respecting http_proxy and https_proxy
 * juliank also pins the host certificate for that keyserver
<stgraber> xnox: so looks like there's some serious work to be done for that gpgv2 replacement to be a thing...
 * juliank hates IPv6
 * stgraber hates IPv4
<juliank> I also had trouble SSHing to my IPv6 enabled xenial server thinkpad.
<juliank> but that one is urnning networkd, so ...
<sarnold> juliank: any chance for an apt that installs multiple packages simultaneously? :) I get a bit sad seeing 5% processor utilization during long builds, when the install stage runs and rus and runs..
<juliank> sarnold: no chance.
<juliank> sarnold: Well, you'd have to tell dpkg to process the stuff in parallel, not APT
<juliank> With 1.3 in yakkety, APT just passes dpkg a directory of deb files and says: Hey, install those.
<sarnold> juliank: yeah, I figured it'd be difficult at best..
<sarnold> oh? does apt hint at ordering? or does dpkg sort it all out?
<juliank> Well, some more ordering is still going on.
<juliank> I think we have to name the files in order for dpkg to not screw up
<sarnold> hehe
<powersj> stgraber, are your GPG comments related to my lxc api test email?
<juliank> because dpkg -i a.deb b.deb != dpkg -i b.deb a.deb
<sarnold> thanks juliank :)
<juliank> One thing I'm happy about is automated coverage checking in the APT CI: We will now be able to see if the lines we changed in a commit where covered by the test suite. This should vastly increase our trust in future SRUs.
<juliank> (thanks to travis ci and codecov.io)
<stgraber> powersj: yes
<stgraber> powersj: filing a couple of critical bugs against gnupg2
<juliank> I somehow would like to create a metric for rating apt solutions, and record anonymized APT upgrade runs on end user systems and then feed new APT releases these problems for regression checking
<juliank> that would be nice
<juliank> Anyway, enough for today :D
<stgraber> powersj: bug 1625845, bug 1625848
<ubottu> bug 1625845 in gnupg2 (Ubuntu) "dirmngr doesn't handle IPv6 properly" [Critical,Triaged] https://launchpad.net/bugs/1625845
<ubottu> bug 1625848 in gnupg2 (Ubuntu) "gnupg2 appears to ignore http_proxy, fails to retrieve keys" [Critical,Triaged] https://launchpad.net/bugs/1625848
<powersj> stgraber, thank you!!!
<stgraber> slangasek: ^ FYI (I assigned to xnox for now since he seemed to be the one dealing with the gnupg2 transition)
<stgraber> powersj: I just hope there's a fix somewhere we can pull for this, because otherwise those two bugs will be extremely painful for enterprise users, makes gpg basically unusable if you need to use a proxy or if you have IPv6 connectivity
<powersj> agreed
<powersj> it is nice to know the automated iso tests are finding real issues now :)
<stgraber> powersj: well, we knew about some of this ever since gnupg2 was made the default as the autopkgtest for lxc has been failing ever since
<stgraber> powersj: first we thought it was becaused of missing dirmngr as it wasn't installed by default, but it looks like a) it is now b) I added a dependency on it anyway
<stgraber> powersj: that lxc change landed yesterday and autopkgtest confirmed that things are still just as bad, so I finally looked at gnupg2 a bit closer now :)
<powersj> ah ok!
<stgraber> can't say I'm happy with what I'm seeing though... not sure how they managed to regress so much when moving code around...
#ubuntu-devel 2016-09-21
<xnox> stgraber, thank you for the analysis.
<xnox> stgraber, and yes this is serious. thanks for assignment, i will look into it during day time.
<pitti> Good morning
<cpaelzer> nacc: oh yeah LP: #1576698 is as much in progress as it can be with the SRU pushed to the approval yesterday
<ubottu> Launchpad bug 1576698 in ntp (Ubuntu Xenial) "ntpdate-debian not working" [Medium,In progress] https://launchpad.net/bugs/1576698
<cpaelzer> nacc: I updated the status triaged -> in progress - and given nothing breaks on the way in it will go to fix released then
<cpaelzer> nacc: it might even be fix committed already given that the SRU is in the queue
<ginggs> pitti, thanks for the FFe :)
<pitti> ginggs: no worries, thanks for working on the wine update!
<cpaelzer> I guess there are some very special considerations on removing a binary package to be no more built by a source via an SRU
<cpaelzer> rbasak: you discussed that with me a while ago for bug 1524526
<ubottu> bug 1524526 in dovecot (Ubuntu Xenial) "Crashes with undefined symbol" [High,Triaged] https://launchpad.net/bugs/1524526
<cpaelzer> but we didn't get to a conclusion back then
<cpaelzer> now all the yakkety parts whicih blocke us before are complete
<cpaelzer> so we have do discuss (=I have to lean) how that is to be done
<cpaelzer> everybody is invited to share experience on this :-)
<rbasak> cpaelzer: we can SRU something that makes the dovecot-lucene binary package effectively empty
<cpaelzer> rbasak: and that is preferred because it avoids the dependency havok it might cause otherwise ?
<rbasak> cpaelzer: what would be the alternative?
<cpaelzer> rbasak: really not building it, but the old bad one would stay around all the time
<rbasak> Ah. If we didn't build dovecot-lucene, then apt would still see the release pocket version. So users would still have it, and the SRU would be ineffective.
<cpaelzer> that is what I expected and wanted confirmed
<cpaelzer> rbasak: do you have any example on such an empty package?
<rbasak> https://launchpad.net/ubuntu/+source/owncloud but I'm not sure that's representative
<rbasak> https://launchpad.net/ubuntu/+source/bitcoin/0.3.24~dfsg-1ubuntu0.2 is another
<rbasak> In this case it wouldn't be as severe - just one binary package going rather than all of it. I don't know of a good example of that.
<G> Just package a README.lucene file? (can't remember the naming format for Maintainer maintained docs) with an explanation of where the contents disappeared to?
<rbasak> Right, and maybe a NEWS.Debian entry as well as a changelog entry, etc, so people using apt-listchanges will see it.
<cpaelzer> thank you all G and rbasak - I'll prep something testbuild and suggest then
<wgrant> doko: http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html and http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-linaro-yakkety.html exist now.
<Mirv> any idea why so many arm builders seem stuck in Cleaning? https://launchpad.net/builders/
<ginggs> pitti: could you remove the wine-development armhf binaries please? LP: #1612180
<ubottu> Launchpad bug 1612180 in wine-development (Ubuntu) "Please remove wine-developement binaries on armhf" [Undecided,Confirmed] https://launchpad.net/bugs/1612180
<pitti> ginggs: done, bug updated
<ginggs> pitti: danke!
<wgrant> Mirv: There's an annoying arm64 KVM bug or two.
 * wgrant resets them.
<pitti> wgrant: are you also running into these rcu_sched stalls?
<wgrant> pitti: These tend to mostly be early boot failures.
<wgrant> Rarely do successfully booted instances later hang.
<pitti> wgrant: I've been wondering all the time why cking and I didn't find a way to circumvent them while they seem to not inflict your buildds
<wgrant> (unless we upgrade them to xenial. then the world burns.)
<wgrant> pitti: Colin and I have long wondered that too.
<Skuggen> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-5.7 could some kind soul with access hit retry on the failed libreoffice build? :)
 * cking needs to reprioritize on that issue, lemme sync up with leann about this
<Mirv> thanks
<pitti> cking: I thought the status quo was that it doesn't happen any more with xenial on the host, but that then ran into bug 1602577
<ubottu> bug 1602577 in linux (Ubuntu Xenial) "[arm64] compute nodes unstable after upgrading from 4.2 to 4.4 kernel" [High,Triaged] https://launchpad.net/bugs/1602577
<wgrant> Right, 4.4 on the hosts was a total disaster.
<cking> ugh, even worse than I recalled
<wgrant> cking: You're at least able to repro outside scalingstack, right?
<wgrant> Unlike the damned ppc64el memory corruption.
<cking> wgrant, yep, the repro was harder to do though outside of scalingstack
<wgrant> scalingstack's a better Tempest than Tempest.
 * cking not sure what that refers to
<wgrant> OpenStack Tempest it their load testing thing.
<wgrant> stress-ng but for clouds, if you will.
<cking> ah :-)
<mapreri> xnox: that's not a reason to remove a package that is even maintained.  Both debian's and ubuntu's archive contains different programs achieving the sme, that's no different.
<sitter> juliank: hey, did you have any more requests for my python-apt change or is it good to merge?
<seb128> doko, hey, could you re-review https://bugs.launchpad.net/ubuntu/+source/libphonenumber/+bug/1618178 ?
<ubottu> Launchpad bug 1618178 in libphonenumber (Ubuntu) "[MIR] libphonenumber" [Undecided,New]
<juliank> sitter: Not sure
<juliank> I wish CI was working for python-apt
<juliank> Let's see if it passes the testsuite
<juliank> sitter: merge works for me, so I can push it to the main repo
 * juliank took the HEAD of https://github.com/apachelogger/python-apt - commit 8a619a70251abef6bf93524889a0221a1c2802e9
<juliank> https://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=6ce94b3
<infinity> juliank: You can probably stop trying to sync apt. :P
<infinity> juliank: (or read your email)
<juliank> infinity: There are no emails
<juliank> I thought it got lost somewhere in the databases
<infinity> juliank: Oh.  Really?  You should have gotten an email that it's in the unapproved queue.
<infinity> cjwatson: ^-- Does that not work for syncs, or is juliank's MTA hating on him?
<Laney> infinity: https://bugs.launchpad.net/launchpad/+bug/830614
<ubottu> Launchpad bug 830614 in Launchpad itself "Email not immediately sent for copied packages which end up in NEW" [Low,Triaged]
<Laney> s/NEW/queues/ :)
<juliank> Oh, now I see it in the launchpad web UI at least
<infinity> Laney: Oh, iz just a celery batch delay?
 * infinity reads the bug.
<juliank> I think I only looked at the new queue in there, and did not think about switching to the unapproved queue
<sitter> juliank: thanks :)
<infinity> That's a very uninformative bug.
<juliank> It also happens with the stable queues if you sync there,
<cjwatson> Just from the bug, that doesn't look like a celery delay, more that we simply don't send mail to the copier in that case.
<juliank> Yes, there is never any email.
<juliank> I sort of wanted to have final 1.3 in the beta, but I guess the beta will also survive without it
<infinity> juliank: I can perhaps slip it in.  But I assume there are no dire bugs in the current apt that make it necessary to do so, right?  Just a nice-to-have?
<infinity> juliank: Letting it into proposed, at least.  A britney block will keep it from migrating while we decide.
<juliank> Yeah. It basically changes the cache generator algorithm in one place a bit when hashing dependency lines to not skip dependency lines larger than 1024 chars (instead always read up to 1024 chars), and two other bugfixes.
<juliank> The changes are tiny bugfixes
 * infinity nods.
<infinity> And no tiny bugfix has ever gone wrong. :)
<juliank> At least my bugfix has full coverage
<juliank> the others happened before I added automated coverage testing
<infinity> juliank: Careful, you're in danger of turning apt into a professional software project.
<juliank> Automated coverage testing is nice, but it is a bit fluctuating  +/- 0.5% coverage
<juliank> for the same commit in the same CI environmenz
<juliank> Because gcov does not handle things very well if we are running multiple programs linked to the same library at the same time (like apt starting acquire methods, all of which are linked against coverage-test-emitting apt-pkg)
<cjwatson> Gah, whose idea was it to redefine scrollbars so that clicking below the active area of the bar now warps the bar to that location rather than doing page-down?
<cjwatson> Makes it very difficult to deal with deep scrolled regions such as the Firefox history pane.
<seb128> chrisccoulson, mardy, is that known/being worked on that adding a google account using ucc/uoa in yakkety the google webauth screen goes away/is white when trying to scroll down? is that on track to be fixed before release? (unsure if that's an oxide thing?)
<juliank> infinity: One thing I really should look at at some point is test speed - An apt CI run on travis currently takes about 40 minutes.
<juliank> I shall probably also move the 1.3.y series CI on shippable to test on yakkety rather than xenial
<juliank> And DonKult also runs tests on semaphore.
<seamlik> Hi everyone
<seamlik> The Gradle package seems to need a binary upload in Ubuntu
<seamlik> Gradle fails to launch and it builds with itself
<seamlik> Well I'm not a Ubuntu Developer, how can I solve this?
<chrisccoulson> seb128, I believe that's a Qt issue
<rbasak> seamlik: Ubuntu doesn't have binary uploads. Can you explain the real problem?
<seamlik> https://bugs.launchpad.net/ubuntu/+source/gradle/+bug/1622550
<ubottu> Launchpad bug 1622550 in gradle (Ubuntu) "Rebuild 2.13-4 Locally with JSch 0.1.53 and Do A Binary Upload" [High,New]
<seamlik> An update of JSch caused Gradle fails to launch, and I have fixed the FTBFS. But Gradle builds using Gradle, uploading a new version still FTBFS
<seamlik> In Debian we did a binary upload
<mardy> seb128: the fix was in qt, got backported by Mirv: bug 1613670
<ubottu> bug 1613670 in oxide-qt (Ubuntu) "Webview turns white after clicking on it" [High,Confirmed] https://launchpad.net/bugs/1613670
<rbasak> seamlik: so a build against gradle 2.13-4 doesn't work, right? How would you fix this locally?
<seamlik> I locally downgrade JSch to the previous version and built it
<rbasak> Sorry, I mean a build against gradle 2.13-3, because 2.13-4 isn't available because it FTBFS.
<rbasak> Which version of JSch works and which doesn't? Why does downgrading it solve the problem? I'm asking because an archive admin can do a bootstrap if required (given the instructions), but I don't really follow why this would be required.
<rbasak> Once gradle 2.13-4 is successfully built, will building it against gradle 2.13-4 and jsch 0.1.54-1 work?
<seamlik> jsch_0.1.53-1 works with Gradle, now it is 0.1.54-1
<seamlik> Gradle previously included the versioned classpath of jsch. So after it got updated, Gradle couldn't find the JAR to load
<rbasak> So 0.1.54-1 doesn't work with gradle?
<seamlik> No, it works with gradle >= 2.13-4
<rbasak> I guess what I'm asking is: is this a one-off bootstrapping problem? Or will rebuilding gradle 2.13-4 in Ubuntu once the problem is solved still fail, when building against gradle 2.13-4 and jsch 0.1.54-1?
<seamlik> Once rebuilding Gradle 2.13-4, jsch 0.1.54-1 would work
<seamlik> Yeah it's a bootstrap problem
<rbasak> OK, understood. Thank you for your patience.
<seamlik> Thanks
<rbasak> So in that case, I'd amend the bug to include bootstrap instructions for an Ubuntu archive admin.
<seamlik> How would you do the bootstrap?
<rbasak> It's done in a privileged PPA, then binary copied to the archive. Only an Ubuntu archive admin has the required permissions.
<seamlik> I see
<rbasak> You can subscribe ~ubuntu-archive to the bug once you have instructions ready. And this channel is the right place to ask if you're looking for one.
<rbasak> Long term, you might want to look into https://wiki.debian.org/BuildProfileSpec for an automated way to solve the bootstrap problem, if you want to implement that.
<seamlik> Hmm, I'm thinking of writing a bootstrapping script to build Gradle without Gradle, I was afraid if it will excceed Yakkety's freeze date
<dholbach> jdstrand, do you know why the click-reviewers-tools upload for 16.04 is still in -proposed?
<dholbach> (http://askubuntu.com/questions/809109 is how I found out)
<seamlik> DebianImportFreeze passed, it means no more update from Debian?
<rbasak> seamlik: we can still manually sync if the update meets freeze requirements.
<seamlik> rbasak: Actually there's not many instructions for rebuilding Gradle. Simply install jsch 0.1.53-1
<jdstrand> dholbach: the bugs aren't marked verification done. let me do that
<dholbach> oh, ok
<rbasak> seamlik: sure. Just make it absolutely clear in the bug what is required and what is going on, and you're likely to get it fixed faster (eliminate the need for an archive admin to ask questions)
<seamlik> So I can still get an update sync before FinalFreeze?
<seamlik> It would be very close :(
<rbasak> As long as you are only fixing bugs and not adding features, and you can find someone to sponsor a sync in time, then yes.
<seamlik> Thank you :)
<seb128> chrisccoulson, mardy, thanks ... need to nag Mirv for landing it then?
<Mirv> seb128: it was landed already, the qtbase version is in that bug
<seb128> Mirv, k, my iso is a week old, need to sync a new one I guess, thanks
<Mirv> seb128: correct, it's two days old now
<jdstrand> dholbach: ok, I verified them all
<dholbach> jdstrand, fantastic :)
<arges> cyphermox: hi. I have a new fix for shim/mokutil (bug 1600452) any problems if I upload? I see shim-signed still needs verification too
<ubottu> bug 1600452 in mokutil (Ubuntu Xenial) ""Failed to set variable: (2) Invalid Parameter" when enrolling MOK" [Medium,Confirmed] https://launchpad.net/bugs/1600452
<cyphermox> arges: please don't upload shim; I'll do that today or very soon
<cyphermox> it needs to be signed by Microsoft anyway
<arges> cyphermox: yea that's why figured I'd ask since its 'special'. I'll post a new yakkety patch to that bug soon then
<arges> and xenial
<cyphermox> can you apply your changes to lp:~ubuntu-core-dev/shim/trunk?
<jdstrand> pitti: hey, looking at click-reviewers-tools in pending-sru, there are two bugs that are golden but I think they should be green. bug #1584346 and bug #1595184
<ubottu> bug 1584346 in click-reviewers-tools (Ubuntu Xenial) "Store reports "package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks"" [Undecided,Fix committed] https://launchpad.net/bugs/1584346
<ubottu> bug 1595184 in click-reviewers-tools (Ubuntu Xenial) "tools do not handled abbreviated toplevel slots and plugs syntax correctly" [Undecided,Fix committed] https://launchpad.net/bugs/1595184
<arges> cyphermox: do a merge request to that branch then?
<cyphermox> arges: that said, I'm due to take a new snapshot so maybe we won't need the patches at all
<arges> cyphermox: its the first three patched on master: https://github.com/rhinstaller/shim/commits/master
<jdstrand> pitti: they look right to me. did I do something wrong?
<arges> patched/patches
<cyphermox> arges: ok
<pitti> jdstrand: hm, they actually are green on my version of http://people.canonical.com/~ubuntu-archive/pending-sru.html
<pitti> jdstrand: oh, you just set them to v-done recently, that explains it
<pitti> jdstrand: yep, so that can be published; are you going to, or want me to?
<jdstrand> pitti: ah, I did very recently, and one went green but two didn't, so I thought I did something wrong
<pitti> jdstrand: presumably just lag then
<jdstrand> pitti: I'm not on the sru team but am on the archive team. if you as a member of the archive team say it is ok for me to do so, I'm happy to
<jdstrand> err
<jdstrand> as a member of the sru team
<pitti> jdstrand: there are no policy decisions, just a quick spot-check on the bugs that the v-done is reasonable (i. e. not just added without any explanation)
<pitti> jdstrand: i. e. it's IMHO fine for archive admins to run sru-release; but if you aren't comfortable with that, I'm happy to run it too
<jdstrand> pitti: I'll do it. thanks!
<arges> cyphermox: should i just push to that trunk branch... or do another branch and do a MP?
<arges> for shim
<jdstrand> done
<jdstrand> dholbach: fyi ^
<dholbach> jdstrand, awesome - thanks!
<cyphermox> arges: up to you, but like I said I need some other patches from shim, I'm going to take a snapshot of master today hopefully (waiting for some other code merged)
<arges> cyphermox: k then i'll just leave it
<lamont> So I ran into this doing dist-upgrade on yakkety last week... thoughts?
<lamont> The following packages have unmet dependencies:
<lamont>  libubuntugestures5-gles : Conflicts: libubuntugestures5
<lamont>  libubuntumetrics5-gles : Conflicts: libubuntumetrics5
<lamont>  libubuntutoolkit5-gles : Conflicts: libubuntutoolkit5
<lamont> apt-get install --purge libubuntugestures5 libubuntumetrics5 libubuntutoolkit5 libubuntugestures5-gles- libubuntumetrics5-gles- libubuntutoolkit5-gles- qml-module-ubuntu-components-gles- qml-module-ubuntu-components
<lamont> I shouldn't have to do that
<lamont> OTOH, developer issue, since it seems to be a mid-yakkety thing
 * lamont notes that apt-get dist-ugprade still results in errors, even after all these years of me trying it.
<cjwatson> rbasak: Not necessarily in a privileged PPA, FWIW; I probably wouldn't bother with that for a smallish bootstrap.
<cjwatson> rbasak: The core mechanism is a highly-privileged API call that adds non-LP sources.list lines to a given build.
<rbasak> I see, thanks.
<mterry> doko, cyphermox: I'm not feeling super great, I may go lie down.  Can you two watch the MIR pipeline for any last minute approvals and such?
<juliank> sitter: Your python-apt commit causes a regression in the test suite on Ubuntu, in the PPA: https://launchpadlibrarian.net/285802879/buildlog_ubuntu-xenial-amd64.python-apt_1.1.0~beta5+982~ubuntu16.04.1_BUILDING.txt.gz
 * juliank only verified on Debian and thought sitter checked on Ubuntu...
<cyphermox> mterry: ack
<nacc> cpaelzer: ack, thanks, was just reviewing our existing bugs' states
<nacc> smoser: apt imported (it's pushing right now), usd-import updated
<smoser> nacc, as i've said before, its un-healthy how much i like the importer.
<nacc> rbasak: --^ if you'd like to review the usd-import changes when you get a chance -- i've tested them, but it's a bit of hairy code
<smoser> or at least how much i like the idea of version control availability of all packages at my finger tips.
<rbasak> nacc: sure. Where? In git master?
<nacc> rbasak: yep
 * rbasak looks
<nacc> smoser: apt import just finished/pushed
<nacc> smoser: and 100% agree -- it makes it really easy to 'see' a source package and its history (being able to `git blame`/`git annotate` is really handy)
<rbasak> nacc: minor nitpick. Instead of:
<Unit193> Would be nicer if it used d/changelog.
<rbasak> branch[len('%s-%s/' % (owner, pkgname)):]
<rbasak> I'd do branch.partition('%s-%s/' % (owner, pkgname))[2] if I understand you correctly. Less prone to error. Maybe even an assert to make sure.
<nacc> rbasak: hrm, are you sure you updated first? master shouldn't have a variable there
<nacc> rbasak: the point is valid
<nacc> but just making sure we're looking at the same tree
<rbasak> I'm looking at https://git.launchpad.net/usd-importer/commit/?id=dc27af24c7abfe9eaf6c51f63f6c47af076a414a
<rbasak> As I started from the diffs. If that's gone, then sorry :)
<nacc> ah ok :)
<nacc> yeah, it's gone in master:HEAD
<rbasak> I see. Sorry!
<nacc> local_head_name = branch[len(remote_name):]
<nacc> ok, so i see what you are saying, though
<nacc> basically, the remote's name will be '<remote>/<branch>', so i'm pulling off '<remote>/'
<nacc> ha, but you found a bug, fixing
<rbasak> :-P
<nacc> rbasak: ok, so partition() will treat the whole thing as the separator and return something like (None, input string, suffix) ?
<chiluk> pitti ... can you take a quick look-see at https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1626166  .... I'm still wrapping my head around systemd... I have a feeling the post-install needs to tell systemd to re-read it's config files and start the lvmetad service, but I'm not sure.
<ubottu> Launchpad bug 1626166 in lvm2 (Ubuntu) "lvm2 not starting lvm2-lvmetad on package install" [Undecided,New]
<nacc> rbasak: http://paste.ubuntu.com/23211888/
<nacc> Unit193: was that referred to me?
<nacc> Unit193: it effectively does, but by publish rather than changelog
<rbasak> nacc: or even:
<nacc> Unit193: presuming good uploads, they correlate -- let's just say that's not always the case :)
<rbasak> prefix = '%s/' % remote_name
<rbasak> _, prefix, local_head_name = branch.partition(prefix)
<rbasak> assert prefix == prefix
<rbasak> I made a mistake there, but YSWIM :)
<nacc> yep, good call
<nacc> http://paste.ubuntu.com/23211898/
<rbasak> Yes, thanks :)
<rbasak> nacc: in clean_repository_state, I'm not sure about using subprocess.run like that. If stdout is a pipe that isn't connected up, the command could block on writing to stdout, no?
<rbasak> I would either not set it, or make and use a fileobj pointing to /dev/null if you want that behaviour.
<nacc> ack it should be unset, sorry, c&p
<rbasak> Incidentally, I usually use subprocess.check_call, rather than subprocess.run, check=True. No strong opinon.
<rbasak> Style-wise, maybe drop the "cp =" if you never use cp?
<pitti> chiluk: replied with initial analysis
<nacc> rbasak: thanks, all fixed
<nacc> rbasak: and now consistent, cp only present if used
<nacc> rbasak: pushed and rebuilding the snap
<nacc> rbasak: feel free to give me more changes, though :)
<chiluk> thanks pitti.. sorry I couldn't look more closely yet, but I'm helping vet the training classes right now.
<chiluk> and it was discovered through that.
<pitti> chiluk: same here, not much time right now; but that's an exercise in debugging debian/rules and the debhelper script essentially
<chiluk> yeah..
<nacc> rbasak: brb, rebooting
<chiluk> alright well at least the bug is open, and not immediately obvious.
<nacc> hrm, i wonder if 'Cannot enable. Maybe the USB cable is bad?' could be ratelimited in 4.8 :) about to fill up my dmesg, i fear
<nacc> also, seems to be a regression...
<barry> pitti: hi.  doko pointed out that python-virtualenv has been failing autopkgtest, on a gcc problem.  he thinks it's a missing test dep on gcc or build-essential, which seems possible though i need to test that.  it started failing on 2016-08-26 but passed for long before that.  the package didn't change.  can you think of anything in the test infra that may have broken this?
<barry> http://autopkgtest.ubuntu.com/packages/p/python-virtualenv/yakkety/amd64
<rbasak> nacc: I'm not keen on the double nested FileNotFoundError handling when trying alternate paths. I would maybe make an open_any([path, path...], *args, **kwargs) function that iterates instead.
<barry> pitti: if that's all it is (a missing dep) it should be an easy fix.  i'd just like to know *why* it suddenly started failing ;)
<nacc> rbasak: ack, was mostly to get it working, i hate that too :)
<nacc> rbasak: thansk for the suggestion, i wasn't sure what the pythonic way would be
<rbasak> Sure, I understand that the initial version is always very hacky :)
<rbasak> "use separate fetch and push urls" -- I like this.
<nacc> yeah, it's cleaner, for sure -- but i also found it to be necessary with pygit2 :)
<rbasak> What does "squash" in the subject of ec9c102 mean?
<nacc> bah!, i did squash (another commit) in, but forgot to change the line
<rbasak> I appreciate the commit message in 7533678 BTW. Nicely put.
<nacc> heh, now it's part of history
<rbasak> :-)
<rbasak> nacc: OK, I'm done with a cursory look. I haven't looked deep enough to find bugs or anything, but in principle I think everything looks fine. Thank you :)
<nacc> rbasak: cool, thanks for the review, cursory or otherwise!
<doko> mterry, cyphermox: afk now. I'll see if I can do some when I'm back tonight
<nacc> rbasak: something like http://paste.ubuntu.com/23212105/
<rbasak> nacc: yes. Though you forgot to chain *args and **kwargs.
<nacc> rbasak: uh, right! :)
<rbasak> nacc: and do you need f.close() if in the context manager?
<rbasak> nacc: and a double indent on 71/72 if I'm reading the patch correctly.
<nacc> rbasak: i wasn't sure if it was tied to the context of open() itself -- i'll dig into it and see
<rbasak> nacc: also I think you used the same (old) pattern in another place that might be worth updating.
<nacc> rbasak: yep, doing that too
<doko> $ dpkg -L python-ldb-dev
<doko> /${DEB_PY2_INCDIR}/pyldb.h
<doko> nice ...
<nacc> rbasak: http://paste.ubuntu.com/23212139/
<rcj> infinity, cjwatson, wgrant: question regarding a current livecd-rootfs question. I have a build which seems to be looping.
<rcj> https://launchpad.net/~cloudware/+livefs/ubuntu/xenial/cpc-development/+build/76111
<rcj> I'm grabbing snippets of the buildlog as it runs
<cjwatson> rcj: I think it must be crashing the builder somehow.
<cjwatson> rcj: All the Launchpad buildd-manager side sees is "twisted.internet.defer.CancelledError" which basically means that it lost communication with the builder
<cjwatson> rcj: We don't have more logs than that, though.
<cjwatson> seamlik: Done.
<rbasak> nacc: looks good
<rcj> cjwatson, is this the end of a build or the beginning of another loop? http://paste.ubuntu.com/23212225/
<rcj> I ask because we've hit the end of our hooks without error if I'm correct that the above paste is at the end of a build
<cjwatson> rcj: near the end, I think
<cjwatson> rcj: it's possible something goes wrong if you cause it to fail to emit a livefs
<cjwatson> not exactly certain, but I think it is likely that hitting the end of your hooks doesn't exonerate your code :-)
<rcj> cjwatson, I thought we were at the end.  This is our basic cloud build plus an new binary output that I'm developing.  So we shouldn't have less than when it was working
<rcj> cjwatson, :)
<rcj> cjwatson, tips on debugging (or running this locally?)
<pitti> barry: hey, how are y ou?
<pitti> barry: doko and I are wondering about the python-virtualenv regression (http://autopkgtest.ubuntu.com/packages/python-virtualenv/yakkety/amd64)
<pitti> barry: it seems while it passed, it downlaoded some "world" tarball from somewhere:
<pitti>   Downloading world-3.1.1-py2.py3-none-any.whl
<pitti> Successfully installed world-3.1.1
<pitti> it originates from ITALY
<pitti> barry: now it says "Downloading world-4.0.tar.gz" ... "Python 3.4.0 or better is required"
<pitti> barry: and it apparently falls back to trying to build it itself, but it's missing gcc and python[3]-dev for that
<pitti> barry: so it seems some external resource changed -- which is confirmed by the test in xenial now also breaking; does that make sense?
<pitti> barry: so IMHO virtualenv should Recommends: gcc, python*-dev, and the test should add needs-recommends; WDYT?
<cjwatson> rcj: It's not quite at the end, since launchpad-buildd has to gather the results of the build and send them back; and there's also some livecd-rootfs stuff that happens after that.
<cjwatson> rcj: This may be fairly laborious to debug.  I'd probably start by doing the equivalent of https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html
<cjwatson> (figure out the slight setup differences for building from your PPA)
<rcj> cjwatson, thank you for the pointer
<rcj> I can do that.
<pitti> barry: same on https://ci.debian.net/packages/p/python-virtualenv/unstable/amd64/
<pitti> doko, barry: filed as bug 1626201 so that I have something to refer to for britney overrides; but it's IMHO an actual packaging bug, not (just) a test bug
<ubottu> bug 1626201 in python-virtualenv (Ubuntu Xenial) "missing python*-dev and gcc dependencies" [Undecided,New] https://launchpad.net/bugs/1626201
<barry> pitti: hi!  doing good modulo nasty jetlag ;)  no, it's just a test dep missing since the package builds fine and doesn't need world to run.  but i think i know why that's "suddenly" failed though.  world 4.0 uses atpublic which does have a C component now.  it's an easy fix and i'll upload that to debian today and sync it over to yakkety.  for xenial, it probably should either just get ignored or we can do a quick sru.  it doesn't
<barry> affect the operation of the package at all
<nacc> barry: pythonic question for you -- for the importer, if i invoke it via ./usd-import  and then later want to do file-based lookups based upon a set of paths (including the path the importer itself lives in), is there a way for me to access the absolute path? I do some chdir'g now, so what I'm seeing is that './usd-import' gets interpreted according to the 'current' value of '.', which is fully sane,
<nacc> but not what I want. Would the pythonic way be to save off the original absolute path?
<barry> pitti, doko https://bugs.launchpad.net/ubuntu/+source/python-virtualenv/+bug/1626201/comments/3
<ubottu> Launchpad bug 1626201 in python-virtualenv (Ubuntu) "missing python*-dev and gcc dependencies" [Undecided,In progress]
<barry> nacc: hi.  i'm not sure i fully understand the question.  what does "file-based lookups" mean?
<nacc> barry: so we've got a few files that are used to override some behavior, and then one of those files includes some paths in it (local patches to apply). So if i run without any arguments, i'd like the importer to search for a specific filename in either the current directory or the directory the importer lives in
<barry> nacc: can you point to the code where you do this?  (i have an up-to-date checkout of the git repo)
<nacc> barry: yeah, one sec
<nacc> barry: i'm in the process of cleaning it up right now, but ll. 419-469 currently
<nacc> it doesnt' work for ./usd-import as-is, for the reasons mentioned above
<nacc> but does work for /path/to/usd-import
<barry> nacc: sorry, more questions :)  are those files in the source tree our outside of it?
<barry> *or outside
<nacc> barry: np
<nacc> barry: i'm realizing the logic is wrong, but this is what i want to do :)
<nacc> 1) if specified ont he commandline, use that specific file, or error out
<nacc> 2) if not specified on the commandline, search the importer script's dirpath for the appropriately named file (parent_overides.txt, e.g.) else error out
<barry> nacc: gotcha.  there's a Right Way, but it'll probably force a bit of a reorg of the importer ;)  i can describe that first and then if that's too much, we can talk about workarounds
<nacc> barry: great!
<barry> nacc: so, the right way is to use pkg_resources
<nacc> i'm reorging this code anyways to consolidate it, so that's fine
 * barry looks for links
<barry> https://setuptools.readthedocs.io/en/latest/pkg_resources.html
<barry> there's a lot there, but you don't need most of it
<barry> nacc: the critical bit to this is that you really want usd-importer to be a stub (more on that in a moment) that does little else than import a main() from a submodule and run it
<barry> nacc: meaning you really want to put all of the python code in usd-import inside a package
<barry> nacc: and inside that package directory you'd put parent_overrides.txt
<barry> (sometimes we have that inside a subpackage like usd_import.data or some such)
<barry> nacc: then it would be totally unambiguous to do this:
<barry> overrides = pkg_resources.resource_filename('usd_importer.data', 'parent_overrides.txt')
<nacc> ah ha!
<nacc> barry: excellent, that does make sesne
<barry> there are a few other useful apis in pkg_resources, such as resource_string()
<barry> but that actually returns bytes in py3 :0
<barry> :)
<barry> nacc: cool!  if that's enough to go on, excellent.  if not, ping me and i'll happily help
<nacc> barry: yep, for sure! i'll tool around with this now!
<barry> nacc: \o/
<barry> nacc: just one other small thing: even though pkg_resources comes in setuptools upstream, in debuntu we split that into separate binary packages
<nacc> got it
<doko> barry, what is the "version of world"?
<barry> doko: it's just a package that the dep-8 test suite tries to install in the virtualenv to prove that it works
<barry> *install and invoke
<barry> the change pins it to v3 which doesn't require any C (via dependencies)
<nacc> barry: many many thanks! I think i got the reorg done and pkg_resources are dtrt!
<barry> nacc: awesome!  yeah, many of us have wanted pkg_resources (or something like it) in the stdlib, but It's Complicated.
<nacc> totally understood, but it was pretty easy to use once i reorged
<nacc> and it's passed my testing with and without '.', so pusehd to master
<barry> cool
<doomwake> http://pastebin.com/cBG4UuCx
<doomwake> [15:50] > libvirtd is getting stuck on creating a network id do you know how to force it on?
<cjwatson> rcj: Your problem may have just been buildd-manager being randomly confused on our side; I got it restarted and another livefs build that had been showing similar weird symptoms now passes
<cjwatson> rcj: So you may want to just retry - hope this hasn't wasted too much of your time :-/
<rcj> cjwatson, thanks for the update.  I will retry
<rcj> cjwatson, it's not all wasted.  I have a script that fires up a VM, imports by private PPA, and prepares the environment to run our livecd-rootfs.  That's pretty good.
<cjwatson> Cute.
<cjwatson> No doubt handy at some point.
<rcj> image recipe iterations will be much faster as we won't need to wait for a build recipe to publish our funky livecd-rootfs
<nacc> fun, spinning up an sbuild on the 4.8 kernel led to a 222 load average for a moment
<nacc> even though all my cpus are idle, it seems like
<nacc> now i'm up to 330
<nacc> feels like a bug :)
<sarnold> make -j is fun :)
<nacc> it's not even that
<nacc> there are no running tasks, but it goes all kinds of laggy and the load calculation is fubar
<nacc> it's only using one cpu (afaict)
<nacc> well, it's coming back down again now that's done setting up the sbuild
<nacc> *schroot
<rcj> cjwatson, xenial builds are fine but my yakkety lb build dies in lp_binary_zsync because it can't find zsync to install.  That's in universe. Is there a trick to get that in the chroot?
<cjwatson> rcj: It's in universe in xenial as well ...
<cjwatson> rcj: Sounds like maybe your yakkety build is configured to only use main?
<rcj> cjwatson, yeah, nm, universe is configured once I looked in /build/chroot/etc/apt/sources.list
<rcj> cjwatson, and it's correct that this http://paste.ubuntu.com/23213541/ is running in the context of that apt sources.list, right
<cjwatson> rcj: Err, there might be a few different contexts involved, not entirely sure.  It's been ages since I messed with this stuff ...
<cjwatson> rcj: Also, I don't think we normally have lb build zsync control files, so maybe your problem is actually that that's turned on when it shouldn't be?
<cjwatson> rcj: Maybe I'm misremembering though.  I'd suggest comparing build logs against the stock ones.
<rcj> cjwatson, sounds good
<rcj> I'm running that now
<rcj> cjwatson, no idea, lb_binary_zsync works in production for us, so my local env is not so good yet http://paste.ubuntu.com/23212225/
<cjwatson> Mm, not sure, sorry!
#ubuntu-devel 2016-09-22
 * mwhudson looks sceptically at dh_systemd_enable
<mwhudson> blargh, docker.socket doesn't start at all on arm64 and docker startup hangs on 16.04
<mwhudson> SRU verification going great
<mwhudson> oh wait docker is in NEW on amd64
<seamlik> cjwatson: Thanks for dealing with Gradle's FTBFS! :)
<mwhudson> so today i found that mongodb 3.2.10~rc1 ftbfs everywhere except ppc64el (!?) and that the docker in xenial-proposed is broken
<mwhudson> sounds like a good time to stop for a bit...
<pitti> barry: I still wonder whether gcc+python-dev shouldn't still be proper depends instead of just test-depends
<pitti> barry: don't we want to move to world-4.0 long-term? pinning it to the older version for python2 seems ok, but the < 4.0 ones will get obsolete at some point?
<pitti> Good morning
<pitti> infinity: oh nice, glibc is green again (after the hostname.. fix)
<doko> wgrant: thanks! results were better in the past, still a lot to fix :-/
<pitti> apw: is it just on my box, or is 4.8 awfully slow at boot? it's no step in particular, everything seems evenly smeared out (dmesg boot timestamps go up to 39s)
<pitti> (ThinkPad x230)
<pitti> meh, brightness change is broken as well
 * pitti will file bugs in a bit
<doko> pitti: brightness change works here, but it's a lot delayed after typing (x250)
<doko> 87 ftbfs in main alone, and armhf and arm64 not yet tested. http://ubuntuqa.tblwd.org/ftbfs/test-rebuild-20160916-yakkety.html
<sarnold> pitti: nacc reported insane load averages with sbuild
<pitti> sarnold: trying that here
<pitti> sarnold: reported in LP already, or just on IRC?
<sarnold> pitti: afaik only on IRC
<pitti> load average: 249,08, 79,27, 34,43
<pitti> holy crap
<sarnold> hah, that's 27 better! he reported 222
<pitti> sarnold: that smells more like a simple numeric problem, though -- the machine doesn't actually "feel" slow and laggy
<pitti> I'll compare sbuild times with 4.4 and 4.8
<sarnold> interesting; he reported "all kinds of laggy"
<pitti> sarnold: well, I've only run it for like 10 minutes
<pitti> I just noticed that boot feels like Pentium with slow spinning rust
<sarnold> ouch :)
 * sarnold hands pitti fvwm1
<pitti> sarnold: well, i3 here, but that actually doesn't seem to be the problem :) it's everything *up to* lightdm, i. e. you can conveniently read every starting service line (without "quiet" and "splash")
<pitti> instead of them just zipping by
<sarnold> wow :)
<pitti> Build needed 00:00:00, 0k disc space
<pitti> err, thanks sbuild
<pitti> I suppose this also used something that broke with 4.8..
<sarnold> and you said it was slow.. :)
<pitti> heh
<pitti> also, *very* efficient RAM compression!
<sarnold> :D
<pitti> sarnold: so, sbuilding color under 4.4 and 4.8 both took about 7'30'', no real difference there
<sarnold> pitti: and how'd the feel interactively?
<pitti> nothing noticeable
<pitti> it's booting that sucks, so maybe setting up cgroups or non-compiler parallelism, not sure
<pitti> sarnold: actually, it's 6'30'' (4.4) vs. 7'30'' (4.8), I just can't do math this morning yet
<StevenK> The coffee drip isn't attached yet?
<pitti> StevenK: yeah, no tea IV :)
<doko> apw: libecap breaks with new kernel headers
<apw> bah
<apw> doko, where can i see that
<mwhudson> pitti: hey
<mwhudson> pitti: i have a package (docker.io) that fails to start its socket on xenial but it works on yakkety
<doko> apw: sorry, http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html. so we will see this for universe only, because the main part of the test rebuild was finished when 4.8 was uploaded
<mwhudson> pitti: do you know of anything in this neighbourhood that's changed xenial->yakkety?
<seb128> doko, hey, would it help with the component mismatch view to change MIR bugs from previously promoted then demoted components back to fix commited to they are yellow on the svg?
<apw> doko, ok ta
<pitti> apw: filed as bug 1626429 and bug 1626436 FTR
<ubottu> bug 1626429 in linux (Ubuntu) "[4.8 regression][ThinkPad X230] brightness change keys do not work any more" [Undecided,Confirmed] https://launchpad.net/bugs/1626429
<ubottu> bug 1626436 in linux (Ubuntu) "[4.8 regression] boot has become very slow" [Undecided,New] https://launchpad.net/bugs/1626436
<pitti> mwhudson: you mean during package installation?
<mwhudson> pitti: yes
<doko> seb128: sure, but would be nice to leave a comment in the issue
<seb128> doko, k, let me do that
<pitti> mwhudson: I saw bug 1626166 yesterday; my suspicion is that this was some fix in dh_systemd_start
<ubottu> bug 1626166 in lvm2 (Ubuntu Xenial) "lvm2 not starting lvm2-lvmetad on package install" [Undecided,Triaged] https://launchpad.net/bugs/1626166
<doko> seb128: or ask pitti to mark those with a different color =)
<mwhudson> pitti: yeah that looks pretty similar
<mwhudson> pitti: i don't think it's a dh_systemd thing though because the postinsts in the yakkety and xenial packages are ~the same
<seb128> doko, that would be even better ;-)
<pitti> mwhudson: I did notice that the .socket wasn't  actually started in the postinst; that seemed to be the obvious missing thing?
<mwhudson> pitti: the docker.socket file is enabled (i.e. /etc/systemd/system/sockets.target.wants/docker.socket exists)
<pitti> mwhudson: yes, enabled is fine, but that only applies to the next boot
<mwhudson> pitti: postinst says "deb-systemd-helper enable docker.socket >/dev/null || true"
<pitti> enabling and starting are two different and independent things
<mwhudson> is that right?
<mwhudson> ah ok
<mwhudson> but it works in yakkety...
<pitti> mwhudson: hmm, maybe daemon-reload now automatically starts enabled sockets
<mwhudson> pitti: that would definitely explain it
<pitti> mwhudson: (just a wild guess, I'm not aware of that and it  shouldn't actually be that way)
<pitti> mwhudson: and I'd also avoid relying on it, so a "dh_systemd_start foo.socket" sounds prudent?
<mwhudson> pitti: how do dh_installinit and dh_systemd_* interact?
 * mwhudson hopes s_langasek is asleep before asking that question
<pitti> mwhudson: the latter basically handles everything that is not a .service; like sockets, timers, targets, etc.
<pitti> mwhudson: and yes, having two different things is a mess :)
 * mwhudson tries to figure out where docker.socket even comes from
<pitti> mwhudson: you can of course also just use dh_installinit and start the .service directly
<pitti> doesn't matter much then if the .socket isn't running
<pitti> (but that's not really the point of setting up socket activation)
<mwhudson> that's what the current docker package in xenial-updates does (although, again, i don't quite understand what the package is doing to achieve this...)
<mwhudson> oh, upstream
<alkisg> To make my own repository packages display in gnome-software, do I need to add appstream metadata to it? I'm currently using reprepro, are there any tools that can help me with that?
<alkisg> And, do PPAs already handle this?
<mwhudson> (the socket, not the starting the service on install)
<mwhudson> hmm
<mwhudson> pitti: is it fair to say that if you override dh_installinit, you're going to want to override dh_systemd_enable too?
<pitti> mwhudson: not really, no; it really depends on what kind of units you ship
<pitti> if you only ship a SysV init plus .service pair, dh_installinit is enouguh
<pitti> (you don't even need dh_systemd_*)
<pitti> but if you only ship systemd units and you need a .socket, then you don't need dh_installinit
<mwhudson> the dh_installinit override is to set --name
 * mwhudson is having a 'surprised this ever worked' moment
<pitti> mwhudson: oh, do you ship a debian/foo.socket?
<mwhudson> pitti: yes
<mwhudson> uh
<mwhudson> no
<mwhudson> sorry
<mwhudson> docker.io.install installs a docker.socket file from the upstream source
<pitti> also, no, debian/*.socket has been handled since 2013 already
<mwhudson> the packaging change that must be at fault here
<pitti> i-s-h added handling for debian/*.path not too long ago
<mwhudson> is that docker 1.11 used the .install file to install the .service file
<mwhudson> but 1.12 does this:
<mwhudson> (xenial *)mwhudson@aeglos:/opt/opensource/deb/docker/debian-docker$ ls -l debian/*.service
<mwhudson> lrwxrwxrwx 1 mwhudson mwhudson 38 Sep  7 14:40 debian/docker.io.docker.service -> ../contrib/init/systemd/docker.service
<mardy> seb128: hi! Is bug 1587282 fine, or do I need to do something else to push it forward?
<ubottu> bug 1587282 in account-plugins (Ubuntu) "create online-account plugin for cmcc mcloud" [Undecided,Triaged] https://launchpad.net/bugs/1587282
<doko> Mirv: could you have a look at https://bugs.launchpad.net/ubuntu/+source/qtchooser/+bug/1626469 ? or tell me who should?
<ubottu> Launchpad bug 1626469 in qtchooser (Ubuntu) "qdoc doesn't work, causes other packages fail to build" [High,Confirmed]
<pitti> doko, barry: filed debian bug 838559 and force-badtested python-pex, FYI; so setuptools should land now (after beta freeze)
<ubottu> Debian bug 838559 in python-pex "python-pex: tests started to fail on "Connection refused"" [Normal,Open] http://bugs.debian.org/838559
<Mirv> doko: outdated build dependencies in those packages, mostly packages that haven't seen recent maintenance since many were updated. updated the bug report.
<doko> Mirv: ta
<directhex> i can't debootstrap precise today :/
<xnox> pitti, will there be a matching release of util-linux for the v4.8 kernel? and will we get it? there is new things exposed in proc on s390x for lscpu to parse.
<xnox> and i'm pondering if it's worth cherrypicking 9 commits into yakkety, wait for new util-linux release, or just forget about it until z-series
<xnox> directhex, from yakkety host?
<directhex> xnox: good guess
<pitti> xnox: we have the latest upstream release (2.28.2); not sure if kzak wants to do another one soon
<pitti> xnox: so if you want it in y, backporting it is
<xnox> directhex, is http://launchpadlibrarian.net/285357737/ubuntu-keyring_2016.09.01_2016.09.19.diff.gz at fault?
<xnox> pitti, well 2.28.2 is point release from the v2.28 branch. I want june cherrypicks from master =/
<xnox> directhex, does $ sudo rm -f /etc/apt/trusted.gpg.d/ubuntu-keyring-*.gpg; sudo apt-key update
<xnox> get you back into a state that allows you to bootstrap precise?
<directhex> xnox: it complains about downloading linux-libc-dev, let me just crank up verbosity
<xnox> ah
<directhex> and maybe try another mirror
<xnox> if it's downloading things, everything is ok w.r.t. keyring =)
<xnox> pitti, cherrypicks don't look too bad http://paste.ubuntu.com/23215380/
<pitti> xnox: ok; but please always put cherry-picks at the top of the series
<xnox> oh, ok.
<pitti> avoids adjusting upstream patches to downstream ones, it should be the other way aroudn (less noise and easier to upgrade to the next version)
<seb128> mardy, looks fine so you can land the silo now
<mardy> Mirv: ^
<Mirv> mardy: ok!
<caribou> Has someone found a fix for LP: #1621269 or moving /var/lib/sbuild/apt-keys out of the way a valid workaround ?
<ubottu> Launchpad bug 1621269 in sbuild (Ubuntu Xenial) "not possible to build yakkety packages because of gpg changes" [High,Triaged] https://launchpad.net/bugs/1621269
<doko> seb128: one more thing, could you check if the packages still build, see http://qa.ubuntuwire.org/ftbfs/test-rebuild-20160916-yakkety.html. if it's not yet built, please ping me so that I can raise the priority
<seb128> doko, ok, sure
<mardy> Mirv: is https://bileto.ubuntu.com/#/ticket/1497 going to land now, or does it need some more acks?
<acheronuk> hi. how often does this update please? http://qa.ubuntuwire.org/ftbfs/
<Mirv> mardy: it "is" landed but we have some trouble that yakkety stuff goes to /dev/null, instead of the UNAPPROVED queue it should be going to
<Mirv> mardy: so therefore it's landed for vivid and xenial but not to yakkety even though publish action was done
<xnox> caribou, i just had missing crc32c module on s390x in the d-i udeba
<xnox> caribou, somehow, it is needed to e.g. mount ext4 filesystems.
<xnox> caribou, given the bug on ppc64el side, i guess it affects s390x too?
<caribou> xnox: could be, I don't have the crc32 issue on amd64; but the makedumpfile issue remains
<caribou> xnox: do you have an LP number for this one ?
<xnox> caribou, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1625728
<ubottu> Launchpad bug 1625728 in linux (Ubuntu Yakkety) "fails to mount ext4 due to missing crypto-crc32 modules in the udeb" [Critical,Fix released]
<caribou> xnox: thanks!
<barry> pitti: thanks.  i did look at this briefly yesterday and it was passing locally for me, but it seems like you can reproduce it, so i'll look in more detail
<caribou> xnox: is the fix for that bug generic to all architectures, or only for s390x ?
<pitti> barry: wow; it fails in Debian CI, in Ubuntu CI, locally  with qemu, lxd, schroot -- what  kind of black magic did you do? :-)
<pitti> barry: (note that just exercise.sh fails, the other three tests are fine)
<barry> pitti: yep.  and yeah, i don't know.  "lucky" i guess
<pitti> apw, cyphermox: do you know how I can debug bug 1626568? i. e. missing kernel symbols on insmod?
<ubottu> bug 1626568 in network-manager (Ubuntu) "rfkill autopkgtests broken with linux 4.8: fake-rfkill.ko: Unknown symbol in module" [Undecided,New] https://launchpad.net/bugs/1626568
<apw> pitti, is that making up its own out-of-tree module ?  or using something we are supplying
<pitti> apw: nope, it's https://git.launchpad.net/~network-manager/network-manager/+git/ubuntu/tree/debian/tests/fake-rfkill.c
<pitti> apw: just a fake module to test NM's rfkill handling, for nonexisting hardware
<pitti> ooh! typical again -- "sudo modprobe rfkill" does it
<pitti> typical: find the solution *after* asking on IRC
<apw> pitti, right so an oot module being compiled against the kernel headers ?
<pitti> apw: correct
<apw> pitti, so likely a straight porting issue
<pitti> so far that test has worked without the modprobe; so maybe rfkill went from "builtin" to "module", or fake-rfkill.c fails to declare a dependency?
<apw> pitti, as in those changed named in the kernel
<apw> or they are not exported or something
<pitti> apw: nope, modprobe rfkill -> then that insmod works fine
<pitti> now, is insmod supposed to load module dependencies? i. e. is that a problem of using insmod, or a bug in fake-rfkill.c by not declaring its dependencies?
<apw> nope, that is a moprobe thing, and you would need to install it in the right place and depmod to sort that i think
<pitti> apw: so somehow rfkill was already loaded with <= 4.4,  or builtin, I  suppose
<pitti> $ modinfo debian/tests/fake-rfkill.ko
<pitti> depends:        rfkill
<pitti> ok, so just b/c using insmod instead of modprobe
<apw> pitti, may have been builtin indeed
<apw> if we can switch you to modprobe and win, life would be good
<pitti> apw: oh, absolutely; this is *not* a kernel bug, just me being a kernel n00b :)
<apw> or at least use modinfo and rip the depends: out and manually insmod them
<pitti> just trying to re-fix that test
<apw> pitti, i've marked it up as related to kernel-4.8 regardless, as it is work and fallout from this
<pitti> apw: one can call modprobe with a file these days, that ought to load it (testing now)
<pitti> apw: thanks, I have a handle on this now
<pitti> sorry for the noise
<pitti> but it would probably have taken me ages without embarrassing myself on IRC :)
<pitti> ah no, no modprobe on a path
<apw> pitti, hey ... this is why we have these things ... to get things sorted without people wasting their lives refinding the world
<apw> damit
<apw> you could drop the .ko into /updates the dkms place
<apw> and dep mod, or use the modinfo output
<apw> modinfo rfkill.ko | awk '/^depends:/ { print $2 }'
<pitti> $ sudo modprobe `modinfo debian/tests/fake-rfkill.ko | sed -n '/depends:/ {s/^.*://; p}'`
<apw> or something
<pitti> apw: ^ poor man's modprobe-on-a-file :)
<apw> yeah, la la la, but yes
<apw> rmemeber to modprobe fake-rfkill.ko as well
<pitti> (insmod)
<apw> that
<pitti> killswitches-no-urfkill PASS
<pitti> take THAT
<davmor2> pitti: oh please don't inflict their music on us
<pitti> davmor2: I have two sisters; guess what always came through TWO walls when we've been teenagers :)
<davmor2> pitti: Bros
<apw> pitti, you wern't the brother sandwich were you ... i feel for you
<davmor2> no no wait I got it nirvana
<pitti> apw: no, youngest
<pitti> apw: anyway, tests are happy again, pushed the fix
<apw> pitti, yay ... thanks
<pitti> and it seems two out of three clouds behave again as well *phew*
<pitti> hatethisdayhatethisday
<pitti> but it's not like we have a beta anytime soon, so 'sallgood
<apw> pitti, no rush :/
<davmor2> pitti: boyzone, new kidz on the block, take that and westlife and Rick Astley as you got rickrolled ;) just count yourself lucky if it was nowadays it would all be beiber
<slangasek> mwhudson: better not to hope such things out loud if what you want is me to not notice the question ;)
<barry> pitti: this pex thing is really hurting my brain.  first it fails locally, then it doesn't and once it stops failing locally i can't reproduce it again (locally).
<pitti> barry: hm, so what is it actually trying to do when connecting to the network?
<pitti> barry: am I right that these proxy vars are meant to intercept/forbid exaclty that?
<barry> pitti: yes exactly.  it *shouldn't* try to hit the net for any modules it can resolve locally, and that's exactly why it uses textwrap (a stdlib module).  what i think is happening when it fails is that it wants the requests library.  so i add that to Depends and then it stops failing.  problem solved, right?  no, if i then *remove* that dep, it continues to not fail, even though i'm building all this in clean sid chroots each time
<bdmurray> mvo: Could you have a look at bug 1602536? I think its just unlucky timing.
<ubottu> bug 1602536 in unattended-upgrades (Ubuntu) "/usr/bin/unattended-upgrade:apt.cache.LockFailedException:/usr/bin/unattended-upgrade@1468:main:do_auto_remove:cache_commit:commit:_fetch_archives" [High,Confirmed] https://launchpad.net/bugs/1602536
<mvo> bdmurray: yes, I think that is it
<bdmurray> mvo: we could just stop the crash from getting to LP then, sound reasonable?
<mvo> bdmurray: yeah, I think ideally it just should retry
<mvo> bdmurray: instead of crashing
<bdmurray> mvo: Ah, you mean retry before the next cron run?
<mvo> bdmurray: yeah, just a small 30sec wait and then retry to acquire the lock
<bdmurray> mvo: Do you have time to do that?
<mvo> bdmurray: its a bit tricky, I can try to squeeze some time in tomorrow moring for u-u, looks like there are two issues worth fixing
<barry> pitti: i think i figured it out
<seb128> Mirv, mardy, chrisccoulson, k, so on current daily when trying to add a google account from ucc->uoa the view doesn't empty anymore when scrolling but it does when trying to click on the text entry, not much better since you still can't enter your login info :-/
<pitti> cyphermox: ubuntu-drivers has no PK/dbus service etc. at all -- it basically just figures out what to install with some poking in /sys and calls apt-get install
<pitti> cyphermox: so that shoudl already be called by a root process
<cyphermox> well, I don't know how it's called, but if it's started by ubiquity directly, it's probably not run as root
<cyphermox> unless there is some other priv escalation steps taken beforehand
<cyphermox> oh, maybe it is done as root after all
<pitti> cyphermox: why would ubiquity not run as root?
<cyphermox> still, there's definitely another issue with the permissions given the crash I see in trying to drive NM
<pitti> davmor2: do you still have the syslog for bug 1626108?
<ubottu> bug 1626108 in ubiquity (Ubuntu) "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,New] https://launchpad.net/bugs/1626108
<davmor2> pitti: no but I can get you one in about 10 minutes
<davmor2> pitti: do you want syslog from broken live session, syslog from an installed system, or syslog from the installer on the installed system?
<pitti> davmor2: broken live session should suffice already
<davmor2> pitti: no worries give me 5 then
<nacc> slangasek: is there a update-maintainer equivalent that would update the VCS-* field to XS-Debian-Vcs-? Would it be worth adding a tool to ubuntu-dev-tools to do that?
<pitti> xnox, barry: FYI: https://ci.debian.net/data/britney/failing.txt
<davmor2> pitti: added to the bug
<davmor2> that is taken on the slide right after the 3rd party drivers are normally installed
<slangasek> nacc: not that I know of
<davmor2> pitti: I've left the system in that state incase you need anything else
<rtg> pitti, regarding bug #1626394, is it sufficient to set CONFIG_ATA=y for amd64 ? Setting that also pulls in the SCSI stack. Is it _really_ required for a systemd test ?
<ubottu> bug 1626394 in linux (Ubuntu) "4.8 dropped CONFIG_ATA=y (breaks systemd's TEST-08-ISSUE-2730 upstream test)" [Critical,Confirmed] https://launchpad.net/bugs/1626394
<pitti> davmor2: cheers!
<nacc> slangasek: ok, i'll see if it's something easy to add, it is a useful tool for our merge process (we already recommend update-maintainer for that part)
<nacc> rbasak: --^
<pitti> davmor2, cyphermox, slangasek: followed up to bug 1626108; this does not appear to be polkit related at all, we just lost the driver in the image's /pool apparently?
<ubottu> bug 1626108 in ubiquity (Ubuntu) "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,New] https://launchpad.net/bugs/1626108
<slangasek> nacc: might be a thing to add to update-maintainer itself, possibly as an optional flag?
<nacc> slangasek: that's what i was thinking, yeah
<rbasak> Agreed
<rbasak> update-maintainer would become a misnomer then though.
<slangasek> <shrug> :)
<nacc> yeah, i wasn't sure if we'd need to rename/alias then to make it clear
<nacc> hence, i'll try, and we'll use a MR as the point of discussion :)
<cyphermox> pitti: huh?
<cyphermox> pitti: /pool/restricted/i/intel-microcode/intel-microcode_3.20160714.1_amd64.deb
<pitti> cyphermox: no, not lost
<pitti> looked at .manifest, not .list
<pitti> it's a version mismatch
<cyphermox> ah, that could explain it yeah
<cyphermox> but then today we should see if work
<cyphermox> *it
<pitti> cyphermox: followed up again
<slangasek> "version mismatch"?
<pitti> it's a version mismatch
<pitti> slangasek, cyphermox: didn't we use to have this before? mirror on cdimage being out of date or something?
<cyphermox> yeah, that's why I said we should see it working correctly in today's image
<slangasek> pitti: yesterday was spent dealing with ftp mirror problems
<slangasek> so that should be fixed now
<pitti> ah, so the next respin should magically fix this
<slangasek> and it's possible that this particular image was bad because I manually ran the ftp sync while builds were running
<pitti> so, OOI, what made this look like a polkit problem?
<cyphermox> pitti: ubiquity crashes when you try to setup wifi
<davmor2> pitti: \o/ that would be nice
<cyphermox> Not authorized to control networking.
<cyphermox> (which is very wrong, because you clearly should be, and my cursory glance at the pkla files shows it should work)
<pitti> cyphermox: so, so that's not bug 1626108 then, but something else?
<ubottu> bug 1626108 in Ubuntu CD Images "Ubiquity session isn't setting up 3rd party hardware drivers" [Undecided,In progress] https://launchpad.net/bugs/1626108
<cyphermox> pitti: something else I noticed while testing this driver issue, I supposed it could be related
<cyphermox> OOI, what versions do you say mismatch?
<cyphermox> afaict the intel-microcode and bcmwl-kernel-source versions in pool/ on the CD yesterday are the right ones.
<slangasek> cyphermox: there was a newer dkms package in the archive than in the pool
<cyphermox> ah!
<slangasek> cyphermox: and the image knew this and went looking
<pitti> cyphermox: yes indeed, it also needs to work on the desktop (and if it wouldn't, I expect we'd get a lot more outcry
<pitti> ... or not, because people can't get on the net to yell at us :)
<cyphermox> pitti: NM works
<cyphermox> pitti: you can drive NM from nm-applet, it just explodes when driven from the installer.
<pitti> cyphermox: right, but nm-applet uses the same d-bus interfaces and thus PK privs
<cyphermox> so does the ubiquity panel, afaik
<cyphermox> everything uses the same magic.
<pitti> so that's ubiquity-only, not ubiquity in the live-session?
<cyphermox> ubiquity in the live session is where I noticed this
<davmor2> cyphermox, pitti: is this the magic https://www.youtube.com/watch?v=ViftZTfRSt8 ?
<barry> pitti: uploaded to unstable.  i'll syncpackage it over once it's imported by lp
<pitti> barry: â¥
<bdmurray> coreycb: Could you add some more SRU information to bug 1623107?
<ubottu> bug 1623107 in python-pylxd (Ubuntu Xenial) "[SRU] python-pylxd 2.0.5" [Undecided,New] https://launchpad.net/bugs/1623107
<coreycb> bdmurray, sure thing
<nacc> doko: re: ftfbfs for gsfonts, looks to be fixed in 1:8.11+urwcyr1.0.7~pre44-4.3 current in unstable. Do you want me to submit a fresh merge or (as there are unrelated to the ftfbs issue changes) just backport the one fix to the Y level?
<nacc> doko: actually, it looks it can be sync'd in yakkety, if i'm reading the .3 changelog right
<nacc> yeah, debian took the ubuntu dela
<nacc> *delta
<Unit193> Nice.
<nacc> doko: and filed LP: #1626776, i have the fix in hand, just testing it now
<ubottu> Launchpad bug 1626776 in nagios3 (Ubuntu) "nagios3: add build-arch and build-indep targets [ftbfs]" [Undecided,New] https://launchpad.net/bugs/1626776
<tsimonq2> so how can I emulate armhf for example to solve build errors?
<tsimonq2> do I need an armhf machine?
<nacc> tsimonq2: i think sbuild can crossbuild?
<tsimonq2> really? how?
<nacc> tsimonq2: with some combination of --build and --host, maybe
<nacc> and an appropriate schroot already made
<nacc> it seems like there is, e.g. crossbuild-essential-armhf
<tsimonq2> nacc: have you tried this before?
<nacc> i think i have with a different arch, but i'd have to go look
<tsimonq2> last time I tried sbuild with armhf it didn't work :/
<tsimonq2> ok
<nacc> yeah, i think armhf may also be special, unfortunately, i can't recall
<nacc> Unit193: do you know if it's appropriate for me to `requestync` gsfonts? or should I wait for doko to handle it?
<nacc> doko: ok, so pacemaker's failure is odd, as the chown in question is '-chown' in the makefile
#ubuntu-devel 2016-09-23
<nacc> doko: ah nm, that's not he failure, it's the lack of debian/tmp/usr/lib/python2.7/dist-packages/cts
<nacc> why dioesn't that also fail on amd64?
<tumbleweed> difference between a -b and -B build?
<nacc> tumbleweed: hrm, could be
<tsimonq2> does Ubuntu offer machines I could use to debug an s390x build? or is there a guide somewhere for emulating that?
<Unit193> nacc: I wouldn't know on that.
<tumbleweed> tsimonq2: Ubuntu doesn't have any porterboxes for non-canonical employees
<tsimonq2> tumbleweed: :((
<tsimonq2> that sucks
<tumbleweed> tsimonq2: qemu works apparently
<tsimonq2> it would be great if there were porterboxes for at the very minimum flavors
<tumbleweed> https://en.wikipedia.org/wiki/Linux_on_z_Systems#Developer_resources ?
<nacc> Unit193: ok, np
<Unit193> nacc: Sorry, don't really know the context on that.  Just always nice when Debian takes the delta and something is sync'able.
<nacc> Unit193: ack, not a problem, just trying to fixup server packages ftbfs from the archive rebuild e-mail doko recently sent
<jbicha> nacc: you can use 'syncpackage'; since the package is seeded it probably will stay in the unapproved queue until this week's Ubuntu beta is released
<nacc> jbicha: ok, that's what i wasn't sure about
<nacc> jbicha: thanks for clarifying!
<nacc> jbicha: given this is my first attempt to use so as core-dev, and there is a current delta, should i do `requestsync` instead? or is it appropriate to use --force if I've verified the delta has been picked up by debian?
<jbicha> I don't think it's necessary to use requestsync since this isn't a Feature Freeze Exception
<xnox> tumbleweed, moreover canonical doesn't even have a s390x porter box
<xnox> tsimonq2, can i be of any help at all? i do have access to s390x.
<nacc> jbicha: ack, so i would use --force to drop the delta then? i'm used to filling out the requestsync template to explain that the delta has been examined and verified
<jbicha> nacc: yes
<nacc> jbicha: thanks!
<Unit193> nacc: Heh, I'm not even a MOTU. :)
<tsimonq2> xnox: I'm assuming you don't want me to just tell you to fix it, right? I don't know what's wrong with it...
<tsimonq2> xnox: hardinfo
<tsimonq2> xnox: in the lubuntu packageset
<xnox> tsimonq2, check which object "strend" is, and wether it's correctly included / linked when linking shell.o and others. in that line.
<xnox> as in it's missing from the long line where hardinfo is linked.
<sarnold> amd64 fail log looks nearly identical to the s390x failure log https://launchpadlibrarian.net/285995082/buildlog_ubuntu-yakkety-amd64.hardinfo_0.5.1-1.4ubuntu1_BUILDING.txt.gz
<xnox> tsimonq2, earlier it appears to be defined as inline.... yet expected later on. Does shell.c missing #include "hardinfo.h" or some such?
<xnox> it all looks odd.
<tsimonq2> we're talking about 0.5.1-1.4ubuntu1 here
<tsimonq2> xnox: been failing ever since vivid, I've had my eye on it but I haven't worked on the package source (yet)
<xnox> tsimonq2, indeed $ pull-lp-source -d hardinfo && sbuild -A -d yakkety hardinfo*.dsc fails.
<xnox> this is not architecture specific at all, and can be worked on / fixed on amd64
<tsimonq2> xnox: but it's not FTBFS on amd64, is it?
<xnox> tsimonq2, it is
<sarnold> it is, see the link  I pasted a few lines back
<xnox> that's what sarnold said.
<xnox> and that's what i've just reproduced locally
<tsimonq2> oh, weird
<tsimonq2> ok
<xnox> tsimonq2, strend is claimed to be referenced and undefined. find which unit it is implemented in, and make sure it is linked correctly.
<sarnold> tsimonq2: 'inline' can be a funny thing, skim this when nothing else makes sense: https://gcc.gnu.org/onlinedocs/gcc/Inline.html
<tsimonq2> thank you both
<xnox> tsimonq2, it seems to me that util.o linking is missing, /after/ shell.o
<xnox> however it is there...
<xnox> not sure, but yeah, not architecture specific at all =)
<sarnold> oh, hrm, did vivid introduce the as-needed linking? https://wiki.debian.org/ToolChain/DSOLinking
<tsimonq2> good to know xnox :)
<sarnold> it -is- good to know xnox :)
 * xnox blushes
<tsimonq2> could you guys slightly simplify this a little bit or point me in the right direction in finding out how? I'm no expert at this ;)
<sarnold> tsimonq2: it looks a bit like the hardinfo.h file declares several functions with an 'inline' keyword; they're defined in (well, at least some are in) util.c : http://sources.debian.net/src/hardinfo/0.5.1-1.5/util.c/?hl=149#L149
<xnox> which to me is odd.
<sarnold> tsimonq2: that usually means that either there's going to be an #include "util.c" -- which looks -strange-
<xnox> usually inline functions are implemented in the header.
<xnox> alternative to that, is to make that function just a normal, non-inline one. and link things normally.
<sarnold> tsimonq2: or it means that util.o needs to be mentioned on every gcc line in the log for every file that uses those functions..
<sarnold> removing the 'inline' seems like the easiest thing to try
<sarnold> actually, -would- mentioning util.o on every line actually help? I'm unsure now.
<tsimonq2> I'll play with it a bit
<tsimonq2> I don't consider myself good at C++ but I think I'm good enough to figure this out with a lot of trial and error :)
<sarnold> woo :)
<tsimonq2> emphasis on /lot/
<tsimonq2> :P
<tsimonq2> ok, I think I fixed it
<sarnold> \o/
<tsimonq2> experienced C++ people will probably scream :P
<tsimonq2> but hey, it builds
<tsimonq2> and I also need to convert everything into debian patches
<tsimonq2> but I'm getting a diff ready so you can tell me how insane I am :P
<tsimonq2> sarnold: is this correct? http://paste.ubuntu.com/23218477/
<tsimonq2> sarnold: I added a header and all of a sudden it builds
<tsimonq2> I have a feeling it might not be the header that's doing that
<tsimonq2> it may just be me removing the inline
 * tsimonq2 tests more
<sarnold> tsimonq2: I think it's just removing the inline -- files would have to #include "util.h" in order for the header file to have an influence
<tsimonq2> that's correct
<tsimonq2> sarnold: so I'm not fully seeing why removing inline does the trick, could you give me a tl;dr so I can convince gilir to upload this for me? :)
<sarnold> well, "fixes FTBFS" ought to be pretty compelling on its own :)
<tsimonq2> (gilir is the development head for Lubuntu, MOTU, if you didn't know ;) )
<tsimonq2> sarnold: well how about if *I* want to know why :P
<sarnold> tsimonq2: the "inline static" means that the compiler absolutely should not generate a function that is callable by other object files -- it should _only_ be available to the same "compilation unit", and not have a name.
<sarnold> hm, I thought util.c was "inline static", not just "inline"
<tsimonq2> what's the difference?
<sarnold> I think "inline" alone means "try to inline this but also generate a callable function for it if it is needed"
<tsimonq2> then why don't you think it was accessible?
<sarnold> this has the full details: https://gcc.gnu.org/onlinedocs/gcc/Inline.html   -- I forget them about ten minutes after re-reading that, every single time..
<tsimonq2> heh
<tsimonq2> sarnold: are you a DD?
<sarnold> tsimonq2: no
 * tsimonq2 checks if this failure is also in Debian
<tsimonq2> upstreaming is good, right? ;)
<sarnold> yes :)
<tsimonq2> seems to be ubuntu-specific
<tsimonq2> sarnold: thank you for your help, I really appreciate it :)
<Unit193> Debian, by default, doesn't use --as-needed.
<tsimonq2> sarnold: have a good evening
<tsimonq2> Unit193: oh, good to know, thanks
<sarnold> Unit193: oh? that'd do it..
<sarnold> you're welcome tsimonq2, have fun :)
<Unit193> sarnold: How aren't you a DD anyway, if you don't mind?
<sarnold> Unit193: when I wanted to apply back in 2000 or so, the new maintainer process was closed
<sarnold> Unit193: since then I got lazy
<Unit193> sarnold: Even I applied to become a DM. :3
<sarnold> :)
<mwhudson> hey, it's easy now, there's a web form and everything
<Unit193> mwhudson: Unless, you have no name and don't exactly live real close to DDs to get sigs. ;)
<mwhudson> well yes, that's true
<mwhudson> but you don't have to try to figure out what a jetring changeset is
<sarnold> i used to see a debian developer at the local coffee shop all the time.. until he had a kid. I don't see him so often any more, hehe :)
<Unit193> Haha, nice sarnold. :)
<mwhudson> i go drinking with a bunch of DDs every six months or so...
<Unit193> sarnold: Anyway, thanks for telling me.
<Unit193> I've...Only ever met one.
<tumbleweed> Unit193: come to a debconf then :)
<sarnold> mwhudson: it's odd to run into coworkers -- who live a few minutes away from me -- only in foreign countries.
<mwhudson> heh
<Unit193> tumbleweed: Yeah, heard you had fun.  superfly was telling me a bit.  My plan is OLF here.
<tumbleweed> Unit193: OLF?
<Unit193> tumbleweed: Ohio Linux Fest, not Debian or Ubuntu centered. :P
<tumbleweed> right, I thought you might mean that
<tumbleweed> the next debconf is in montreal, which isn't *that* far from ohio
<Unit193> Considering the last was in SA?  Yeah, not too far.
<tumbleweed> :)
 * tumbleweed was at pyohio this year, maybe again next year...
<Unit193> ...You live in SA, right?
<tumbleweed> SF, I'm ex-ZA, though
<Unit193> Ah!  I met Asheesh, know him?
<tumbleweed> everybody knows asheesh
<Unit193> Still, consider Ohio a bit of a flyover state, so interesting you've gone to a conf here.
<tumbleweed> CarlFK wanted help with video recording
<tumbleweed> but generally, small conferences are fun
<Unit193> If I make it this year, it'll actually be my first one (with Nathan Handler, pleia2, jose, and maybe a few others.)  Anywho, this isn't exactly development related..
<tsimonq2> xnox, sarnold: https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html
<tsimonq2> hmm, what's up with Firefox?!?!????
<tsimonq2> !Info firefox xenial
<tsimonq2> !info firefox xenial-updates
<ubottu> 'xenial-updates' is not a valid distribution: kubuntu-backports, kubuntu-experimental, kubuntu-updates, partner, precise, precise-backports, precise-proposed, stable, testing, trusty, trusty-backports, trusty-proposed, unstable, utopic, utopic-backports, utopic-proposed, vivid, vivid-backports, vivid-proposed, wily, wily-backports, wily-proposed, xenial, xenial-backports, xenial-proposed, yakkety, yakkety-backports, yakkety-proposed
<tsimonq2> !info firefox xenial
<ubottu> firefox (source: firefox): Safe and easy web browser from Mozilla. In component main, is optional. Version 49.0+build4-0ubuntu0.16.04.1 (xenial), package size 45662 kB, installed size 110656 kB
<tsimonq2> !info firefox yakkety
<ubottu> firefox (source: firefox): Safe and easy web browser from Mozilla. In component main, is optional. Version 48.0+build2-0ubuntu1 (yakkety), package size 46753 kB, installed size 110732 kB
<tsimonq2> anyone see the problem?
<tsimonq2> AND firefox in Yakkety is FTBFS
<tsimonq2> who is the person that's usually in charge for firefox?
<Unit193> !info firefox yakkety-proposed
<ubottu> Package firefox does not exist in yakkety-proposed
<Unit193> Fancy.
<tsimonq2> O__o
<tsimonq2> ...so it mograted to release while failing on two arches?
<tsimonq2> *migrated
<tsimonq2> weird
<tsimonq2> also...why upload to xenial but not yakkety?!?
<Unit193> Just PPC and system-z where nobody cares.  Those are the reasons it gets stuck in devel-proposed though.
<Unit193> tsimonq2: In case you didn't remember, beta freeze and ISO rebuilds might have a little to do with it, or just plain time.
<tsimonq2> Unit193: but I guess the point I'm trying to make is it's not the fact that it's FTBFS that's the issue, it's the fact that the Xenial version is greater than the Yakkety version
<tsimonq2> Unit193: -- Chris Coulson <chris.coulson@canonical.com> Mon, 12 Sep 2016 13:03:01 +0100
<tsimonq2> Unit193: done a week ago
<tsimonq2> (more than that)
<tsimonq2> Feature Freeze could be a thing
 * tsimonq2 shrugs
<pitti> Good morning
<mardy> seb128: hi! Is everything fine here, or does this hint to some error: https://bileto.ubuntu.com/#/ticket/1497 ?
<pitti> mardy: I think it's just pointing out https://launchpad.net/ubuntu/yakkety/+queue?queue_state=1&queue_text=
<pitti> mardy: (we are in beta freeze)
<mardy> pitti: ok, so no error there, right?
<pitti> yes
<doko> seb128: I uploaded libabw with changed library name. could you rebuild writerperfect and libreoffice? will  be offline until Monday
<seb128> doko, let me check with Bjoern if he has a libreoffice upload planned
<seb128> but yeah, can do
<seb128> doko, enjoy your w.e!
<seb128> mardy, sorry forgot to reply earlier but yeah, no error indeed, just beta freeze holding the package in the review queue
<mardy> seb128: nw, thanks
<caribou> juliank: I just replied to LP: #1625667; sorry for the serie's mixup I fixed that
<ubottu> Launchpad bug 1625667 in apt (Ubuntu Trusty) "Trusty: apt does not try next mirror if index file download fails with mirror:// source" [Medium,In progress] https://launchpad.net/bugs/1625667
<caribou> juliank: TL;DR : I have a fix for this, just awaiting for MVO to review so I can SRU to trusty
<caribou> juliank: I was supposed to update the case with the info I sent to mvo but forgot about it
<juliank> caribou: I would not call mvo the main apt developer anymore, he rarely did anything the past months (since April, mvo!) :D
<caribou> juliank: well, I had doubts & didn't want to hurt any feelings ;-)
<caribou> juliank: I only met David once @UDS-R & Michael was the other one I knew f2f
<caribou> juliank: so you do work on apt these days ?
 * juliank manages apt releases (series) and maintains the new cmake build system
<juliank> And yes, I also fix tiny bugs.
<juliank> David does most of the large work
<caribou> juliank: yes, just glanced at the git history
<caribou> juliank: ok, so this Trusty issue is just a one line fix (details in the bug _now_). Sorry for dropping the ball on the details
<juliank> Oh, I also handle pull requests of github, and maintain the xenial series
<juliank> and soon I'll add yakkety (1.3) to my list of stable APT series to maintain...
<juliank> caribou: That's great, BTW. Did you bisect the fix? I wonder what release fixed that.
<caribou> juliank: Wily had the fix
<juliank> Right.
<caribou> juliank: & I spent a few days reading the code & running gdb sessions to figure out how the Queues, Fetchers & other niceties worked
<juliank> I'm interested to know if 1.0.9.8 (Debian stable series) was broken too, which happened between vivid and wily :/
<juliank> caribou: Whoa. I'd just tried the new one, noticed it works, track back to the oldest Ubuntu release, and run git bisect :D
<caribou> juliank: well, it all started with discussion with mvo who thought at the beginning that there were no retries on index files
<juliank> I thought that too, but noticed I was wrong a few weeks ago :D
<caribou> juliank: so the explanation I sent to mvo are in the bug, so if the fix looks ok to you, I'll handle the SRU
<juliank> caribou: I think it looks OK.
<caribou> juliank: ok, I'll SRU this, thanks!
<tsimonq2> pitti: hey, ping, you're patch pilot today?
<pitti> tsimonq2: by the calendar, yes; but not a good day today (beta preparations, archive is frozen, and I'm currently bandwidth deprived) -- will do Monday instead
<tsimonq2> pitti: can you at the very minimum tell me if something is *sane*, then upload on Monday? I sent this to gilir (MOTU, Lubuntu dev head) and he responded on FB Messenger that he hasn't really had the time for this sort of thing lately, so he told me to ask a patch pilot. https://lists.ubuntu.com/archives/lubuntu-devel/2016-September/000824.html
<pitti> tsimonq2: that looks a bit weird at first sight -- if it's a public function it must be in the .h, not the .c; and if it's a private function within util.c, it shuld be declared "static"
<tsimonq2> pitti: but there's no .h
<tsimonq2> pitti: *I* thought *that* was weird
<tsimonq2> pitti: bunch of other files have headers but not this one...
<pitti> tsimonq2: so how are functions in util.c being used by other files then?
<tsimonq2> pitti: that's what I have absolutely no clue about
<pitti> tsimonq2: anyway, if sarnold and xnox already reviewed it, it's fine (I don't need to second/third-guess them)
<pitti> but it shoudl at least be forwarded upstream -- this sort of hacky patch isn't something we want to carry downstream forever
<pitti> (and it's also not a real solution)
<tsimonq2> well upstream has a lot of commits and no tags...
<tsimonq2> pitti: as I said in the email, doesn't apply to Debian, and eventually, when they tag and Debian packages it (I might just do it myself and then talk to a DD about getting it uploaded) we should be able to drop this when we merge from Debian
<tsimonq2> pitti: if not, then I'd say file upstream
<pitti> tsimonq2: ah, so that's already fixed upstream, just not in our currnet ubuntu version?
<tsimonq2> pitti: it should be, I'm making assumptions there, everything got moved around upstream
<tsimonq2> pitti: I'll do a little testing later
<tsimonq2> pitti: but regardless, this fixes the issue for the time being
<pitti> tsimonq2: ack; still a really curious patch which I don't really understand :/
<tsimonq2> pitti: < sarnold> this has the full details: https://gcc.gnu.org/onlinedocs/gcc/Inline.html   -- I forget them about ten minutes after re-reading that, every single time..
<tsimonq2> :P
<pitti> heh, indeed -- I just don't see how a public inline function would ever work in a .c file
<pitti> "static inline" â .c files; public "inline" â .h file
<xnox> yeah .h should drop inline as well, or difinition be moved into the header file.
<xnox> i didn't review anything, i just speculated that dropping inline and making the undefined symbol a normal function should do the trick =)
<pitti> yes, that's what I mean -- the whole definition belongs into the .h, not just the declaration
<tsimonq2> pitti: as I told them yesterday, I don't consider myself good at C++, seems logical enough :P
<pitti> but if there is no .h file which declares that strend() function, how is it ever being used?
<pitti> implicitly? (eww)
<xnox> tsimonq2, also this is not C++ =)
<xnox> pitti, i thought hardinfo.h did
<tsimonq2> oh shoot it isn't?!?
<pitti> ah, then move it to hardinfo.h
<tsimonq2> huh
<pitti> tsimonq2: (plain C)
<tsimonq2> hahahahahaha /o\
<pitti> or drop the "inline" from both declaratoin and definition, yes
<pitti> but either way, if it's fixed upstream I'm fine with it
<tsimonq2> ok cool
<tsimonq2> pitti: thanks for your time :)
 * tsimonq2 is off to school o/
<ogra_> bah, why cant file-roller open udebs
<seb128> mardy, did you see my comment yesterday about u-c-c/uoa google account view going away when focussing the textentry?
<pitti> doko: FYI, I fixed the libreadline recommends in postgresql-common more generically and reuploaded
<pitti> (just in case you wonder why I clobber your upload)
<rbasak> doko: would you mind taking a look at bug 1609043 please? I'm not sure it's MySQL-specific. Could it be an unintentional ABI break in libstdc++?
<ubottu> bug 1609043 in mysql-5.7 (Ubuntu) "mysqld: relocation error: mysqld: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference" [High,Confirmed] https://launchpad.net/bugs/1609043
<doko> rbasak: will try
<tyhicks> wgrant: hey - it looks like LP is no longer importing packages from wheezy LTS security updates but I want to sync unadf 0.7.11a-3+deb7u1 from wheezy to yakkety to fix two CVEs
<tyhicks> wgrant: should I use syncpackage --no-lp in this instance?
<tyhicks> (the reason I think that LP is no longer importing packages from wheezy LTS is because it still doesn't know about cacti 0.8.8a+dfsg-5+deb7u10
<tyhicks> )
<xnox> pitti, would you expect this to work? sudo busctl --address=unix:path=/run/systemd/private get-property org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.systemd1.Manager SystemState
 * xnox is trying to find a way to probe /run/systemd/private to see if systemd is listening and replying on it.
<pitti> xnox: not really, the internal socket is a bit special; for example, it also doesn't handle property notifications, you need the real dbus for that
<pitti> the internal one is only being used if dbus is not installed
<wgrant> tyhicks: Hrm, we import anything from the wheezy suite itself. If Debian's LTS process uses a separate wheezy-lts suite then we've probably never supported that.
<doko> rbasak: the cxx11 symbols were only introduced with GCC 5, so maybe checked if the new libstdc++ is alreeady unpacked?
<doko> but afk now
<pitti> xnox: you can check if "systemctl list-units" works as root (then it will use /run/systemd/private)
<pitti> xnox: but, why would it not listen to that?
<tyhicks> wgrant: they're not using a separate wheezy-lts suite so I'm surprised that it isn't working (https://wiki.debian.org/LTS/Using#Using_Debian_Long_Term_Support_.28LTS.29)
<pitti> xnox: or is-system-running
<rbasak> doko: could it be a partial upgrade problem? On upgrade from T to X, a build-against-X mysql binary is running without a versioned depdendency on libstdc++?
<tyhicks> wgrant: 'For Debian 7 "Wheezy" LTS there will be no requirement to add a separate wheezy-lts suite to your sources.list any more.'
<wgrant> tyhicks: Mysterious. How long has that been published in wheezy?
<pitti> xnox: run it with DBUS_SYSTEM_BUS_ADDRESS=/nonexisting to make sure it doesn't use the "official" dbus
<xnox> ack
<tyhicks> wgrant: unadf has been published for 2 days but cacti was published Sep 1
<xnox> pitti, well, it doesn't =) when zhcp devices are present on kernel machines on s390x.....
<rbasak> doko: BTW, I'm off next week too.
<wgrant> tyhicks: The Debian importer is having some disk space issues, but I thought we had them mostly under control. Give me a few to investigate.
<mardy> seb128: yes, it's strange, it should be fixed; I'll try reproducing it on Monday
<seb128> mardy, thanks
<mardy> seb128: maybe not all needed patches have been backported
<seb128> Mirv, ^
<seb128> yeah, dunno
<seb128> scrolling is fixed
<seb128> but now the view gets white on focussing the textentry
<seb128> so in practice it's not much better
<seb128> still can't enter your login info
<tyhicks> wgrant: It may not be disk space related beacuse I'm not seeing any wheezy-lts package imports since the LTS team took over security support in late April
<tyhicks> wgrant: I'm happy to run syncpackage --no-lp, rather than have you sort out the importer issues, but I have never used that option and wanted to get an "ack" from you before doing so after reading the warning in the syncpackage man page
<cjwatson> tyhicks,wgrant: That's only in wheezy/updates (aka wheezy-security), which I don't think we've ever imported.
<wgrant> tyhicks: It looks to me like that unadf updateis only in wheezy-security
<wgrant> Which I don't think we've... that
<tyhicks> oh
<wgrant> I've imported post-release suites locally, but we've never had that capability on prod.
<cjwatson> I think --no-lp would be fine here.
<tyhicks> wgrant, cjwatson: thanks for getting to the bottom of it - this is good info to know :)
 * tyhicks will use --no-lp
<seb128> Mirv, mardy, L_aney confirmed it does the same on his install so it's not only virtualbox iso testing
<nacc> doko: if you're around, what do i need to do to reproduce the build failures locally? e.g., pacemaker's failure is weird and I'm not seeing how it would only affect non-amd64 archs
<Laney> nacc: Builds-only-on-amd64 makes me think of an arch-only build problem
<Laney> try to sbuild with --no-arch-all
<nacc> Laney: thanks, i'll test that now
<nacc> Laney: perfect, thank you!
<Laney> nacc: now the fun part :-)
<nacc> Laney: yeah :)
<nacc> Laney: doko: ah interesting with --no-arch-all on amd64, it also fails, not sure why that's not the case in the archive version, but makes the fix clearer to me
<Laney> nacc: The problem is the type of build (arch + indep or arch only), not the architecture it's building on
<nacc> Laney: right, but why would the amd64 not also have been run as a arch only build?
<Laney> because we have to build the arch:all packages somewhere, and for us it's amd64
<nacc> ah!
<nacc> that's what i was missing :)
<nacc> i wonder if it would be clearer to do both for the rebuild purposes? that way it's a bit more obvious when there's a generic bug?
<Laney> if you look at the build log, you can see that different debian/rules targets are called
<nacc> oh well, i know what to do for now :)
<nacc> ok, i have a fix, but i'm not sure it's 100% correct, in that two things are changing, 2.7 -> 3.5 and dist -> site. The first seems expected, but not sure if the second is? Maybe because it's a 'local' installation of the python files?
<nacc> pacemaker_1.1.15-1ubuntu2.dsc
<nacc> http://paste.ubuntu.com/23220944/
<nacc> gah
<smoser> what would make thsi happen
<smoser> http://paste.ubuntu.com/23221052/
<smoser> 'groups' says the ubuntu user is in the libvirtd group twice
<smoser> ah. isee 2 lines for libvirtd group in e/tc/group. wonder what did that
<nacc> libvirtd and libvirt?
<nacc> weird
<smoser> ah. by same name
<smoser> er... gid
<nacc> yeah, that's ... fun
<nacc> so a pseudo-bug in groups? :)
<smoser> i bet it is fallout of either a human or machine dealing with the fact that libvirt group changed from libvirt-bin to libvirtd
<smoser> er... libvirt to libvirtd
<smoser> whatever it was
<nacc> yeah
<slangasek> seb128: hey, so investigating python slowness on arm/snappy turned up that we were stripping .pyc files out in livecd-rootfs
<slangasek> seb128: this was originally added for the desktop CD, where it's still being used - does that still make sense there?  Are people happy with the performance of python on the live CD?
<ahoneybun> what is the package name for the Ubuntu Software on Launchpad?
<sarnold> slangasek: seb128's gone on holidays for a few weeks apparently
<ahoneybun> I know it's GNOME software but did we fork it or is it upstream?
<jbicha> ahoneybun: gnome-software is the new xenial era source package
<ahoneybun> jbicha: https://launchpad.net/gnome-software ?
<ahoneybun> need to file a bug about Steam not showing in the search
<jbicha> ubuntu-bug gnome-software
<ahoneybun> is there a reason the LP bugs are turned off?
<jbicha> https://bugs.launchpad.net/gnome-software "Bugs are tracked in GNOME bug tracker"
<ahoneybun> right
<jbicha> but I think you're thinking of https://bugs.launchpad.net/ubuntu/+source/gnome-software
<ahoneybun> well I'll just use ubuntu-bug then
<jbicha> upstream bugs are filed with GNOME directly; Ubuntu ones use the Ubuntu url
<ahoneybun> mm not sure if it's upstream
<slangasek> sarnold: if the question sits in his scrollback for a while, that's ok :)
<ahoneybun> you can install Steam with apt and find it with apt search
<sarnold> slangasek: ah, good :)
<ahoneybun> just can't see it in Ubuntu Software
<jbicha> ahoneybun: thanks; when you use ubuntu-bug it automatically picks up your distro version number and the package version number
<seb128> slangasek, we don't have complains about the performances of e.g update-manager or language-selector on desktop afaik so I would keep the hack at least for yakkety, we can look at how much space difference it makes and performances next cycle
<slangasek> seb128: ok. how should we keep this on the desktop team's radar? it went unnoticed for years, none of the people working on livecd-rootfs probably remembered it was there
<seb128> slangasek, open a bug against livecd-rootfs and assign to us
<tsimonq2> so I want to know, is there a good guide for updating symbols?
<tsimonq2> when it's ok to remove symbols etc.
<tsimonq2> search engines aren't helping :/
<tsimonq2> (for debian/*.symbols files)
<tumbleweed> removing symbols will cause dynamic linker errors for anything that was using them
<tumbleweed> so generally if you remove a symbol, you bump the soname
<tumbleweed> unless you can be sure that it wasn't being used, and you don't have any other ABI incompatibility
<tsimonq2> tumbleweed: how do I tell if it's being used?
<tumbleweed> you look at all the reverse dependencies with readelf / nm
<tumbleweed> so much fun
<sarnold> .. and hope there's not significant use of out-of-archive tools
<tumbleweed> and that there's no dlopen usage
<tsimonq2> tumbleweed: you got a manpage and/or an example for using those tools?
<tumbleweed> they have manpages
<sarnold> they're not the friendliest, heh
<tumbleweed> readelf -sw is what I'd use there
<tumbleweed> err W
<tumbleweed> not w
<tsimonq2> sarnold: you have any better suggestions? ;)
<tumbleweed> and I wouldn't even think about keeping the soname, unless there were just a couple of reverse-deps
<tsimonq2> tumbleweed: does the package have to be native or the source at least unpacked? what preparation do I need for this?
<tumbleweed> tsimonq2: this is looking at built binaries
<tsimonq2> tumbleweed: ah, so *.deb files?
<tumbleweed> no /usr/bin/foo
<sarnold> it's odd to recommend _drepper_ for something more friendly... but here we are :) https://software.intel.com/sites/default/files/m/a/1/e/dsohowto.pdf
<slangasek> or 'objdump -T'
<slangasek> but also, in general since you can't control what symbols someone outside the archive might be using from that library, best practice is to always change the soname upstream if that symbol was ever exported in a public header
<slangasek> and if upstream doesn't change the soname, best practice is for the binary package name to change but keep the soname as-is
<tumbleweed> and if it's C++, accept the fact that every time you touch it the soname will change
<slangasek> well, not entirely :)
<tsimonq2> (I'm working with akonadi in the Kubuntu set, I just thought I'd ask here)
<tsimonq2> this is what I'd like to fix: https://launchpad.net/~kubuntu-ci/+archive/ubuntu/unstable/+build/10941905/+files/buildlog_ubuntu-yakkety-amd64.akonadi_4%3A16.04.3+p16.10+git20160922.0751-0_BUILDING.txt.gz
<tumbleweed> so, removed symbols aren't the only kind of ABI breakage, you also care about backwards-incompatible changes to structs, and C++ classes
<tsimonq2> so I basically need to inspect the upstream diff?
<tsimonq2> is there any case where a symbol will go MISSING and it's *not* good to remove it?
<slangasek> what do you mean by "good to remove it"?
<tsimonq2> sarnold: well look at that log I pasted
<tsimonq2> whoops, I mean slangasek ^
<tsimonq2> slangasek: there's a bunch of symbols there that got the "#MISSING" prefix added to them
<tsimonq2> slangasek: when are symbols like that safe to remove and not safe to remove, is what I'm essentially asking
<slangasek> yes, and we've just explained that you *shouldn't* just remove those from the .symbols file without the soname / package name getting changed
<tsimonq2> what if I do bump that?
<slangasek> for C++, an exception is template symbols
<slangasek> which are exported but not part of the ABI
<slangasek> I'm afraid the answer for this is not straigtforward, especially for C++
<tsimonq2> I see
<tsimonq2> ok
#ubuntu-devel 2016-09-24
<slangasek> smoser: hi, the cloud-init in the xenial SRU queue is a 'new upstream snapshot' - I'm not aware that there's been discussion with the SRU team of exempting cloud-init from the usual SRU rules?
<slangasek> smoser: i.e., there are changes here that are not tied to bug reports with SRU test cases, and I have no reference to upstream CI having been done prior to upload.  As this is blocking lamont's somewhat urgent ipv6 support requirements, should I reupload with only the currently-SRUable changes?
<slangasek> smoser: ugh - sorry, I didn't mean to reject your cloud-init upload just yet, I was only trying to reject lamont's; anyway, the preceding questions still apply before I could turn that into an 'accept'
<tmus> the new resolvd based universal resolver in Yakkety seems to rely on changes to /etc/resolv.conf - at least sometimes... Unless I'm missing something, this will bring back resolver-issues for running (glibc) apps whet the DNS changes on the fly (VPN comes to mind). Is this true?
<maxb> Yes, it's true, it has affected me already
<tmus> hmmm
<maxb> I had to change my VPN script to SIGUSR2 systemd-resolved on up/down
<tmus> I believe resolvd actually listens on 127.0.0.53:53, so it seems to me we should just have 127.0.0.53 in resolv.conf and never change resolv.conf (exactly as with dnsmasq)?
<maxb> Well, it gets even more complicated than that
<maxb> Because systemd-resolved both obtains DNS servers for it to use FROM resolv.conf AND puts itself in resolv.conf
<tmus> that sounds messy
<maxb> yes
<maxb> I'm thinking I'll probably disable systemd-resolved completely for my own use
<tmus> especially when VPN's come along and modify the changed resolv.conf that resolvd will now have to parse and merge new resolvers to it's running config. And how does it keep track of removing them again?
<maxb> Well hopefully you're using the resolvconf framework, otherwise it becomes complex beyond all sanity
<tmus> this probably requires that network-manager can talk to resolvd directly and update DNS's directly - again, it'll need to leave resolv.conf alone
<maxb> So right now on my yakkety laptop NetworkManager is providing a nameserver line it got from DHCP and systemd-resolved is providing 127.0.0.53 ... and presumably systemd-resolved is also reading the generated resolv.conf to get hold of the results of the DHCP
<tmus> bad stuff
<maxb> This seems to be yet another case of systemd coming up with features that overrule all historical configuration conventions
<tmus> in this case at least, it seems we're missing some essential glue to make it usable in real life
<tmus> every time resolv.conf is updated, we risk new applications won't have valid/consistent DNS resolution with the rest of the system
<maxb> I feel it was an error to have systemd-resolved's 127.0.0.53 being injected into resolvconf
<tmus> but if resolvconf could be made easily resolvd-aware, perhaps the problem is not too bad?
<tmus> howcome?
<maxb> It turns out that systemd-resolved(8) is actually fairly clear on three possible modes of operating resolv.conf, but what we seem to have in yakkety is a hybrid that is none of those three
<tmus> (as long as that's the only nameserver in there, we should be golden, right?
<tmus> makes sense
<maxb> Quite. as long as that's the only nameserver in there. But that's just not happening the way the rest of Ubuntu is set up right now
<tmus> agree... hopefully this can be fix'ed before release
<tmus> is there a bug on this somewhere? do you know?
<maxb> I don't, I've only started upgrading my machines to yakkety in the last few days and discovered this "fun" little detail
<tmus> :)
<maxb> I wonder if there's a list of everything that integrates with resolvconf anywhere
<tmus> Alright - I need to run some errands, but I'll probably find the time to file a bug later - This seems broken enoug to warrant a fix before release
<tmus> thanks for the ping-pong :)
<maxb> I can see two possible ways forward: 1) everything that talks to resolvconf today to provide DNS server needs to talk to systemd-resolved directly, or resolvconf needs to parse interface-specific fragments handed to it and communicate the result to systemd-resolved.
<maxb> Either sounds like a bit of a stretch this close to release
<tmus> maxb, according to https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver stuff should start to work soon... a change to nsswitch.conf should probably take care of the "forward to local resolver" thing, although I can't say i'm a big fan of the inherent confusion updating a historic configuration file with synthetic information just for kicks
<tmus> i think i actually kind of hate that idea
<tmus> to me the sanest solution is to use resolvd exactly as we use dnsmasq today - 127.0.0.53 in resolv.conf so admins KNOW that some sort of behind the scenes stuff is going on. systemd-resolv --status can then be used to get information
<maxb> Ugh yes, I'm not at all convinced that putting anything other than 127.0.0.53 in resolv.conf when systemd-resolved is in use makes sense
<maxb> Doing so is going to cause significantly confusing behaviour if the user is running any software which reads resolv.conf and tries to use the nameservers directly
<maxb> So, anything that implements a non-glibc resolver
#ubuntu-devel 2016-09-25
<Muppen> Hey guys, lets say I install a library from source, and have it in my library path. how can i make sure tht programs can use it? ldconfig?
#ubuntu-devel 2017-09-18
<karstensrage> hi LocutusOfBorg
<karstensrage> are you still doing sponsorship for debian?
<LocutusOfBorg> jbicha, mozjs24 is a merge or a sync?
<LocutusOfBorg> karstensrage, please debdiff the package with the one in unstable
<LocutusOfBorg> missing changes, e.g. new identity4c package, wrong version (dpkg --compare-versions helps), target should be sid, not "stable", the first changelog timestamp has been changed, old std-version, vcs fields non canonical (see mentors link), pre-depends should be dropped now
<jbicha> LocutusOfBorg: I'd prefer it if we could RM mozjs24 â¦ here's what's blocking its final rdepends: https://bugs.debian.org/872040
<ubottu> Debian bug 872040 in src:duktape "duktape: please ship a duktape library" [Wishlist,Open]
<jbicha> and I'd like to drop mozjs38 too but that's blocked on https://github.com/linuxmint/cjs/issues/52
<karstensrage> LocutusOfBorg, thanks, will do
<karstensrage> LocutusOfBorg, done
<LocutusOfBorg> karstensrage, std-version is 4.1.0, dh-autoreconf is useless in compat level 10, changelog doesn't list changes
<LocutusOfBorg> bump debian/compat and debhelper to 10
<LocutusOfBorg> and drop --with-autoreconf from rules
<LocutusOfBorg> and update the changelog file
<LocutusOfBorg> debian/changelog.j2 <-- what is that?
<karstensrage> is that in there
<karstensrage> yikeks
<karstensrage> LocutusOfBorg, thats a template file since everyone wants different versions for their builds
<karstensrage> it shouldnt be in there...
<karstensrage> and does changelog only reflects package changes right?
<LocutusOfBorg> upstream in case they fix a debian bug
<LocutusOfBorg> and packaging yes
<karstensrage> so all these changes you're suggesting reflected in changelog?
<karstensrage> hmm have to figure out how to get rid of that .j2
<LocutusOfBorg> do a debdiff of the current unstable package
<LocutusOfBorg> and check it
<TJ-> seems to be a bug in openssh-client-ssh1, it fails if ~/.ssh/config has a stanza with "Protocol 1", same as the regular ssh client.
<doko> is sysvinit-utils still supposed to be essential in artful?
<coreycb> bdmurray: hello, would you be able to take a look at promoting neutron-lbaas-dashboard to zesty-updates when you get a chance?
<beisner> coreycb dosaboy - fyi, promoted neutron to uca mitaka-proposed re: https://bugs.launchpad.net/neutron/+bug/1668410
<ubottu> Launchpad bug 1668410 in neutron "[SRU] Infinite loop trying to delete deleted HA router" [Medium,In progress]
<coreycb> beisner: thanks sir
<bdmurray> coreycb: It doesn't seem to be verified
<beisner> coreycb dosaboy - fyi, promoted nova from staging to proposed in uca M, N, O for https://bugs.launchpad.net/neutron/+bug/1668410
<ubottu> Launchpad bug 1668410 in neutron "[SRU] Infinite loop trying to delete deleted HA router" [Medium,In progress]
<coreycb> bdmurray: urg sorry, too many tags
<doko> chrisccoulson: fyi, there is a new cargo in unstable, and a new rustc in experimental
<tjaalton> doko: uploaded tomcat8.0 to debian & artful, assuming it'll take too long to process through debian NEW to reach artful..
<doko> tjaalton: accepted
<tjaalton> :D
<cajhne_> Hi.
<doko> tjaalton: please keep a bug report open to remove it for 18.04
<cajhne_> 17.10 crashes every time I fill up the RAM.
<tjaalton> doko: much thanks, I'll push new tomcatjss etc later
<tjaalton> doko: yup
<cajhne_> Anyone else seeing that?
<cajhne_> It's almost as though the new swap (file) is broken in some way.
<cajhne_> does anyone know a way to test if it's the swap file that's crashing Ubuntu 17.10?
<cajhne_> in the log it says /failed to activate swap file
<nacc> cajhne_: then you aren't usinng the sawp file and it probably OOM'd
<cajhne_> nacc: thanks. I'm surprised there's no bug report for this.
<nacc> cajhne_: what's the bug? swap failed to activate and you used up all your memory
<nacc> cajhne_: swap failing to activate isn't itself a bug
<cajhne_> nacc: I don't understand... that's expected behaviour? To crash and not swap anything to disk?
<nacc> cajhne_: without understanding *why*
<cajhne_> all I can think of is that I made the horrible error of choosing "encrypt my home folder"
<cajhne_> on install.
<nacc> cajhne_: how can it swap when there is no swap?
<cajhne_> Other than that, there's nothing at all unusual about my install.
<nacc> cajhne_: did you put your swapfile in your /home?
<juliank> rbalint: If you wondered why I did not upload the apt SRU yet: I was waiting to get this ACKed upstream (in Debian) for stretch / 1.4.8, but this did not happen yet. I guess I'll have to rebuild with a different version number. very unfortunate after all the work I put in :(
<cajhne_> nacc: Ubuntu has always set up swap however it likes. Does it not do that anymore?
<cajhne_> If not, yes, I'd consider that a pretty major bug.
<nacc> cajhne_: of course it does
<nacc> cajhne_: also, i think you might be in the wrong channel, did you want #ubuntu?
<cajhne_> nacc: for the install I chose to wipe the disk and install ubuntu 17.10
<nacc> cajhne_: or #ubuntu+1
<cajhne_> I'm ready to report a bug, but wanted to see if it's a bug.
<nacc> cajhne_: right, so wronng channel
<cajhne_> nacc: usually I work with devs to troubleshoot bugs. This is for the upcoming release.
<nacc> cajhne_: this appears to be a support request, and this is not the support channel (as pointed out in /topic)
<nacc> cajhne_: hence use #ubuntu or #ubuntu+1 as appropriate (imo)
<rbalint> juliank: thanks for the reminder
<CRogers> is #ubuntu broken?
<nacc> CRogers: you need to be registered
<nacc> CRogers: is that what you mean?
<CRogers> I am.
<nacc> CRogers: what are you seeingn?
<CRogers> ubuntu channel with 0 people in it.
<rbalint> juliank: i'm working on issues surfaced in u-u thus i'm not blocked on missing apt but i hope apt gets accepted
<CRogers> no way to type anything.
<nacc> CRogers: well, i'm in #ubuntu now ... are you on the wrong server?
<wxl> 1210 -!- Irssi: #ubuntu: Total of 1082 nicks [1 ops, 0 halfops, 0 voices, 1081 normal]
<wxl> seems you're missing SOMEthing, CRogers
<CRogers> nacc: freenode, right?
<nacc> CRogers: yeah
<CRogers> yea. :(
<wxl> i'm in #ubuntu and according to whois, you're not, CRogers
 * CRogers grrrrs
<CRogers> Okay, maybe it's Polari.
<wxl> can you invite me to the channel?
<wxl> the one that you think is #ubuntu
<CRogers> wxl no, cant type anything.
<CRogers> maybe I'll re-start polari.
<wxl> i'm not asking you to dialogue, but to send an irc command
<wxl> if you can't type anything (versus the server refuses your entry for some reason) that's certainly a client issue
<CRogers> wxl: I can do nothing in that channel. Polari isn't letting me.
<sarnold> CRogers: /invite wxl #ubuntu
<CRogers> sarnold: I typed that here, but I don't think it wil do any good.
<CRogers> brb
<CRogers> Heh
<CRogers> Nickserv is like: "Identified for CRogers"
<CRogers> Polari is like... nah. :P
<CRogers> It's definitely a bug in Polari.
<CRogers> Sorry for the noise.
<coreycb> bdmurray: ok i've completed verification for https://bugs.launchpad.net/ubuntu/+source/neutron-lbaas-dashboard/+bug/1709604 now
<ubottu> Launchpad bug 1709604 in neutron-lbaas-dashboard (Ubuntu Zesty) "package installs and enables two panels" [High,Fix committed]
<coreycb> bdmurray: i promise :)
<smoser> anyone seen this ? my schroot build fails
<smoser>  http://paste.ubuntu.com/25568080/
<jbicha> smoser: https://launchpad.net/ubuntu/+source/python3-defaults/3.6.2-1ubuntu2
<jbicha> but that same problem is causing the fix to ftbfs :(
<jbicha> doko: ^
<karstensrage> ok LocutusOfBorg im not sure what you are intending to communicate with "do a debdiff of the current unstable package" i have done some debdiffs of the dsc and the changes look correct
<karstensrage> but if you are seeing something else please let me know
<infinity> jbicha: The fix will build once the deletion is published.
<infinity> Or unpublished, as it were.
<LocutusOfBorg> karstensrage, pull-debian-source packagename
<LocutusOfBorg> debdiff it with the one I should sponsor
<LocutusOfBorg> and filterdiff for the debian directory
<karstensrage> LocutusOfBorg, like https://paste.ubuntu.com/25568716/
<infinity> karstensrage: Why the new package?
<infinity> karstensrage: libufpidentity-dev is for dev, and if something's linked against the library, it will get a dependency on libufpidentity1, so identity4c seems entirely pointless.
<karstensrage> infinity, the upstream package was updated
<infinity> karstensrage: Yes... And?
<infinity> karstensrage: That doesn't really answer my question. :)
<karstensrage> i thought this is what i had to do
<infinity> karstensrage: Why the new *binary*?
<karstensrage> binary?
<nacc> someone is reporting (well, technically they are complaining that nont all flavors do this) that mate enables the upstream oracle virtualbox repo by default
<infinity> karstensrage: That diff adds a new binary package, identity4c.deb, whose only purpose is to be an empty package that depends on the library.
<nacc> that seems ... surprising if so, as it would lead to a rather different UX only on mate?
<infinity> nacc: That would be a violation of (admittedly, not well-documented) policy.
<karstensrage> infinity, thats how it was originally packaged
<infinity> karstensrage: Except, it isn't?
<nacc> infinity: that was my guess too, and wasn't where to find said policy :) (still looking to see if it's true)
<sarnold> nacc: eww.
<infinity> karstensrage: It wouldn't be showing up in the diff if that was how it was previously packaged.
<nacc> infinity: sarnold: i'll get a live instance going and see
<karstensrage> im not sure i understand
<karstensrage> im sorry
<karstensrage> im not well versed in packaging
<nacc> karstensrage: there's no identity4c binary package in Ubuntu
<nacc> karstensrage: and your debdiff implies one is being added
<infinity> karstensrage: The current source package produces two binaries: libufpidentity-dev and libufpidentity1.  Your updated version also produces a identity4c package that depends on the library.
<karstensrage> hmm ok
<karstensrage> im not sure why that is the case
<karstensrage> it was only my intention to update the upstream
<infinity> Also, those Vcs-* links still seem to point nowhere useful.
<karstensrage> yes im not exactly sure what those are supposed to be, i just followed the convention in the maintainers guide
<karstensrage> i would be happy to remove them if thats allowed
<infinity> If there's no Vcs, having the links is wrong.
<karstensrage> ok
<infinity> But I'm more curious about how you "accidentally" add a new binary package to debian/control. ;)
<infinity> (Or is this someone else's changes?)
<nacc> karstensrage: how did you do the upstream update? uupdate?
<karstensrage> oh i see what youre saying now... hmm
<karstensrage> wait
<karstensrage> oh oh
<karstensrage> i see what youre saying now
<karstensrage> yes nacc maybe uupdate
<karstensrage> i dont think i "added" that, i think it was added for me by something
<infinity> That would be pretty much impossible.
<karstensrage> i can definitely make it look like it looked before, im sorry for the misunderstanding
<infinity> No automatic tool would have written that Description.
<nacc> uupdate won't do that, afaik (it will only buimp your changelog and create a new dir for the updated version)
<nacc> infinity: good point :)
<nacc> unless ... skynet? :)
<karstensrage> ah ok
<karstensrage> i see more now
<nacc> what a sad (sly?) way to show self-awareness, though! subtly modifying our debdiffs
<tsimonq2> Next weekend project (on my 1,000,000,000 item long list of them), build a bot to do exactly that, write debian/control descriptions :P
<infinity> karstensrage: Just to deal with my own confusion here a bit, are you 'richardl@ufp.com'?
<karstensrage> yes
<infinity> Okay. :)
<karstensrage> so i did this a long time ago
<karstensrage> and its hard to remember what occurred when
<nacc> tsimonq2: heh
<karstensrage> so there are three possible things to upload to, debian, launchpad, (ppa's) and ubuntu
<infinity> karstensrage: Yeah.  Well, Debian and then sync to Ubuntu, since we're already in sync.
<karstensrage> i may have indicated i wanted to do apt-get install identity4c and that is what makes that happen
<infinity> karstensrage: But then PPAs if you feel the urge.
<karstensrage> and all three need different forms of versioning
<karstensrage> iirc
<infinity> karstensrage: Anyhow, libraries shouldn't have a way to install them that way.  That's not particularly reasonable.
<infinity> karstensrage: Libraries should be pulled in as dependencies of things that link to them.
<karstensrage> hmm
<infinity> karstensrage: For instance, there's no way to "apt-get install glibc", you just get it because, well, everything else depends on it.
<infinity> And if you want to develop C, you "apt-get install libc6-dev", or in your case, libufpidentity-dev
<infinity> karstensrage: So, I get the intent, just saying it's not Debian library maintenance best practices or policy.
<infinity> (But drop that delta, and I'd be happy to sponsor the rest to Debian for you, since I assume the issue here is that you're not currently a DM or DD?)
<karstensrage> thats correct im not a DM or DD
<karstensrage> this update is for another module i plan to package as well
<karstensrage> </scary drums>
<infinity> Heh.
<karstensrage> so would you be willing to look over another package and tell me if thats the right track?
<karstensrage> and maybe sponsor that too?
<karstensrage> i will remove that delta and resubmit, i do agree that its odd but i cant recall why or where it got added, i realize now i must have put it in for apt-get install identity4c
<karstensrage> but youre right thats a bit odd
<infinity> karstensrage: I'd be willing to look over more bits, sure.  Also, yes, you should remove the Vcs-* lines if they point to no VCS. ;)
<infinity> karstensrage: Looks like libpam-ufpidentity has the same VCS blackhole bug.
<karstensrage> yeah thats the other one i wanted to know if it was the right track
<karstensrage> there is another library, dependent on this new stuff, libnss_ufp
<karstensrage> youre going to absolutely LOVE that one
<karstensrage> :P
<infinity> Of course.  Can't have a PAM module without an NSS module.
<karstensrage> right
<infinity> I mean, you can, but they do seem to come in pairs. :)
<karstensrage> but i felt it was important to mimic glibc
<karstensrage> so it creates its so just like the others in /lib/
<infinity> Famous last words.
<karstensrage> yeah
<karstensrage> ok let me remove that package and resubmit
<infinity> karstensrage: I also note you haven't tagged a 1.1.0 on github yet.
<infinity> karstensrage: Were you waiting to do that after the package review, in case the reviewer(s) found something you should fix upstream?
<karstensrage> yes and to make sure all the stuff went together, since this is for another library
<karstensrage> the NSS thing
<karstensrage> its much easier for clients to install from packaging, no one really goes to github
<infinity> Check.  So this is a bit of a sanity check review, not a "please upload right now" review, since there's no upstream orig tarball yet?
<karstensrage> correct
<infinity> Works for me.
<jbicha> nacc: I assume the 3rd party repositories are facilitated by the ubuntu-mate-welcome app
<infinity> jbicha: And such facilitation is entirely okay, if it's opt-in.   If the assertion that it's opt-out (or no opting at all) is true, then it's a grave violation of all things Good and Pure and True.
<jbicha> I also assume the Tech Board is generally aware of that app. It's an old Tech Board policy that requires rare, documented exceptions for enabling 3rd party repos by default
<infinity> Well, opt-in with some solid explanation of WTF you're signing up for.
<nacc> fwiw, i think jbicha is right
<nacc> and ubuntu-mate seeds the ubuntu-mate-welcome package
<nacc> so it's opt-out, afaict?
<infinity> I believe I've been off and on aware of it over the years. :)
<infinity> nacc: ubuntu-mate-welcome enables those repos by default?
<nacc> infinity: i'm still downloading the iso, will let you know soon
<nacc> infinity: the above was just as stmt on that package, sorry
<infinity> Anyhow, if it does it by default, it's a pretty nasty bug that we should have caught earlier.
<jbicha> nacc: I believe the additional repos aren't enabled by default but it's very easy to do so and may not be obvious to users what they're doing
<infinity> If it does it on an opt-in basis, but without sufficient warning, it's a normalish bug that should be addressed.
<infinity> If it's opt-in with flashing warnings and sirens, there's nothing to see here.
<nacc> jbicha: infinity: ack, will check
<jbicha> anyway, the Tech Board is aware now ;)
<nacc> heh
<jbicha> btw, Ubuntu Budgie has a welcome app now too
<infinity> jbicha: BTW, that python3-defaults thing finally got over the hump, if you had any specific builds that needed retrying.
<jbicha> infinity: thanks, already retried :)
<infinity> jbicha: Though, it might be that time of year where I should just retry all of artful-proposed so people can whine about spam.
<infinity> (Note that whining about spam generated by the FTBFS packages YOU uploaded has always seemed a bit silly to me)
<karstensrage> ok uploaded
<jbicha> I used to get so excited when the Release Team would send me an email, but then disappointment
<karstensrage> i think that might be what you wanted
<infinity> jbicha: Hahaha.
<jbicha> now they email me all the time :|
<infinity> karstensrage: No idea where you uploaded to (note I was commenting on your pasted diff before).
<infinity> karstensrage: Though, seeing the whole package would indeed be better, if you have a pointer to that.
<slangasek> infinity: somebody already retried all of artful-proposed last week-ish, this might be why you get complaints about spam ;)
<infinity> slangasek: Was that somebody you?
<slangasek> \no
<slangasek> I suspect doko
<infinity> If it wasn't me, I question if it was "all of", unless someone wrote a very, very, very slow API client to do it.
<karstensrage> infinity, https://mentors.debian.net/package/identity4c
<infinity> Since I'm one of the few with access to do it directly from ftpmaster without seven hours of round trip hell.
<infinity> karstensrage: Ta.
<slangasek> infinity: well, I got a /lot/ of random build failure mails, but yeah, not sure
<infinity> But also, I figure the solution to "I don't like FTBFS mails on old uploads" is "fix your old upload".
<jbicha> any AA volunteers to remove the ostree binaries from artful/s390x, general tracker bug is LP: #1712083
<ubottu> Launchpad bug 1712083 in gjs (Ubuntu) "Please remove gjs/s390x" [Undecided,Fix released] https://launchpad.net/bugs/1712083
<infinity> I get more than most, since I "own" all the proposed-to-proposed forward-copies, but most others shouldn't have that excuse.
<jbicha> the Debian ostree package build-depends on s390x already so it currently doesn't build on s390x at all
<jbicha> *build-depends on gjs
<infinity> Ugh.
<infinity> WHY DO PEOPLE DO THIS.
<infinity> Maybe I should just make the tools not allow it.
<infinity> So, the problem with removing existing published binaries is that they'll come back if the source is copied around.
<infinity> Like, say, when opening a new series.
<infinity> The correct way to do this is to upload a mozjs and gjs that no longer produce s390x binaries, than reupload all the rdeps so they end up dep-waiting.
#ubuntu-devel 2017-09-19
<jbicha> cortina and meta-gnome3 are the only 2 I see that will need new uploads now then for that
<jbicha> so I'll do that now
<infinity> Well, ostree clearly does, or it wouldn't have s390x binaries.
<infinity> Not sure I want to hunt through the rest of the bug to see if others are in such a state.
<jbicha> yes but as long as we can get the newer ostree to migrate that will be fixed
<infinity> jbicha: Eh?
<slangasek> infinity: when people are retrying builds for things that ftbfs on random archs that have never built, and I get email for those, I absolutely reserve the right to not like the emails and not commit to fixing the builds
<infinity> jbicha: The new ostree has s390x binaries.
<infinity> slangasek: Okay, it's fair that we could do with some regression history, so we could maybe tag FTBFS mails in a filterable way.
<jbicha> infinity: no, it's in depwait (and my diff is unnecessary) https://launchpad.net/ubuntu/+source/ostree/2017.11-1ubuntu1
<infinity> jbicha: Oh, there's a VERY new one. :)
<infinity> jbicha: I was looking at rmadison, silly me.
<jbicha> ok
<infinity> jbicha: Alright, removing away.
<infinity> jbicha: Thanks for weathering my rant with rational responses. :P
<jbicha> infinity: since you're opinionated, do you prefer I have cortina build-depend on gjs (so depwait) or specify a list of architecture to build for?
<slangasek> infinity: to your rant though, I want to double-check I'm not doing something wrong - my usual response to "please remove these binaries" is "please give me a new version in -proposed that isn't just going to bring those binaries back."  so I'm in the clear, right?
<infinity> slangasek: Right.  Binary removal should only happen if the binary is NBS.
<jbicha> cortina/s390x has an unsatisfiable depends on gnome-shell, which confuses britney I believe
<slangasek> ok
<infinity> slangasek: I mean, there should also be due diligence to make sure that version in proposed will actually migrate, but basically the right track there.
<infinity> jbicha: That doesn't confuse britney, britney's correct.
<infinity> jbicha: ostree cleaned up.
<infinity> (And so noted in the bug)
<infinity> jbicha: As for the question, I prefer the unnecessary build-dep method (though, really, it should build-dep on gnome-shell, since that's what it depends on) because, while it's a bit heavy-handed and gross, it has the advantage of "fixing itself" if the stack suddenly becomes buildable again.
<infinity> jbicha: And also doesn't need adjusting for new arches.
<jbicha> ok
<doko> slangasek, infinity: I gave back all packages last week, because it wasn't done since April
<infinity> The amount of the archive that isn't built on Random Arch X purely because the maintainer chose an Architecture line 13 years ago that no one has since reviewed for accuracy is larger than you'd think.
<jbicha> there's a chance someone in Debian will figure out gettings mozjs52 to work on other archesâ¦
<infinity> doko: Thanks.
<doko> and yes, it built a handful more packages sucessfully
<infinity> jbicha: Well, afaik, newer mozjs is entirely dependent on rustc being non-crap, which arch maintainers are working on, so it might just kinda fix itself over the next 6-12 months on a few arches.
<doko> well, working on rust is wishful thinking
<infinity> doko: I don't mean downstream arch maintainers, I mean IBM has people working on it.
<infinity> I certainly am dedicating exactly as much time to rustc as I did to golang.
<jbicha> I think mozjs52 is pre-rust but yeah, the future will be fun
<infinity> jbicha: Ahh, if it's pre-rust, it may just be a legit silly endian bug or something and, indeed, Debian might fix it.
<infinity> jbicha: The future actually looks pretty good for mozilla after the switch to rust, IMO.  And that's coming from someone who's sick of "oh look, a new compiler that needs porting."
<jbicha> https://buildd.debian.org/status/package.php?p=mozjs52 ( you can probably ignore mips64el but the other test failures are really bad)
<infinity> jbicha: Cause at least this compiler WILL be ported (over time).
<infinity> jbicha: The most complex part of firefox that ALWAYS broke on non-primary arches was mozjs, so switching to a highly-portable thing that needs less babysitting by port maintainer might make firefox Just Work a lot more often than it used to.
<infinity> (Again, in a wonderful future of a year or three when rust's ports are all solid)
<jbicha> it's nice that GNOME is now on the latest mozjs (ESR) instead of mozjs24 like we were a year ago too
<infinity> Of course, if you take my above analysis to extremes, I may have just accidentally advocated writing a javascript interpreter in Perl.
<infinity> Which I don't recommend.
<infinity> (Though it wouldn't be any worse than jbailey's pet project to write a libc in js)
<jbicha> if you're in a removing mood, want to remove some or all of the packages at LP: #1710318? we might leave a few webkitgtk rdeps in artful but it doesn't need to be so many
<ubottu> Launchpad bug 1710318 in xiphos (Ubuntu) "Please remove webkit1 rdepends removed from Debian Testing" [Undecided,New] https://launchpad.net/bugs/1710318
<infinity> jbicha: I have to run out to the hospital shortly, but I have a browser tab open to look at it.
<infinity> karstensrage: Oh, ditto to you.  I got sidetracked a bit here.  But when I get back, I'll have a poke at your stuff.  What timezone are you in?
<karstensrage> Pacific
<jbicha> infinity: what time zone are you in? lol
<infinity> karstensrage: Ahh, kay.  I'm Mountain.  So if we need some real-time back-and-forth on this (and your NSS module), let's talk tomorrow.
<karstensrage> hope all is well infinity and thank you for your patience with me
<karstensrage> will do
<infinity> jbicha: I'm in both all of them and none of them.  And even moreso the last week or two with the above mentioned hospital issue. :/
<jbicha> best wishes
<infinity> There are many crossed fingers.
<infinity> Mom's scheduled for all the open heart surgery ever next week.
<infinity> Which is a bit scary.
<infinity> A lot scary.
<gaughen> infinity, slangasek - would you, or someone else with a release team hat, have a look at - https://bugs.launchpad.net/ubuntu-power-systems/+bug/1706248
<ubottu> Launchpad bug 1706248 in slof (Ubuntu) "[FFE] SLOF dhcp request doesn't include client architecture code 93" [Medium,Confirmed]
<infinity> gaughen: I'm conceptually okay with a new SLOF from an HWE perspective, but I think I'd like to give it a once-over/test-drive, and chat with Aurelien about doing it in Debian too.
<infinity> gaughen: So putting that open browser tab on my "will look a bit later".
<gaughen> fair enough
<infinity> Also super curious about this "new boot menu" thing, since firmware presenting boot menus is usually a bad thing, in my experience, not a good one. :P
<gaughen> cpaelzer, ^^ fyi re: ffe on slof
<gaughen> infinity, from the perspective of users select options they shouldn't?
<infinity> gaughen: I want to see what they mean by "boot menu".  If it's "hit a key combination to enter forth prompt", fair enough, if it's some nasty attempt to present what grub should be presenting, ick.
<gaughen> yeah that is ick
<infinity> gaughen: Anyhow, the motivation for the bug report (the dhcp thing) feels like something we'd want to cherry pick back to (at least) xenial, so worth someone looking at that while I also evaluable the wholesale version bump.
<infinity> evaluate, too.
<infinity> evaluable?  Really, fingers?  THAT'S NOT EVEN A WORD.
<slangasek> UEFI has a boot menu, it must be a good idea
<infinity> slangasek: Yeah, and it's STELLAR.
<infinity> Except the other thing.
<infinity> Also, see petitboot as exhibit suck.
<slangasek> yes, I was just seeing petitboot this afternoon
<infinity> My condolences.
<slangasek> for half a second, before its 10 second boot timeout triggered after I had waited a half hour for it to load
<cjwatson> Evaluable is totally a word.  Just not the word you wanted.
<infinity> Err, yes it is.  But not in the way I was thinking.
<infinity> e-valuable is how my brain broke it apart.
<cpaelzer> good morning
<Unit193> Heya.
<jamespage> o/
<doko> stgraber: autopkg test failures triggered by lxc
<doko> jamespage: cinder autopkg test failure on s390x
<jamespage> doko: looking now
<LocutusOfBorg> hello chrisccoulson, doesn't rust need a sync from debian? because of firefox?
<LocutusOfBorg> (actually a merge probably)
<chrisccoulson> unless you're also going to do cargo, please do not sync or merge rust
<ricotz> LocutusOfBorg, chrisccoulson, notice/remember libgit2
<ricotz> chrisccoulson, please see PM
<LocutusOfBorg> chrisccoulson, I was asking about what firefox requires, I don't plan to do it :)
<LocutusOfBorg> ricotz, what is the libgit2 problem?
<LocutusOfBorg> is somebody requesting a ffe?
<ricotz> LocutusOfBorg, debian is not shipping it internally and relies on it as system-dep which won't work on ubuntu
<ricotz> since backport down to trusty are required
<ricotz> LocutusOfBorg, so don't plainly take it from debian
<ricotz> basically the toolchain for firefox 56 is already done
<ricotz> the version of rustc/cargo which are in debian currently will be required beginning with firefox 57
<LocutusOfBorg> ok, anyway, I don't plan to do cargo/libgit2/rust work
<LocutusOfBorg> I was just asking in case you want to prepare for FF57
<LocutusOfBorg> libgit2 will be autosyncd btw when 18.04 opens
<ricotz> LocutusOfBorg, I think rustc/cargo should not be synced, e.g. even likely that ff56 won't build with rustc 1.20
<rbasak> xnox: any progress on bug 1691096 please? AFAICT, it's a bug in systemd and I'd like to start considering it release-critical for server.
<ubottu> bug 1691096 in systemd (Ubuntu Artful) "mysql in lxd fails to start with systemd 233, 234: failed at step KEYRING" [High,Triaged] https://launchpad.net/bugs/1691096
<rbasak> ahasenack: ^
<ahasenack> thx
<sil2100> hm, we seem to be having some issues with our autopkgtests in our ubuntu-image CI
<sil2100> Looks like it has problems installing haveged?
<sil2100> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-canonical-foundations-ubuntu-image/artful/amd64/u/ubuntu-image/20170918_021026_e3fc6@/log.gz
 * sil2100 tries re-running
<xnox> sil2100, universe is not enabled?
<sil2100> Did it get disabled from the infra?
<sil2100> Since I don't think this is anything we control
<stgraber> doko: I know, I've been watching :)
<nacc> jbicha: infinity: ok, setup a mate VM of 16.04.3. In the 'boutique', if i search for virtualbox, both virt-manager and oracle's virtualbox show up (confusingly not the one from multiverse). No repository is setup for virtualbox initially (that I can see in boutique). If I click on install oracle virtualbox, it queues it and then if i click on apply changes, the third party virtualbox repo has been
<nacc> added and a non-ubuntu package has been installed. Now, it does say the source is oracle's repo (by URL), but I'm not sure a regular user would konw it's unsupported software (by Ubuntu)
<nacc> infinity: not sure if that still constitutes a policy violation or not; it's opt-in, but not at all obvious to an end-user what they are opting in to, imo
<rbasak> ddstreet: sorry, I didn't realise you had a new patch for me there. I don't think forcing use of gcc-6 is a suitable fix for the development release though. I suspect doko wouldn't be happy about that.
<rbasak> ddstreet: I think I'd already made suggestions on this channel?
<ddstreet> rbasak it's being worked by niedbalski who is actually out today, but i'll pass that on to him, so he may ping you tomorrow
<pitti> wgrant: trouble with lgw again? most builders seem to be stuck in "cleaning" again (some spot checks like https://launchpad.net/builders/lgw01-amd64-041/+history says 6 hours)
<karstensrage> infinity, very sorry to bother you, no worries if you have more pressing issues, any preliminary comments? Id like to get started on the new NSS packaging
<karstensrage> i assume since thats new it will be an ITP and then a RFS so it goes through the normal process
#ubuntu-devel 2017-09-20
<infinity> karstensrage: Sorry, yeah.  Haven't had a chance yet.  It's been a messy 24h.
<karstensrage> i understand, very sorry
<alkisg> Good morning
<alkisg> smoser: Re: #1718227, does that need action from the developers of those affected packages, or netplan will gain support for calling if{up,down}.d script and us developers just need to test that it works fine?
<slangasek> alkisg: netplan only feeds configuration into the network renderer (systemd-resolved or network-manager).  It does not call any scripts, and neither does systemd-resolved
<alkisg> slangasek: AFAIK, network-manager does have a compatibility layer that calls ifupdown scripts
<slangasek> yes. networkd does not, and will not
<alkisg> slangasek: to rephrase... as the developer of one of the affected packages (epoptes), I don't know what I'm supposed to do with that bug
<slangasek> alkisg: add a systemd unit that handles the corresponding events from systemd
<alkisg> OK, so it's not actually about supporting netplan, but about supporting systemd-networkd?
<slangasek> yes
<alkisg> Got it, thank you :)
<alkisg> slangasek: ehm, an additional question just to make sure... so the best resolution is to ship (1) ifupdown scripts for backwards compatibility, (2) network-manager dispatcher.d scripts for those using nm, and (3) networkd units, for those using that?
<alkisg> Or just (3) is enough for 16.04+ compatibility?
<alkisg> Is everyone guaranteed to be running networkd from some release and on/
<alkisg> ?
<slangasek> alkisg: desktops will continue to use Network Manager, so really you want to integrate with both NM and networkd going forward
<slangasek> alkisg: looking at /etc/network/if-up.d/epoptes-client, I wonder if this shouldn't be some combination of a udev rule, and a systemd unit that starts on network-online
<slangasek> because the latter is a generic entry point supported by all network renderers
<alkisg> slangasek: the basic task there is to relaunch the client when the ip changes
<alkisg> As it doesn't have enough intelligence to reestablish the ssl tunnel using the new ip
<alkisg> network-online wouldn't be recalled when the ip changes, would it?
<slangasek> alkisg: correct, it would not; but I don't see anything there that shuts down the previous client, where does that happen?
<alkisg> Just running epoptes-client (the last line) takes care about all that
<alkisg> Terminating the previous instance and running a new one
<slangasek> ok
<slangasek> arguably, this should be implemented using netlink instead, to reconnect when the source IP changes - for any reason
<alkisg> Thank you, I'll read about that
<slangasek> however, netlink is basically impossible in shell, and barely possible in C ;)
<alkisg> Whoops :)
<slangasek> still, that's the way you subscribe to kernel network change events
<seb128> wgrant, hey, could you trigger an artful langpack export manually? I would like to refresh the base pack to look at where we stand with those without having to wait for next monday
<wgrant> seb128: Have you hit the web UI flag to request the full export?
<seb128> wgrant, yes
<wgrant> seb128: It's running now.
<seb128> wgrant, thanks! do you know how long the job takes nowadays?
<wgrant> seb128: Looks like about 3h15
<seb128> nice
<seb128> thx
<LocutusOfBorg> kirkland, hello, wrt your pdf (thanks for sharing it)
<LocutusOfBorg> page 18, rhythmbox is in two different graphs
<LocutusOfBorg> because many people mispelled it
<xnox> infinity, netcfg: relocation error: /lib/libnss_dns.so.2: symbol __resolv_context_get, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
<xnox> i wonder what am I doing wrong
<xnox> hm my libc.so.6 checksums don't match
<xnox> ok rebuild again, and things are fine
<xnox> unping
<cpaelzer> LocutusOfBorg: I remember doing so on other packages but I fail to find the link to the old llvm versions debs to download for bug 1717574
<ubottu> bug 1717574 in clamav (Ubuntu) "freshclam crashed with SIGABRT in __assert_fail_base()" [Medium,Confirmed] https://launchpad.net/bugs/1717574
<cpaelzer> I thought to remember something like built binaries being a list of debs, but can't find the right link from publishing hostroy to them atm :-/
<cpaelzer> ah on the builds
<LocutusOfBorg> exactly
<LocutusOfBorg> click on the version, and grab the debs
<cpaelzer> I knew I did that before :-)
<LocutusOfBorg> snapshots.debian.org works better indeed
<LocutusOfBorg> you just need libllvm3.9 AFAICS
<cpaelzer> for dependencies it is libllvm3.9 llvm-3.9 llvm-3.9-dev llvm-3.9-runtime, which isn't much harder
<cpaelzer> while the case is building I can script the fetch of all those pkg's
<doko> mehh, opencv was synced from experimental :-/
<blaze> qtcreator still depends on outdated llvm libllvm3.9 (>= 1:3.9.1-6~), isn't it possible to rebuild it?
<cpaelzer> LocutusOfBorg: since 1:3.9.1-13ubuntu6-13377849
<cpaelzer> LocutusOfBorg: but there was quite a lot in between
<cpaelzer> LocutusOfBorg: that was on those that released, I'll split those that at least built and made it into LP publishing history after lunch
<doko> mapreri: please could you have a look at the sikuli ftbfs? works with opencv2 in debian ... you synced the new one from experimental
<mapreri> doko: you mean sikulix?  well, I only did https://launchpad.net/ubuntu/+source/sikulix/1.1.0-2build1 that went just file (+ ubuntu1 to fix an hardcoded dependency)
<mapreri> i.e. didn't do anything extra/special for it
<doko> mapreri: well, changes lists you ask the one syncing ...
<doko> as even
<mapreri> doko: I'll have a look, as that means we have yet another package breaking with opencv 3 now, and we're struggling to take that transition to an end :\
<mapreri> just not today
<doko> ta
<doko> mapreri: so my idea to sync opencv again was not a good idea. probably will reject it, currently sitting in NEW
<cpaelzer> LocutusOfBorg: more specific it broke 1:3.9.1-13ubuntu4-13351809 -> 1:3.9.1-13ubuntu6-13377849
<mapreri> doko: yes, I recommend against.  OCV 3.2 brings more FTBFS among its rdeps that 3.1 doesn't.
<mapreri> I aim at working on it on the debian side (finally) during the next days and the week end
<LocutusOfBorg> cpaelzer, since the failure happens on i386 too, would be nice to test 3.9.1-13ubuntu5
<LocutusOfBorg> doko, how could using -g1 instead of -g cause the issue https://launchpad.net/bugs/1717574
<ubottu> Launchpad bug 1717574 in clamav (Ubuntu) "freshclam crashed with SIGABRT in __assert_fail_base()" [Medium,Confirmed]
<LocutusOfBorg> blaze, why? there is no need to have a stricter dependency
<doko> does clamav use unwinding internally?
<cpaelzer> LocutusOfBorg: need to setup an nev doing so on i386, but ok easy enough
<LocutusOfBorg> I uploaded something in a ppa
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+packages
<LocutusOfBorg> it won't probably build
<LocutusOfBorg> also, I expect it to fail also here http://debomatic-amd64.debian.net/distribution#unstable/clamav/0.99.3~beta1+dfsg-2build1/buildlog
<LocutusOfBorg> since the same llvm is in Debian
<LocutusOfBorg> if it doesn't fail, I would blame glibc
<cpaelzer> The same test doesn't trigger in i386
<cpaelzer> I'll check out your ppa ocne built
<blaze> LocutusOfBorg: look at the package name: libllvm3.9
<LocutusOfBorg> libllvm3.9 (>= 1:3.9.1-6~),
<blaze> now I have 3.9, 4.0 and 5.0. Isn't it a bit toomuch
<LocutusOfBorg> this means, everything with an higher value
<LocutusOfBorg> blaze, if you want to port the code to llvm 4.0, 5.0 or 6.0, you are welcome to do it
<LocutusOfBorg> cpaelzer, http://debomatic-amd64.debian.net/distribution#unstable/clamav/0.99.3~beta1+dfsg-2build1/buildlog
<LocutusOfBorg> good
<LocutusOfBorg> so I blame glibc
<cpaelzer> wow that worked
<cpaelzer> interesting
<cpaelzer> so this becomed a package update love triangle then
<LocutusOfBorg> my package won't probably build because llvm takes too memory on amd64 without -g1
<LocutusOfBorg> rbalint, unattended-upgrades merge?
<smoser> slangasek, i'm not sure that "it's not actually about supporting netplan, but about supporting systemd-networkd?" is true.
<smoser> from a forward looking perspective, systemd-networkd is happenstance and netplan is design. i'd much rather tell people "this is how you integrate with netplan" and promise that that will work in 18.04, 20.04 and 22.04 then "integrate with systemd-networkd and then we might tell you something else in 20.04"
<smoser> ie, it *is* about supporting netplan.  and netplan being able to support things that interact with networking events.
<ddstreet> bdmurray can you approve artful nomination for lp #1716964 please
<ubottu> Launchpad bug 1716964 in vlan (Ubuntu Zesty) "VLAN network script if-up.d/ip limits rp_filter value to 0 or 1" [Medium,In progress] https://launchpad.net/bugs/1716964
<doko> bdmurray: 1715641 doesn't match the changelog. wrong number?
<rbalint> LocutusOfBorg: yes, i'm preparing it
<LocutusOfBorg> cpaelzer, interestingly, clamav builds on all except amd64 and i386
<kirkland> LocutusOfBorg: indeed, turns out "rhythm" is a hard word to spell :-)
<LocutusOfBorg> :)
<LocutusOfBorg> kirkland, fortunately the outcome didn't change
<LocutusOfBorg> it is still in second place
<doko> rbasak: is mariadb serverish? if yes, there are autopkg test failures on ppc64el and s390x
<LocutusOfBorg> btw such results, are probably somewhat faulty, because people who answered, are probably ubuntu users, and Ubuntu always used gnome apps
<rbasak> doko: yes, though not in main. I've passed on a message to one of the DDs who looks after it for us in Ubuntu.
<rbasak> (well, pinged him on IRC at least - #debian-mysql on OFTC)
<doko> ta
<xnox> doko, yes but it is systemd fault
<xnox> rbasak, unping
<ricotz> LocutusOfBorg, hi, regarding your mention of rustc/cargo, syncing libgit2 0.26.0 would still be nice
<ddstreet> bdmurray would you like to sponsor a bug for me into artful?  or cpaelzer perhaps?  lp #1716964 please
<ubottu> Launchpad bug 1716964 in vlan (Ubuntu Zesty) "VLAN network script if-up.d/ip limits rp_filter value to 0 or 1" [Medium,In progress] https://launchpad.net/bugs/1716964
<cpaelzer> ddstreet: bdmurray: I'm looking at it
<ddstreet> cpaelzer thnx
<ddstreet> bdmurray i have another one you could sponsor please, lp #1718055
<ubottu> Launchpad bug 1718055 in initramfs-tools (Ubuntu) "update-initramfs fails for MODULES=dep when root is on LVM wich uses nvme device" [Medium,In progress] https://launchpad.net/bugs/1718055
<LocutusOfBorg> ricotz, but out of Ffe
<doko> nacc: https://launchpad.net/ubuntu/+source/pacemaker/1.1.17-1ubuntu1
<nacc> doko: yeah, it's ftbfs in debian too
<nacc> doko: LP: #1712441
<ubottu> Launchpad bug 1712441 in pacemaker (Ubuntu) "pacemaker 1.1.17-1ubuntu1 FTBFS" [Undecided,New] https://launchpad.net/bugs/1712441
<cpaelzer> LocutusOfBorg: I see your llvm ppa at dh_install so it might even succeed
<LocutusOfBorg> cpaelzer, strange
<LocutusOfBorg> I see it too
<rbasak> xnox: error: ping stack underflow :-)
<xnox> rbasak, que....?
<rbasak> <xnox> rbasak, unping
<rbasak> Never mind :)
<xnox> rbasak, hahahahah =) ok
 * xnox doesn't understand underflow jokes, i mostly code in C </giggles>
<slangasek> seb128: uhhhh how is gnome-software using packagekit instead of aptdaemon now?  that's not ok
<seb128> slangasek, why is it not ok?
<seb128> slangasek, it's bug #1673258, aptdaemon is unmaintained for years
<ubottu> bug 1673258 in update-notifier (Ubuntu) "Remove aptdaemon and drop or port its reverse-dependencies" [Undecided,New] https://launchpad.net/bugs/1673258
<slangasek> seb128: packagekit's lack of debconf integration is a critical blocker, we JUST fixed all the regressions with debconf handling that were breaking users from being able to enable dkms modules on secureboot systems
<slangasek> yes, aptdaemon is unmaintained; but packagekit is broken by design
<slangasek> this needs to be reverted
<seb128> slangasek, I though that debconf was working in gnome-software now (robert_ancell fixed that iirc)
<seb128> slangasek, I don't think it's as simple as "can be reverted"
<slangasek> seb128: AIUI it was working by way of an aptdaemon backend, not packagekit
<slangasek> am I mistaken?
<seb128> could be, I didn't check
<seb128> Laney probably knows more
<slangasek> ok
<slangasek> I thought you were referring to a recent change in artful :)
<seb128> it's not that old
<seb128> we dropped our aptd backend and switching to packagekit in 3.25
<seb128> which landed in august iirc
<slangasek> ok hmm
<slangasek> cyphermox, bdmurray: ^^ we need to revalidate virtualbox install on secureboot in 17.10
<seb128> did anyone test recently?
<slangasek> seb128: not in the past month, I'm sure
<bdmurray> slangasek: I forget was there a bug with instructions for testing that?
<Laney> I don't know that PK doesn't work with debconf.
<slangasek> bdmurray: LP: #1679435 is the bug
<ubottu> Launchpad bug 1679435 in gnome-software (Ubuntu Artful) "GNOME Software fails to install .deb packages that trigger debconf prompts" [High,Fix released] https://launchpad.net/bugs/1679435
<Laney> Robert worked on that https://mail.gnome.org/archives/gnome-software-list/2017-May/msg00010.html
<slangasek> was that with the pk backend?  I don't know.  if there's been a change, we need to revalidate
<slangasek> in any case, there are also architectural problems with how pk approaches apt that are going to be a problem down the line
<slangasek> infinity can speak to this
<infinity> slangasek: I mean, I can in theory.  I'm pretty sure I need to re-evaluate the current state of the world.
<slangasek> ok
<infinity> slangasek: In the past, pk's approach to apt/dpkg was "install the package you asked for and hope for the best, and hey, maybe we'll try some crap dependency resolution on our own", ie: it entirely bypassed apt.
<infinity> slangasek: aptdaemon, of course, is the other end of the insane spectrum, which is "hand off an exact apt-get call to aptdaemon, and let it go to town", which gets perfect results, but also assumes you entirely trust the every bit of that pipe.
<cjwatson> I think that must have been quite a while in the past
<cjwatson> I haven't looked very recently, but when I was trying to understand packagekit for click, it made basically sensible apt transactions
<infinity> slangasek: I haven't looked at the current state of pk, but unless they invoke apt or python-apt to do proper resolution, I have doubts it'd be any better than it once was.
<infinity> cjwatson: Okay, that sounds promising.  What do you mean by "apt transactions"?  Does it invoke apt via backend priv escalation?
<infinity> (Which would, effectively, make it aptdaemon part two)
<cjwatson> it's using libapt
<infinity> s/part/mark/
<cjwatson> in C++
<cjwatson> (I think)
<infinity> Well, that's definitely more promising then.
<cjwatson> see backends/aptcc/ (you might want to check that that's actually still the backend in use)
<infinity> Probably still has issues with bubbling up dpkg interaction, but aptdaemon had that same problem (it's just that aptdaemon frontends were usually written to know that).
<infinity> Anyhow, if it's using libaptpkg, I think many of my old concernes might be moot.
<cjwatson> You should definitely actually review its current state, since it sounds like your concerns are from several years ago at least.
<infinity> I still loathe the gnome-software UI, but that's not a technical concern. :P
<infinity> cjwatson: Oh, indeed, as mentioned when I jumped into the conversation, my concerns are based on outdated information from the last time I argued with pk and gave up ever wanting to use it on dpkg systems. ;)
<infinity> And I believe that was from the last time someone suggested update-manager should be ported to pk, and the conclusion was "lol, no".
<slangasek> cool; if the net is that pk does meet our needs and we can migrate to it, that's a good item to have off the lits
<cjwatson> At one point there was a threat to remove aptcc due to undermaintenance, but I see a chunk of maintenance from (mainly) Ubuntuish people that's more recent than that.
<cjwatson> So that's probably not a problem any more.
<slangasek> however, since we didn't expect pk to be a viable replacement for aptdaemon, we haven't scoped that work for update-manager this cycle
<infinity> slangasek: Yup, definitely worth re-evaluating the world here and seeing if aptdaemon can indeed die.
<cyphermox> slangasek: I have this brand new install of artful where I can go install virtualbox from the software tool
<slangasek> cyphermox: so you're going to take care of validating this and bdmurray doesn't need to look further?
<cyphermox> sure, I'm kicking it *now*
<slangasek> ok
<cyphermox> or I would have, if gnome-software hadn't crashed on me
<slangasek> dun-dun-dunnnnn
<cyphermox> it's working now...
<cyphermox> I do have a prompt. That was using the image from yesterday
<cyphermox> is that software/pk change something that landed today?
<Laney> no
<Laney> several weeks ago
<cyphermox> ah, backlog tells me
<cyphermox> right
<cyphermox> that's what I thought too, just making sure
<cyphermox> thanks Laney
<Laney> sounds good, we can not panic?
<Laney> :-)
<cyphermox> yes, we can not panic
<Laney> great, thanks
 * cyphermox moves the hands away from the Big Red Panic Button
<cyphermox> Laney: how can I make very sure this indeed used PK and not aptdaemon, given that aptdaemon is still on the system?
<cyphermox> I mean, I would expect things to just use DBus, but as I recall aptdaemon has just enough DBus pretention of being PK
<Laney> it doesn't, that was dropped
<cyphermox> oh right, I dropped it :)
<Laney> there's probably PackageKit stuff in the journal
<cyphermox> indeed
<cyphermox> history.log mentions this was a Commandline: packagekit role='install-packages'
<bdmurray> I tested it with the noisy-fake-driver deb and it worked for me too with packagekit in the history.log
<Laney> â¥
<slangasek> \o/
<slangasek> cyphermox, seb128, Laney, bdmurray: thanks for the double-check
<slangasek> now if we could figure out how to make that an autopkgtest... :)
<cyphermox> make the installing the driver
<cyphermox> ?
<cyphermox> should be "doable", but requires an UEFI-SB-enabled VM
<slangasek> we would need to be able to drive gnome-software programmatically
<cyphermox> that too
<slangasek> it doesn't have to be SB-enabled, see fake-noisy-driver
<cyphermox> oh, that one is doing straight debconf?
<cyphermox> because you don't necessarily have to run gnome-software programmatically, it could be dbus-driven, as a PK autopkgtest.
<cyphermox> (I think)
<LocutusOfBorg> cpaelzer, works :/
<Laney> there's a gnome-software-cmd
<Laney> feel free to look at / hack on that :-)
<Laney> (also, it has a testsuite)
<Laney> not an autopkgtest one, but it is a start
<slangasek> cool, then we would just need to divert the gnome debconf frontend :)
<slangasek> cyphermox: this is not about autopkgtesting pk, it's about autopkgtesting gnome-software.
<slangasek> autopkgtesting pk itself would be useless, because the debconf passthrough has to be setup /by/ gnome-software
<cyphermox> ah, right :(
<cpaelzer> LocutusOfBorg: the ppa build works, I updated the bug
<smoser> ok. clearly i dont know what i'm doing
<smoser> i go https://extensions.gnome.org/extension/615/appindicator-support/
<smoser> i click 'on'
<smoser> it moves over, but then reloading the page shows 'off' again.
<LocutusOfBorg> strange cpaelzer , really strange
<nacc> smoser: fwiw, i thikn there's something lower level busted with extensions in artful
<nacc> smoser: you're not the onnly one to complain of this (and i see it too with the tweak tool)
<nacc> smoser: the only extensions i got to to 'stay on' were those that had the gear and in their submenu i had to turn them on as well
<smoser> nacc, :-(
<nacc> smoser: yeah
<smoser> nacc, i completely removed just about all my .* files
<smoser> tried agin
<smoser> now i get 'error'
<nacc> smoser: yeah, have a test user for the same purposes
<nacc> smoser: i can switch over to it later and check
<smoser> seems like it must have worked at some point
<smoser> https://didrocks.fr/2017/08/23/ubuntu-gnome-shell-in-artful-day-7/
<smoser> anyone know how to configure more than 2 virtual desktops or viewports or whatever they're called.
<smoser> logged in to default Ubuntu (which i'm pretty sure is wayland now)
<jbicha> smoser: I recommend installing gnome-tweak-tool 3.26.1-1ubuntu1 which has some fixes for the Workspaces panel
<jbicha> it's brand new
<smoser> jbicha, in -proposed ?
 * smoser gets
<nacc> not in artful at all afaict
<nacc> artful or artful-proposed
<nacc> per rmadison
<nacc> jbicha: --^
<smoser> https://launchpad.net/ubuntu/+source/gnome-tweak-tool
<smoser> ^ shows in -proposed as of 16 minutes ago. you are way behind the times nacc
<nacc> smoser: ah rmadison hasn't seen it yet
<jbicha> I did say it was brand new ;)
<nacc> heh
<dmj_s76> Trevinho: I think there are some issues with the new scaling code in gnome 3.26.
<dmj_s76> There's been a fairly recent regression where the shell text is tiny every login.  the control center also requires the user to set the scale twice for it to actually take effect.
<jdstrand> xnox: hi! so, in your estimation, is there anything special I should have to do to ssh into lxd containers or libvirt qemu guests on artful? (ie, with systemd-resolved)
<nacc> jdstrand: (to be clear (from #snappy) -- i have the ssh snippet stgraber recommended)
<nacc> jdstrand: and i generally use uvt-kvm for VMs
<stgraber> right and that snippet bypasses DNS so you don't have to fight with systemd
<nacc> yep
<jdstrand> xnox: ok, nm on lxc (nacc is referring to http://paste.ubuntu.com/25582138/ for lxd), but how about libvirt?
 * jdstrand nods
<jdstrand> I could probably do the same with libvirt
<jdstrand> that would be way better than injecting stuff into resolved, only to have it occasionally forget
<stgraber> jdstrand: https://stgraber.org/2012/07/17/easily-ssh-to-your-containers-and-vms-on-ubuntu-12-04-lts/
<stgraber> jdstrand: that has the .libvirt equivalent
<jdstrand> nic
<jdstrand> nice even
<jdstrand> stgraber: that is *super* helpful. I've been using way worse workarounds for so long it is sad
<jdstrand> stgraber: thanks! :)
<jdstrand> ah right, the dnsmasq looks at the host's configuration so you get:
<jdstrand> $ host sec-xenial-amd64 192.168.122.1
<jdstrand> ...
<jdstrand> sec-xenial-amd64 has address 192.168.122.182
<jdstrand> Host sec-xenial-amd64 not found: 2(SERVFAIL)
<jdstrand> ;; connection timed out; no servers could be reached
<jdstrand> which is slow and annoying. however, libvirt now has virsh domifaddr
<jdstrand> so I can use that
<ddstreet> very good .ssh-config-fu ^ I will have to use similar modifications for my lxd/uvt-kvm instances
<nacc> ddstreet: if you use uvt-kvm, then i thinkn you can use `uvt-kvm ip <isntance>`
<nacc> ddstreet: or just use uvt-kvm ssh <instance> :)
<ddstreet> nacc i do that, but uvt-kvm ssh forces you to use --insecure every time
<ddstreet> so right now i alias uvssh='uvt-kvm ssh --insecure'
<nacc> ddstreet: heh
<nacc> good poitn
<ddstreet> but throwing a bit of .ssh/config logic in there will let me ssh to them even more easily
<ddstreet> and lxd containers too, i just do lxc exec bash now
<jdstrand> ddstreet: I landed on this for libvirt: http://paste.ubuntu.com/25582228/
 * nacc suggests someone do a blog post
 * jdstrand is doing it now :)
<nacc> heh
<ddstreet> jdstrand that's pretty good i may steal that for my .ssh/config ;-)
<ddstreet> jdstrand nacc this is what i wound up with for lxd: http://paste.ubuntu.com/25582407/
<ddstreet> just uses the first non-lo ipv4 addr it finds
<nacc> ddstreet: why not just use -c4 like the other one?
<nacc> ddstreet: which explicitly askes for the ipv4 config?
<ddstreet> nacc -c4 to what, cut?
<nacc> ddstreet: lxd list
<nacc> *lxc list
<ddstreet> nacc yeah you can do that, parsing that table output is a bit harder imo
<cjwatson> lxc list --format=json would probably be more sensible than all this seddery
<cjwatson> with jq
<cjwatson> shame info doesn't have that
<nacc> ddstreet: i'm just quoting stgraber's reference :)
<nacc> cjwatson: true :)
<ddstreet> cjwatson oh i like that
<stgraber> that was unfortunately missing back in LXD 2.0 :)
<ddstreet> yes, i don't know how anyone got anything done with containers before lxd 2.0, very happy for it xD
<nacc> heh
<ddstreet> i mean pre-lxd 2.0 is still light-years ahead of non-lxc/non-lxd
<stgraber> these days (2.17+) you could even use something like: lxc query /1.0/containers/artful/state | jq -r .network.eth0.addresses[0].address
<stgraber> which would grab just what you need in a single API call
<cjwatson> yeah, it's quite fiddly with earlier versions
<cjwatson> lxc list -c4 --format=json | jq -r 'map(select(.name=="INSERT-CONTAINER-NAME-HERE"))|.[].state.network.eth0.addresses[0].address'   is the best I've been able to do with xenial's lxd
<cjwatson> (probably possible to do better - I only speak quite basic jq)
<ddstreet> stgraber i'm still waiting for lxc ssh NAME ;-)
<seb128> dmj_s76, did you report bugs on launchpad (and maybe GNOME upstream) about those hidpi issues?
#ubuntu-devel 2017-09-21
<Trevinho> dmj_s76: that's something that is using the classic scaling mode, not the new one...
<dmj_s76> Trevinho: hmm...there have been a lot changes in the mutter/settings center code recently, even for xorg
<dmj_s76> if not directly from hidpi work then from the settings center changes.
<tsimonq2> How would I go about using syncpackage with a package from wheezy-security?
<tsimonq2> (oh, just as I got done typing that I see other uploads in {stretch,jessie}-security but it's still an interesting question nonetheless)
<tsimonq2> (probably just needs --no-lp and the link to the dsc file)
<cpaelzer> LocutusOfBorg: your last llvm didn't go in for a failed upload https://launchpadlibrarian.net/337703796/upload_13396831_log.txt
<LocutusOfBorg> sure cpaelzer there is an ubuntu3
<LocutusOfBorg> not sure why it was good amd64 on my ppa and not on ubuntu official builds
<cpaelzer> well only s390x didn't copy
<cpaelzer> but ok looking for ubuntu3 then
<cpaelzer> ah no ubuntu3 is the one with amd64 issues
<cpaelzer> ok I see
<LocutusOfBorg> cpaelzer, didn't copy because of superseeded
<cpaelzer> well whatever it is worth, the ubuntu2 that didn't copy works
<cpaelzer> LocutusOfBorg: since you said the same ubuntu3 worked for you before what is the plan, rebuilding that?
<LocutusOfBorg> cpaelzer, I'm trying a patch without that RELWITHDEBINFO
<LocutusOfBorg> or relegated only for arm64
<cpaelzer> LocutusOfBorg: ok, just let me know if I shall try anything new
<doko> LocutusOfBorg, cpaelzer: what are you trying? we are back with two one gigabyte debug builds on ppc64el and s390x, and of course the failing amd64 build
<LocutusOfBorg> doko, -g1 is breaking clamav
<LocutusOfBorg> -g works
<LocutusOfBorg> I'm doing a -g -NDEBUG to see what happens
<cpaelzer> doko: bug 1717574
<ubottu> bug 1717574 in clamav (Ubuntu) "new llvm3.9 breaking freshclam bytecode execution" [Medium,Confirmed] https://launchpad.net/bugs/1717574
<doko> cpaelzer: is this upstreamed to clamav, or are trying to change things which we don't understand? why is a change for the debug information responsible for that?
<doko> s/are/are we/
<cpaelzer> doko: I only rerun the test and found the link of the issue to llvm - there is no clamav change
<cpaelzer> doko: so nothing to upstream there that we'd know yet
<cpaelzer> doko: it is just that their bytecode worked before a certina llvm upload and fails since then
<doko> cpaelzer: did you try to rebuild clamav with the same flags as llvm?
<doko> cpaelzer: or did you try to rebuild clamav at all?
<cpaelzer> we rebuilt clamav with old and new llvm, but not change flags
<cpaelzer> none of the rebuilds had any effect
<LocutusOfBorg> we also tried a new clamav just to be sure
<LocutusOfBorg> but yeah, no changes in flags, except for llvm
<doko> please can you report that upstream?
<cpaelzer> so far things looked like "Ubuntu changed the llvm build and that broke clamav" at least I expected clamav to say "so what fix your llvm" - but I can report if you think that is worth
<doko> cpaelzer: we can't accomodate these builds if they take too much disk space to build, and even if, each of these packages take 1 gb, that makes 4gb for every upload ...
<cpaelzer> doko: I did never say "please make them big" I'm only naively debugged a clamav crash and found that it is broken since these llvm uploads
<cpaelzer> I beg your pardon if that got to you differently
<cpaelzer> I'm reporting to clamav and will link it up
<cpaelzer> Also the case is easily reproducible, I msut admit I don't even understand why exactly it now fails
<cpaelzer> doko: if you follow the bug I linked maybe you can see what the actual root cause might be the reason for that incompatibility
<doko> cpaelzer: what is the change in compiler and linker flags?
<LocutusOfBorg> cpaelzer, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+packages
<LocutusOfBorg>  II uploaded a new llvm with -g1 (to make doko and infra happy) and with -DNDEBUG
<LocutusOfBorg> what I discovered, is that ppassing RELWITHDEBINFO flags, overrides the cmake default ones
<LocutusOfBorg> and that -DNDEBUG is stripped then
<LocutusOfBorg> so the change has probably been a side-effect of that -g1, but not directly related
<cpaelzer> I'll test that once it is built LocutusOfBorg
<doko> cpaelzer: there's nothing about this -DNDEBUG in the bug report
<doko> and then find out why clamav is relying on that ...
<LocutusOfBorg> I discovered it some minutes ago, melding the failed amd64 and the succeeded one
<LocutusOfBorg> because in my ppa it was good that build
<doko> you should turn on creation of debug package in your ppa if you want to simulate the builders
<LocutusOfBorg> both enabled, build and publish
<LocutusOfBorg> thanks for the reminder, I admit I didn't recheck it
<LocutusOfBorg> interesting, libclamav is using some NDEBUG stuff
<cpaelzer> LocutusOfBorg: doko: I reported to clamav and linked it up in the bug
<cpaelzer> LocutusOfBorg: let me know if/once there is a build I shall try for you
<LocutusOfBorg> configure: CXXFLAGS from llvm-config: -I/usr/lib/llvm-3.9/include -std=c++0x -gsplit-dwarf -Wl,-fuse-ld=gold -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -O2 -g -DNDEBUG
<LocutusOfBorg> -fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
<LocutusOfBorg> interestingly, clamav is getting the build flags from llvm, so a no change rebuild should change them too
<LocutusOfBorg> and in fact this seems to happen
<cpaelzer> but you rebuilt a new clamav
<cpaelzer> also I did with a local build vs the new library and -dev packages
<LocutusOfBorg> but clamav not picking up NDEBUG from llvm flags, means that the code ifdefs are not triggered
<LocutusOfBorg> this means less asserts
<cpaelzer> but the clamav currently in artful uploaded by mdeslaur still built by picking -DNDEBUG up as it was before the llvm changes
<LocutusOfBorg> I think I'll directly upload to Ubuntu this one
<cpaelzer> https://launchpadlibrarian.net/333379617/buildlog_ubuntu-artful-amd64.clamav_0.99.2+dfsg-6ubuntu2_BUILDING.txt.gz
<cpaelzer> LocutusOfBorg: do you mean we have lost the -NDEBUG in llvm and those "extra" asserts might be the reason to break it now?
<LocutusOfBorg> somewhat this is a possible reason
<LocutusOfBorg> rebuilding makes it assert because the current llvm in artful proposed is built without
<LocutusOfBorg> probably rebuilding it with -DNDEBUG makes it pass
<cpaelzer> LocutusOfBorg: ok, so since clamav is already built with -DNDEBUG from the old llvm builds that would mean likely no re-upload there. Once your ppa is ready I would install from it and then retry + rebuild+retry - ok?
<LocutusOfBorg> ok
<cpaelzer> so waiting on https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/13399109 now
<LocutusOfBorg> I could also upload directly to Ubuntu
<cpaelzer> I personally prefer uploading to ubuntu what is known or at least expected to work
<LocutusOfBorg> the current proposed one has debug symbols too huge
<cpaelzer> ah, ok I see the reason
<LocutusOfBorg> even if not working, it is worth an upload
 * LocutusOfBorg meeting time
<cpaelzer> well, are you sure the ubuntu5 at least builds and is as good/bad than the last one that had small symbols?
<cpaelzer> I'll carry all this discussion into the bug for documentation
<LocutusOfBorg> yes, it should build
<LocutusOfBorg> now with debug logs melded I had a clear view of the build issue
<zhongjun> coreycb: ping
<LocutusOfBorg> cpaelzer, mostly built
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9/1:3.9.1-16ubuntu4/+build/13399140
<petersaints> Hi guys! I was looking at the latest Live CD/USB manifest (http://cdimage.ubuntu.com/daily-live/pending/artful-desktop-amd64.manifest), at the Ubuntu Package Search (https://packages.ubuntu.com/), and at Launchpad (https://launchpad.net/ubuntu), and I noticed that there are still lots of GNOME-related packages with 3.25.x versions (3.26 pre-releases). Will they be replaced with proper 3.26 versions? What about packages that
<petersaints> are stuck at 3.24 (e.g., gnome-terminal or gnome-getting-started-docs, among others)? And perhaps there are even packages lingering from even older GNOME releases that I've missed! Any plans about this?
<jbicha> petersaints: that's a lot of questions!
<jbicha> the docs package might get updated today. Generally if we have a 3.25 version we can update it to 3.26. Terminal might stay at 3.24
<jbicha> for 17.10
<petersaints> Thats what I thought @jbicha. It wouldn't have made much sense to move packages to 3.25.x if they are not supposed to be replaced by the final 3.26 version.
<petersaints> And thanks for the reply jbicha
<cpaelzer> LocutusOfBorg: FYI 1:3.9.1-16ubuntu4 from the current build in a-p is not working
<cpaelzer> 1:3.9.1-16ubuntu2 from the same place did work
<cpaelzer> so while -DNDEBUG was a nice idea, that wasn't it
<cpaelzer> no reply on the upstream report yet
<doko> mwhudson: golang still at 1.8, and nobody complained?
<LocutusOfBorg> so cpaelzer I have zero idea
<LocutusOfBorg> if doko is not happy with debug symbols of 1gb, and no other flags changed...
<LocutusOfBorg> I don't know
<LocutusOfBorg> (I'm not happy with them too, btw)
<LocutusOfBorg> cpaelzer, did you try a rebuild of it?
<LocutusOfBorg> did you try to use -g1 in clamav too?
<cpaelzer> configure: CXXFLAGS from llvm-config: -I/usr/lib/llvm-3.9/include -std=c++0x -Wl,-fuse-ld=gold -Wl,--no-keep-files-mapped -Wl,--no-map-whole-files -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -Werror=date-time -std=c++11 -ffunction-sections -fdata-sections -g1  -
<cpaelzer> fno-exceptions -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
<cpaelzer> LocutusOfBorg: I thought you brought -DNDEBUG back but in combination with -g1 in ubuntu4
<cpaelzer> And failing still when rebuilt against the most recent - as expected
<LocutusOfBorg> I'm really with no ideas
<LocutusOfBorg> some parts in llvm build log are with -g instead of -g1
<LocutusOfBorg> not sure why
<LocutusOfBorg> btw manually adding -DNDEBUG does change something?
<doko> ohh wonderful new gnome3 world ...
<doko> Laney, seb128: python2 is back on the desktop. was this intended?
<doko> ubuntu-artwork team using python2. great!
<doko> ... and samba is installed by default again ...
<seb128> doko, what is bringing it in
<seb128> ?
<doko> seb128: ^^^
<seb128> doko, ubuntu-artwork team ... a team is using python?
<seb128> for what  package?
<doko> ahh, adium-theme-ubuntu
<doko> seb128: or is this temporary and will be replaced?
<abeato> sil2100, hi, I have tried to use '--image-size' option in ubuntu-core. The effect is that the size of the resulting volume is as I specified, but the rootfs partition has the same size as before, leaving empty space in the volume...
<abeato> sil2100, is that a bug?
<seb128> doko, that seems like a packaging error, let me look
<abeato> s/ubuntu-core/ubuntu-image
<doko> just asking because this theme has changes up to 2012, and one in 2016
<seb128> doko, that theme is not very active indeed but can still be useful
<doko> seb128: but it's installed by default
<seb128> right
<seb128> it's still useful
<doko> ok, converting to py3
<seb128> doko, you know python build systems better than me, why is that package even getting a depends on python?
<seb128> doko, it uses     ${python:Depends},
<seb128> but there is no python file included in the deb
<seb128> doko, it has a setup.py that is just used to copy files to the right target as far as I can tell
<doko> seb128: yes, I see that, but it provides an egg-info file too. why?
<seb128> bug
<seb128> ?
<seb128> where is that coming from
<seb128> it's not in the source?
<doko> because it's *built* as a python module. see setup.py
<seb128> is that easy to change?
<seb128> I don't know that build system at all
<seb128> doko, I guess I could just revert the packaging changes in http://launchpadlibrarian.net/255953920/adium-theme-ubuntu_0.3.4-0ubuntu1_0.3.4-0ubuntu2.diff.gz
<seb128> before that it didn't have that depends
<doko> seb128: sure, sounds fine
<seb128> k
<doko> seb128: and the status quo about samba was, that it was installed on demand, afaik
<seb128> what is pulling it in now?
<seb128> doko, samba itself isn't installed, only -common-bin?
<seb128> and libs
<doko> seb128: gnome-control-center -> gvfs-backends libsmbclient
<doko> libsmbclient is linked against libpython2.7
<seb128> ah
<seb128> that's not a new issue
<seb128> we never resolved that one afaik
<doko> yes, but now it's pulled in unconditinally
<seb128> it always was
<doko> no?
<seb128> libsmbclient is used by the gvfs samba backend
<doko> we had python2 free desktop images in the past
<seb128> are you sure? when?
<seb128> I don't think we ever got there
<cpaelzer> LocutusOfBorg: -g1 -NDEBUG on the clamav rebuild still not changing a thing
<cpaelzer> it is llvm that has "changed"
<cpaelzer> I'm lost
<cpaelzer> hope that upstream respsonds at some point
<seb128> doko, I've uploaded a fix for the theme
<cpaelzer> completely disabling llvm support in clamav is the only option that I could toggle on clamav to unbreak it
<LocutusOfBorg> I agree with doko on the fact that the change -g -g1 should have no effect, because symbols file are outside the package and stripped away
<cpaelzer> but then I wonder if there is more out there that might react to thellvm change
<cpaelzer> I totally agree, but I can only report what I see :-/
<cpaelzer> LocutusOfBorg: do you know if the -g1 change was also done in Debian already?
<cpaelzer> that might be a great chance to cross check there
<LocutusOfBorg> yes, and it is not failing there
<LocutusOfBorg> I already tried a no change rebuild
<cpaelzer> ld/glibc then maybe?
<LocutusOfBorg> the llvm in artful is in sync with the one in debian
<LocutusOfBorg> (the one in artful proposed not really)
<LocutusOfBorg> ld is in sync, because binutils is at the same version
<LocutusOfBorg> glibc isn't
<LocutusOfBorg> (this is why I put glibc on the table)
<cpaelzer> fortunately libc6 is the simplest package to exchange for a test :-/
<LocutusOfBorg> lol
<cpaelzer> so zesty + new llvm + new clamav might be the closest low-hanging-fruit to try
<LocutusOfBorg> you can ask infinity to upload new glibc on debian experimental
<LocutusOfBorg> and test there
<cpaelzer> good idea as well
<doko> cpaelzer, LocutusOfBorg: did you compare the build flags from before and after these changes?
<LocutusOfBorg> doko, melding the build flags is painful with 500k logs
<doko> I now ...
<LocutusOfBorg> for some reasons current llvm does -g somewhere and -g1 somewhere else
<LocutusOfBorg> so, not even in sync with itself
<cpaelzer> clamav picks up the CXX Flags from llvm-config - so the one in artful righ tnow still has -g, but rebuilding with the -g1 doesn't change anything
<LocutusOfBorg> https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/13396394
<cpaelzer> also tried the -NDEBUG, same (no) effect
<LocutusOfBorg> this is the llvm that worked
<LocutusOfBorg> cpaelzer, confirm please :)
<cpaelzer> confirmed
<cpaelzer> of the -16 series ubuntu1 = bad, ubuntu2 = good, ubuntu 3 doesn't exist) ubuntu4 = bad
<cpaelzer> all -g1 are bad for the case at hand, but they obviously fix the huge debug symbols
<cpaelzer> the NDEBUG was the other flag that LocutusOfBorg found, but that didn't resolve it either
<cpaelzer> and we all agree that without debug symbols installed the effect of -g[1] should be non
<cpaelzer> but this is "shoult (tm)" which never does as it should :-)
<LocutusOfBorg> why the hell the NDEBUG is not there
<LocutusOfBorg> hold on
<LocutusOfBorg> :/
<doko> seb128: incomplete, you need to use python3:Depends. otoh, you should just remove the egg-info file, shouldn't you?
<LocutusOfBorg> cpaelzer, please try the llvm ubuntu5 I have just uploaded
<LocutusOfBorg> :(
<doko> or just remove the python:Depends
<seb128> doko, I'm not familiar with python packaging, feel free to fix it (or to let it like that, it removed the depends which was not useful anyway)
<doko> later, I have an idea how to remove the interpreter from the images ...
<seb128> doko, oh, how? and did you figure out if python was really off the iso on some serie and when? (I'm happy to compare/look what regressed if that's the case)
<cpaelzer> LocutusOfBorg: https://launchpad.net/ubuntu/+source/llvm-toolchain-3.9/1:3.9.1-16ubuntu5 ?
<cpaelzer> will do so
<LocutusOfBorg> did you spot the error?
<cpaelzer> I didn't compare debdiffs or anything
<cpaelzer> I just read you cahngelog and will try later
<LocutusOfBorg> you can see it in the web interface
<LocutusOfBorg> just click on the link at the bottom
<LocutusOfBorg> :)
<LocutusOfBorg> once it is generated
<cpaelzer> sure, but I only click there if needed :-)
<cpaelzer> it is there already
<cpaelzer> oh I see, yeah +=/=
<cpaelzer> so O2 and NDEBUG went away
<cpaelzer> well worth a try for sure
<cpaelzer> you don't have to upload to a-p all the time
<cpaelzer> I'm fine with a ppa
<cpaelzer> until we have settled on one working version
<doko> seb128: https://launchpad.net/ubuntu/+source/talloc/2.1.9-2ubuntu1
<seb128> doko, let's see how that goes :-)
<LocutusOfBorg> cpaelzer, cross your fingers
<LocutusOfBorg> :)
<doko> seb128: done, shouldn't be there anymore on the image
<seb128> great
<smoser> didrocks, i have a question wrt your continued posts on desktop stuff.
<smoser> mostly this is due to my novice like understanding of desktops
<smoser>  https://didrocks.fr/2017/08/23/ubuntu-gnome-shell-in-artful-day-7/
<smoser> i used rely on 2 indicators heavily
<didrocks> smoser: you should have the indicators shown there
<smoser>  * the 'mail' icon, which would go blue when xchat highlighted me
<didrocks> but it's only appindicator
<didrocks> not messaging indicator
<smoser>  * the indicator multiload indicator
<didrocks> (the mail icon was the messaging indicator)
<didrocks> so you will only get the first one
<smoser> (see, you just went way over my head with the distinction of 'appindicator' and 'messaging indicator' )
<smoser> :)
<didrocks> heh, I'm a little bit late and need to head out
<didrocks> we can talk about it tomorrow or andyrock can help you ^
<seb128> I can reply
<smoser> ok. thanks.
<didrocks> ah seb128 as well :)
<didrocks> thanks seb128 :)
<seb128> waiting to see where smoser is going
<seb128> yw!
<smoser> :)
<smoser> so i just ran 'indicator-multiload' and it seems like it only gets a dozen pixels wide or so
<smoser> and then i really want *some* indication that i got a xchat highlight.
<smoser> are we expecting to get a 'messaging indicator' again ?
<seb128> smoser, for the monitor you might want to try https://extensions.gnome.org/extension/120/system-monitor/ or look for similar extensions
<seb128> smoser, not at the moment but we are trying to get back the "unread count" on the launcher, see bug #1713712
<ubottu> bug 1713712 in gnome-shell-extension-ubuntu-dock (Ubuntu) "[UIFe, FFe] Provide Unity Launcher API" [Medium,New] https://launchpad.net/bugs/1713712
<seb128> smoser, like https://user-images.githubusercontent.com/3677105/30074008-23a5de62-9270-11e7-91e1-19ebc7b7dade.png
<seb128> smoser, that should give you hint about IRC pings and unread email
<seb128> if you use apps that integrate, like hexchat and tb
<smoser> seb128, thanks.
<jibel> FWIW, I replaced indicator multiload by the extension seb128 mentioned when I switched to gnome-shell and never went back.
<ricotz_> LocutusOfBorg, hi, is it expected that the installed libllvm3.9 grew by 44MB with -16ubuntu2?
<ricotz_> I mean -16ubuntu4
<LocutusOfBorg> ricotz, yes, I changed the -g flag
<ricotz> LocutusOfBorg, ah, I see
<LocutusOfBorg> ricotz, the latest ubuntu5 should be fine again
<ricotz> ok
<LocutusOfBorg> I missed a "+" so the NDEBUG and the -O2 got stripped
<sboeuf_> apw: Hi, James Hunt told me you are a Ubuntu kernel maintainer and I have a question regarding the recent kernel supplied by Canonical in the Ubuntu 16.04.3 LTS image through Azure
<sboeuf_> apw: I have noticed that the kernel bumped from 4.4.0-92-generic (yesterday) to 4.11.0-1011-azure (today)
<sboeuf_> apw: the problem being that 4.11.0-1011-azure does not have CONFIG_KVM enabled
<sboeuf_> apw: is that expected ?
<smoser> seb128, sorry. you're prbably gone now, but i just looked at your screenshot. the only thing that i'd suggest is that any unread counts in hte launcher i'm generally not going to see because it auto-hides.l  the panel blue envelope i saw all the time.
<apw> sboeuf_: in azure or elsewhere?
<sboeuf_> in azure
<sboeuf_> apw: ^
 * ogra_ is curious how the -generic kernel ended up there in the first place
<apw> ogra_: virtual reports as generic
<ogra_> ah
<sboeuf_> ogra_: well that's supposed to be a completely *clean* Ubuntu 16.04 image, meaning that it is supposed to be delivered with the generic kernel, right ?
<ogra_> but wouldnt -azure have been used initially ?
<apw> ogasawara: |`
<sboeuf_> apw: ogra_ : I don't really know if the "generic" name matters here, but basically the latest kernel provided by Canonical for the Ubuntu 16.04 image does not enable KVM anymore
<ogra_> no, the name doesnt matter for that particular issue ... i was just curious why the original image didnt use -azure in the first place
<sboeuf_> apw: ogra_ : and that's an issue since I am using some Azure platforms allowing nested VM
<apw> you should be able to switch by installing linux-hwe by eneric
<apw> bloody autocorrupt
<apw> linux-generic
<ogasawara> sboeuf_: we are talking with Microsoft right now about this
<ogasawara> sboeuf_: and relaying impact of it not being enabled
<sboeuf_> ogasawara: oh okay, thank you
<sboeuf_> ogasawara: do you know the timeline for a new release (if you/they agree on releasing a new Ubuntu 16.04 with a kernel supporting KVM) ?
<ogasawara> sboeuf_: I suspect we could respin a kernel in a day once we reach agreement
<sboeuf_> apw: what do you mean ? installing when logged into the distro ? or you suggest custom image ?
<sboeuf_> ogasawara: oh that's pretty fast ;)
<ogasawara> sboeuf_: apw was suggesting you could go back to the previous linux-virtual kernel
<apw> when logged into the instance install linux-virtual and reboot selecting that kernel
<sboeuf_> apw: that's a good idea but I need to see how it goes about interactions between my Jenkins CI and the automation of Azure VMs launching
 * apw nods
<LocutusOfBorg> apw :force-badtest virtualbox/5.1.26-dfsg-2
<LocutusOfBorg> please update it! 5.1.28-dfsg-1
<LocutusOfBorg> or make it versionless
<LocutusOfBorg> thanks :)
<Laney> it'd be good to fix dkms ...
<LocutusOfBorg> now it is currently blocking libpng and python :)
<LocutusOfBorg> dkms can wait I guess
<LocutusOfBorg> maybe you can just lower a little bit the kernel version for the module
<LocutusOfBorg> calling it 5.1.28~
<LocutusOfBorg> so the virtualbox-dkms one has higher value and overrides it
<apw> interesting thought, I like that
<LocutusOfBorg> :)
<LocutusOfBorg> or I can increase it
<LocutusOfBorg> I appreciate having higher priority wrt your module
<apw> we should reduce will look at it when I have power again
<sboeuf_> apw: btw, how am I supposed to reboot to the new installed kernel (modifying grub I guess)
<LocutusOfBorg> apw, in case you want to override the virtualbox one you can call it 5.1.28Ubuntu1
<LocutusOfBorg> otherwise a ~Ubuntu1 might be the best versioning
 * LocutusOfBorg didn't test that
<apw> LocutusOfBorg: likely we want the dkms package to replace in case you want the live ones
<LocutusOfBorg> why should somebody prefer them? maybe because they  might be signed?
<ogasawara> sboeuf_: fyi bug 1718740
<ubottu> bug 1718740 in linux-azure (Ubuntu) "linux-azure: KVM nested virtualization is disabled" [Undecided,In progress] https://launchpad.net/bugs/1718740
<dmj_s76> ping Trevinho
<Trevinho> dmj_s76: hey
<dmj_s76> When you were making the hidpi changes, did any of the multimonitor (not fractional) work get incorporated in a way that xorg would use or was that purely left in the old way?
<Trevinho> dmj_s76: no, there was a big refactoring of the configuration management which jonas did...
<dmj_s76> Trevinho: so this is probably the configuration changes separate from the hidpi work, xorg should be using the same exact scaling mechanisms as before, and the new config settings tools just didn't get any testing for scaling on xorg.
<Trevinho> dmj_s76: I suggest you to ping Jonas in #gnome-shell (he will be available later)
<Trevinho> (jadahl is the nick)
<dmj_s76> yeah, waiting on a response :)
<dmj_s76> Thanks!
<jtaylor> tjaalton: xorg in artful probably needs https://lists.freedesktop.org/archives/wayland-devel/2017-August/034895.html
<jtaylor> part of the pointer confine fixes the package already has
<tjaalton> jtaylor: I think that patch was dropped from artful already
<jtaylor> tjaalton: dropped as in added and removed again?
<seb128> jtaylor, https://launchpad.net/ubuntu/+source/xorg-server/2:1.19.3-1ubuntu6
<seb128> jtaylor, which was the segfault your fix addresses
<jtaylor> seb128: no its the xwayland-pointer-confine.diff
<jtaylor> I have added the patch to ubuntu6 and it fixed my issue
<seb128> jtaylor, what issue? did you report it to lp?
<jtaylor> no, it requires prop. software to reproduce, though according the xwayland bug it can be reproduced with qemu too
<jtaylor> ah you commented on the bug :) https://bugs.freedesktop.org/show_bug.cgi?id=102474
<ubottu> Freedesktop bug 102474 in XWayland "segfault in zwp_pointer_constraints_v1_lock_pointer" [Normal,Resolved: fixed]
<jtaylor> I think
<tjaalton> well i can drop that one too :)
<seb128> jtaylor, well for me (and I reported the upstream bug you mention) the upload withough xwayland-add-grab-protocol-support.diff fixes the issue
<seb128> tjaalton, or just include the fix
<tjaalton> sure
<jtaylor> fwiw the program I hit the crash was the steam game xcom2 in windowed mode which is already buggy as all hell
<jtaylor> but with that patch at elast it doesn't crash wayland :)
<Odd_Bloke> slangasek: What's the alternative to dhclient hooks in the networkd world?  Do you know?
<slangasek> Odd_Bloke: so, I think you can introspect /run/systemd/netif/leases after the fact; there is no explicit hook mechanism because networkd itself is designed to be asynchronous and non-blocking, so there would be some scaffolding to build up around querying + triggering
<slangasek> I haven't checked if anyone is already working on this generically around networkd
<slangasek> (haven't checked recently)
<cyphermox> right
<slangasek> Odd_Bloke: and you should spot-check that /run/systemd/netif/leases actually gives you all the info you require
<cyphermox> leases will tell you some of what you want to know, otherwise you'd need to have a unit trigger based on a network interface being up, I guess?
<slangasek> cyphermox: we need to get the actual value of the ntp server passed by the dhcp server
<slangasek> and reconfigure the ntp client based on changes
<cyphermox> right, that's why I say from leases (which should have some data from the dhcp server), and trigered from a job
<cyphermox> or timedateddd or whatever it's called.
<slangasek> right, you said "some of" what we want to know, we need to know that it tells us everything we want to know (except the timing)
<cyphermox> I don't know right now, will be able to tell you in a few minutes
<cyphermox> this desktop is using NM, I'm installing an artful VM with server :)
<slangasek> I was just going to spin up an instance directly on GCE to check
<cyphermox> yeah, or that
<slangasek> # grep -i ntp /run/systemd/netif/leases/2
<slangasek> NTP=169.254.169.254
<slangasek> #
<slangasek> lgtm
<cyphermox> yup
<cyphermox> 2 would be the ifindex of the interface, if you care
<slangasek> yeah, that's the scaffolding bit that sucks to write
<cyphermox> indeed :)
<slangasek> well, possibly we don't need to map interfaces
<slangasek> we just need to know whether the set of ntp servers has changed as a result of any interface going up or down
<slangasek> (... or getting a new lease)
<cyphermox> what if more than one iface comes up, with a different NTP server?
<slangasek> so we don't need to know /which/ interface triggered, we just need to know there was an event, and re-examine /run/systemd/netif/leases/*
<cyphermox> oh, I guess you just re-read everything then
<slangasek> the sensible default behavior is to take the union of those values, unless we have configuration telling us to ignore ntp from one source but not another
<cyphermox> yes
<slangasek> (which AFAIK for ifupdown+dhclient we have never had previously)
<slangasek> Odd_Bloke: sound good so far? :P
<cyphermox> slangasek: that NTP value looks odd though, that's a zeroconf address. not that it means it's wrong, just surprising to see.
<Odd_Bloke> cyphermox: That's the GCE metadata server IP address.
<slangasek> cyphermox: indeed, and therefore I went to double-check if it's really there; and I discovered that a) yes the address pings, and b) it's also the DNS server and functions as one, and c) this GCE daily image has broken /etc/resolv.conf
<Odd_Bloke> And the EC2 one, for that matter.
<cyphermox> weee
<cyphermox> yeah, I supposed it might be good in this context, for ease of use or something
<slangasek> Odd_Bloke: are you aware of /etc/resolv.conf pointing to non-existent ../run/resolvconf/resolv.conf in the latest artful daily?
<Odd_Bloke> slangasek: Nope.
<Odd_Bloke> Well, I mean, I am now. :p
<slangasek> :)
<slangasek> daily-ubuntu-1710-artful-v20170920
<Odd_Bloke> Ah, it's fine on the Alan-built image from today: daily-ubuntu-alan-1710-artful-v20170921
<slangasek> ok
<Odd_Bloke> cyphermox: It also won't accidentally route outside of the cloud, IIUC.
<slangasek> (that's good, because I didn't find any code in livecd-rootfs that would've broken it)
<cyphermox> Odd_Bloke: that too, yep
<sarnold> what's a reasonable upper-limit on the number of interfaces that may exist? re-reading them all on a change may be painful on a host with a few thousand containers?
<slangasek> sarnold: generally your containers are on a shared bridge as seen from the host, no?
<slangasek> and you would only have lease files for interfaces where you have run a dhcp client
<slangasek> (AIUI)
<sarnold> slangasek: ah I thought there was a commonly-used mode with per-container interfaces on the host too
<sarnold> ah good good
<ginggs> kirkland: hi, do you know petname is FTBFS? https://launchpad.net/ubuntu/+source/petname/2.6-0ubuntu1
<kirkland> ginggs: oh!  no, I hadn't noticed...  let me fix that :-)
<kirkland> TEST [12/16]: Ensure all adverbs are common in the SCOWL database [usr/share/petname/medium/]...
<kirkland> skillfully
<kirkland> â¤· Failure
<kirkland> odd...
<kirkland> ginggs: out of curiosity... did you notice that because you needed something from petname, or just because you were looking at FTBFS generally?
<sboeuf_> ogasawara: that's great, thank you very much ! So basically, what does mean that the fix has been submitted ? Does that mean it is up to Azure now to publish the updated version ?
<bjf> sboeuf_, we will build a new kernel today and get that out after some testing. then you would be able to upgrade the kernel for your instances
<bjf> sboeuf_, it will take a little longer (a couple days I believe) for that new kernel to be the default in new images
<sboeuf_> bjf: ok makes sense, thanks for the heads up
<bjf> sboeuf_, np
<Odd_Bloke> slangasek: Hmm, so I don't particularly want to take on building a generic solution (or even a specific one, if I can avoid it :p); any suggestions on next steps to resolve this?
<slangasek> Odd_Bloke: scrape the above IRC backlog into a trello card? :)
<Odd_Bloke> Will do.
<TJ-> Odd_Bloke: could you tie into how systemd-timesyncd receives the NTP server addresses from networkd in some way?
<ginggs> kirkland: just trawling FTBFSs
<slangasek> kirkland: have you been receiving the britney nagmails regarding your package being delayed in -proposed?
<kirkland> slangasek: don't think so...  can you give me a key phrase to search for?  maybe it's getting filtered...
<kirkland> slangasek: I searched for "britney petname" and got nothing
<cjwatson> try "proposed-migration"
<slangasek> kirkland: Subject: [proposed-migration] petname $version stuck in artful-proposed for EIGHTY YEARS
<kirkland> slangasek: negative;  not getting any of those
<kirkland> slangasek: should this just be going to my upload address
<slangasek> that's a good question
<slangasek> since there was a bit of hacking around in the implementation to deal with the fact that snakefruit was still running on precise at the time
<kirkland> slangasek: for better or worse, all of my mail eventually just collates down to a gmail address
<slangasek> and therefore was not using launchpadlib
<slangasek> kirkland: I can confirm emails have never been sent for petname :)
<slangasek> now to see why
<kirkland> slangasek: ah?  my fault?
<slangasek> kirkland: not directly, no
<slangasek> you're just exposing a bug somewhere in the britney policy
<kirkland> slangasek: woot?
<Odd_Bloke> TJ-: Unfortunately, it looks like timesyncd uses inotify in-process (via a systemd library) to be notified on new time servers from DHCP.
<TJ-> Odd_Bloke: I was afraid of that :)
<TJ-> Odd_Bloke: never easy is it!?
<Odd_Bloke> Generally not, no. :p
<slangasek> kirkland: ah, so it comes down to the fact that "missing package builds" is treated as a "temporary" failure in britney; even after 118 days.  So you should have received the emails informing you of the build failure initially, but don't get any other emails currently for the case of a build failure
#ubuntu-devel 2017-09-22
<jbicha> ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
<sarnold> "cannot open shared object file"
<jbicha> yes, that sounds bad
<jbicha> this is with my sbuild's now on artful host
<jbicha> glibc?
<Unit193> jbicha: Seen http://paste.openstack.org/show/621666/ after recent updates?
<Unit193> Aha, I think I see it.
<Muyfret> are multiple passes of testing and inspection of an update to a package done for popular packages
<Muyfret> for example thunderbird or samba
<kirkland> slangasek: alrighty -- so....other than fixing my FTBFS (which is fixed now!), are there any other changes I need to make on my end?
<slangasek> kirkland: nope; we need to think about how to fix the lack of periodic nag mails for FTBFS packages, though
<honestly> Hello! I know this is a big ask, but is there anyone here who can walk me through setting up an ubuntu maintenance/packaging environment so that I can prepare an SRU? It's really hard to do this on my own since the documentation is rather fragmented. The bug is here: https://bugs.launchpad.net/ubuntu/+source/ieee-data/+bug/1714602, and it should be eligible for an SRU to xenial, especially since it
<ubottu> Launchpad bug 1714602 in ieee-data (Ubuntu Xenial) "ieee-data cron fails every month because it DDoSes an upstream website" [High,Triaged]
<honestly> has pretty high impact.
<tyhicks> slangasek: thanks for the stenographer test fix!
<cpaelzer> LocutusOfBorg: all the finger crossing helped - TL;DR fixed I made all the bug updates required
<cpaelzer> thanks
<slangasek> tyhicks: no prob!
<LocutusOfBorg> ;)
<Unit193> Is your eye twitchcing?
<doko> bad pitti, cockpit not using python3 ;p
<honestly> hello! I am trying to work on getting a fix for https://bugs.launchpad.net/ubuntu/+source/ieee-data/+bug/1714602 SRU'd into xenial but I'm a complete newbie. I followed http://packaging.ubuntu.com/html/getting-set-up.html to set up a packaging environment, what should I do next? Should I try to pull a new package version from upstream?
<ubottu> Launchpad bug 1714602 in ieee-data (Ubuntu Xenial) "ieee-data cron fails every month because it DDoSes an upstream website" [High,Triaged]
<pitti> doko: the tests aren't indeed, but there shouldn't be a runtime dependency?
<doko> cjwatson: nice idea with s/python/python2/ but we probably won't catch all insanities users do with symlinks. I haven't yet found the webpage recommending changing the symlink
<doko> pitti: haven't check, just saw the autopkg test
<cjwatson> doko: Yeah, I'm sure we won't, it just seemed like a reasonable change in this case
<jbicha> oh, I think my ld.so error was user error since it's working fine for me now
<seb128> smoser, re your comment from yesterday, yeah the badges on the launcher are fine if you don't autohide it ... I guess somebody could write a g-s extension that does something similar to what the messaging indicator was doing
<smoser> g-s ?
<smoser> gnome-..
<seb128> gnome-shell
<smoser> thanks.
<seb128> yw
<didrocks> smoser: come to our room next week, you will be used to all our acronyms you don't want to know :)
<didrocks> (/!\ g-s can as well be gnome-session, context is important :p like for g-c-c)
<seb128> or gnome-software
<didrocks> oh right
<didrocks> almost forgot that one. We need to create another project with Gâ¦ Sâ¦
<Laney> session
<Laney> screenshot
<Laney> shell sushi
<Laney> :)
<smoser> and here i thought gcc was a complier
<smoser> lame i am
<ogra_> it is only a compiler because it can not afford dashes ...
<didrocks> heh
<jtaylor> infinity: are there still glibc updates planned for 17.10?
<jtaylor> bugfixes
<infinity> jtaylor: There will be one or two minor bugfix uploads I'm sure, yeah.
<jtaylor> infinity: great, can you consider the fix for bug 1718928
<ubottu> bug 1718928 in glibc (Ubuntu) "glibc: backport "Add x86_64 to x86-64 HWCAP" for 17.10" [Undecided,Confirmed] https://launchpad.net/bugs/1718928
<jtaylor> I can provide a patch if it helps
<infinity> jtaylor: If the patch provided is "git show hash", I think I can figure it out. :P
<jtaylor> though so, thanks :)
<johnny_|_> Hi. I am trying to connect 2 4k monitors on 17.10. Sometimes I even manage to do that but right now when I connect second monitor the screen is black and I can see mouse cursor both on laptop screen and first external monitor. What to do from here?
<wxl> johnny_|_: i'd suggest #ubuntu for support
<wxl> johnny_|_: or perhaps #ubuntu+1 since you did say 17.10
<johnny_|_> wxl: thanks, confused -devel with +1, sorry
<wxl> johnny_|_: np :)
#ubuntu-devel 2017-09-23
<gabmus[m]> Hello people, I am an Arch user, and I'm trying to build an app I made (gtk+python) for debian into a .deb file for debian and ubuntu. I have already a vm running ubuntu mate 17.10 and I verified that the app builds and runs. I am using the meson build system and I already have all the necessary debian specific files in place (compat, control, copyright, rules, soruce/format). I was wondering if there was a simple
<gabmus[m]> meson to deb tutorial I could follow, and since I couldn't find anything on google, I'm asking here. any clue? thanks.
<Unit193> gabmus[m]: Newer debhelper supports meson buildsystem actually!
<gabmus[m]> Unit193: please, tell me more
<Unit193> gabmus[m]: https://nthykier.wordpress.com/2017/06/26/debhelper-10-5-1-now-available-in-unstable/ basically, add meson to the build-depends.  https://anonscm.debian.org/git/collab-maint/casync.git/tree/debian for example.
<gabmus[m]> thanks, gonna have a look
<Unit193> Sure thing.
<Unit193> (Short of it, meson should work out of the box without any additional setup.)
<gabmus[m]> cool, but I still don't get how to use debhelper. I'm a little bit spoiled by arch build system being so easy, I've got all the files I need in place already (copied from another project, thanks gpl) but don't know where to go next. for reference, here's the repo: https://github.com/gabmus/razercommander
 * ogra_ would just create a snap instead ... runs on more distros, you are independent from the distro release and can update when you like ...
<Faux> gabmus[m]: The aim is that your debian/rules doesn't need anything below line 10, as it's all done by line 9. https://github.com/GabMus/razerCommander/blob/master/debian/rules#L9 I am not awake enough to help, though.
<gabmus[m]> not sure about snaps, but I'm pretty sure that once I get a deb file, the next thing will eb a flatpak
<gabmus[m]> Faux: I'm pretty sure that lines below 10 won't hurt anyway, right?
<Unit193> http://paste.openstack.org/show/d9jqWbmh9I8IlBkT8UJq
<gabmus[m]> Unit193: Awesome! thank you, will see where this goes
<Unit193> gabmus[m]: Your tarball didn't contain the meson build stuff, so untested.
<gabmus[m]> what do you mean?
<Unit193> The tarball https://github.com/GabMus/razerCommander/releases
<gabmus[m]> forget the releases, it's not up to date
<gabmus[m]> clone master
<gabmus[m]> will make an official release when I have the deb file ready
<Unit193> FWIW: WARNING: Passed invalid keyword argument "type" in data/meson.build line 7.
<Unit193> http://paste.openstack.org/show/74A11xMBTTVKir03Sph4 on top of my last patch and you're set (well, clearly fix d/changelog and the description.)
<Unit193> gabmus[m]: Anywho, hope that helps ya out.  I presume you know  `dpkg-buildpackage` to build it an everything?
<gabmus[m]> > FWIW: WARNING: Passed invalid keyword argument "type" in data/meson.build line 7.
<gabmus[m]> already fixed in local repo, gonna push soon
<Unit193> \o/
<Unit193> I can't help you with snaps though, I tend to pretend they don't exist.
<gabmus[m]> > I can't help you with snaps though, I tend to pretend they don't exist.
<gabmus[m]> same here, won't bother about them for now
<gabmus[m]> `dpkg-source: error: syntax error in razercommander/debian/control at line 29: block lacks the 'Package' field`
<gabmus[m]> But it's there at line 17. any clue?
<Unit193> End of file is line 27, I presume you changed it?
<gabmus[m]> nope
<gabmus[m]> anyway, found the error, there was a newline he didn't like
<Unit193> OK..
<ogra_> Unit193, you really shoudl give them a try unless you really love package maintenance (which you probably do since you are around in ubuntu nearly as long as i am :) ) ...creating a 30 line yaml file and 5 clicks in a webform to have every GH commit autobuild and release your stuff in a bunch of distros regardless of the release (without ever having to care again for the packaging) is really compelling ;)
<gabmus[m]> wth is going on: http://termbin.com/7dwu
<Unit193> ogra_: I've been around as long as you?  Oh dear, I'm not an old one!  Eh, I don't use GH, and snaps just really aren't my thing.  I do get how they're handy, perhaps a little too handy at times, but nevertheless.  They shouldn't be the only option. :)
<ogra_> really, i thought you are around since ages :)
<Unit193> Eh, first started with Ubuntu in 2006/2007, didn't even fully move over until quite a bit later.
<ogra_> well, thats only 2 years less than i am around :)
<Unit193> gabmus[m]: 1. Malformed d/changelog, <email@domain.tld> and two spaces before the date.  Looks like a bad clean up too.
<ogra_> (and 10 years ... dude ! ... dont say your'e an old one ;) )
<ogra_> *you're not
<Unit193> Nonono, that was first install!  Not daily use!  I dropped out for a while until 2010!
<Unit193> ...OK, I'm seeing your point.  Fair enough.
<ogra_> :)
<Unit193> ...I'm old. :(
<Unit193> gabmus[m]: Basically, looks like the builddir wasn't removed.
<gabmus[m]> dammt! I had a manually made builddir, that's what caused this
<gabmus[m]> woah! it works! got a deb file along with many other files (.dsc, .build, .buildinfo, .changes)
<gabmus[m]> and the deb installs and runs fine, that's awesome
<Unit193> \o/
<gabmus[m]> thank you Unit193 , your help has been invaluable to me
<Unit193> gabmus[m]: Sure thing, happy to help!
<Unit193> gabmus[m]: https://github.com/GabMus/razerCommander/blob/master/debian/control#L22 you generally want 'depends' under depends though.
<gabmus[m]> tbh I don't know what those lines mean
<Unit193> 'debhelper' uses tools to figure out what the package depends on, in this case python3 3.4+ and adds that.
<madigens_> sladen: hi! could you please have a look at https://github.com/daltonmaag/ubuntu/pull/1?
<sladen> madigens_: short answer, what we do with all th e manual hinting that was done
<madigens_> is that the main road blocker?
<sladen> madigens_: a lot of the budget went on hinting.  Things have moved on now (higher-DPI screens) and the requirement for manual hinting vs. eg. ttfautohint is less
<madigens_> (i personally would have no qualms just tossing it, but i guess that's not an option ;) )
<sladen> madigens_: however, it's a big mental block to effectively toss it
<madigens_> that i understand
<madigens_> i personally am not a fan of the way it was done -- it's as if daltonmaag tried to hint the font to diplay well on win95
<sladen> madigens_: the algorithm that idd the original cubic -> quatratic is proprietary (fontlab) so either we write some intelligent code that can do its best to replicate
<sladen> madigens_: or we toss pretty much eeverything to do with hting and accept that
<sladen> madigens_: as time goes on, the decision perhaps gets easier, but it's a hard pill to swallow
<madigens_> have there been discussions with dm on how to proceed?
<sladen> madigens_: Dalton Maag did was needed and requested.  Most Ubuntu Font users aren't using Ubuntu (OS)...
<sladen> madigens_: and if you want to rener half decent on Windows/Cleartype then hinting is required.
<sladen> render
<madigens_> i know, but given that most browsers aren't using GDI to render fonts anymore, a more ttfautohint-like approach (a "lightly" hinted font) would make more sense. i find the harsh hinting slightly dreadful on windows
<sladen> madigens_: MacOSX/Quartz is less of an issue because it ignores most of the hinting
<madigens_> i'm not against hinting, i'm just a proponent of "light" hinting in the ttfautohint and adobe cff engine sense :)
<sladen> madigens_: it also varies between the weights, different people worked on each
<sladen> madigens_: yes, I concur, ttfautohint is the (ultimate) way to go
<sladen> madigens_: we will have a zero-day at some point when it is moved to cubic + ttfautohint
<sladen> madigens_: the question is when
<madigens_> additionally, the regular weight could be made slighly thinner ;)
<sladen> madigens_: and how at that point to prove reasonable non-regression with the older cubic->qiuadratic->manually hinted outlines
<madigens_> so the typeface is still on the roadmap, good to hear. would be a shame to let it rot
<sladen> madigens_: very happy to go over this more, and thank you for the poke.  But it's the end of lunch and time to turn back into a train driver...!
<madigens_> is there a workgroup of sorts that moves these things forward? I'm asking because i'm working on cantarell (gnome default typeface) and would love to help with the other popular typeface :)
<madigens_> good luck!
<mitya57> Can a package in main have a dependency on package-in-main | package-in-universe?
<nacc> mitya57: yes
<nacc> (I believe)
<nacc> mitya57: because that implies all necessary dependencies are satisfiable with just main
<mitya57> nacc, thanks. I think I heard the opposite some time ago, but maybe that has been fixed since then.
<nacc> mitya57: you might want someone with more experience than me to weigh in, to be sure; but I believe I have seen packages with that formulation
<nacc> mitya57: e.g., i've also seen some with <a> | <b> where <b> doesn't exist in Ubuntu
<mitya57> nacc, I have found an example of such a dependency in the same package I am working on (qtbase).
<mitya57> So yes, it seems to work ;)
<nacc> mitya57: :)
<mitya57> tsimonq2, FYI I am building qtbase merge in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2969/+packages
<mitya57> Also FYI qtdeclarative will move to universe soon.
<tsimonq2> mitya57: ack
<jbicha> mitya57: I think the remaining reason qtbase is in main in artful is because ibus-mozc Recommends mozc-utils-gui in the live seed
<mitya57> jbicha, interesting
<tsimonq2> mitya57: On another Qt-related note, do you think it's worth it to look at releasing Qt 5.6.3 as an SRU in 16.04?
<mitya57> tsimonq2, of course no, 5.5 â 5.6 transition would break a lot of packages
<tsimonq2> mitya57: oh... I forgot Xenial was on 5.5 >_<
<tsimonq2> nvm, you're right
 * tsimonq2 thought Xenial was on 5.6 and we could Just Update it
<jbicha> mitya57: that's at least the reason Qt is still on the artful iso. https://lists.ubuntu.com/archives/ubuntu-desktop/2017-September/005212.html
<mitya57> jbicha, actually it looks like there are more reverse dependencies: https://paste.ubuntu.com/25602299/
<tsimonq2> Oh, snapd is a thing
<mitya57> Of course getting rid of Qt 5 on ISO is also a good task, as it would save some space.
<jbicha> mitya57: yes I saw that output but it's difficult to read. Some of those are only in main *because* qtbase is in main
<jbicha> some are already in http://people.canonical.com/~ubuntu-archive/component-mismatches.html at least
<mitya57> Oh right.
<jbicha> part of that is because of this section: https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.artful/view/head:/supported#L315
<jbicha> that's how libpoppler-qt5-dev is in main but I don't think it should beâ¦
<jbicha> oh, qtubuntu is intentionally in main LP: #1708326
<ubottu> Launchpad bug 1708326 in qtubuntu (Ubuntu) "RM: obsolete product" [Undecided,Invalid] https://launchpad.net/bugs/1708326
<mitya57> Maybe it can be reconsidered if it turns out that itâs the only package keeping Qt in main?
<jbicha> I believe because Canonical ships qtubuntu as part of its kiosk products, it needs to be in main
<jbicha> is Qt being in main causing you problems?
<mitya57> No.
<mitya57> The only advantage for me of having it in universe would be that tsimonq2 will be able to upload it :)
<jbicha> he could probably apply for ppu for that
<mitya57> Right
 * mitya57 â bed
 * tsimonq2 looks into applying for PPU
<fossfreedom> anyone have any idea about this bug affecting both todays 32bit Ubuntu daily and Ubuntu Budgie 64bit daily? https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1719136
<ubottu> Launchpad bug 1719136 in ubiquity (Ubuntu) "Ubuntu and Ubuntu Budgie - there is no background picture on try/install" [Undecided,New]
<fossfreedom> odd - the 64bit Ubuntu daily is still stuck on the 19th Sept - no builds since then?
#ubuntu-devel 2017-09-24
<jbicha> fossfreedom: you have to look in ../pending/ instead of current/ for the 64-bit image. It apparently did not pass its automated tests
<fossfreedom> jbicha, thanks.  I'm downloading 64bit pending to see if the same ubiquity issue occurs.  Where can I see the results of the automated tests (if possible)?
<mitya57> Sigh, my qtbase upload is borked
<mitya57> Why was the new binary package libqt5sql5-ibase accepted into main? It should be in universe (like libqt5sql5-tds).
<mitya57> Because currently we get this: libqt5sql5-ibase/amd64 unsatisfiable Depends: libfbclient2 (>= 2.5.0.25784~ReleaseCandidate1.ds2)
<madigens> sladen: please get back to me once you're done driving :) also, i can't find your email address on your homepage
<Unit193> LocutusOfBorg: While https://packages.qa.debian.org/q/qr-tools/news/20170924T133614Z.html has a Qt4 to Qt5 port, you still might want to consider it for the couple other features.
<Unit193> And by 'features', I mean crash fixes. :P
<Unit193> New upstream snapshot == two/three commits above the release, it looks like.
#ubuntu-devel 2018-09-17
<Moc> Who should I talk to regarding a packaging script error with Nvidia driver forcing a lot of user to use a old driver (340) rather than a newer one like 390 ?
<roaksoax>  /win 14
<federico3> hi
<tdaitx> @cjwatson I'm taking a look at doing an xenial+bionic sru for LP: #1667512, but I'm curious on why doing a "filesystem" sync was preferred compared to a "file" sync (ie. "sync -f <initrd.img>" instead of "sync <initrd.img>")
<tdaitx> the particular patch you proposed is at https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/6/diffs
<udevbot_> Error: "cjwatson" is not a valid command.
<tdaitx> cjwatson: ^
<cjwatson> tdaitx: I think I simply didn't realise that the file mode existed - the man page doesn't make it clear
<cjwatson> tdaitx: That said, the fsync mode is tricky - you have to fsync the containing directory as well
<cjwatson> tdaitx: So I think syncfs is harder to get wrong
<tdaitx> cjwatson: hmm, you mean "sync the containing directory"  because it is a new file, right? in that case, yes, syncfs is better
<cjwatson> indeed
<cjwatson> don't want to end up with the dirent still pointing to the previous iteration of the same initramfs or something
<tdaitx> indeed, fsync for new files is filesystem dependent
<bneff> Having a weird issue where after using the keyboard audio controls, chrome does not process any mouse clicks.  Any pointers?
#ubuntu-devel 2018-09-18
<eangulo> I am searching for devs so I came here. I have modeled a 32bit computer with logisim and have working pseudo-assy compiler. Thinking on next step I want to use a real compiler that, in this state of development, must generate my own pseudo-assy. Is that possible? See it working: https://www.youtube.com/channel/UCpXJ4YQjSkt5EWqJIXcYN9w
<LocutusOfBorg> hello juliank ... feature request...
<LocutusOfBorg> E: Type 'deb[trusted=yes]' is not known on line 3 in source list /etc/apt/sources.list
<LocutusOfBorg> can we please have apt working also when I forget to put the space? :)
<LocutusOfBorg> or having a better error message might help too ;)
<tseliot> slangasek, bdmurray: hey, can you approve ubuntu-drivers-common in LP: #1778011 , please? It's blocking my SRU.
<ubottu> Launchpad bug 1778011 in ubuntu-drivers-common (Ubuntu Bionic) "SRU: PRIME Power Saving mode draws too much power" [High,In progress] https://launchpad.net/bugs/1778011
<andrewsh> jbicha: fwiw, that patch alone doesnât fix all issues Unity has
<andrewsh> but only the most notable ones
<andrewsh> juliank: could you please remove old/unnecessary patches from wpa?
<andrewsh> e.g. debian/patches/session-ticket.patch
<andrewsh> or android_hal_fw_path_change.patch
<andrewsh> or CONFIG_ANDROID_HAL
<andrewsh> I donât think Android support is used these days by anyone
<realitix> Hello Ubuntu team. Can someone merge this patch for Xenial: https://bugs.launchpad.net/ubuntu/+source/tomcat8/+bug/1644144
<ubottu> Launchpad bug 1644144 in tomcat8 (Ubuntu Xenial) "Tomcat 8.0.32 has ClassLoader Issues" [Medium,In progress]
<realitix> Thanks a lot
<rbasak> realitix: it can be done, but it looks like nobody responded to nacc's request to test his trial fix.
<rbasak> If nobody can be bothered to test our work, then I'm not sure it's worth spending the time on fixing it.
<realitix> I have a client that can test it
<realitix> What is the procedure to test the fix ?
<rbasak> Please use nacc's PPA that he linked in the bug.
<realitix> ok, I will tell my client to do it, are you sure the ppa is for xenial ?
<rbasak> https://launchpad.net/~nacc/+archive/ubuntu/tomcat8v2/+packages says Xenial
<rbasak> Note that the current PPA version will be a downgrade and will undo security fixes, so use it for testing only
<rbasak> If it is confirmed to still work, then it'll need rebasing on top of the security fixes
<rbasak> Then tested again. And then we can look into releasing it officially
<realitix> ok thanks
<gpunk> bumblebee broken on ubuntu?
<sarnold> gpunk: what bug number? perhaps someone can suggest something
<gpunk> I dont have in mind the bug number, i am using 18.10
<gpunk> i found it broken on 18.04 too
<juliank> andrewsh: I don't know
<juliank> LocutusOfBorg: um
<juliank> LocutusOfBorg: We do need better parsers for everything in apt
<juliank> andrewsh: The Android HAL is probably used by ubports
<juliank> session ticketing patch idk
<cyphermox> ubports?
<juliank> Also we're frozen
<cyphermox> it tended to be used for the phone IIRC.
<juliank> cyphermox: yes
<juliank> cyphermox: ubports are maintaining ubuntu phone
<cyphermox> eh
<andrewsh> juliank: session ticketing definitely not needed anymore
<andrewsh> juliank: ubports could ship the patch themselves?
<juliank> andrewsh: Does it do harm?
<juliank> Is it wise to drop it weeks before the release?
<andrewsh> juliank: ummâ¦ why ship extra patches with no purpose?
<juliank> because we're close to release
<andrewsh> mm, okayâ¦
<cyphermox> andrewsh: I tend to agree session ticketing is perhaps not needed
<cyphermox> OTOH, if it's not clearly busted, we probably best avoid changing wpa
<cyphermox> I'm no longer really in any position to test WPA enterprise, for one thing
<cyphermox> oh
<cyphermox> actually, that's not quite true, I could set it up at home easier now.
<cyphermox> andrewsh: I'm +1 on dropping the patches when we're not frozen and after checking that the android HAL is no longer necessary (but I suspect it always will be, because android hardware tends to have half-baked badly written drivers with tons of missing features that make them unsuitable to being included in a real kernel
<andrewsh> cyphermox: the bug in question has been fixed ages ago in a different way as I remember
<cyphermox> ie. proper firmware loading, proper rfkill, etc.
<cyphermox> ah?
<cyphermox> re ticketing or android?
<andrewsh> it's not android-specific
<andrewsh> cyphermox: well, but if Ubuntu doesn't run on Android hardware anymore, and UBports build their own packages anyway, why can't they ship wpa with Android things enabled?
<cyphermox> the android patch did use android-specific APIs to get/change fw path
<andrewsh> (btw I do agree re freeze, I didn't know it is on now)
<cyphermox> I don't think they do anything that isn't in the ubuntu archive?
<andrewsh> oh
<cyphermox> tbh, I don't know
<andrewsh> I thought they run a separate packaging infra
<cyphermox> fwiw, I'm not particularly proud of that patch, I'll be happy when it dies
<andrewsh> oh, it was you who wrote it :)
<tdaitx> cjwatson: I added you to 2 merge proposals (xenial and bionic sru) for initramfs-tools as it includes the sync change
<tdaitx> wouldn't mind another pair of eyes looking over the old-dkms change as well if you happen to have the time ;-)
<cyphermox> I prefer when the evidence of my ugly hacks don't stick around indefinitely ;)
<mwhudson> cyphermox: just waiting until all current LTSes are EOL is hardly indefinite!!
<doko> didrocks: you started with LP: #1709164, today I was called out to not process this further. Please could you follow-up on that, setting it to Committed if appropriate?
<ubottu> Launchpad bug 1709164 in bubblewrap (Ubuntu) "[MIR] bubblewrap" [High,Triaged] https://launchpad.net/bugs/1709164
<bluesabre> Is anybody familiar with how the live session gdm doesn't ask (and knows not to ask) for a password? I'd like to do the same with lightdm-gtk-greeter and xubuntu
<jbicha> bluesabre: casper package, scripts/casper-bottom/15autologin , there is also an adjustment in 25adduser
<bluesabre> jbicha: excellent, thanks!
<teward> doko: jbicha: can you confirm whether exim (who technically owns PCRE2 supposedly?) supports PCRE2 over PCRE3?
<teward> doko: jbicha: http://mailman.nginx.org/pipermail/nginx-devel/2018-September/011448.html is why I asked - I don't think PCRE2 is actually 'supported' everywhere...
<jbicha> I'm not really working on getting old pcre out of main (and I would be surprised if that happened before 20.04 LTS), I just want the new pcre in
<teward> jbicha: is there any reason to not have both in `main`?
<teward> other than the headaches of "Which do we support"
<slangasek> It's not a question of confusion over which we support.  It's a matter that actually supporting them costs, and we seek to avoid code duplication wherever possible.
<jbicha> Ubuntu generally only has one of a "thing" in main but there are exceptions. So the question is whether pcre and pcre2 are the same thing or whether an exception is appropriate
<jbicha> pcre does have a security vulnerability history so it is going to be some amount of extra work for the Security team
<nacc> rbasak: i can rebase it at some point, if i'm reminded :)
<tsimonq2> rbasak, bdmurray: In hindsight, I believe I politely deferred bug 1773811, but can I get some confirmation that these changes are not suitable for an SRU?
<ubottu> bug 1773811 in gazebo (Ubuntu) "[SRU] Missing static libs in the -dev package metadata" [Undecided,New] https://launchpad.net/bugs/1773811
<tsimonq2> (If not a violation of Debian Policy.)
#ubuntu-devel 2018-09-19
<Skuggen> rbasak: Do you have time to take a look at https://salsa.debian.org/mariadb-team/mysql/merge_requests/6 ?
<Skuggen> tsimonq2: ^
<rbasak> tsimonq2: it sounds fairly harmless to add a static lib. I don't know if any existing builds would change behaviour, but if not, it should be OK. What's missing from that bug though is a real explanation of _user_ impact.
<rbasak> Skuggen: it's on my list. Sorry I haven't got to it yet
<Skuggen> rbasak: Np. It's not a great rush, so if you have it on your list that's fine :)
<cyphermox> bluesabre: oem-setup does that for oem sessions, you might want to look at the config written (it's in ubiquity source)
<RAOF> cyphermox: Heeeeeeeey! You mentioned on https://bugs.launchpad.net/ubuntu/+source/ltrace/+bug/771805 that you were going to track it down soonish (in 2016 âº). I don't suppose that you did track it down and just forgot to close the bug? :)
<ubottu> Launchpad bug 771805 in ltrace (Ubuntu) "[armel/armhf] ltrace hangs" [Medium,Triaged]
<cyphermox> RAOF: ah, nope?
<cyphermox> RAOF: are you saying it's still hanging in cosmic?
<RAOF> cyphermox: I don't know; I've got a xenial system on this board and it hangs.
<RAOF> (I'd be perfectly happy to install the cosmic package if that's likely to work, although it doesn't seem to have changed significantly since xenial)
<cyphermox> ah, yes
<cyphermox> RAOF: try it, there's some added arm64 support, that might help
<RAOF> Well, this is an armhf board âº
<cyphermox> basically, when I looked at it, we needed ppc64el patching, and then I tried to fix armhf at the same time but it needed a gazillion extra patches
<RAOF> But I'll try it, thanks.
<cyphermox> yeah, but some was arm64 ;)
<cyphermox> basiclaly, it was getting unwieldy for a SRU
<cyphermox> I saw some patches that looked like they'd help, but also not really in a position to test it
<cyphermox> alternatively, let's try to build from a recent git snapshot?
<mwhudson> er i think armhf and arm64 are going to be pretty different if you're thinking at the level of ltrace
<mwhudson> (and also i'd much rather work on the arm64 implementation myself :-p)
<RAOF> cyphermox: No dice; cosmic package fails identically.
<cyphermox> heh
<cyphermox> looks like there's isn't a git up anymore
<cyphermox> and maybe I'm wrong about git altogethr, because this seems like an original debian project :(
<cyphermox> RAOF: anything I can help with re: debugging whatever you're debugging?
<RAOF> cyphermox: I just want to get the set of calls this particular build of weston is making into libMali
<cyphermox> ah
<RAOF> cyphermox: And gdb is being unhelpful, and aaaaaargh.
<cyphermox> RAOF: heh. I was under the impression ltrace was relying heavily on gdb things
<RAOF> It's apparently all the `ptrace`, all the time.
<cyphermox> ah
<cyphermox> any luck with 'latrace' ?
<mwhudson> well gdb is _also_ all ptrace all the time i guess
<cyphermox> or maybe systemtap
<RAOF> cyphermox: Nah, latrace segfaults as soon as it tries to do anything.
<cyphermox> yay
<Faux> (riir!)
<RAOF> Embedded development is the best!
<mwhudson> is systemtap any less awful than the last time i tried to use it?
<cyphermox> heh, I thought I had something for systemtap already, but it would be more akin to strace anyway
<cyphermox> mwhudson: depends, I've had some success in the very odd, infrequent cases I had gone through all other options with no luck and resorted to it
<RAOF> printf debugging it is!
<RAOF> (If I can actually build something that runsâ¦)
<cyphermox> RAOF: can you file a bug for your latrace segfault too?
<sarnold> RAOF: woah woah woah.. that's a dastic step
<sarnold> RAOF: if you don't mind out-of-archive, perhaps sysdig would suit you
<sarnold> RAOF: maybe perf trace?
<cyphermox> if we can fix one of the tools, at the very least the next people might have more luck :)
<RAOF> cyphermox: Sure, although it may be a quirk of this board.
<cyphermox> ack
<cyphermox> well, I'm definitely no arm wizard
<RAOF> cyphermox: Enjoy https://bugs.launchpad.net/ubuntu/+source/latrace/+bug/1793272
<ubottu> Launchpad bug 1793272 in latrace (Ubuntu) "latrace segfaults on armhf" [Undecided,New]
<cyphermox> ta
<rbasak> Skuggen: the merge looks good in itself, but there are some entries missing from debian/changelog - probably the ones that didn't get imported into our VCS tree?
<rbasak> It might be easiest to fix it just by adding a commit to the end rather than redoing everything.
<rbasak> Separately, should we perhaps note in the changelog that we're reverting a sync?
<Skuggen> For the first, sure I can add those (5.7.22-0ubuntu18.04.1 and 5.7.23-0ubuntu0.18.0.4.1?)
<rbasak> No the ones that landed in the development release only
<Skuggen> Not entirely sure I know what you mean.
<rbasak> In a meeting but I can do a HO with you in a bit?
<Skuggen> Sure
<rbasak> I'll ping when available. Hopefully within the next hour or so
<Skuggen> I'm free from about 30 minutes from now
<jamesh> robert_ancell: here's the details on the snapd-glib changes needed: https://bugs.launchpad.net/ubuntu/+source/snapd-glib/+bug/1793298
<ubottu> Launchpad bug 1793298 in snapd-glib (Ubuntu) "snapd-glib changes needed for pulseaudio snap policy module xenial backport" [Undecided,New]
<robert_ancell> jamesh, ok
<rbasak> Skuggen: I can be ready in five minutes if you are
<Skuggen> Yup
<rbasak> OK I'll find a corner
<rbasak> Skuggen: corner found. I'm at the usual link
#ubuntu-devel 2018-09-20
<mwhudson> cjwatson: so i want to make a change to merge-o-matic and would like to test it :)
<mwhudson> cjwatson: do you have any tips?
<cjwatson> mwhudson: not really, sadly
<mwhudson> cjwatson: hooray
<cjwatson> mwhudson: I've mostly just done spot-checks of whatever I'm specifically trying to do, ad-hoc
<mwhudson> well i guess my fix looks pretty plausible so we can always test in prod
<mwhudson> slangasek: https://code.launchpad.net/~mwhudson/merge-o-matic/exec-bits/+merge/355396
<willcooke> tjaalton, put something in the calendar for tomorrow morning, let me know if that doesnt work
<tjaalton> willcooke: works fine, thanks
<willcooke> https://wiki.ubuntu.com/MIRTeam
<willcooke> didrocks, https://bugs.launchpad.net/ubuntu/+source/pcre2/+bug/1636666
<ubottu> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,Confirmed]
<doko> https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1792544
<ubottu> Launchpad bug 1792544 in php7.2 (Ubuntu) "demotion of pcre3 in favor of pcre2" [Undecided,Triaged]
<coreycb> sil2100: bdmurray: hello, would one of you have a moment to review the python-pylxd SRU for xenial? it's tracked in bug 1754657.
<ubottu> bug 1754657 in Ubuntu Cloud Archive "[SRU] python-pylxd 2.0.7 (xenial), python-pylxd 2.2.6 (artful)" [Undecided,New] https://launchpad.net/bugs/1754657
<bdmurray> coreycb: In a meeting but after that.
<coreycb> bdmurray: thanks
<bdmurray> coreycb: It was mistagged which is why it wasn't released earlier.
<Unit193> I find it amusing that everyone is saying "no pcre2 in main", when it's *already* in main due to libqt5 bundling it.  Perhaps rather than getting it in main, vte2.91 should just bundle it too. :P
<Unit193> (Or a better option would be to have a second vte package you keep patched in main, then the real one in universe so that there's actually a working vte in Ubuntu.  Upstreams and other non-Ubuntu flavors would likely be happier with this.)
<coreycb> bdmurray: got it, i'll relay that
<juliank> stgraber: Do you plan to submit your autopkgtest changes upstream? the suggests have been adjusted already, but the test fixes not
<stgraber> juliank: ah yeah, I meant to ping pitti about it, which is my usual way of upstreaming those bits :)
 * pitti does a jump to the left and feels pinged
<pitti> hey stgraber, hallo juliank ! comment vas-tu ? wie gehts?
<juliank> pitti: all good here :)
#ubuntu-devel 2018-09-21
<cjwatson> mwhudson: https://paste.ubuntu.com/p/p5pb5RMbNZ/
<cjwatson> missing .st_mode in some places I imagine
<mwhudson> cjwatson: yes
<mwhudson> waiting until i get out of meetings :)
<cyphermox> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Feature Freeze (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic | If you can't send messages here, authenticate to nickserv first | Patch Pilots: cyphermox
<seb128> bdmurray, do you have any idea why opening a bug from e.u.c  (https://errors.ubuntu.com/problem/b7bbe8793010d7f757f3de7861f6c9584a1fe623) is giving a "qastaging.launchpad.net" url?
<mwhudson> cjwatson, slangasek: https://code.launchpad.net/~mwhudson/merge-o-matic/oops/+merge/355485
<cjwatson> mwhudson: +1
 * mwhudson belatedly notices that i can actually push to trunk
<mwhudson> bdmurray: can you update the mom branch on shedu pls?
<mwhudson> cjwatson: unless you can do that too
<cjwatson> mwhudson: will do
<cjwatson> mwhudson: done
<mwhudson> cjwatson: after making my change i found the code in mom that was trying to handle permission bits already, so i have no idea (a) why that wasn't working already (b) if my change will help
<mwhudson> but well we'll see
<cjwatson> indeed
<mwhudson> oh
<mwhudson> i don't think merge_attr was run in the conflict case
<mwhudson> so that would be one thing
<xnox> mwhudson, https://launchpadlibrarian.net/389094029/buildlog_ubuntu-cosmic-amd64.gocryptfs_1.4.3-6_BUILDING.txt.gz
<xnox> mwhudson, is this the error?!
<xnox> # github.com/jacobsa/crypto/cmac
<xnox> src/github.com/jacobsa/crypto/cmac/hash.go:97:3: undefined: xorBlock
<Unit193> https://packages.qa.debian.org/g/gocryptfs/news/20180915T001910Z.html might otherwise help.
<Unit193> https://salsa.debian.org/blade/apt-cacher-ng/commit/e9f49ca951599c09f23973fc0d294b0c0e78d59a miiight be handy for Bionic users of apt-cacher-ng, though it only blocks the release upgrader, not actual updates.
<Unit193> (Or https://salsa.debian.org/blade/apt-cacher-ng/commit/72b9fa4fb51860dc48e827572941b47b49d0ffb4 really..)
<Kremator>  hello folks, i com here with a design question: i know canonical devs wanted to move away from sysV init system because it was serialized, that means each process could only be launched after the previous one fully started so my question is: if upstart (old ubuntu's init system) was already asynchronous why did you wanted to move to another init system?
<Kremator> was it the fact that systemd was actively developed and maintained by redhat so it would save you workload or similar? o were the features?
<Unit193> I'd say a big part of it was that when Debian finally moved away from sysvinit, they went with systemd.  As I'm sure you're aware, there's a lot shared with Ubuntu and Debain, so this would likely be an area that would keep diverging, adding more and more delta.
<Kremator> Unit193, well yeah, just rechecked with other people about the dates and yeah
<Kremator> debian jssie and ubuntu 15.04 coincide in release dates, so canonical could launch a sysd LTS a year later after testing it
<Kremator> Unit193, btw sir, is this your webpage? https://unit193.net/xubuntu/core/
<Unit193> Sort of, yeah.
<Kremator> what do you mean "sort of"?
<Kremator> btw thansk for your builds, i used to use the 17.04 of your site a lot and  upgraded it to 17.10 till had to rollback to 16.04 lts
<Unit193> Well, I guess nothing really.  It's my site/domain.
<Kremator> just try to keep it up online
<Unit193> Heh, I tend to get rid of ISOs once the next release happens, though there's always torrents.
<Kremator> not about that, but back when i used to use your builds, i remember your site going offline everyonce in a while :P
<bdmurray> seb128: I've seen that too and its not clear to me what is going on but I'll look into it.
<seb128> bdmurray, thx
<bdmurray> seb128: the bugs do get opened on launchpad.net though
<seb128> right, I ended up at the right place, it's just confusing
<seb128> bdmurray, it seems to do it for any new bug until you refresh the page then it's fine
<bdmurray> seb128: Its not terrible but still curious
<seb128> right
<bdmurray> seb128: Have you seen bug 1743216?
<ubottu> bug 1743216 in xdg-utils (Ubuntu) "perl crashed with SIGABRT in _dbus_abort()" [High,Confirmed] https://launchpad.net/bugs/1743216
<seb128> bdmurray, yes, it's a weird one, I had a look but it's nothing obvious
<seb128> Laney, you wouldn't have a clue about this one would you?
<bdmurray> It looked like something in xdg-screensaver to me
<Laney> nope
<Laney> dunno what that is
<Laney> rls tagging would be the right route to get it considered to be looked at by our team imho (rather than assigning it)
<bdmurray> Laney: okay, noted
<sarnold> https://codesearch.debian.net/search?q=named_window_id
<Laney> thanks
<Laney> (sarnold should feel free to fix it :-))
<sarnold> :D
<doko> coreycb, mwhudson: http://people.canonical.com/~ubuntu-archive/transitions/html/python3.7-only.html
<mwhudson> coreycb: http://people.canonical.com/~ubuntu-archive/transitions/html/python3.7-add.html
<mwhudson> coreycb: https://docs.google.com/document/d/1sdXd-IklDzdta6KvIhoqiOJP6OdILjPE7b_mrGqKwHQ/edit#
#ubuntu-devel 2018-09-22
<bigon> mmmh
<bigon> I'm doing an update (the laptop of my mother) from 16.04 to 18.04 with update-manager
<bigon> and one of the maintainer script of systemd-shim fails when trying to remove it
<bigon> (that doesn't sound good as systemd-sysv will not be installed and system might not boot)
#ubuntu-devel 2019-09-16
<Odd_Bloke> Unit193: barrier> I think it can wait, it's a pretty specific case.
<Unit193> https://launchpad.net/ubuntu/+source/barrier/2.3.1+dfsg-1ubuntu1
<rcj> tjaalton: Would you be able to promote livecd-rootfs from -proposed in disco?
<tjaalton> rcj: done
<rcj> tjaalton: With that unblocked, do you have time for the livecd-rootfs uploades for bug #1837254 d/b/x releases.
<ubottu> bug 1837254 in livecd-rootfs (Ubuntu Disco) "ubuntu-cpc parallel builds produce unused files" [Undecided,New] https://launchpad.net/bugs/1837254
<tjaalton> rcj: sure
<rcj> tjaalton: thank you
<robert_ancell> bdmurray, is https://people.canonical.com/~ubuntu-archive/phased-updates.html broken?
<bdmurray> robert_ancell: I believe so
<Eickmeyer> cyphermox: Thanks for the update!
<ddstreet> Laney not sure if you're still around, but do you know of any ongoing problems with armhf autopkgtest testbeds having trouble accessing ftpmaster.internal?  Tests for that arch seem to intermittently fail, just wondering if it was something being worked on
#ubuntu-devel 2019-09-17
<pieq> Morning!
<cpaelzer> doko: I doubt that you had a chance to look at bug 1843394 while travelling
<ubottu> bug 1843394 in ipxe (Ubuntu) "FTBFS in Eoan - Error: operand type mismatch for `push' - gcc 9.2.1 / binutils 2.32.51.20190905-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1843394
<cpaelzer> doko: but if you'd have a some time for me to visit after you fully arrived here let me know
<cpaelzer> I'd appreciate having at least someone (that is somewhat happy with assembly) to talk about this issue
<cpaelzer> I have relaized we have a team sync later today, we might sit together a bit after the actual session is done if we had no chance before that
<Laney> ddstreet: yes, it's a long standing problem but we've never managed to understand it or catch it happening :(
<Laney> a while ago with StÃ©phane we fixed up all the settings we could find but it didn't solve the problem
<robert_ancell> RAOF, I have a bunch of gnome-software SRUs - could you help get them out of the queue?
<RAOF> Sure, after my current thing
<robert_ancell> RAOF, thanks
<RAOF> cjwatson: So, curious findings in the "why does mir now fail to build on 16.04" hunt. It doesn't seem to be a kernel bug (the xenial release kernel fails in the same way)
<RAOF> cjwatson: The most recent successful build was 2019-08-30, so quite recently.
<cjwatson> Have you tried diffing successful/failing build logs to look for build-dep differences?
<RAOF> The initial part of the build shows some differences, the most suspicious of which is makedev.
<RAOF> (The changelog for which is "don't  populate /dev in a container")
<RAOF> However: That was uploaded in 2017!?
<cjwatson> Hm, we did get rid of makedev from the chroots IIRC?  Or maybe add it
<cjwatson> I remember noting that but thinking nothing could possibly care
<cjwatson> It could be that
<RAOF> It doesn't appear in the successful build from 2019-08-30, does in the failing builds. Has the chroot lost an apt pin or something?
<cjwatson> Can't look right now but I think that could be a lead
<cjwatson> We upgraded chroots in that window, switching from artisanally-crafted chroots to ones built by livecd-rootfs
<RAOF> Ooooh.
<RAOF> I'll try to run a build with makedev pinned.
<cjwatson> Pinning is a red herring
<cjwatson> It's not about version, it'll be about whether it's present or not
<cjwatson> I forget which right now, in the middle of a retro
<RAOF> Ok.
 * RAOF wonders how Launchpad has generated a diff from gnome-software 3.31.2-0ubuntu1, which as far as I can tell exists nowhere?
<cjwatson> RAOF: sure does, was in disco-proposed
<cjwatson> I guess it's maybe still the highest version
<cjwatson> (see https://launchpad.net/ubuntu/+source/gnome-software/+publishinghistory)
<RAOF> cjwatson: Aha! I was looking at the soruce page, which doesn't list that (because it was deleted)
<RAOF> It is unhelpful for launchpad to generated diffs against deleted uploads ð¬
<cjwatson> Right, so the xenial chroot change did in fact add makedev, on the grounds that it was Priority: required in xenial.
<cjwatson> Hmm.
<cjwatson> Apparently it was manually purged from the old chroots (I can see because they had /root/.bash_history in them ...)
<cjwatson> So uh I guess https://paste.ubuntu.com/p/QKGNWTNPqH/ ?
<cjwatson> https://code.launchpad.net/~cjwatson/livecd-rootfs/+git/livecd-rootfs/+merge/372869
<ddstreet> Laney re: autopkgtest-cloud mojo-juju-2 branch, was that the right branch you suggested i use?  it seems a bit better but still doesn't work
<Laney> doesn't work in what way?
<ddstreet> latest failure for me is because yaml in the unit can't find yaml.CSafeLoader
<ddstreet> seems the venv uses a different yaml than the packaged system one
<Laney> is that a failure from mojo or juju?
<ddstreet> the juju unit
<Laney> good news is I'm going to try to deploy that on the staging cloud this week
<Laney> so maybe I'll see that too and fix it
<ddstreet> well not juju unit, one of the deployed units
<Laney> fwiw the dependencies are in charms/bionic/autopkgtest-cloud-worker/layer.yaml
<ddstreet> yep i updated that already to include python3-pygit2 which was missing, and python3-yaml, but even with python3-yaml installed it doesn't have the CSafeLoader as it seems it's not built correctly with cython and/or libyaml
<ddstreet> anyway
<ddstreet> Laney so there is no branch that currently is known to work to deploy it?
<Laney> I mean the one I gave you is known to work to deploy for me and juliank
<Laney> sorry that it's not working for you, but it is not known that it doesn't as far as I'm concerned
<ddstreet> well, for production you mean?
<ddstreet> or it works for you for devel?
<Laney> like I say hopefully I'll get to it this week
<Laney> the goal is to re-deploy autopkgtest.ubuntu.com with this new spec
<juliank> Laney: I was wondering if we wanted to schedule something / get together for doing the staging deploy
<Laney> currently it is using what's in master, but I wouldn't say that is very advisable for you to try to deploy
<Laney> juliank: yeah, later on in the week sounds good
<Laney> we should go sit near an IS person to do that ð
<ddstreet> that's strange that it works for both of you but not when i try :(  i suppose it doesn't make much sense for me to open MR for anything i fix, since it works for you already?
<juliank> Laney: +1
<Laney> missing dependencies would be good to add, sure
<Laney> perhaps something moved on in bionic in the meantime and we'd see if it we tried again now
<ddstreet> ok
<juliank> I did deploy from an eoan host fwiw
<Laney> shouldn't matter if it's a hook error from inside one of the units
<juliank> yaml.CSafeLoader exists in both eoan and bionic
<ddstreet> juliank yeah, but not with python3-yaml inside the unit's venv :(
<Laney> what venv?
<Laney> wait, is it one that juju itself is using?
<ddstreet> charm vevn
<Laney> none of those on our side I don't think
<Laney> welllllll, probably more efficient for us to try this ourselves
<Laney> thanks for raising it
<ddstreet> yeah
<ddstreet> sure
<ddstreet> np
 * juliank certainly hasn't tried it this month :D
<ddstreet> btw not sure if you're using canonistack (i assume not) but it's having trouble on some archs currently
<juliank> Laney: _now_ I just got the notification from your first sentence where you highlighted me
<juliank> super odd
<Laney> O_O
<juliank> It's being pushed from weechat to pushbullet to google to chrome
<juliank> and well, the phone
<RAOF> robert_ancell: Enjoy your gnome-software.
<robert_ancell> om nom. So tasty.
<rbasak> ahasenack: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940582
<ubottu> Debian bug 940582 in default-libmysqlclient-dev "default-libmysqlclient-dev attempting to install libmariadbclient-dev 10.1.38 -- Getting 404 Error" [Normal,Open]
<rbasak> Wrong bug, sorry
<rbasak> ahasenack: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1429285
<ubottu> Launchpad bug 1429285 in apt (Ubuntu) "feature request: apt-get update --if-necessary" [Undecided,Confirmed]
#ubuntu-devel 2019-09-18
<seb128> hum, are we out of builders?
<cjwatson> Just a big pile of Lubuntu CI builds really
<cjwatson> Should clear up soon enough
<seb128> k, thx
<cpaelzer_> bryce: https://code.launchpad.net/~kstenerud/ubuntu/+source/php7.2/+git/php7.2/+merge/364746
<bdmurray> cyphermox: Can we close this out? https://bugs.launchpad.net/ubuntu/+source/gssdp/+bug/1799977
<ubottu> Launchpad bug 1799977 in gssdp (Ubuntu) "[MIR] gssdp" [Undecided,New]
<cyphermox> da
<infinity> dannf: Do you have context on LP: #1842284 (or can you poke ike for me)?
<ubottu> Launchpad bug 1842284 in initramfs-tools (Ubuntu Xenial) "initramfs does not copy ehci-platform" [Undecided,New] https://launchpad.net/bugs/1842284
<dannf> infinity: yes, and yes - asked him to join
<dannf> infinity: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1842284/comments/3
<ubottu> Launchpad bug 1842284 in initramfs-tools (Ubuntu Xenial) "initramfs does not copy ehci-platform" [Undecided,In progress]
<infinity> dannf: Ah-ha.  Fair enough.
<coreycb> rbasak: hi, if you have a chance would you be able to take a look at accepting keystone into disco-updates for bug 1832265 ?
<ubottu> bug 1832265 in OpenStack Identity (keystone) "py3: inconsistent encoding of token fields" [Undecided,In progress] https://launchpad.net/bugs/1832265
<rbasak> coreycb: I'm not sure it's going to happen today, but I will if I get a moment.
<coreycb> rbasak: thanks. that's blocking another SRU that's getting heat in bootstack.
<coreycb> edsousa: i think you want to run:  juju run-action ceilometer/0 ceilometer-upgrade
<coreycb> edsousa: sorry wrong channel
<LocutusOfBorg> <7lidy
<cpaelzer_> doko: FYI I filed the assembly issue at https://sourceware.org/bugzilla/show_bug.cgi?id=25012
<ubottu> sourceware.org bug 25012 in gas "pushq/popq %gs/%fs in .code64 now unsupported" [Normal,Unconfirmed]
#ubuntu-devel 2019-09-19
<dupondje> https://launchpad.net/ubuntu/+source/iwd
<dupondje> Might be nice to sync 0.21 from sid? Or ? :)
<bdmurray> tkamppeter: Given your last comment in bug 1721839 can we close that bug?
<ubottu> bug 1721839 in systemd (Ubuntu) "[REGRESSION] Services asked for by UDEV do not get triggered" [Low,Incomplete] https://launchpad.net/bugs/1721839
<mwhudson> please can an aa (hi vorlon) enable bugs on https://bugs.launchpad.net/ubuntu-archive-scripts
<vorlon> mwhudson: why did launchpad suggest tsimonq2 as a bug supervisor
<vorlon> (done)
<sarnold> he subscribes to everything, no? :)
<mwhudson> vorlon: nfi
<mwhudson> vorlon: thanks
<mwhudson> rbasak: https://bugs.launchpad.net/ubuntu-archive-scripts now useful
<rbasak> Thanks!
<rbasak> mwhudson: https://bugs.launchpad.net/ubuntu-archive-scripts/+bug/1844638 - thanks!
<ubottu> Launchpad bug 1844638 in ubuntu-archive-scripts "Difficult to create a bug from the by-team excuses page" [Undecided,New]
<mwhudson> rbasak: ta
<rbasak> cyphermox: chdist-if-migrated: http://paste.ubuntu.com/p/xrkzv4FPm4/
<cyphermox> rbasak: thanks
<dupondje> LocutusOfBorg: hehe :) thx for iwd
<coreycb> sil2100: hello, if you have a chance would you be able to take a look at accepting keystone into disco-updates for bug 1832265 ?
<ubottu> bug 1832265 in keystone (Ubuntu Disco) "py3: inconsistent encoding of token fields" [High,Fix committed] https://launchpad.net/bugs/1832265
<rbasak> cpaelzer_: https://salsa.debian.org/php-team/php/blob/master-7.4/debian/control.in
<rbasak> https://git.launchpad.net/ubuntu/+source/byobu/tree/debian/source_byobu.py?h=ubuntu/eoan-devel
<Laney> ddstreet: https://git.launchpad.net/autopkgtest-cloud/commit/?id=4944ef344e5977396aa3fa193116976e7069e29d
<Laney> we got your problem and fixed it with that
<ddstreet> Laney yep i dont actually think you need python3-yaml in the basic section (i didn't), all i did was include_system_packages in the MR i opened yesterday
<ddstreet> since fnordahl switched the default for it recently (wonder if that will cause other juju users problems?)
<ddstreet> Laney you also need to install libjs-jquery as i added to the readme in my MR
<Laney> didn't see that MR yet, sorry
<ddstreet> np
<Laney> did you get it working with that?
<Laney> working enough anyway
<ddstreet> yep
<Laney> cool
<ddstreet> well, it doesn't support https, but working well enough with http
<Laney> yeah
<Laney> we'll get a DNS name shortly and so I can make that work
<ddstreet> yeah that's no big deal for devel work, http is fine
<ddstreet> i deployed it in canonistack but wow, it sure does create a lot of instances, more than my limits :)  i'll have to deploy into a private cloud instead
<Laney> CLOUD!
<ddstreet> lol
<Laney> you can reduce the number of apache2 units, and probably even get rid of the haproxy if you don't want it
<ddstreet> thnx very much for the help so far! :)
<mfo> looking to recreate the launchpad's livecd.ubuntu-base.rootfs.tar.gz  with livecd-rootfs, but hitting a few errors.  anyone w/ working steps/pointers about the env vars?   I've been using PROJECT=ubuntu-base SUBPROJECT=buildd ARCH=amd64 MIRROR=http://archive.ubuntu.com/ubuntu SUITE=xenial /usr/share/livecd-rootfs/live-build/auto/{clean,config,build}  but apparently it copies nothing into binary/  and a binary hook fails later on. thanks!
#ubuntu-devel 2019-09-20
<rbasak> Skuggen: o/
<Unit193> I like how they all ping out at once. :D
<rbasak> Meet thedac who is looking into using mysql-shell around OpenStack
<rbasak> He's excited about the snap I think you just published?
<thedac> Hey, Skuggen.
<Skuggen> o/
<thedac> I'll test out your snap today
<Skuggen> Yeah, I made a fairly trivial one. Since shell is a fairly straightforward client app it doesn't need to be all that complex, but one issue is that it can't access the socket file right now (except in devmode)
<Skuggen> And should probably have a mysqlsh alias, since that's the standard command
<rbasak> I'll leave you two to it now that you're connected. Thank you for working on all of this!
<rbasak> Let me know if you need anything please.
 * rbasak goes to lunch
<Skuggen> rbasak: Np!
<thedac> Skuggen: I'll see if there is a local socket plugin for snapcraft.
<thedac> And I'll get back to you after I get a chance to test with your version of the snap. Is there a github repo for the snapcraft.yaml that I might be able to contirbute to?
<Skuggen> Do you know if there's any general file access plugins? The efforts to make a MySQL server snap some time ago stranded because I couldn't get it to work right on a system level
<Skuggen> We do have a repo for the old server snap (which I might look into getting updated), but don't have the shell yaml uploaded there now
<thedac> Not off the top of my head, but I'll get back to you. --classic is always a mid step. That gives you normal access to the file system.
<thedac> OK, I should be able to get back to you in a couple of hours
<Skuggen> https://paste.ubuntu.com/p/DPvjT43DWY/ is all there is to the yaml right now :)
<Skuggen> Ok, sounds good!
<thedac> Perfect. Thanks. Talk to you soon.
<rbasak> xnox: I don't understand your git-ubuntu bug request.
<rbasak> xnox: maybe while you're here we can chat in person?
<rbasak> The three people around this table think you're asking for three different things.
<xnox> rbasak:  hahahhaha
<xnox> rbasak:  where?
<rbasak> xnox: we're in the server room
<xnox> ok
<thedac> Skuggen: I am running out of day (we are cutting out early)
<thedac> I have tested your snap and it seems to be working. We both derived the exact same solution with one exception. I had the following for the apps section w
<thedac> hich allows for the msyqlsh command and network access: https://pastebin.ubuntu.com/p/SN8B78bG3
<thedac> Regarding local sockets. Here is some hints on running the server:
<thedac> https://snapcraft.io/docs/snapcraft-yaml-reference
<thedac> Search for apps.<app-name>.socket
<thedac> And by using the common area both the server and the client can find the socket in strict confinement:
<thedac> https://forum.snapcraft.io/t/sharing-a-unix-domain-socket-between-a-daemon-and-an-app/12332
<thedac> Ultimately, my goal for the mysql-shell snap is to build it for multiple architectures, which requires compiling from source. If you have any hints on com
<thedac> piling the shell let me know.
<thedac> I will ping you next week when I have more info. Feel free to DM me an email address and we can work to get this it great shape.
<thedac> Skuggen: That link was broken. This is correct: https://pastebin.ubuntu.com/p/SN8B78bG39/
<Skuggen> Ah, yeah will need network access of course
<Skuggen> Building from source would be better, yeah. It shouldn't be all that complicated, but will need to check the exact dependencies. I'll take a look at adding the socket support and getting that working, plus setting this up in git
<Skuggen> Also, we only test upstream for amd64, i386 and arm64 builds, so possible we'll run into some issues with other archs
<thedac> OK, good to know. Sounds like a plan. I'll touch base next week.
<LocutusOfBorg> Unit193, your fix in http://launchpadlibrarian.net/335155209/bzr-fastimport_0.13.0+bzr361-1_0.13.0+bzr361-1ubuntu1.diff.gz will disappear post eoan...
<LocutusOfBorg> do you have any idea?
<Unit193> LocutusOfBorg: So I saw, at least that brz didn't have the fix.  I'm just presuming nobody cares about bzr/brz enough at this point, a lot of Ubuntu stuff moved to git.
<cjwatson> Unit193: jelmer is being pretty active in maintaining brz.  Did you ever send the patch their way?  Might be worth a resend if so.
<cjwatson> (fastimport has always been pretty hairy of course ...)
<Unit193> cjwatson: The patch was picked out of three bug reports, I did create a MR back in '15 which he commented on though.
<cjwatson> Just saying that what I'm seeing at the moment doesn't suggest that a presumption of nobody caring is valid.
<Unit193> Fair, perhaps fastimport is somewhat neglected instead.
<jelmer> Unit193: we do care about fastimport bugs in breezy; I'm not aware of any open merge requests or bug reports related to it
<Unit193> jelmer: There's not one in brz, just an old one in bzr.  Good to know!  I haven't used brz (yet), but I don't use bzr much.
#ubuntu-devel 2019-09-22
<Unit193> LocutusOfBorg: -ext-pack was removed from eoan?
<Unit193> ...And not vbox itself?
<Unit193> LocutusOfBorg: On a slightly different note, have you heard of Debian fasttrack?
<LocutusOfBorg> Unit193, sad day, I don't understand why vorlon did that
<LocutusOfBorg> I can't get it, it makes no sense to me
<LocutusOfBorg> it was in multiverse, license was clear
<LocutusOfBorg> PUEL notice before installation about the licensing
<LocutusOfBorg> meh vorlon ^^
<Unit193> LocutusOfBorg: And -fasttrack?
<LocutusOfBorg> Unit193, never heard
<LocutusOfBorg> oh I heard some people asking me to put vbox there
<Unit193> Seems very fitting!
<vorlon> LocutusOfBorg: well, see my response on the bug report.  The package was assuming a default of 'yes' to the EULA which is unacceptable.
<LocutusOfBorg> juliank, ^^ do you happen to understand why the debconf answer is working correctly on my system, and on all the systems (graphical, dpkg, apt apt-get and so on), but it doens't on ubuntu builders?
<LocutusOfBorg> https://salsa.debian.org/pkg-virtualbox-team/virtualbox-ext-pack/blob/master/debian/templates
<LocutusOfBorg> I presume, when no input is detected the window is not shown?
<juliank> I don't know
<juliank> I might have a better answer tomorrow, but my brain not usable right now.
<LocutusOfBorg> my brain too :) have a nice sleep
<LocutusOfBorg> got it, it was the default value
<LocutusOfBorg> if debconf can't detect input it assumes the default
